From owner-freebsd-net@FreeBSD.ORG Sun May 11 05:48:01 2008 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 095C4106567C; Sun, 11 May 2008 05:48:01 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id AE12B8FC0C; Sun, 11 May 2008 05:48:00 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 82A70B8BA; Sun, 11 May 2008 08:47:58 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id E091AB82C; Sun, 11 May 2008 08:47:44 +0300 (EEST) Message-ID: <48268881.4070504@samoylyk.sumy.ua> Date: Sun, 11 May 2008 08:47:45 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> <4825D4EE.2060006@samoylyk.sumy.ua> <4825DA46.1090400@FreeBSD.org> In-Reply-To: <4825DA46.1090400@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 11 May 2008 05:48:01 -0000 Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Alexander Motin wrote: >>> Oleksandr Samoylyk wrote: >>>> It's "upper". And I don't know why :( >>>> The sources were updated before building new kernel on May, 5, 2008. >>>> The mpd5 port was rebuilt and restarted just few hours ago. >>> >>> Have you updated your world also? >> >> No, just kernel. Should I? > > In my experience it is sane to keep kernel and the world in sync. Even > if binary compatibility is declared inside the same branch, there could > be some minorities like this one. Also it may be hard for developers to > track all possible kernel/world combinations. > >>> Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from >>> /usr/include/netgraph/ng_pptpgre.h at the build time to detect this >>> feature presence. >> >> # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: >> * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 >> imp Exp $ > > HEAD: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.10 2008/03/24 22:55:22 > mav Exp $ > RELENG_7: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 > 08:01:26 mav Exp $ > RELENG_6: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.2.1 2008/04/07 10:33:28 > mav Exp $ > Thanks for the tip! I got it working. Let's see if the load changes. # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 08:01:26 mav Exp $ # ngctl show mpd5909-L-1-lt: Name: mpd5909-L-1-lt Type: tee ID: 00000256 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right mpd5909-B-1 ppp 00000267 link0 left pptpgre 00000258 session_6492 # grep "PPTP: can't connect to" mpd5 Binary file mpd5 matches -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 11 09:21:39 2008 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 86B181065671 for ; Sun, 11 May 2008 09:21:39 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 425C48FC27 for ; Sun, 11 May 2008 09:21:39 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id E33CD5C64; Sun, 11 May 2008 13:21:37 +0400 (MSD) Date: Sun, 11 May 2008 13:20:46 +0400 From: Igor Sysoev To: Julian Elischer Message-ID: <20080511092046.GC79358@rambler-co.ru> References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> <48176C65.4080600@gtcomm.net> <481772C7.8090300@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <481772C7.8090300@elischer.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Net Subject: Re: Multiple routing tables in action... 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, 11 May 2008 09:21:39 -0000 On Tue, Apr 29, 2008 at 12:11:03PM -0700, Julian Elischer wrote: > >Then you can export RIB entries , say > >you have 5 BGP peers and you want to export 2 or 3 or all of them into > >the 'main' routing instance you can set up a policy to add those learned > >routes into the main instance and v-v. > >Linux behaves a little bit differently as you have to make an 'ip rule' > >entry for it but it doesn't use the firewall. > > for now this code asks you to use a firewall to classify incoming > packets.. > > e.g. > 100 setfib 2 ip from any to any in recv em0 Is is possible to extend ifconfig to classify incoming packets ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Sun May 11 09:42:13 2008 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 5C285106566C for ; Sun, 11 May 2008 09:42:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 42D8A8FC1A for ; Sun, 11 May 2008 09:42:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 11 May 2008 15:55:21 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 8178E2D600D; Sun, 11 May 2008 02:42:12 -0700 (PDT) Message-ID: <4826BF74.3030204@elischer.org> Date: Sun, 11 May 2008 02:42:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Igor Sysoev References: <48134DDE.9010306@elischer.org> <20080429084032.GW71371@stlux503.dsto.defence.gov.au> <48175793.30606@elischer.org> <48175B91.1010202@gtcomm.net> <481766A2.7040809@elischer.org> <48176C65.4080600@gtcomm.net> <481772C7.8090300@elischer.org> <20080511092046.GC79358@rambler-co.ru> In-Reply-To: <20080511092046.GC79358@rambler-co.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Multiple routing tables in action... 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, 11 May 2008 09:42:13 -0000 Igor Sysoev wrote: > On Tue, Apr 29, 2008 at 12:11:03PM -0700, Julian Elischer wrote: > >>> Then you can export RIB entries , say >>> you have 5 BGP peers and you want to export 2 or 3 or all of them into >>> the 'main' routing instance you can set up a policy to add those learned >>> routes into the main instance and v-v. >>> Linux behaves a little bit differently as you have to make an 'ip rule' >>> entry for it but it doesn't use the firewall. >> for now this code asks you to use a firewall to classify incoming >> packets.. >> >> e.g. >> 100 setfib 2 ip from any to any in recv em0 > > Is is possible to extend ifconfig to classify incoming packets ? > > You could assign a default fib for all packets received by an interface and that is on my list of things to look at doing later. In the meantime you can use ipfw and pf to assign fibs to incoming packets depending on the receive interface. From owner-freebsd-net@FreeBSD.ORG Sun May 11 13:18:12 2008 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 644DE106566B for ; Sun, 11 May 2008 13:18:12 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from sepehrs.com (www.sepehrs.com [213.217.59.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8BCBB8FC2C for ; Sun, 11 May 2008 13:18:10 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from [192.168.1.180] ([192.168.1.180]) by sepehrs.com (8.13.6/8.13.6) with ESMTP id m4BGLFvd057719; Sun, 11 May 2008 16:21:16 GMT (envelope-from fazaeli@sepehrs.com) Message-ID: <4826EB42.104@sepehrs.com> Date: Sun, 11 May 2008 17:19:06 +0430 From: "H.fazaeli" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Jay L. T. Cornwall" References: <4825EF8D.1050304@jcornwall.me.uk> In-Reply-To: <4825EF8D.1050304@jcornwall.me.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sepehr-MailScanner-Information: Please contact the ISP for more information X-Sepehr-MailScanner: Found to be clean X-Sepehr-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.921, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, DATE_IN_PAST_03_06 0.48) X-MailScanner-From: fazaeli@sepehrs.com X-Spam-Status: No Cc: freebsd-net@freebsd.org Subject: Re: if_bridge with two subnets 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, 11 May 2008 13:18:12 -0000 The bridge works as it should: It receives packets from XX.XX.XXX.YYY on the interface connected to the switch, and forwards them on the interface connected to the gateway. The problem is that forwarding between subnets is the responsibility of your switch. The switch does its job, but since the two clients are not on the same IP subnet, they can not reach each other w/o the help of an intermediate router. Jay L. T. Cornwall wrote: > Hi, > > I have an if_bridge, thus: > > bridge0: flags=8843 metric 0 > mtu 1500 > inet XX.XX.XXX.20 netmask 0xfffffff8 broadcast XX.XX.XXX.23 > inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255 > > On one side of the bridge is a layer 2 switch with clients of a mix of > addresses from these two subnets. On the other side is a gateway > XX.XX.XXX.22. All clients can communicate through the gateway > correctly, with the 192.168.1.x subnet being NAT'd. > > However, clients from one subnet cannot communicate with clients from > the other subnet. Pinging a 192.168.1.X machine from the other subnet > shows the packet incorrectly routed out through the gateway, not back > through the interface it came. > > The routing table shows that both subnets should be routed through the > bridge: > > XX.XX.XXX.XX/29 link#5 UC 0 0 bridge > 192.168.1.0/24 link#5 UC 0 0 bridge > > The bridge host itself can ping machines on both subnets. So why is > the if_bridge routing packets destined for the private subnet out > through the default route instead? > > (The specific hosts being pinged are present in the routing table from > ARP lookups. They are all destined for the bridge interface.) > -- With best regards. Hooman Fazaeli Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From owner-freebsd-net@FreeBSD.ORG Sun May 11 19:52:14 2008 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 E17A01065670 for ; Sun, 11 May 2008 19:52:14 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from vps1.jcornwall.me.uk (vps1.jcornwall.me.uk [193.227.111.74]) by mx1.freebsd.org (Postfix) with ESMTP id AC32C8FC13 for ; Sun, 11 May 2008 19:52:14 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from [82.70.152.17] (cobra.home.jcornwall.me.uk [82.70.152.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vps1.jcornwall.me.uk (Postfix) with ESMTP id C2FC95201CF; Sun, 11 May 2008 20:54:05 +0100 (BST) Message-ID: <48274E6D.9060704@jcornwall.me.uk> Date: Sun, 11 May 2008 20:52:13 +0100 From: "Jay L. T. Cornwall" User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: "H.fazaeli" References: <4825EF8D.1050304@jcornwall.me.uk> <4826EB42.104@sepehrs.com> In-Reply-To: <4826EB42.104@sepehrs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: if_bridge with two subnets 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, 11 May 2008 19:52:15 -0000 H.fazaeli wrote: > The bridge works as it should: It receives packets from > XX.XX.XXX.YYY on the interface connected to the switch, and > forwards them on the interface connected to the gateway. > > The problem is that forwarding between subnets is the responsibility > of your switch. The switch does its job, but since the two clients are > not on the same IP subnet, they can not reach each other w/o the help of > an intermediate router. Perhaps I am mixing up two separate networking concepts. On a machine configured to act as a gateway, I would expect a single interface with more than one subnet to route packets correctly across those subnets. That may not be how it works in practice. If it does not work, I would question why not. If it does work then I would expect the same behaviour on each of a bridge's constituent interfaces? -- Jay L. T. Cornwall http://www.jcornwall.me.uk/ From owner-freebsd-net@FreeBSD.ORG Sun May 11 21:59:08 2008 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 A1619106566B; Sun, 11 May 2008 21:59:08 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE238FC19; Sun, 11 May 2008 21:59:08 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4BLx8oR057475; Sun, 11 May 2008 21:59:08 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4BLx8s9057471; Sun, 11 May 2008 21:59:08 GMT (envelope-from vwe) Date: Sun, 11 May 2008 21:59:08 GMT Message-Id: <200805112159.m4BLx8s9057471@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: bin/123465: [ip6] route(1): route add -inet6 -interface gif0 -proxy mangle ipv6 address 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, 11 May 2008 21:59:08 -0000 Synopsis: [ip6] route(1): route add -inet6 -interface gif0 -proxy mangle ipv6 address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun May 11 21:58:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123465 From owner-freebsd-net@FreeBSD.ORG Sun May 11 23:51:33 2008 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 7288B106564A; Sun, 11 May 2008 23:51:33 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7E48FC16; Sun, 11 May 2008 23:51:33 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4BNpXwc067454; Sun, 11 May 2008 23:51:33 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4BNpXhJ067450; Sun, 11 May 2008 23:51:33 GMT (envelope-from vwe) Date: Sun, 11 May 2008 23:51:33 GMT Message-Id: <200805112351.m4BNpXhJ067450@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/123160: [ip] Panic and reboot at sysctl kern.polling.enable=0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2008 23:51:33 -0000 Old Synopsis: Panic and reboot at sysctl kern.polling.enable=0 New Synopsis: [ip] Panic and reboot at sysctl kern.polling.enable=0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun May 11 23:50:18 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123160 From owner-freebsd-net@FreeBSD.ORG Mon May 12 06:44:05 2008 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 BBD4B1065672 for ; Mon, 12 May 2008 06:44:05 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from gtcomm.net (web.gtcomm.net [72.10.164.67]) by mx1.freebsd.org (Postfix) with ESMTP id 655698FC23 for ; Mon, 12 May 2008 06:44:05 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from [192.168.1.7] (c-76-108-179-28.hsd1.fl.comcast.net [76.108.179.28]) by gtcomm.net (8.12.20/8.12.10) with ESMTP id m4C6hfZN028036 for ; Mon, 12 May 2008 03:43:41 -0300 Message-ID: <4827E79C.8050608@gtcomm.net> Date: Mon, 12 May 2008 02:45:48 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Discrepancy on netstat -w x -I and what Cisco reports 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, 12 May 2008 06:44:05 -0000 This is very strange.. I can do: netstat -w 10 -I lagg0 input (lagg0) output packets errs bytes packets errs bytes colls 57806 0 41751685 232442 0 51062425 0 56459 0 38341591 225146 0 48865209 0 60687 0 43552946 227987 0 52008241 0 which is roughly 23,000 pps and the Cisco switch reports 30 second input rate 44544000 bits/sec, 16198 packets/sec Another example: netstat -w 10 -I lagg0 input (lagg0) output packets errs bytes packets errs bytes colls 71111 0 52180947 89734 0 25304669 0 66847 0 49028588 81737 0 21614941 0 63530 0 43502418 83419 0 24599547 0 8,300 or so pps Cisco: 30 second input rate 19230000 bits/sec, 4594 packets/sec In some cases it's pretty close, cisco says 6500 and bsd says 7500.. but sometimes it is way off I even checked the em interfaces directly to see if it was a problem with the lagg interface code and they report weird issues, check below. Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue with the counters. It's two different Cisco switches and two fbsd machines that have the same kernel, etc. Maybe this is a side effect of setting my kernel HZ at 4000? Gets even worse like this: netstat -w 100 lagg0 input (Total) output packets errs bytes packets errs bytes colls 9229322 0 3337789024 9424932 0 3510341158 0 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports 2 minute input rate 44130000 bits/sec, 14892 packets/sec and even check this out: netstat -w 1 lagg0 input (Total) output packets errs bytes packets errs bytes colls 92481 0 31630795 94952 0 34193131 0 89078 0 32498082 91460 0 35094821 0 87540 0 34526292 89992 0 37159101 0 88987 0 32391984 91765 0 35394351 0 netstat -w 1 em0 input (Total) output packets errs bytes packets errs bytes colls 96802 0 39474036 99897 0 42814245 0 93277 0 37018533 95943 0 39860879 0 95916 0 37559076 99032 0 40739640 0 netstat -w 1 em1 input (Total) output packets errs bytes packets errs bytes colls 97102 0 38369949 99508 0 40841183 0 92321 0 35375169 94305 0 37384073 0 92225 0 33171455 94253 0 35209658 0 What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k and i KNOW it's not doing anywhere near.. cisco report 2 minute output rate 32928000 bits/sec, 5823 packets/sec Now all lagg interfaces are reporting netstat -w 1 lagg1 input (Total) output packets errs bytes packets errs bytes colls 89324 0 30824353 91518 0 32770482 0 85875 0 31924738 87813 0 33552137 0 84105 0 31176932 85666 0 32393051 0 83617 0 32175677 84871 0 33120271 0 90611 0 37313093 92403 0 38818721 0 lagg1 goes directly to another freebsd box and on the other freebsd box I do: netstat -w 1 -I lagg1 input (lagg1) output packets errs bytes packets errs bytes colls 45 0 3078 2213 0 1890198 0 48 0 3245 1958 0 1545642 0 43 0 3186 1975 0 1628916 0 43 0 2905 2169 0 1918250 0 46 0 3464 1859 0 1729764 0 46 0 3134 1873 0 1739662 0 and the other one netstat -w 1 lagg1 input (Total) output packets errs bytes packets errs bytes colls 92149 0 31706183 93523 0 32673138 0 89737 0 28119643 91323 0 28958816 0 Doing all these reports now seems to have the interfaces stuck at packets errs bytes packets errs bytes colls 96937 0 31749525 98551 0 32678863 0 85892 0 29411078 87233 0 30182355 0 90435 0 31628680 91620 0 32215244 0 87383 0 30616741 88278 0 31026608 0 every interface on the machine is reporting the same PPS and bytes.. lol :) So something is extremely fishy about the counters.. I'm going to try and update to -STABLE to see if it makes any difference. It's not just the lagg interface either because all the em's are showing it as well. This is using 4 port Intel Server PCI Express NIC ifstat seems to report correct usage in Kbps and seems to report correct packet count. Maybe it's just a netstat problem? I will see if stable fixes it. Also, feel free to make any comments on my config file for routing. FreeBSD 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 UPDATE.. Changed 1 router to stable: FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 amd64 Still see: 2 minute input rate 10463000 bits/sec, 2481 packets/sec 2 minute output rate 40075000 bits/sec, 6847 packets/sec and input (lagg0) output packets errs bytes packets errs bytes colls 6940 0 5172153 4841 0 1345660 0 5922 0 4252074 3963 0 1087205 0 6673 0 4982394 4116 0 1056933 0 6659 0 4467398 4140 0 1068919 0 7085 0 4692973 4777 0 1665109 0 7140 0 4654486 4713 0 1658303 0 7070 0 4558384 5078 0 1994666 0 6375 0 4575464 4037 0 1121385 0 6257 0 3932910 4321 0 1607862 0 6504 0 4345014 4370 0 1278819 0 Hmmmm.. em0: port 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci12 em0: Using MSI interrupt em0: Ethernet address: 00:15:17:5d:18:00 em0: [FILTER] em1: port 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 on pci12 em1: Using MSI interrupt em1: Ethernet address: 00:15:17:5d:18:01 em1: [FILTER] .......etc.. to em7 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 root@CR1.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.28-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4285833216 (4087 MB) avail memory = 4124545024 (3933 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 Kernel config file: (if you have any suggestions about the config let me know for faster routing speed) cpu HAMMER ident GENERIC #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler #options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options ADAPTIVE_GIANT # Giant mutex is adaptive. options NO_ADAPTIVE_MUTEXES ## options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options IPSEC ## for tcp md5 options TCP_SIGNATURE ##include support for RFC 2385 device crypto ## for md5 device cryptodev ## for md5 # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers device mfi # LSI MegaRAID SAS # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse ### OPTIONS options MP_WATCHDOG options DEVICE_POLLING device pf device pflog device pfsync device carp device vlan device gre device if_bridge device tun device lagg device stf #6to4 IPv6 over IPv4 encapsulation options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_CDNR options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options NETGRAPH options NETGRAPH_CISCO options NETGRAPH_FEC options NETGRAPH_ETHER Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 root@CR2.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.26-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4286042112 (4087 MB) avail memory = 4124753920 (3933 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 64-87 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci6: on pcib1 pcib2: at device 0.0 on pci6 pci7: on pcib2 pcib3: at device 0.0 on pci7 pci8: on pcib3 pcib4: at device 0.0 on pci8 pci9: on pcib4 bce0: mem 0xd6000000-0xd7ffffff irq 16 at device 0.0 on pci9 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:19:b9:cd:60:44 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW MSI ) pcib5: at device 1.0 on pci7 pci10: on pcib5 pcib6: at device 0.0 on pci10 pci11: on pcib6 pcib7: at device 0.0 on pci11 pci12: on pcib7 em0: port 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 on pci12 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:5d:2a:40 em1: port 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 on pci12 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:5d:2a:41 pcib8: at device 1.0 on pci11 pci13: on pcib8 em2: port 0xdce0-0xdcff mem 0xd5ce0000-0xd5cfffff,0xd5cc0000-0xd5cdffff irq 18 at device 0. lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:2a:40 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c lagg1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:28:62 inet netmask 0xfffffffc broadcast media: Ethernet autoselect status: active laggproto lacp laggport: em7 flags=1c laggport: em6 flags=1c lagg2: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:5d:28:60 media: Ethernet autoselect status: active laggproto lacp laggport: em5 flags=1c laggport: em4 flags=1c From owner-freebsd-net@FreeBSD.ORG Mon May 12 09:01:02 2008 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 855AB106567B for ; Mon, 12 May 2008 09:01:02 +0000 (UTC) (envelope-from dkramer@coverity.com) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6628F8FC22 for ; Mon, 12 May 2008 09:01:02 +0000 (UTC) (envelope-from dkramer@coverity.com) Received: from gwsout01.mbox.net (gwsout01.mbox.net [165.212.64.24]) by gateout01.mbox.net (Postfix) with ESMTP id 5F9A0411201 for ; Mon, 12 May 2008 08:49:51 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gwsout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID837meLixz5099Xo1; Mon, 12 May 2008 08:49:51 -0000 X-USANET-Source: 165.212.116.254 IN dkramer@coverity.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID837meLixz5099Xo1 Received: from [10.176.129.230] ([69.12.168.114]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 02:49:50 -0600 Message-ID: <482804BF.1090506@coverity.com> Date: Mon, 12 May 2008 01:50:07 -0700 From: David Kramer User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2008 08:49:51.0087 (UTC) FILETIME=[23F4A7F0:01C8B40D] Subject: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) 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, 12 May 2008 09:01:02 -0000 **IF this is the wrong list for this topic please let me know which list I should post network services issues to. I am relatively new to FreeBSD but have quite a bit of experience with NIS on Linux. I am currently working on connecting a FreeBSD 4.9 client connection to NIS server running on OpenBSD 3.9. The ypcat commands are working and I can see the passwd and group files, however when I attempt to login to the machine I keep getting SSHD Illegal User Errors. The type of behavior I am seeing would be common on a Linux machine that uses nssswitch.conf to state which objects to pass authentication through, but its missing the nis value for passwd: or group:. Looking through the FreeBSD website I see that nssswitch was introduced in FreeBSD 5.X. For previous versions of FreeBSD and NIS, are there any additional configurations that need to be done? Possibly with PAM? I have the following values in my /etc/rc.conf files: nisdomainname="myNISdomain" nis_client_enable="YES" I have followed the FreeBSD NIS/YP Handbook configuration to the T, and still get the illegal user authentication any insight would be greatly appreciated. Thanks much, DK -- David Kramer, RHCE Sr. Systems Engineer Coverity, Inc. From owner-freebsd-net@FreeBSD.ORG Mon May 12 09:19:36 2008 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 A6DC01065684 for ; Mon, 12 May 2008 09:19:36 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 76C568FC15 for ; Mon, 12 May 2008 09:19:35 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id EADF91B10EE0; Mon, 12 May 2008 11:19:33 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 027921B10EF8; Mon, 12 May 2008 11:19:20 +0200 (CEST) Message-ID: <48280B97.1020708@moneybookers.com> Date: Mon, 12 May 2008 12:19:19 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080503) MIME-Version: 1.0 To: Paul References: <4827E79C.8050608@gtcomm.net> In-Reply-To: <4827E79C.8050608@gtcomm.net> X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: Discrepancy on netstat -w x -I and what Cisco reports 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, 12 May 2008 09:19:36 -0000 Greetings, I just have a question: is "netstat -w 100 lagg0" a typo ? If you want to see the traffic only on single interface you should use -I I do not know if this is bug, but netstat -w 100 something_non_existing works on my bsd and just shows "Total" So may be from here comes the confusion. You think, that netstat count only traffic on lagg0, but it shows you the Total traffic? Paul wrote: > This is very strange.. I can do: > > netstat -w 10 -I lagg0 > input (lagg0) output > packets errs bytes packets errs bytes colls > 57806 0 41751685 232442 0 51062425 0 > 56459 0 38341591 225146 0 48865209 0 > 60687 0 43552946 227987 0 52008241 0 > > which is roughly 23,000 pps and the Cisco switch reports > 30 second input rate 44544000 bits/sec, 16198 packets/sec > > > Another example: > > netstat -w 10 -I lagg0 > input (lagg0) output > packets errs bytes packets errs bytes colls > 71111 0 52180947 89734 0 25304669 0 > 66847 0 49028588 81737 0 21614941 0 > 63530 0 43502418 83419 0 24599547 0 > > 8,300 or so pps > > Cisco: > 30 second input rate 19230000 bits/sec, 4594 packets/sec > > > In some cases it's pretty close, cisco says 6500 and bsd says 7500.. > but sometimes it is way off > I even checked the em interfaces directly to see if it was a problem > with the lagg interface code and they report weird issues, check below. > Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue > with the counters. > It's two different Cisco switches and two fbsd machines that have the > same kernel, etc. > > Maybe this is a side effect of setting my kernel HZ at 4000? > Gets even worse like this: > netstat -w 100 lagg0 > input (Total) output > packets errs bytes packets errs bytes colls > 9229322 0 3337789024 9424932 0 3510341158 0 > > 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports > 2 minute input rate 44130000 bits/sec, 14892 packets/sec Again this is Total not lagg0 > and even check this out: > > netstat -w 1 lagg0 > input *(Total) * output > packets errs bytes packets errs bytes colls > 92481 0 31630795 94952 0 34193131 0 > 89078 0 32498082 91460 0 35094821 0 > 87540 0 34526292 89992 0 37159101 0 > 88987 0 32391984 91765 0 35394351 0 > > > netstat -w 1 em0 > input *(Total) * output > packets errs bytes packets errs bytes colls > 96802 0 39474036 99897 0 42814245 0 > 93277 0 37018533 95943 0 39860879 0 > 95916 0 37559076 99032 0 40739640 0 > > netstat -w 1 em1 > input * (Total) * output > packets errs bytes packets errs bytes colls > 97102 0 38369949 99508 0 40841183 0 > 92321 0 35375169 94305 0 37384073 0 > 92225 0 33171455 94253 0 35209658 0 > > What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k > and i KNOW it's not doing anywhere near.. > cisco report > 2 minute output rate 32928000 bits/sec, 5823 packets/sec Again missing -I :) > > Now all lagg interfaces are reporting > netstat -w 1 lagg1 > input * (Total) * output > packets errs bytes packets errs bytes colls > 89324 0 30824353 91518 0 32770482 0 > 85875 0 31924738 87813 0 33552137 0 > 84105 0 31176932 85666 0 32393051 0 > 83617 0 32175677 84871 0 33120271 0 > 90611 0 37313093 92403 0 38818721 0 > > lagg1 goes directly to another freebsd box and on the other freebsd > box I do: > netstat -w 1 -I lagg1 > input (lagg1) output > packets errs bytes packets errs bytes colls > 45 0 3078 2213 0 1890198 0 > 48 0 3245 1958 0 1545642 0 > 43 0 3186 1975 0 1628916 0 > 43 0 2905 2169 0 1918250 0 > 46 0 3464 1859 0 1729764 0 > 46 0 3134 1873 0 1739662 0 > > and the other one > netstat -w 1 lagg1 > input * (Total)* output > packets errs bytes packets errs bytes colls > 92149 0 31706183 93523 0 32673138 0 > 89737 0 28119643 91323 0 28958816 0 > > > Doing all these reports now seems to have the interfaces stuck at > packets errs bytes packets errs bytes colls > 96937 0 31749525 98551 0 32678863 0 > 85892 0 29411078 87233 0 30182355 0 > 90435 0 31628680 91620 0 32215244 0 > 87383 0 30616741 88278 0 31026608 0 > > > every interface on the machine is reporting the same PPS and bytes.. > lol :) > > So something is extremely fishy about the counters.. I'm going to try > and update to -STABLE to see if it makes any difference. It's not > just the lagg interface either because all the em's are showing it as > well. > > This is using 4 port Intel Server PCI Express NIC > > ifstat seems to report correct usage in Kbps and seems to report > correct packet count. Maybe it's just a netstat problem? > > I will see if stable fixes it. Also, feel free to make any comments > on my config file for routing. > > FreeBSD 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 > EDT 2008 amd64 > > > UPDATE.. Changed 1 router to stable: > FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT > 2008 amd64 > > Still see: > 2 minute input rate 10463000 bits/sec, 2481 packets/sec > 2 minute output rate 40075000 bits/sec, 6847 packets/sec > > and > input (lagg0) output > packets errs bytes packets errs bytes colls > 6940 0 5172153 4841 0 1345660 0 > 5922 0 4252074 3963 0 1087205 0 > 6673 0 4982394 4116 0 1056933 0 > 6659 0 4467398 4140 0 1068919 0 > 7085 0 4692973 4777 0 1665109 0 > 7140 0 4654486 4713 0 1658303 0 > 7070 0 4558384 5078 0 1994666 0 > 6375 0 4575464 4037 0 1121385 0 > 6257 0 3932910 4321 0 1607862 0 > 6504 0 4345014 4370 0 1278819 0 > > > Hmmmm.. > > > > > em0: port > 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 > at device 0.0 on pci12 > em0: Using MSI interrupt > em0: Ethernet address: 00:15:17:5d:18:00 > em0: [FILTER] > em1: port > 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 > at device 0.1 on pci12 > em1: Using MSI interrupt > em1: Ethernet address: 00:15:17:5d:18:01 > em1: [FILTER] > .......etc.. to em7 > > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > root@CR1.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.28-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > Features=0xbfebfbff > > > Features2=0x4e3bd > > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4285833216 (4087 MB) > avail memory = 4124545024 (3933 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > > > > Kernel config file: (if you have any suggestions about the config let > me know for faster routing speed) > > cpu HAMMER > ident GENERIC > > #makeoptions DEBUG=-g # Build kernel with gdb(1) > debug symbols > > options SCHED_4BSD # 4BSD scheduler > #options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control > lists > options UFS_DIRHASH # Improve performance on big > directories > options UFS_GJOURNAL # Enable gjournal-based UFS > journaling > options MD_ROOT # MD is a potential root device > options NTFS # NT File System > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires > PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] > options COMPAT_IA32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options SCSI_DELAY=5000 # Delay (in ms) before probing > SCSI > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > #options ADAPTIVE_GIANT # Giant mutex is adaptive. > options NO_ADAPTIVE_MUTEXES ## > options STOP_NMI # Stop CPUS using NMI instead > of IPI > options AUDIT # Security event auditing > options IPSEC ## for tcp md5 > options TCP_SIGNATURE ##include support for RFC 2385 > device crypto ## for md5 > device cryptodev ## for md5 > > # Make an SMP-capable kernel by default > options SMP # Symmetric MultiProcessor Kernel > > # CPU frequency control > device cpufreq > > # Bus support. > device acpi > device pci > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and > SAF-TE) > > # RAID controllers > device mfi # LSI MegaRAID SAS > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device kbdmux # keyboard multiplexer > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > device uart # Generic UART driver > > # PCI Ethernet NICs. > device em # Intel PRO/1000 adapter Gigabit > Ethernet Card > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these > NICs! > device miibus > device bce # Broadcom BCM5706/BCM5708 Gigabit > Ethernet > > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device sl # Kernel SLIP > device ppp # Kernel PPP > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > device firmware # firmware assist module > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > device ugen # Generic > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device umass # Disks/Mass storage - Requires scbus > and da > device ums # Mouse > > ### OPTIONS > > > options MP_WATCHDOG > options DEVICE_POLLING > device pf > device pflog > device pfsync > device carp > device vlan > device gre > device if_bridge > device tun > device lagg > device stf #6to4 IPv6 over IPv4 encapsulation > > options ALTQ > options ALTQ_CBQ # Class Bases Queuing (CBQ) > options ALTQ_RED # Random Early Detection (RED) > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_CDNR > options ALTQ_PRIQ # Priority Queuing (PRIQ) > options ALTQ_NOPCC # Required for SMP build > > > > options NETGRAPH > options NETGRAPH_CISCO > options NETGRAPH_FEC > options NETGRAPH_ETHER > > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 > root@CR2.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.26-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > Features=0xbfebfbff > > > Features2=0x4e3bd > > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4286042112 (4087 MB) > avail memory = 4124753920 (3933 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 64-87 on motherboard > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff > on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci6: on pcib1 > pcib2: at device 0.0 on pci6 > pci7: on pcib2 > pcib3: at device 0.0 on pci7 > pci8: on pcib3 > pcib4: at device 0.0 on pci8 > pci9: on pcib4 > bce0: mem > 0xd6000000-0xd7ffffff irq 16 at device 0.0 on pci9 > miibus0: on bce0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bce0: Ethernet address: 00:19:b9:cd:60:44 > bce0: [ITHREAD] > bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W > (0x02090105); Flags( MFW MSI ) > pcib5: at device 1.0 on pci7 > pci10: on pcib5 > pcib6: at device 0.0 on pci10 > pci11: on pcib6 > pcib7: at device 0.0 on pci11 > pci12: on pcib7 > em0: port 0xece0-0xecff > mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 > on pci12 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:15:17:5d:2a:40 > em1: port 0xecc0-0xecdf > mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 > on pci12 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:15:17:5d:2a:41 > pcib8: at device 1.0 on pci11 > pci13: on pcib8 > em2: port 0xdce0-0xdcff > mem 0xd5ce0000-0xd5cfffff,0xd5cc0000-0xd5cdffff irq 18 at device 0. > > > lagg0: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:15:17:5d:2a:40 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em1 flags=1c > laggport: em0 flags=1c > > > lagg1: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:15:17:5d:28:62 > inet netmask 0xfffffffc broadcast > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em7 flags=1c > laggport: em6 flags=1c > > lagg2: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:15:17:5d:28:60 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: em5 flags=1c > laggport: em4 flags=1c > > > _______________________________________________ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Mon May 12 10:12:30 2008 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 8435F1065671 for ; Mon, 12 May 2008 10:12:30 +0000 (UTC) (envelope-from volker@thalreit.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBAE8FC17 for ; Mon, 12 May 2008 10:12:30 +0000 (UTC) (envelope-from volker@thalreit.de) Received: from thalreit.de (p5496FD19.dip.t-dialin.net [84.150.253.25]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1JvUot1QjR-0004dF; Mon, 12 May 2008 11:59:48 +0200 Received: from gemini.thalreit ([10.87.15.6]) by thalreit.de with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1JvUp1-0006Hw-FE; Mon, 12 May 2008 11:59:55 +0200 Message-ID: <48281511.6000003@thalreit.de> Date: Mon, 12 May 2008 11:59:45 +0200 From: Volker Jahns User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Kramer References: <482804BF.1090506@coverity.com> In-Reply-To: <482804BF.1090506@coverity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/Walpy+sBOp3FJGVVQOEadsqgTY896SITJBbT NTkI9DeI9ZXd1HKWWcX5cVHKbVi+7uMc4+ZZsH9skmsxlGYetr E/sB3O2CNFNL0pZFxG22g== Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) 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, 12 May 2008 10:12:30 -0000 David Kramer schrieb: > I am currently working on connecting a FreeBSD 4.9 client connection > to NIS server running on OpenBSD 3.9. The ypcat commands are working > and I can see the passwd and group files, however when I attempt to > login to the machine I keep getting SSHD Illegal User Errors. As a first guess I would recommend: - check /etc/hosts.allow (ssh access control used by FreeBSD) - shadow support - rpcinfo -p works OK? - run ypserv daemon in foregound, check its output -- Volker Jahns, volker@thalreit.de From owner-freebsd-net@FreeBSD.ORG Mon May 12 11:02:20 2008 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 96B35106564A for ; Mon, 12 May 2008 11:02:20 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 54F408FC16 for ; Mon, 12 May 2008 11:02:20 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7dfe.q.ppp-pool.de [89.53.125.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 0FCC412883F for ; Mon, 12 May 2008 12:36:14 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id C5BB73F439 for ; Mon, 12 May 2008 12:38:53 +0200 (CEST) Message-ID: <48281D8F.2090501@vwsoft.com> Date: Mon, 12 May 2008 12:35:59 +0200 From: Volker User-Agent: Thunderbird 2.0.0.14 (X11/20080503) MIME-Version: 1.0 To: net@freebsd.org X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1211193543.1864@/CFIk2UlJzZHglojyzIAsg X-MailScanner-ID: C5BB73F439.810A7 X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Subject: how to identify a PHY? 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, 12 May 2008 11:02:20 -0000 Hi! >From the bugbusting front, I'm often seeing network related issues with unknown (new) PHYs. Can please somebody explain me how one is able to identify what kind of PHY interface is build into a system? Does pciconf output provide some piece of information which leads into getting PHY information? I need to know that to work with the submitter and get their interfaces running (or retrieve information for you to work on). Thanks! Volker From owner-freebsd-net@FreeBSD.ORG Mon May 12 11:07:02 2008 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 826F410656E1 for ; Mon, 12 May 2008 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB858FC13 for ; Mon, 12 May 2008 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4CB72SM038089 for ; Mon, 12 May 2008 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4CB71pE038085 for freebsd-net@FreeBSD.org; Mon, 12 May 2008 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 May 2008 11:07:01 GMT Message-Id: <200805121107.m4CB71pE038085@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, 12 May 2008 11:07:02 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123123 net [re][patch] Realtek RTL8111C detection and failure o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(1): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre 74 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123053 net [re][patch] re(4) unsupported hardware revision (8168/ o kern/123147 net [ti] [patch] ti(4) doesn't use mii, but kernel configs 45 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 12 11:37:27 2008 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 E6E70106566C for ; Mon, 12 May 2008 11:37:27 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 088978FC16 for ; Mon, 12 May 2008 11:37:26 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.1/8.14.1/ALCHEMY.FRANKEN.DE) with ESMTP id m4CBJwMO095717; Mon, 12 May 2008 13:19:58 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.1/8.14.1/Submit) id m4CBJwCm095716; Mon, 12 May 2008 13:19:58 +0200 (CEST) (envelope-from marius) Date: Mon, 12 May 2008 13:19:58 +0200 From: Marius Strobl To: Volker Message-ID: <20080512111958.GA95632@alchemy.franken.de> References: <48281D8F.2090501@vwsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48281D8F.2090501@vwsoft.com> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: how to identify a PHY? 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, 12 May 2008 11:37:28 -0000 On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: > Hi! > > >From the bugbusting front, I'm often seeing network related issues with > unknown (new) PHYs. > > Can please somebody explain me how one is able to identify what kind of > PHY interface is build into a system? Does pciconf output provide some > piece of information which leads into getting PHY information? I need to > know that to work with the submitter and get their interfaces running > (or retrieve information for you to work on). > If the system is running the simplest thing in order to identifiy the PHYs is to check the oui= and model= output of `devinfo -v`. Otherwise boot verbose and check the OUI and model output of ukphy(4). Marius From owner-freebsd-net@FreeBSD.ORG Mon May 12 11:47:17 2008 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 D11F01065672 for ; Mon, 12 May 2008 11:47:17 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id A09B38FC1B for ; Mon, 12 May 2008 11:47:16 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.14.2/8.14.2) with ESMTP id m4CB7DnW021604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 May 2008 14:07:19 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <482824E2.4000403@aws-net.org.ua> Date: Mon, 12 May 2008 14:07:14 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Kramer References: <482804BF.1090506@coverity.com> In-Reply-To: <482804BF.1090506@coverity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.0 (alf.aws-net.org.ua [192.168.32.61]); Mon, 12 May 2008 14:07:20 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) 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, 12 May 2008 11:47:17 -0000 David Kramer wrote: > **IF this is the wrong list for this topic please let me know which list > I should post network services issues to. > > I am relatively new to FreeBSD but have quite a bit of experience with > NIS on Linux. I am currently working on connecting a FreeBSD 4.9 client > connection to NIS server running on OpenBSD 3.9. The ypcat commands are > working and I can see the passwd and group files, however when I attempt > to login to the machine I keep getting SSHD Illegal User Errors. The > type of behavior I am seeing would be common on a Linux machine that > uses nssswitch.conf to state which objects to pass authentication > through, but its missing the nis value for passwd: or group:. Looking > through the FreeBSD website I see that nssswitch was introduced in > FreeBSD 5.X. For previous versions of FreeBSD and NIS, are there any > additional configurations that need to be done? Possibly with PAM? I > have the following values in my /etc/rc.conf files: Have you added special records to /etc/group and /etc/master.passwd files? It should be +::: in /etc/group and +::::::::: in /etc/master.passwd. Use vipw to edit password file. > > nisdomainname="myNISdomain" > nis_client_enable="YES" > > I have followed the FreeBSD NIS/YP Handbook configuration to the T, and > still get the illegal user authentication any insight would be greatly > appreciated. > > Thanks much, > > DK > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | ================================ FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Mon May 12 11:55:53 2008 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 04218106566C for ; Mon, 12 May 2008 11:55:53 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 91E8F8FC0A for ; Mon, 12 May 2008 11:55:51 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7dfe.q.ppp-pool.de [89.53.125.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 71A8A12881E; Mon, 12 May 2008 13:55:44 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id F075A3F439; Mon, 12 May 2008 13:58:28 +0200 (CEST) Message-ID: <48283036.8060602@vwsoft.com> Date: Mon, 12 May 2008 13:55:34 +0200 From: Volker User-Agent: Thunderbird 2.0.0.14 (X11/20080503) MIME-Version: 1.0 To: Marius Strobl References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> In-Reply-To: <20080512111958.GA95632@alchemy.franken.de> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1211198313.9915@RNe5nR70vnWx+QveYjAeog X-MailScanner-ID: F075A3F439.57A4E X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: net@freebsd.org Subject: Re: how to identify a PHY? 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, 12 May 2008 11:55:53 -0000 On 05/12/08 13:19, Marius Strobl wrote: > On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: >> Hi! >> >> >From the bugbusting front, I'm often seeing network related issues with >> unknown (new) PHYs. >> >> Can please somebody explain me how one is able to identify what kind of >> PHY interface is build into a system? Does pciconf output provide some >> piece of information which leads into getting PHY information? I need to >> know that to work with the submitter and get their interfaces running >> (or retrieve information for you to work on). >> > > If the system is running the simplest thing in order to identifiy > the PHYs is to check the oui= and model= output of `devinfo -v`. > Otherwise boot verbose and check the OUI and model output of > ukphy(4). Marius, thanks for your answer. As far as I understand, the devinfo output will only contain useful information if a driver attaches to the phy. Sometimes a new mainboard hits the market and the ID of the phy's chip is unknown the FreeBSD. If a submitter files a PR and no phy driver attaches, I would like to check if the chip ID is currently known to the system. So I need to know a way to check the ID of a chip without a driver being attached. In short my original question better reads as "how do I know the kind of phy if no driver has been attached". Can one retrieve that information out of a verbose boot dmesg (from probing messages)? I would like to first check if a PR might be related to a phy problem at all and if it's just coming with an ID currently unknown to FreeBSD to prepare the PR into a state containing every piece of information needed to have the net-team working easily on it. Thanks Volker From owner-freebsd-net@FreeBSD.ORG Mon May 12 12:01:24 2008 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 F269D1065672 for ; Mon, 12 May 2008 12:01:24 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id ABAF48FC1C for ; Mon, 12 May 2008 12:01:24 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7dfe.q.ppp-pool.de [89.53.125.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id B6A8C12881E; Mon, 12 May 2008 14:01:16 +0200 (CEST) Received: from cesar.sz.vwsoft.com (unknown [192.168.18.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 990963F4C2; Mon, 12 May 2008 14:03:55 +0200 (CEST) Message-ID: <4828317C.4000807@vwsoft.com> Date: Mon, 12 May 2008 14:01:00 +0200 From: Volker User-Agent: Thunderbird 2.0.0.14 (X11/20080503) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> <48282DEE.9090502@FreeBSD.org> In-Reply-To: <48282DEE.9090502@FreeBSD.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1211198644.40328@/cPOx5xspM4iapngq1MdzA X-MailScanner-ID: 990963F4C2.6799C X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Marius Strobl , net@freebsd.org Subject: Re: how to identify a PHY? 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, 12 May 2008 12:01:25 -0000 On 05/12/08 13:45, Bruce M. Simpson wrote: > Marius Strobl wrote: >> If the system is running the simplest thing in order to identifiy >> the PHYs is to check the oui= and model= output of `devinfo -v`. >> Otherwise boot verbose and check the OUI and model output of ukphy(4). >> > > There's a project for someone in there I'm sure. > > Linux has mii-tool and mii-diag. Whilst we generally don't need all of > the knobs, sometimes it can be useful to dump and poke PHY registers on > the MII. src/sys/dev/mii/miibus_if.m contains the newbus interface > definition for miibus which would be a place to start. Bruce, am I correct assuming there's currently no easy way to get that information? Thanks Volker From owner-freebsd-net@FreeBSD.ORG Mon May 12 12:02:37 2008 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 A2A6B1065676 for ; Mon, 12 May 2008 12:02:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7A77D8FC23 for ; Mon, 12 May 2008 12:02:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6DA54108552; Mon, 12 May 2008 07:45:52 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 12 May 2008 07:45:52 -0400 X-Sasl-enc: Q9NeweJ9BKkJa2W3U7xQdyt7tQDmv2JLuujihtMyyxus 1210592751 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1B29720D87; Mon, 12 May 2008 07:45:51 -0400 (EDT) Message-ID: <48282DEE.9090502@FreeBSD.org> Date: Mon, 12 May 2008 12:45:50 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: net@freebsd.org References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> In-Reply-To: <20080512111958.GA95632@alchemy.franken.de> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Volker , Marius Strobl Subject: Re: how to identify a PHY? 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, 12 May 2008 12:02:37 -0000 Marius Strobl wrote: > If the system is running the simplest thing in order to identifiy > the PHYs is to check the oui= and model= output of `devinfo -v`. > Otherwise boot verbose and check the OUI and model output of > ukphy(4). > There's a project for someone in there I'm sure. Linux has mii-tool and mii-diag. Whilst we generally don't need all of the knobs, sometimes it can be useful to dump and poke PHY registers on the MII. src/sys/dev/mii/miibus_if.m contains the newbus interface definition for miibus which would be a place to start. cheers BMS From owner-freebsd-net@FreeBSD.ORG Mon May 12 12:07:53 2008 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 58BD9106564A for ; Mon, 12 May 2008 12:07:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB4B8FC1C for ; Mon, 12 May 2008 12:07:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id CABD9108372; Mon, 12 May 2008 08:07:52 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 12 May 2008 08:07:52 -0400 X-Sasl-enc: uJVrlmLmigE7uBV7IAIoSvieU25H8cBpywE+WevWG5sa 1210594072 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CF84ED379; Mon, 12 May 2008 08:07:51 -0400 (EDT) Message-ID: <48283316.2080100@FreeBSD.org> Date: Mon, 12 May 2008 13:07:50 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: Volker References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> <48283036.8060602@vwsoft.com> In-Reply-To: <48283036.8060602@vwsoft.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org, Marius Strobl Subject: Re: how to identify a PHY? 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, 12 May 2008 12:07:53 -0000 Volker wrote: > ... > In short my original question better reads as "how do I know the kind of > phy if no driver has been attached". Can one retrieve that information > out of a verbose boot dmesg (from probing messages)? > You can't determine which PHY is in use unless a driver is attached, because it's necessary to attach a driver in order to access the card's MII registers. Same with any other OS. If no PHY driver attached, but a NIC driver attached, you should see this message: device_printf(dev, "MII without any PHY!\n"); It sounds like someone needs to instrument the code path mii_phy_probe() to print useful information in the situation you describe. cheers BMS From owner-freebsd-net@FreeBSD.ORG Mon May 12 12:10:43 2008 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 5504D106564A for ; Mon, 12 May 2008 12:10:43 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C6F628FC1F for ; Mon, 12 May 2008 12:10:42 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.1/8.14.1/ALCHEMY.FRANKEN.DE) with ESMTP id m4CCAfdN096352; Mon, 12 May 2008 14:10:41 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.1/8.14.1/Submit) id m4CCAfxT096351; Mon, 12 May 2008 14:10:41 +0200 (CEST) (envelope-from marius) Date: Mon, 12 May 2008 14:10:41 +0200 From: Marius Strobl To: Volker Message-ID: <20080512121041.GD36894@alchemy.franken.de> References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> <48283036.8060602@vwsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48283036.8060602@vwsoft.com> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: how to identify a PHY? 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, 12 May 2008 12:10:43 -0000 On Mon, May 12, 2008 at 01:55:34PM +0200, Volker wrote: > On 05/12/08 13:19, Marius Strobl wrote: > > On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote: > >> Hi! > >> > >> >From the bugbusting front, I'm often seeing network related issues with > >> unknown (new) PHYs. > >> > >> Can please somebody explain me how one is able to identify what kind of > >> PHY interface is build into a system? Does pciconf output provide some > >> piece of information which leads into getting PHY information? I need to > >> know that to work with the submitter and get their interfaces running > >> (or retrieve information for you to work on). > >> > > > > If the system is running the simplest thing in order to identifiy > > the PHYs is to check the oui= and model= output of `devinfo -v`. > > Otherwise boot verbose and check the OUI and model output of > > ukphy(4). > > Marius, > > thanks for your answer. As far as I understand, the devinfo output will > only contain useful information if a driver attaches to the phy. > Sometimes a new mainboard hits the market and the ID of the phy's chip > is unknown the FreeBSD. > > If a submitter files a PR and no phy driver attaches, I would like to > check if the chip ID is currently known to the system. So I need to know > a way to check the ID of a chip without a driver being attached. > > In short my original question better reads as "how do I know the kind of > phy if no driver has been attached". Can one retrieve that information > out of a verbose boot dmesg (from probing messages)? > > I would like to first check if a PR might be related to a phy problem at > all and if it's just coming with an ID currently unknown to FreeBSD to > prepare the PR into a state containing every piece of information needed > to have the net-team working easily on it. > For NIC drivers interfacing with miibus(4) the ukphy(4) driver always matches as a last resort. If even ukphy(4) doesn't attach this means there's a more fundamental problem of some sort with the NIC driver communicating with the MII bus. In that case there's no way to identify which PHYs are on the MII bus (it even doesn't necessarily mean they are "unknown" to the system.) Marius From owner-freebsd-net@FreeBSD.ORG Mon May 12 13:14:22 2008 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 63EB8106566B for ; Mon, 12 May 2008 13:14:22 +0000 (UTC) (envelope-from slawek.zak@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 20AB78FC26 for ; Mon, 12 May 2008 13:14:21 +0000 (UTC) (envelope-from slawek.zak@gmail.com) Received: by an-out-0708.google.com with SMTP id b33so537549ana.13 for ; Mon, 12 May 2008 06:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=0VFcoGbFMl42KFoYUDNg4bivPpsB8ac6hN3X4Pf0YE8=; b=U36c/yu3WdGBvSJrsiSAhvJ43fRnG7dUDp5dP9mBU4hwsj9AqxZ75DLQLksc0SBWx9/KE/hK2gVIWNscc9lL6uxe0QJlrvCU1v8qR7NsVSK3CWW7G5dolFGFwWGJKPtufMX03hJ8ynfKjbehEdCJUI5P/Q2o/UbWg+4kkQP096I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NhKxz5EsYtz15osF1xmIt6TCS/dGSphp14YhbUMPVCGxTCw7I7NXbALgmbJa1HGS/tXiFSiM/Vai37T6w03u6E5PnursC2hT/R9rlXHAHxdf325sklkjlSFfvlU95lLViOh8aXcH+E2cBzQbXuvSZyiHbKHlelSSEFHdoBnmbFA= Received: by 10.100.214.3 with SMTP id m3mr8027456ang.81.1210596590767; Mon, 12 May 2008 05:49:50 -0700 (PDT) Received: by 10.100.213.17 with HTTP; Mon, 12 May 2008 05:49:50 -0700 (PDT) Message-ID: <787bbe1c0805120549m8d80979t3932d091608dbbfa@mail.gmail.com> Date: Mon, 12 May 2008 14:49:50 +0200 From: "Slawek Zak" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: PF NAT and IPSec (ESP) not working 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, 12 May 2008 13:14:22 -0000 Hi, I probably do something wrong, and I can't seem to get NAT in PF working with IPSec tunnel mode. Here's the network diagram: (172.16.0.0/16) internal network-- remote end of tunnel AA.AA.AA.AA --- XX.XX.XX.XX re0 (Internet) ----- enc (IPSec) ---- ZZ.ZZ.ZZ.ZZ gif1 --- tun0 --- YY.YY.YY.YY/24 OpenVPN clients I want OpenVPN clients to be NAT'ed to ZZ.ZZ.ZZ.ZZ and then enter the ipsec tunnel, be encrypted and land on the other side. When I've setup NAT using following PF rule: nat pass log on enc0 inet from YY.YY.YY.YY/24 to 172.16.0.0/16 -> ZZ.ZZ.ZZ.ZZ the packets go out on gif1 but are not encrypted (no traffic on enc0). Same for following NAT rule: nat pass log on enc0 inet from YY.YY.YY.YY/24 to 172.16.0.0/16 -> ZZ.ZZ.ZZ.ZZ Help, please! Thanks, /S From owner-freebsd-net@FreeBSD.ORG Mon May 12 13:58:01 2008 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 33CEA106564A for ; Mon, 12 May 2008 13:58:01 +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 9712B8FC2D for ; Mon, 12 May 2008 13:58:00 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 97372 invoked from network); 12 May 2008 12:58:53 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 May 2008 12:58:53 -0000 Message-ID: <48284CE7.2020707@freebsd.org> Date: Mon, 12 May 2008 15:57:59 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Tim Gebbett References: <4822BABB.4020407@freebsd.org> <4824211C.9090105@freebsd.org> <482561F3.6080701@gebbettco.com> In-Reply-To: <482561F3.6080701@gebbettco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Deng XueFeng , Mark Hills Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 12 May 2008 13:58:01 -0000 Tim Gebbett wrote: > Hi Andre, did some careful testing yesterday and last night. I seem to > be still hitting an unknown buffer although the probem is much alleviated. > The system achieved a 7hour run at 500mbit where ETIMEDOUT occured. I > was feeding 11 other streams to the server whos counters show an > uninterrupted eleven hours. The feeder streams are from the same source, > so it is unlikely that the one feeding the test could of had a problem > without affecting the counters of the others. > sysctls are: > > (loader.conf) hw.em.txd=4096 > net.inet.tcp.sendspace=78840 > net.inet.tcp.recvspace=78840 > > kern.ipc.nmbjumbop=51200 > kern.ipc.nmbclusters=78840 > kern.maxfiles=50000 > > IP stats are miraculously improved, going from a 10% packet loss within > stack (output drops) to a consistent zero at peaks of 80000 pps. I > believe the problem is now being shunted to the NIC from the following > output: > > dev.em.0.debug=1 > > < em0: Adapter hardware address = 0xc520b224 > > < em0: CTRL = 0x48f00249 RCTL = 0x8002 < em0: Packet buffer = Tx=16k > Rx=48k < em0: Flow control watermarks high = 47104 low = 45604 > < em0: tx_int_delay = 66, tx_abs_int_delay = 66 > < em0: rx_int_delay = 0, rx_abs_int_delay = 66 > < em0: fifo workaround = 0, fifo_reset_count = 0 > < em0: hw tdh = 3285, hw tdt = 3285 > < em0: hw rdh = 201, hw rdt = 200 > < em0: Num Tx descriptors avail = 4096 > < em0: Tx Descriptors not avail1 = 4591225 > < em0: Tx Descriptors not avail2 = 0 > < em0: Std mbuf failed = 0 > < em0: Std mbuf cluster failed = 0 > < em0: Driver dropped packets = 0 > < em0: Driver tx dma failure in encap = 0 > > dev.em.0.stats=1 > > < em0: Excessive collisions = 0 > > < em0: Sequence errors = 0 > < em0: Defer count = 0 > < em0: Missed Packets = 16581181 > < em0: Receive No Buffers = 74605555 > < em0: Receive Length Errors = 0 > < em0: Receive errors = 0 > < em0: Crc errors = 0 > < em0: Alignment errors = 0 > < em0: Collision/Carrier extension errors = 0 > < em0: RX overruns = 289717 > < em0: watchdog timeouts = 0 > < em0: XON Rcvd = 0 > < em0: XON Xmtd = 0 > < em0: XOFF Rcvd = 0 > < em0: XOFF Xmtd = 0 > < em0: Good Packets Rcvd = 848158221 > < em0: Good Packets Xmtd = 1080368640 > < em0: TSO Contexts Xmtd = 0 > < em0: TSO Contexts Failed = 0 > > > Does the counter 'Tx Descriptors not avail1' indicate lack of > decriptors at the time not available, and would this be symptomatic of > something Mark suggested: > "(the stack) needs to handle local buffer fills not as a failed attempt > on transmission that increments the retry counter, a possible better > strategy required for backoff > when the hardware buffer is full?" Indeed. We have rethink a couple of assumptions the code currently makes and has made for the longest time. Additionally the defaults for the network hardware need to be better tuned for workloads like yours. I'm on my way to BSDCan'08 soon and I will discuss these issues at the Developer Summit. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon May 12 15:33:02 2008 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 514251065672 for ; Mon, 12 May 2008 15:33:02 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from sepehrs.com (www.sepehrs.com [213.217.59.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5518FC17 for ; Mon, 12 May 2008 15:33:00 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from [192.168.1.180] ([192.168.1.180]) by sepehrs.com (8.13.6/8.13.6) with ESMTP id m4CIrBI8068051; Mon, 12 May 2008 18:53:11 GMT (envelope-from fazaeli@sepehrs.com) Message-ID: <48286052.6000507@sepehrs.com> Date: Mon, 12 May 2008 19:50:50 +0430 From: "H.fazaeli" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Jay L. T. Cornwall" References: <4825EF8D.1050304@jcornwall.me.uk> <4826EB42.104@sepehrs.com> <48274E6D.9060704@jcornwall.me.uk> In-Reply-To: <48274E6D.9060704@jcornwall.me.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sepehr-MailScanner-Information: Please contact the ISP for more information X-Sepehr-MailScanner: Found to be clean X-Sepehr-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.921, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, DATE_IN_PAST_03_06 0.48) X-MailScanner-From: fazaeli@sepehrs.com X-Spam-Status: No Cc: freebsd-net@freebsd.org Subject: Re: if_bridge with two subnets 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, 12 May 2008 15:33:02 -0000 Jay L. T. Cornwall wrote: > H.fazaeli wrote: > >> The bridge works as it should: It receives packets from >> XX.XX.XXX.YYY on the interface connected to the switch, and >> forwards them on the interface connected to the gateway. >> >> The problem is that forwarding between subnets is the responsibility >> of your switch. The switch does its job, but since the two clients are >> not on the same IP subnet, they can not reach each other w/o the help of >> an intermediate router. > > Perhaps I am mixing up two separate networking concepts. > > On a machine configured to act as a gateway, I would expect a single > interface with more than one subnet to route packets correctly across > those subnets. That may not be how it works in practice. > > If it does not work, I would question why not. If it does work then I > would expect the same behaviour on each of a bridge's constituent > interfaces? > It does work. However, if I understand your setup correctly, the freebsd box has been setup to act as a bridge, not as a router (routing is enabled with sysctl net.inet.ip.forwarding=1). Bridging works when the forwarding is between the same subnets. For freebsd box to route between subnets: - enable routing: sysctl net.inet.ip.forwarding=1 - clients must use the freebsd box as gateway. - IP addresses must be removed from the bridge and assigned to the member interfaces. (the bridge is no longer needed). You may have bridging & routing on the same box at the same time but note that a single packet coming into the system either goes through bridging _or_ routing code, but not both. The former case happens if packet's destination MAC address is not that of box. The latter case happens when destination MAC address is that of receiving interface. If you provide a network diagram along with your requirements, we can better discuss the matter. -- With best regards. Hooman Fazaeli Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 From owner-freebsd-net@FreeBSD.ORG Mon May 12 17:42:30 2008 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 F32651065686; Mon, 12 May 2008 17:42:29 +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 CD9368FC55; Mon, 12 May 2008 17:42:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4CHgTKM076340; Mon, 12 May 2008 17:42:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4CHgTT1076336; Mon, 12 May 2008 17:42:29 GMT (envelope-from linimon) Date: Mon, 12 May 2008 17:42:29 GMT Message-Id: <200805121742.m4CHgTT1076336@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123603: [tcp] tcp_do_segment and Received duplicate SYN 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, 12 May 2008 17:42:30 -0000 Old Synopsis: tcp_do_segment and Received duplicate SYN New Synopsis: [tcp] tcp_do_segment and Received duplicate SYN Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 12 17:42:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123603 From owner-freebsd-net@FreeBSD.ORG Mon May 12 18:50:07 2008 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 235D9106564A for ; Mon, 12 May 2008 18:50:07 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from gtcomm.net (web.gtcomm.net [72.10.164.67]) by mx1.freebsd.org (Postfix) with ESMTP id B38BE8FC14 for ; Mon, 12 May 2008 18:50:06 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from [192.168.1.7] (c-76-108-179-28.hsd1.fl.comcast.net [76.108.179.28]) by gtcomm.net (8.12.20/8.12.10) with ESMTP id m4CInlY4022249; Mon, 12 May 2008 15:49:47 -0300 Message-ID: <482891C7.1030603@gtcomm.net> Date: Mon, 12 May 2008 14:51:51 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Stefan Lambrev References: <4827E79C.8050608@gtcomm.net> <48280B97.1020708@moneybookers.com> In-Reply-To: <48280B97.1020708@moneybookers.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Discrepancy on netstat -w x -I and what Cisco reports 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, 12 May 2008 18:50:07 -0000 Yes it was a typo I meant -w -I It just doesn't add up to what the switch is seeing, and it's directly connected and the traffic can't be going anywhere else. Stefan Lambrev wrote: > Greetings, > > I just have a question: > > is "netstat -w 100 lagg0" a typo ? > > If you want to see the traffic only on single interface you should use -I > > I do not know if this is bug, but netstat -w 100 > something_non_existing works on my bsd and just shows "Total" > > So may be from here comes the confusion. You think, that netstat count > only traffic on lagg0, > but it shows you the Total traffic? > > Paul wrote: >> This is very strange.. I can do: >> >> netstat -w 10 -I lagg0 >> input (lagg0) output >> packets errs bytes packets errs bytes colls >> 57806 0 41751685 232442 0 51062425 0 >> 56459 0 38341591 225146 0 48865209 0 >> 60687 0 43552946 227987 0 52008241 0 >> >> which is roughly 23,000 pps and the Cisco switch reports >> 30 second input rate 44544000 bits/sec, 16198 packets/sec >> >> >> Another example: >> >> netstat -w 10 -I lagg0 >> input (lagg0) output >> packets errs bytes packets errs bytes colls >> 71111 0 52180947 89734 0 25304669 0 >> 66847 0 49028588 81737 0 21614941 0 >> 63530 0 43502418 83419 0 24599547 0 >> >> 8,300 or so pps >> >> Cisco: >> 30 second input rate 19230000 bits/sec, 4594 packets/sec >> >> >> In some cases it's pretty close, cisco says 6500 and bsd says 7500.. >> but sometimes it is way off >> I even checked the em interfaces directly to see if it was a problem >> with the lagg interface code and they report weird issues, check below. >> Kind of weird.. I'm not sure if this is a Cisco issue or Fbsd issue >> with the counters. >> It's two different Cisco switches and two fbsd machines that have the >> same kernel, etc. >> >> Maybe this is a side effect of setting my kernel HZ at 4000? >> Gets even worse like this: >> netstat -w 100 lagg0 >> input (Total) output >> packets errs bytes packets errs bytes colls >> 9229322 0 3337789024 9424932 0 3510341158 0 >> >> 100 seconds, 9.4 million packets? That's 94,000 pps and cisco reports >> 2 minute input rate 44130000 bits/sec, 14892 packets/sec > Again this is Total not lagg0 >> and even check this out: >> >> netstat -w 1 lagg0 >> input *(Total) * output >> packets errs bytes packets errs bytes colls >> 92481 0 31630795 94952 0 34193131 0 >> 89078 0 32498082 91460 0 35094821 0 >> 87540 0 34526292 89992 0 37159101 0 >> 88987 0 32391984 91765 0 35394351 0 >> >> >> netstat -w 1 em0 >> input *(Total) * output >> packets errs bytes packets errs bytes colls >> 96802 0 39474036 99897 0 42814245 0 >> 93277 0 37018533 95943 0 39860879 0 >> 95916 0 37559076 99032 0 40739640 0 >> >> netstat -w 1 em1 >> input * (Total) * output >> packets errs bytes packets errs bytes colls >> 97102 0 38369949 99508 0 40841183 0 >> 92321 0 35375169 94305 0 37384073 0 >> 92225 0 33171455 94253 0 35209658 0 >> >> What in the world?? em0 + em1 is almost 200k pps but lagg0 says 100k >> and i KNOW it's not doing anywhere near.. >> cisco report >> 2 minute output rate 32928000 bits/sec, 5823 packets/sec > Again missing -I :) >> >> Now all lagg interfaces are reporting >> netstat -w 1 lagg1 >> input * (Total) * output >> packets errs bytes packets errs bytes colls >> 89324 0 30824353 91518 0 32770482 0 >> 85875 0 31924738 87813 0 33552137 0 >> 84105 0 31176932 85666 0 32393051 0 >> 83617 0 32175677 84871 0 33120271 0 >> 90611 0 37313093 92403 0 38818721 0 >> >> lagg1 goes directly to another freebsd box and on the other freebsd >> box I do: >> netstat -w 1 -I lagg1 >> input (lagg1) output >> packets errs bytes packets errs bytes colls >> 45 0 3078 2213 0 1890198 0 >> 48 0 3245 1958 0 1545642 0 >> 43 0 3186 1975 0 1628916 0 >> 43 0 2905 2169 0 1918250 0 >> 46 0 3464 1859 0 1729764 0 >> 46 0 3134 1873 0 1739662 0 >> >> and the other one >> netstat -w 1 lagg1 >> input * (Total)* output >> packets errs bytes packets errs bytes colls >> 92149 0 31706183 93523 0 32673138 0 >> 89737 0 28119643 91323 0 28958816 0 >> >> >> Doing all these reports now seems to have the interfaces stuck at >> packets errs bytes packets errs bytes colls >> 96937 0 31749525 98551 0 32678863 0 >> 85892 0 29411078 87233 0 30182355 0 >> 90435 0 31628680 91620 0 32215244 0 >> 87383 0 30616741 88278 0 31026608 0 >> >> >> every interface on the machine is reporting the same PPS and bytes.. >> lol :) >> >> So something is extremely fishy about the counters.. I'm going to try >> and update to -STABLE to see if it makes any difference. It's not >> just the lagg interface either because all the em's are showing it as >> well. >> >> This is using 4 port Intel Server PCI Express NIC >> >> ifstat seems to report correct usage in Kbps and seems to report >> correct packet count. Maybe it's just a netstat problem? >> >> I will see if stable fixes it. Also, feel free to make any comments >> on my config file for routing. >> >> FreeBSD 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 >> 18:11:49 EDT 2008 amd64 >> >> >> UPDATE.. Changed 1 router to stable: >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT >> 2008 amd64 >> >> Still see: >> 2 minute input rate 10463000 bits/sec, 2481 packets/sec >> 2 minute output rate 40075000 bits/sec, 6847 packets/sec >> >> and >> input (lagg0) output >> packets errs bytes packets errs bytes colls >> 6940 0 5172153 4841 0 1345660 0 >> 5922 0 4252074 3963 0 1087205 0 >> 6673 0 4982394 4116 0 1056933 0 >> 6659 0 4467398 4140 0 1068919 0 >> 7085 0 4692973 4777 0 1665109 0 >> 7140 0 4654486 4713 0 1658303 0 >> 7070 0 4558384 5078 0 1994666 0 >> 6375 0 4575464 4037 0 1121385 0 >> 6257 0 3932910 4321 0 1607862 0 >> 6504 0 4345014 4370 0 1278819 0 >> >> >> Hmmmm.. >> >> >> >> >> em0: port >> 0xece0-0xecff mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 >> at device 0.0 on pci12 >> em0: Using MSI interrupt >> em0: Ethernet address: 00:15:17:5d:18:00 >> em0: [FILTER] >> em1: port >> 0xecc0-0xecdf mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 >> at device 0.1 on pci12 >> em1: Using MSI interrupt >> em1: Ethernet address: 00:15:17:5d:18:01 >> em1: [FILTER] >> .......etc.. to em7 >> >> >> Copyright (c) 1992-2008 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 >> root@CR1.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.28-MHz >> K8-class CPU) >> Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 >> >> Features=0xbfebfbff >> >> >> Features2=0x4e3bd >> >> AMD Features=0x20100800 >> AMD Features2=0x1 >> Cores per package: 2 >> usable memory = 4285833216 (4087 MB) >> avail memory = 4124545024 (3933 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 6 >> cpu3 (AP): APIC ID: 7 >> ioapic0: Changing APIC ID to 8 >> ioapic1: Changing APIC ID to 9 >> >> >> >> Kernel config file: (if you have any suggestions about the config let >> me know for faster routing speed) >> >> cpu HAMMER >> ident GENERIC >> >> #makeoptions DEBUG=-g # Build kernel with gdb(1) >> debug symbols >> >> options SCHED_4BSD # 4BSD scheduler >> #options PREEMPTION # Enable kernel thread >> preemption >> options INET # InterNETworking >> options INET6 # IPv6 communications protocols >> options FFS # Berkeley Fast Filesystem >> options SOFTUPDATES # Enable FFS soft updates >> support >> options UFS_ACL # Support for access control >> lists >> options UFS_DIRHASH # Improve performance on big >> directories >> options UFS_GJOURNAL # Enable gjournal-based UFS >> journaling >> options MD_ROOT # MD is a potential root device >> options NTFS # NT File System >> options MSDOSFS # MSDOS Filesystem >> options CD9660 # ISO 9660 Filesystem >> options PROCFS # Process filesystem >> (requires PSEUDOFS) >> options PSEUDOFS # Pseudo-filesystem framework >> options GEOM_PART_GPT # GUID Partition Tables. >> options GEOM_LABEL # Provides labelization >> options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP >> THIS!] >> options COMPAT_IA32 # Compatible with i386 binaries >> options COMPAT_FREEBSD4 # Compatible with FreeBSD4 >> options COMPAT_FREEBSD5 # Compatible with FreeBSD5 >> options COMPAT_FREEBSD6 # Compatible with FreeBSD6 >> options SCSI_DELAY=5000 # Delay (in ms) before >> probing SCSI >> options KTRACE # ktrace(1) support >> options SYSVSHM # SYSV-style shared memory >> options SYSVMSG # SYSV-style message queues >> options SYSVSEM # SYSV-style semaphores >> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B >> real-time extensions >> options KBD_INSTALL_CDEV # install a CDEV entry in /dev >> #options ADAPTIVE_GIANT # Giant mutex is adaptive. >> options NO_ADAPTIVE_MUTEXES ## >> options STOP_NMI # Stop CPUS using NMI instead >> of IPI >> options AUDIT # Security event auditing >> options IPSEC ## for tcp md5 >> options TCP_SIGNATURE ##include support for RFC 2385 >> device crypto ## for md5 >> device cryptodev ## for md5 >> >> # Make an SMP-capable kernel by default >> options SMP # Symmetric MultiProcessor >> Kernel >> >> # CPU frequency control >> device cpufreq >> >> # Bus support. >> device acpi >> device pci >> >> # Floppy drives >> device fdc >> >> # ATA and ATAPI devices >> device ata >> device atadisk # ATA disk drives >> device ataraid # ATA RAID drives >> device atapicd # ATAPI CDROM drives >> device atapifd # ATAPI floppy drives >> device atapist # ATAPI tape drives >> options ATA_STATIC_ID # Static device numbering >> >> # SCSI peripherals >> device scbus # SCSI bus (required for SCSI) >> device ch # SCSI media changers >> device da # Direct Access (disks) >> device sa # Sequential Access (tape etc) >> device cd # CD >> device pass # Passthrough device (direct SCSI >> access) >> device ses # SCSI Environmental Services (and >> SAF-TE) >> >> # RAID controllers >> device mfi # LSI MegaRAID SAS >> >> # atkbdc0 controls both the keyboard and the PS/2 mouse >> device atkbdc # AT keyboard controller >> device atkbd # AT keyboard >> device psm # PS/2 mouse >> >> device kbdmux # keyboard multiplexer >> >> device vga # VGA video card driver >> >> device splash # Splash screen and screen saver support >> >> # syscons is the default console driver, resembling an SCO console >> device sc >> >> device agp # support several AGP chipsets >> >> # Serial (COM) ports >> device sio # 8250, 16[45]50 based serial ports >> device uart # Generic UART driver >> >> # PCI Ethernet NICs. >> device em # Intel PRO/1000 adapter Gigabit >> Ethernet Card >> # PCI Ethernet NICs that use the common MII bus controller code. >> # NOTE: Be sure to keep the 'device miibus' line in order to use >> these NICs! >> device miibus >> device bce # Broadcom BCM5706/BCM5708 Gigabit >> Ethernet >> >> # Pseudo devices. >> device loop # Network loopback >> device random # Entropy device >> device ether # Ethernet support >> device sl # Kernel SLIP >> device ppp # Kernel PPP >> device tun # Packet tunnel. >> device pty # Pseudo-ttys (telnet etc) >> device md # Memory "disks" >> device gif # IPv6 and IPv4 tunneling >> device faith # IPv6-to-IPv4 relaying (translation) >> device firmware # firmware assist module >> >> # The `bpf' device enables the Berkeley Packet Filter. >> # Be aware of the administrative consequences of enabling this! >> # Note that 'bpf' is required for DHCP. >> device bpf # Berkeley packet filter >> >> # USB support >> device uhci # UHCI PCI->USB interface >> device ohci # OHCI PCI->USB interface >> device ehci # EHCI PCI->USB interface (USB 2.0) >> device usb # USB Bus (required) >> #device udbp # USB Double Bulk Pipe devices >> device ugen # Generic >> device uhid # "Human Interface Devices" >> device ukbd # Keyboard >> device umass # Disks/Mass storage - Requires scbus >> and da >> device ums # Mouse >> >> ### OPTIONS >> >> >> options MP_WATCHDOG >> options DEVICE_POLLING >> device pf >> device pflog >> device pfsync >> device carp >> device vlan >> device gre >> device if_bridge >> device tun >> device lagg >> device stf #6to4 IPv6 over IPv4 encapsulation >> >> options ALTQ >> options ALTQ_CBQ # Class Bases Queuing (CBQ) >> options ALTQ_RED # Random Early Detection (RED) >> options ALTQ_RIO # RED In/Out >> options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) >> options ALTQ_CDNR >> options ALTQ_PRIQ # Priority Queuing (PRIQ) >> options ALTQ_NOPCC # Required for SMP build >> >> >> >> options NETGRAPH >> options NETGRAPH_CISCO >> options NETGRAPH_FEC >> options NETGRAPH_ETHER >> >> >> >> >> >> Copyright (c) 1992-2008 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 >> root@CR2.MTL3.Gtcomm.net:/usr/obj/usr/src/sys/ROUTER >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2329.26-MHz >> K8-class CPU) >> Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 >> >> Features=0xbfebfbff >> >> >> Features2=0x4e3bd >> >> AMD Features=0x20100800 >> AMD Features2=0x1 >> Cores per package: 2 >> usable memory = 4286042112 (4087 MB) >> avail memory = 4124753920 (3933 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 6 >> cpu3 (AP): APIC ID: 7 >> ioapic0: Changing APIC ID to 8 >> ioapic1: Changing APIC ID to 9 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 64-87 on motherboard >> kbd1 at kbdmux0 >> cryptosoft0: on motherboard >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> acpi_hpet0: iomem 0xfed00000-0xfed003ff >> on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est1 attach returned 6 >> p4tcc1: on cpu1 >> cpu2: on acpi0 >> est2: on cpu2 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est2 attach returned 6 >> p4tcc2: on cpu2 >> cpu3: on acpi0 >> est3: on cpu3 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 728072806000728 >> device_attach: est3 attach returned 6 >> p4tcc3: on cpu3 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 2.0 on pci0 >> pci6: on pcib1 >> pcib2: at device 0.0 on pci6 >> pci7: on pcib2 >> pcib3: at device 0.0 on pci7 >> pci8: on pcib3 >> pcib4: at device 0.0 on pci8 >> pci9: on pcib4 >> bce0: mem >> 0xd6000000-0xd7ffffff irq 16 at device 0.0 on pci9 >> miibus0: on bce0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> bce0: Ethernet address: 00:19:b9:cd:60:44 >> bce0: [ITHREAD] >> bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W >> (0x02090105); Flags( MFW MSI ) >> pcib5: at device 1.0 on pci7 >> pci10: on pcib5 >> pcib6: at device 0.0 on pci10 >> pci11: on pcib6 >> pcib7: at device 0.0 on pci11 >> pci12: on pcib7 >> em0: port 0xece0-0xecff >> mem 0xd5ee0000-0xd5efffff,0xd5ec0000-0xd5edffff irq 17 at device 0.0 >> on pci12 >> em0: Using MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:15:17:5d:2a:40 >> em1: port 0xecc0-0xecdf >> mem 0xd5ea0000-0xd5ebffff,0xd5e80000-0xd5e9ffff irq 18 at device 0.1 >> on pci12 >> em1: Using MSI interrupt >> em1: [FILTER] >> em1: Ethernet address: 00:15:17:5d:2a:41 >> pcib8: at device 1.0 on pci11 >> pci13: on pcib8 >> em2: port 0xdce0-0xdcff >> mem 0xd5ce0000-0xd5cfffff,0xd5cc0000-0xd5cdffff irq 18 at device 0. >> >> >> lagg0: flags=8843 metric 0 >> mtu 1500 >> options=19b >> ether 00:15:17:5d:2a:40 >> media: Ethernet autoselect >> status: active >> laggproto lacp >> laggport: em1 flags=1c >> laggport: em0 flags=1c >> >> >> lagg1: flags=8843 metric 0 >> mtu 1500 >> options=19b >> ether 00:15:17:5d:28:62 >> inet netmask 0xfffffffc broadcast >> media: Ethernet autoselect >> status: active >> laggproto lacp >> laggport: em7 flags=1c >> laggport: em6 flags=1c >> >> lagg2: flags=8843 metric 0 >> mtu 1500 >> options=19b >> ether 00:15:17:5d:28:60 >> media: Ethernet autoselect >> status: active >> laggproto lacp >> laggport: em5 flags=1c >> laggport: em4 flags=1c >> >> >> _______________________________________________ >> 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" > > -- > > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > From owner-freebsd-net@FreeBSD.ORG Mon May 12 20:42:29 2008 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 549191065677 for ; Mon, 12 May 2008 20:42:29 +0000 (UTC) (envelope-from dkramer@coverity.com) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by mx1.freebsd.org (Postfix) with ESMTP id 23D398FC1B for ; Mon, 12 May 2008 20:42:29 +0000 (UTC) (envelope-from dkramer@coverity.com) Received: from gwsout01.mbox.net (gwsout01.mbox.net [165.212.64.24]) by gateout02.mbox.net (Postfix) with ESMTP id 8CE33720213; Mon, 12 May 2008 20:42:28 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gwsout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID007meLuQC5484Xo1; Mon, 12 May 2008 20:42:28 -0000 X-USANET-Source: 165.212.116.254 IN dkramer@coverity.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID007meLuQC5484Xo1 Received: from [10.0.252.227] ([38.99.3.113]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 14:42:28 -0600 Message-ID: <4828ABC5.60201@coverity.com> Date: Mon, 12 May 2008 13:42:45 -0700 From: David Kramer User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Volker Jahns References: <482804BF.1090506@coverity.com> <48281511.6000003@thalreit.de> In-Reply-To: <48281511.6000003@thalreit.de> X-OriginalArrivalTime: 12 May 2008 20:42:28.0198 (UTC) FILETIME=[B12E0860:01C8B470] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.9 - NIS Authentication Problem (SSHD Illegal User ERROR) 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, 12 May 2008 20:42:29 -0000 Thank you all for your responses, I have solved my issue. I needed to have Bash installed and setup for the shell to mount properly when the authentication happens. A symbolic link took care of it. Thanks much, DK Volker Jahns wrote: > > David Kramer schrieb: > > I am currently working on connecting a FreeBSD 4.9 client connection > > to NIS server running on OpenBSD 3.9. The ypcat commands are working > > and I can see the passwd and group files, however when I attempt to > > login to the machine I keep getting SSHD Illegal User Errors. > As a first guess I would recommend: > - check /etc/hosts.allow (ssh access control used by FreeBSD) > - shadow support > - rpcinfo -p works OK? > - run ypserv daemon in foregound, check its output > > -- > Volker Jahns, volker@thalreit.de > > -- David Kramer, RHCE Sr. Systems Engineer Coverity, Inc. dkramer@coverity.com o. 415.694.5315 c. 650.302.7889 bb. 415.646.6320 Yahooo: Pollucts AIM: PolluctsXXX From owner-freebsd-net@FreeBSD.ORG Mon May 12 22:43:59 2008 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 9DF491065671; Mon, 12 May 2008 22:43:59 +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 7626F8FC12; Mon, 12 May 2008 22:43:59 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4CMhxAg002786; Mon, 12 May 2008 22:43:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4CMhx3b002782; Mon, 12 May 2008 22:43:59 GMT (envelope-from linimon) Date: Mon, 12 May 2008 22:43:59 GMT Message-Id: <200805122243.m4CMhx3b002782@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123617: [tcp] breaking connection when client downloading files from server 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, 12 May 2008 22:43:59 -0000 Old Synopsis: breaking connection when client downloading files from server New Synopsis: [tcp] breaking connection when client downloading files from server Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 12 22:43:35 UTC 2008 Responsible-Changed-Why: Over to maintainer(s), although I supposed this could also be an re(4) problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=123617 From owner-freebsd-net@FreeBSD.ORG Tue May 13 14:38:02 2008 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 7F123106566B for ; Tue, 13 May 2008 14:38:02 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 470F48FC18 for ; Tue, 13 May 2008 14:38:01 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id DA3E82218A7F; Wed, 14 May 2008 00:38:00 +1000 (EST) X-Viruscan-Id: <4829A7C800004EB4ACB2AF@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 9A65F21B2CCF; Wed, 14 May 2008 00:38:00 +1000 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 10D462218A77; Wed, 14 May 2008 00:38:00 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id A62B87C9; Wed, 14 May 2008 00:37:58 +1000 (EST) Date: Wed, 14 May 2008 00:37:58 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org Message-ID: <20080513143758.GA3041@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> <48215D08.5050500@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48215D08.5050500@incunabulum.net> User-Agent: Mutt/1.4.2.3i Cc: "Bruce M. Simpson" , Julian Elischer Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 13 May 2008 14:38:02 -0000 On Wed, May 07, 2008 at 08:40:56AM +0100, Bruce M. Simpson wrote: > Julian Elischer wrote: > >actually the divert sockets should really not be in PF_INET > >they could deliver both inet and inet6 packets. > >the sockaddr that they return (and which needs to be read for divert > >to make sense) could be used to distinguish between them. > > Good point. I'd forgotten that they were abusing the fields in sin_zero. > This is not OK for IPv6, although the kludge can still be perpetuated by > looking at sa_len and stashing what divert wants at the end of sockaddr_in6. > > So there IS a case for making them a separate protocol family if > someone's going to do a clean implementation of divert sockets for IPv6. I have it more or less working! See my "FreeBSD IPv6 Divert socket adventures" at http://www.mavetju.org/weblog/html/00231.html (1) http://www.mavetju.org/weblog/html/00232.html (2) http://www.mavetju.org/weblog/html/00233.html (3) It contains links to patches for FreeBSD 6.3 and the nat6to4d.c. Please read the disclaimer in the second last paragraph of the 3rd article about the rough edges on it. I'm very keen on getting help from somebody to check it and to polish it up once I'm happy with it. For example with regarding to the "inpcb" things which I have absolutely no idea about what they are or what they do, or how to properly manage them. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Tue May 13 14:45:28 2008 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 A886F1065675 for ; Tue, 13 May 2008 14:45:28 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 703038FC1D for ; Tue, 13 May 2008 14:45:28 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 3E25F2218A77; Wed, 14 May 2008 00:45:27 +1000 (EST) X-Viruscan-Id: <4829A98700006A41EADEEF@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id CE70221B2DA6; Wed, 14 May 2008 00:45:26 +1000 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 665852218A66; Wed, 14 May 2008 00:45:26 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id A9DF37CC; Wed, 14 May 2008 00:45:25 +1000 (EST) Date: Wed, 14 May 2008 00:45:25 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org, "Bruce M. Simpson" , Julian Elischer Message-ID: <20080513144525.GA3038@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> <48215D08.5050500@incunabulum.net> <20080513143758.GA3041@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080513143758.GA3041@k7.mavetju> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 13 May 2008 14:45:28 -0000 On Wed, May 14, 2008 at 12:37:58AM +1000, Edwin Groothuis wrote: > It contains links to patches for FreeBSD 6.3 and the nat6to4d.c. Needless to say that the code of nat6to4d.c is a proof-of-concept and is missing essential features like garbage-collection and configurationability. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Tue May 13 22:00:35 2008 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 6AA691065672 for ; Tue, 13 May 2008 22:00:35 +0000 (UTC) (envelope-from m.oe@x-trader.de) Received: from qhexrelay1.hosting.inetserver.de (fw1.hostedoffice.ag [81.20.90.82]) by mx1.freebsd.org (Postfix) with ESMTP id 2D35B8FC18 for ; Tue, 13 May 2008 22:00:35 +0000 (UTC) (envelope-from m.oe@x-trader.de) Received: from qhexedge1.hosting.inetserver.de (unknown [10.20.9.10]) by qhexrelay1.hosting.inetserver.de (Postfix) with ESMTP id 50182175C49; Tue, 13 May 2008 23:43:55 +0200 (CEST) Received: from qhexhub1.hosting.inetserver.de (10.20.10.20) by mail.hostedoffice.ag (10.20.9.10) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 13 May 2008 23:43:49 +0200 Received: from QHEXMBOX1.hosting.inetserver.de ([10.20.10.31]) by qhexhub1.hosting.inetserver.de ([10.20.10.20]) with mapi; Tue, 13 May 2008 23:43:55 +0200 From: Markus Oestreicher To: "freebsd-net@freebsd.org" Date: Tue, 13 May 2008 23:43:55 +0200 Thread-Topic: RX/TX multiqueue support Thread-Index: AQHItUJxHHho+WYl10qp+iOq3Uvphg== Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jfvogel@gmail.com" Subject: RX/TX multiqueue support 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, 13 May 2008 22:00:35 -0000 Good Day, I see that the new igb driver has a tunable for multiple rx/tx queues. Is that for future use or already working when using a 82575 NIC? Currently the processing of packets is limited to one CPU per NIC. Can we now have multiple taskq processes for one NIC in parallel? Best Regards, Markus From owner-freebsd-net@FreeBSD.ORG Tue May 13 22:55:47 2008 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 5DC6D106564A for ; Tue, 13 May 2008 22:55:47 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from gtcomm.net (web.gtcomm.net [72.10.164.67]) by mx1.freebsd.org (Postfix) with ESMTP id 239D58FC15 for ; Tue, 13 May 2008 22:55:46 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from [192.168.1.3] (c-76-108-179-28.hsd1.fl.comcast.net [76.108.179.28]) by gtcomm.net (8.12.20/8.12.10) with ESMTP id m4DMtrg2026603; Tue, 13 May 2008 19:55:54 -0300 Message-ID: <482A1CDB.3030802@gtcomm.net> Date: Tue, 13 May 2008 18:57:31 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Markus Oestreicher References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "jfvogel@gmail.com" Subject: Re: RX/TX multiqueue support 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, 13 May 2008 22:55:47 -0000 This would be awesome, like the Yandex driver for fbsd 6.. I wish there was some way of doing this for 7.0 :) maybe this is it.. So this is the question now....... Markus Oestreicher wrote: > Good Day, > > I see that the new igb driver has a tunable for multiple rx/tx queues. > Is that for future use or already working when using a 82575 NIC? > > Currently the processing of packets is limited to one CPU per NIC. > Can we now have multiple taskq processes for one NIC in parallel? > > Best Regards, > Markus > _______________________________________________ > 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 May 14 06:11:38 2008 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 706A11065676 for ; Wed, 14 May 2008 06:11:38 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id B27F48FC16 for ; Wed, 14 May 2008 06:11:37 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id m4E67t6S004226 for ; Wed, 14 May 2008 15:37:56 +0930 (CST) Received: from fmbex510.dsto.defence.gov.au (fmbex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Wed, 14 May 2008 15:41:06 +0930 Received: from stlex510.dsto.defence.gov.au ([203.6.60.184]) by fmbex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 16:11:06 +1000 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by stlex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 14:11:05 +0800 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.2/8.14.2) with ESMTP id m4E66BTQ066320 for ; Wed, 14 May 2008 14:06:14 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.2/8.14.2/Submit) id m4E65vAQ066318 for freebsd-net@freebsd.org; Wed, 14 May 2008 14:05:57 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 14 May 2008 14:05:57 +0800 From: "Wilkinson, Alex" To: freebsd-net@freebsd.org Message-ID: <20080514060556.GI65832@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-net@freebsd.org References: <48281D8F.2090501@vwsoft.com> <20080512111958.GA95632@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20080512111958.GA95632@alchemy.franken.de> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.17 (2007-11-01) X-OriginalArrivalTime: 14 May 2008 06:11:05.0313 (UTC) FILETIME=[4AFA6510:01C8B589] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.5.1026-15908.003 X-TM-AS-Result: No-1.375000-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: how to identify a PHY? 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, 14 May 2008 06:11:38 -0000 0n Mon, May 12, 2008 at 01:19:58PM +0200, Marius Strobl wrote: >If the system is running the simplest thing in order to identifiy >the PHYs is to check the oui= and model= output of `devinfo -v`. >Otherwise boot verbose and check the OUI and model output of >ukphy(4). Curious, once we have the hex codes for the oui and model e.g. brgphy0 pnpinfo oui=0x818 model=0x1a rev=0x2 at phyno=1 How do we then determine what 0x818 and 0x1a refer to ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Wed May 14 21:04:47 2008 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 566441065677; Wed, 14 May 2008 21:04:47 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 33E408FC1B; Wed, 14 May 2008 21:04:47 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4EL4lPH016648; Wed, 14 May 2008 21:04:47 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4EL4kKt016644; Wed, 14 May 2008 21:04:46 GMT (envelope-from vwe) Date: Wed, 14 May 2008 21:04:46 GMT Message-Id: <200805142104.m4EL4kKt016644@freefall.freebsd.org> To: oliver@akephalos.de, vwe@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/120966: [rum] kernel panic with if_rum and WPA encryption 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, 14 May 2008 21:04:47 -0000 Old Synopsis: [rum]: kernel panic with if_rum and WPA encryption New Synopsis: [rum] kernel panic with if_rum and WPA encryption State-Changed-From-To: feedback->open State-Changed-By: vwe State-Changed-When: Wed May 14 21:03:46 UTC 2008 State-Changed-Why: Feedback has been provided. Does this belong to net or better assign to usb? http://www.freebsd.org/cgi/query-pr.cgi?pr=120966 From owner-freebsd-net@FreeBSD.ORG Wed May 14 21:12:25 2008 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 419D5106566C; Wed, 14 May 2008 21:12:25 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1E88C8FC0C; Wed, 14 May 2008 21:12:25 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4ELCOea017083; Wed, 14 May 2008 21:12:24 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4ELCO3R017079; Wed, 14 May 2008 21:12:24 GMT (envelope-from vwe) Date: Wed, 14 May 2008 21:12:24 GMT Message-Id: <200805142112.m4ELCO3R017079@freefall.freebsd.org> To: peter@wemm.org, vwe@FreeBSD.org, freebsd-net@FreeBSD.org, vwe@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/116172: [tun] [panic] Network / ipv6 recursive mutex panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 21:12:25 -0000 Synopsis: [tun] [panic] Network / ipv6 recursive mutex panic State-Changed-From-To: feedback->suspended State-Changed-By: vwe State-Changed-When: Wed May 14 21:10:24 UTC 2008 State-Changed-Why: unfortunately we haven't received feedback and the state of this issue is still unclear if it has been solved or not by updating to a recent version. suspend for now until either we're seeing feedback or this ticket can be closed within a reasonable timeframe. Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 14 21:10:24 UTC 2008 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=116172 From owner-freebsd-net@FreeBSD.ORG Wed May 14 21:14:59 2008 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 90E64106567A; Wed, 14 May 2008 21:14:59 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB398FC14; Wed, 14 May 2008 21:14:59 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4ELExvq018849; Wed, 14 May 2008 21:14:59 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4ELEx3J018845; Wed, 14 May 2008 21:14:59 GMT (envelope-from vwe) Date: Wed, 14 May 2008 21:14:59 GMT Message-Id: <200805142114.m4ELEx3J018845@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: bin/123633: ifconfig doesn't set inet and ether address in one command 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, 14 May 2008 21:14:59 -0000 Synopsis: ifconfig doesn't set inet and ether address in one command Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 14 21:14:27 UTC 2008 Responsible-Changed-Why: I'm able to reproduce this on 7-STABLE. Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123633 From owner-freebsd-net@FreeBSD.ORG Thu May 15 03:15:09 2008 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 6C062106564A for ; Thu, 15 May 2008 03:15:09 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4EDB38FC18 for ; Thu, 15 May 2008 03:15:09 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m4F3EJPp065913 for ; Wed, 14 May 2008 20:14:57 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m4F3EIJa061777 for ; Wed, 14 May 2008 20:14:18 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com ([24.114.252.231]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m4F3EHlA024759 for ; Wed, 14 May 2008 20:14:18 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 14 May 2008 23:14:17 -0400 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Wed_May_14_23:14:17_2008-1" X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 384286 - c3351feda92d X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Subject: Proposed patch to the kernel and to netstat... 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, 15 May 2008 03:15:09 -0000 --Multipart_Wed_May_14_23:14:17_2008-1 Content-Type: text/plain; charset=US-ASCII Howdy, I have developed the attached patch which extends the functionality of netstat (via the -x flag) to show us all the socket buffer statistics. The kernel change counts mbufs, as well as clusters (at the moment of any size) and gives output like this: Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA R-BCNT S-BCNT R-BMAX S-BMAX (state) tcp4 0 0 127.0.0.1.6010 *.* 0 0 0 0 65536 32768 1 2048 0 0 262144 262144 LISTEN tcp6 0 0 ::1.6010 *.* 0 0 0 0 65536 32768 1 2048 0 0 262144 262144 LISTEN tcp4 0 0 172.16.186.130.22 172.16.186.1.53443 0 0 0 0 66608 33304 1 2048 0 0 262144 262144 ESTABLISHED tcp4 0 0 172.16.186.130.29178 172.16.186.1.22 0 0 0 0 0 0 0 0 0 0 0 0 TIME_WAIT tcp4 0 0 172.16.186.130.62302 69.147.83.41.22 0 0 0 0 65700 74540 1 2048 0 0 262144 262144 ESTABLISHED tcp4 0 0 127.0.0.1.62415 127.0.0.1.6010 0 0 0 0 0 0 0 0 0 0 0 0 TIME_WAIT Note you need a very wide screen to read that. The man page is also updated but the relevant bits are: The -x flag causes netstat to output all the information recorded about data stored in the socket buffers. The fields are: R-MBUF Number of mbufs in the receive queue. S-MBUF Number of mbufs in the send queue. R-CLUS Number of clusters, of any type, in the recieve queue. S-CLUS Number of clusters, of any type, in the send queue. R-HIWA Receive buffer high water mark, in bytes. S-HIWA Send buffer high water mark, in bytes. R-LOWA Receive buffer low water mark, in bytes. S-LOWA Send buffer low water mark, in bytes. R-BCNT Receive buffer byte count. S-BCNT Send buffer byte count. R-BMAX Maximum bytes that can be used in the receive buffer. S-BMAX Maximum bytes that can be used in the send buffer. Please email me comments. I'd like to commit this to HEAD soon. It can't be put into 7 without removing the cluster and mbuf counting, but I might do that as well if there is interest. Best, George --Multipart_Wed_May_14_23:14:17_2008-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="netstat.diff" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9rZXJuL3VpcGNfc29ja2J1Zi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21l L25jdnMvc3JjL3N5cy9rZXJuL3VpcGNfc29ja2J1Zi5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjE3NgpkaWZmIC11IC1yMS4xNzYgdWlwY19zb2NrYnVmLmMKLS0tIHN5cy9rZXJuL3VpcGNfc29j a2J1Zi5jCTQgRmViIDIwMDggMTI6MjU6MTMgLTAwMDAJMS4xNzYKKysrIHN5cy9rZXJuL3VpcGNf c29ja2J1Zi5jCTE1IE1heSAyMDA4IDAyOjU0OjA4IC0wMDAwCkBAIC0xMDI3LDYgKzEwMjcsOCBA QAogCXhzYi0+c2JfY2MgPSBzYi0+c2JfY2M7CiAJeHNiLT5zYl9oaXdhdCA9IHNiLT5zYl9oaXdh dDsKIAl4c2ItPnNiX21iY250ID0gc2ItPnNiX21iY250OworCXhzYi0+c2JfbWNudCA9IHNiLT5z Yl9tY250OwkKKwl4c2ItPnNiX2NjbnQgPSBzYi0+c2JfY2NudDsKIAl4c2ItPnNiX21ibWF4ID0g c2ItPnNiX21ibWF4OwogCXhzYi0+c2JfbG93YXQgPSBzYi0+c2JfbG93YXQ7CiAJeHNiLT5zYl9m bGFncyA9IHNiLT5zYl9mbGFnczsKSW5kZXg6IHN5cy9zeXMvc29ja2V0dmFyLmgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL3N5cy9zb2NrZXR2YXIuaCx2CnJldHJpZXZp bmcgcmV2aXNpb24gMS4xNjMKZGlmZiAtdSAtcjEuMTYzIHNvY2tldHZhci5oCi0tLSBzeXMvc3lz L3NvY2tldHZhci5oCTkgTWF5IDIwMDggMjM6MDI6NTkgLTAwMDAJMS4xNjMKKysrIHN5cy9zeXMv c29ja2V0dmFyLmgJMTUgTWF5IDIwMDggMDI6NTQ6MTggLTAwMDAKQEAgLTExMCw2ICsxMTAsOCBA QAogCQl1X2ludAlzYl9jYzsJCS8qIChjL2QpIGFjdHVhbCBjaGFycyBpbiBidWZmZXIgKi8KIAkJ dV9pbnQJc2JfaGl3YXQ7CS8qIChjL2QpIG1heCBhY3R1YWwgY2hhciBjb3VudCAqLwogCQl1X2lu dAlzYl9tYmNudDsJLyogKGMvZCkgY2hhcnMgb2YgbWJ1ZnMgdXNlZCAqLworCQl1X2ludCAgIHNi X21jbnQ7ICAgICAgICAvKiAoYy9kKSBudW1iZXIgb2YgbWJ1ZnMgaW4gYnVmZmVyICovCisJCXVf aW50ICAgc2JfY2NudDsgICAgICAgIC8qIChjL2QpIG51bWJlciBvZiBjbHVzdGVycyBpbiBidWZm ZXIgKi8KIAkJdV9pbnQJc2JfbWJtYXg7CS8qIChjL2QpIG1heCBjaGFycyBvZiBtYnVmcyB0byB1 c2UgKi8KIAkJdV9pbnQJc2JfY3RsOwkJLyogKGMvZCkgbm9uLWRhdGEgY2hhcnMgaW4gYnVmZmVy ICovCiAJCWludAlzYl9sb3dhdDsJLyogKGMvZCkgbG93IHdhdGVyIG1hcmsgKi8KQEAgLTI1OSw2 ICsyNjEsOCBAQAogCQl1X2ludAlzYl9jYzsKIAkJdV9pbnQJc2JfaGl3YXQ7CiAJCXVfaW50CXNi X21iY250OworCQl1X2ludCAgIHNiX21jbnQ7CisJCXVfaW50ICAgc2JfY2NudDsKIAkJdV9pbnQJ c2JfbWJtYXg7CiAJCWludAlzYl9sb3dhdDsKIAkJaW50CXNiX3RpbWVvOwpAQCAtMzIwLDggKzMy NCwxMSBAQAogCWlmICgobSktPm1fdHlwZSAhPSBNVF9EQVRBICYmIChtKS0+bV90eXBlICE9IE1U X09PQkRBVEEpIFwKIAkJKHNiKS0+c2JfY3RsICs9IChtKS0+bV9sZW47IFwKIAkoc2IpLT5zYl9t YmNudCArPSBNU0laRTsgXAotCWlmICgobSktPm1fZmxhZ3MgJiBNX0VYVCkgXAorCShzYiktPnNi X21jbnQgKz0gMTsgXAorCWlmICgobSktPm1fZmxhZ3MgJiBNX0VYVCkgeyBcCiAJCShzYiktPnNi X21iY250ICs9IChtKS0+bV9leHQuZXh0X3NpemU7IFwKKwkJKHNiKS0+c2JfY2NudCArPSAxOyBc CisJfSBcCiB9CiAKIC8qIGFkanVzdCBjb3VudGVycyBpbiBzYiByZWZsZWN0aW5nIGZyZWVpbmcg b2YgbSAqLwpAQCAtMzMwLDggKzMzNywxMSBAQAogCWlmICgobSktPm1fdHlwZSAhPSBNVF9EQVRB ICYmIChtKS0+bV90eXBlICE9IE1UX09PQkRBVEEpIFwKIAkJKHNiKS0+c2JfY3RsIC09IChtKS0+ bV9sZW47IFwKIAkoc2IpLT5zYl9tYmNudCAtPSBNU0laRTsgXAotCWlmICgobSktPm1fZmxhZ3Mg JiBNX0VYVCkgXAorCShzYiktPnNiX21jbnQgLT0gMTsgXAorCWlmICgobSktPm1fZmxhZ3MgJiBN X0VYVCkgeyBcCiAJCShzYiktPnNiX21iY250IC09IChtKS0+bV9leHQuZXh0X3NpemU7IFwKKwkJ KHNiKS0+c2JfY2NudCAtPSAxOyBcCisJfSBcCiAJaWYgKChzYiktPnNiX3NuZHB0ciA9PSAobSkp IHsgXAogCQkoc2IpLT5zYl9zbmRwdHIgPSBOVUxMOyBcCiAJCShzYiktPnNiX3NuZHB0cm9mZiA9 IDA7IFwKSW5kZXg6IHVzci5iaW4vbmV0c3RhdC9pbmV0LmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog L2hvbWUvbmN2cy9zcmMvdXNyLmJpbi9uZXRzdGF0L2luZXQuYyx2CnJldHJpZXZpbmcgcmV2aXNp b24gMS44MgpkaWZmIC11IC1yMS44MiBpbmV0LmMKLS0tIHVzci5iaW4vbmV0c3RhdC9pbmV0LmMJ NCBKYW4gMjAwOCAwMzowOToyOCAtMDAwMAkxLjgyCisrKyB1c3IuYmluL25ldHN0YXQvaW5ldC5j CTE1IE1heSAyMDA4IDAyOjU0OjI1IC0wMDAwCkBAIC0xNDIsNiArMTQyLDggQEAKIAl4c2ItPnNi X2NjID0gc2ItPnNiX2NjOwogCXhzYi0+c2JfaGl3YXQgPSBzYi0+c2JfaGl3YXQ7CiAJeHNiLT5z Yl9tYmNudCA9IHNiLT5zYl9tYmNudDsKKwl4c2ItPnNiX21jbnQgPSBzYi0+c2JfbWNudDsKKwl4 c2ItPnNiX2NjbnQgPSBzYi0+c2JfY2NudDsKIAl4c2ItPnNiX21ibWF4ID0gc2ItPnNiX21ibWF4 OwogCXhzYi0+c2JfbG93YXQgPSBzYi0+c2JfbG93YXQ7CiAJeHNiLT5zYl9mbGFncyA9IHNiLT5z Yl9mbGFnczsKQEAgLTQwNSwxMyArNDA3LDE5IEBACiAJCQlpZiAoTGZsYWcpCiAJCQkJcHJpbnRm KCIlLTUuNXMgJS0xNC4xNHMgJS0yMi4yMnNcbiIsCiAJCQkJICAgICJQcm90byIsICJMaXN0ZW4i LCAiTG9jYWwgQWRkcmVzcyIpOworCQkJcHJpbnRmKChBZmxhZyAmJiAhV2ZsYWcpID8gCisJCQkg ICAgICAgIiUtNS41cyAlLTYuNnMgJS02LjZzICAlLTE4LjE4cyAlLTE4LjE4cyIgOgorCQkJICAg ICAgICIlLTUuNXMgJS02LjZzICUtNi42cyAgJS0yMi4yMnMgJS0yMi4yMnMiLAorCQkJICAgICAg ICJQcm90byIsICJSZWN2LVEiLCAiU2VuZC1RIiwKKwkJCSAgICAgICAiTG9jYWwgQWRkcmVzcyIs ICJGb3JlaWduIEFkZHJlc3MiKTsKKwkJCWlmICh4ZmxhZykKKwkJCQlwcmludGYoIiUtNi42cyAl LTYuNnMgJS02LjZzICUtNi42cyAlLTYuNnMgJS02LjZzICUtNi42cyAlLTYuNnMgJS02LjZzICUt Ni42cyAlLTYuNnMgJS02LjZzICVzXG4iLAorCQkJCSAgICAgICAiUi1NQlVGIiwgIlMtTUJVRiIs ICJSLUNMVVMiLCAiUy1DTFVTIiwKKwkJCQkgICAgICAgIlItSElXQSIsICJTLUhJV0EiLCAiUi1M T1dBIiwgIlMtTE9XQSIsIAorCQkJCSAgICAgICAiUi1CQ05UIiwgIlMtQkNOVCIsICJSLUJNQVgi LCAiUy1CTUFYIiwgCisJCQkJICAgICAgICIoc3RhdGUpIik7CiAJCQllbHNlCi0JCQkJcHJpbnRm KChBZmxhZyAmJiAhV2ZsYWcpID8KLQkJIiUtNS41cyAlLTYuNnMgJS02LjZzICAlLTE4LjE4cyAl LTE4LjE4cyAlc1xuIiA6Ci0JCSIlLTUuNXMgJS02LjZzICUtNi42cyAgJS0yMi4yMnMgJS0yMi4y MnMgJXNcbiIsCi0JCQkJICAgICJQcm90byIsICJSZWN2LVEiLCAiU2VuZC1RIiwKLQkJCQkgICAg IkxvY2FsIEFkZHJlc3MiLCAiRm9yZWlnbiBBZGRyZXNzIiwKLQkJCQkgICAgIihzdGF0ZSkiKTsK KwkJCQlwcmludGYoIihzdGF0ZSlcbiIpOwogCQkJZmlyc3QgPSAwOwogCQl9CiAJCWlmIChMZmxh ZyAmJiBzby0+c29fcWxpbWl0ID09IDApCkBAIC00MzgsNyArNDQ2LDggQEAKIAkJCSAgICBzby0+ c29faW5jcWxlbiwgc28tPnNvX3FsaW1pdCk7CiAJCQlwcmludGYoIiUtMTQuMTRzICIsIGJ1ZjEp OwogCQl9IGVsc2UgewotCQkJcHJpbnRmKCIlNnUgJTZ1ICAiLCBzby0+c29fcmN2LnNiX2NjLCBz by0+c29fc25kLnNiX2NjKTsKKwkJCXByaW50ZigiJTZ1ICU2dSAiLCAKKwkJCSAgICAgICBzby0+ c29fcmN2LnNiX2NjLCBzby0+c29fc25kLnNiX2NjKTsKIAkJfQogCQlpZiAobnVtZXJpY19wb3J0 KSB7CiAJCQlpZiAoaW5wLT5pbnBfdmZsYWcgJiBJTlBfSVBWNCkgewpAQCAtNDk0LDEwICs1MDMs MjkgQEAKIAkJCX0gLyogZWxzZSBub3RoaW5nIHByaW50ZWQgbm93ICovCiAjZW5kaWYgLyogSU5F VDYgKi8KIAkJfQorCQlpZiAoeGZsYWcpIHsKKwkJCWlmIChMZmxhZykKKwkJCQlwcmludGYoIiUy MXMgJTZ1ICU2dSAlNnUgJTZ1ICU2dSAlNnUgJTZ1ICU2dSAlNnUgJTZ1ICU2dSAlNnUgIiwgCisJ CQkJICAgICAgICIgIiwKKwkJCQkgICAgICAgc28tPnNvX3Jjdi5zYl9tY250LCBzby0+c29fc25k LnNiX21jbnQsCisJCQkJICAgICAgIHNvLT5zb19yY3Yuc2JfY2NudCwgc28tPnNvX3NuZC5zYl9j Y250LAorCQkJCSAgICAgICBzby0+c29fcmN2LnNiX2hpd2F0LCBzby0+c29fc25kLnNiX2hpd2F0 LAorCQkJCSAgICAgICBzby0+c29fcmN2LnNiX2xvd2F0LCBzby0+c29fc25kLnNiX2xvd2F0LAor CQkJCSAgICAgICBzby0+c29fcmN2LnNiX21iY250LCBzby0+c29fc25kLnNiX21iY250LAorCQkJ CSAgICAgICBzby0+c29fcmN2LnNiX21ibWF4LCBzby0+c29fc25kLnNiX21ibWF4KTsKKwkJCWVs c2UKKwkJCQlwcmludGYoIiU2dSAlNnUgJTZ1ICU2dSAlNnUgJTZ1ICU2dSAlNnUgJTZ1ICU2dSAl NnUgJTZ1ICIsCisJCQkJICAgICAgIHNvLT5zb19yY3Yuc2JfbWNudCwgc28tPnNvX3NuZC5zYl9t Y250LAorCQkJCSAgICAgICBzby0+c29fcmN2LnNiX2NjbnQsIHNvLT5zb19zbmQuc2JfY2NudCwK KwkJCQkgICAgICAgc28tPnNvX3Jjdi5zYl9oaXdhdCwgc28tPnNvX3NuZC5zYl9oaXdhdCwKKwkJ CQkgICAgICAgc28tPnNvX3Jjdi5zYl9sb3dhdCwgc28tPnNvX3NuZC5zYl9sb3dhdCwKKwkJCQkg ICAgICAgc28tPnNvX3Jjdi5zYl9tYmNudCwgc28tPnNvX3NuZC5zYl9tYmNudCwKKwkJCQkgICAg ICAgc28tPnNvX3Jjdi5zYl9tYm1heCwgc28tPnNvX3NuZC5zYl9tYm1heCk7CisJCX0KIAkJaWYg KGlzdGNwICYmICFMZmxhZykgewogCQkJaWYgKHRwLT50X3N0YXRlIDwgMCB8fCB0cC0+dF9zdGF0 ZSA+PSBUQ1BfTlNUQVRFUykKIAkJCQlwcmludGYoIiVkIiwgdHAtPnRfc3RhdGUpOwotICAgICAg ICAgICAgICAgICAgICAgIGVsc2UgeworCQkJZWxzZSB7CiAJCQkJcHJpbnRmKCIlcyIsIHRjcHN0 YXRlc1t0cC0+dF9zdGF0ZV0pOwogI2lmIGRlZmluZWQoVEZfTkVFRFNZTikgJiYgZGVmaW5lZChU Rl9ORUVERklOKQogCQkJCS8qIFNob3cgVC9UQ1AgYGhpZGRlbiBzdGF0ZScgKi8KQEAgLTUwNSw3 ICs1MzMsNyBAQAogCQkJCQlwdXRjaGFyKCcqJyk7CiAjZW5kaWYgLyogZGVmaW5lZChURl9ORUVE U1lOKSAmJiBkZWZpbmVkKFRGX05FRURGSU4pICovCiAJCQl9Ci0JCX0KKwkJfSAJCQogCQlwdXRj aGFyKCdcbicpOwogCX0KIAlpZiAoeGlnICE9IG94aWcgJiYgeGlnLT54aWdfZ2VuICE9IG94aWct PnhpZ19nZW4pIHsKSW5kZXg6IHVzci5iaW4vbmV0c3RhdC9tYWluLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1Mg ZmlsZTogL2hvbWUvbmN2cy9zcmMvdXNyLmJpbi9uZXRzdGF0L21haW4uYyx2CnJldHJpZXZpbmcg cmV2aXNpb24gMS44OApkaWZmIC11IC1yMS44OCBtYWluLmMKLS0tIHVzci5iaW4vbmV0c3RhdC9t YWluLmMJMiBKYW4gMjAwOCAyMzoyNjoxMSAtMDAwMAkxLjg4CisrKyB1c3IuYmluL25ldHN0YXQv bWFpbi5jCTE1IE1heSAyMDA4IDAyOjU0OjI1IC0wMDAwCkBAIC0zMzEsNiArMzMxLDcgQEAKIGlu dAlzZmxhZzsJCS8qIHNob3cgcHJvdG9jb2wgc3RhdGlzdGljcyAqLwogaW50CXRmbGFnOwkJLyog c2hvdyBpL2Ygd2F0Y2hkb2cgdGltZXJzICovCiBpbnQJV2ZsYWc7CQkvKiB3aWRlIGRpc3BsYXkg Ki8KK2ludCAgICAgeGZsYWc7ICAgICAgICAgIC8qIGV4dHJhIGluZm9ybWF0aW9uLCBpbmNsdWRl cyBhbGwgc29ja2V0IGJ1ZmZlciBpbmZvICovCiBpbnQJemZsYWc7CQkvKiB6ZXJvIHN0YXRzICov CiAKIGludAlpbnRlcnZhbDsJLyogcmVwZWF0IGludGVydmFsIGZvciBpL2Ygc3RhdHMgKi8KQEAg LTM0OSw3ICszNTAsNyBAQAogCiAJYWYgPSBBRl9VTlNQRUM7CiAKLQl3aGlsZSAoKGNoID0gZ2V0 b3B0KGFyZ2MsIGFyZ3YsICJBYUJiZGY6Z2hJOmlMbE06bU46bnA6clNzdHVXdzp6IikpICE9IC0x KQorCXdoaWxlICgoY2ggPSBnZXRvcHQoYXJnYywgYXJndiwgIkFhQmJkZjpnaEk6aUxsTTptTjpu cDpyU3N0dVd3Onh6IikpICE9IC0xKQogCQlzd2l0Y2goY2gpIHsKIAkJY2FzZSAnQSc6CiAJCQlB ZmxhZyA9IDE7CkBAIC00NTYsNiArNDU3LDkgQEAKIAkJCWludGVydmFsID0gYXRvaShvcHRhcmcp OwogCQkJaWZsYWcgPSAxOwogCQkJYnJlYWs7CisJCWNhc2UgJ3gnOgorCQkJeGZsYWcgPSAxOwor CQkJYnJlYWs7CiAJCWNhc2UgJ3onOgogCQkJemZsYWcgPSAxOwogCQkJYnJlYWs7CkluZGV4OiB1 c3IuYmluL25ldHN0YXQvbmV0c3RhdC4xCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMv c3JjL3Vzci5iaW4vbmV0c3RhdC9uZXRzdGF0LjEsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNTgK ZGlmZiAtdSAtcjEuNTggbmV0c3RhdC4xCi0tLSB1c3IuYmluL25ldHN0YXQvbmV0c3RhdC4xCTEw IEp1biAyMDA3IDA2OjExOjAzIC0wMDAwCTEuNTgKKysrIHVzci5iaW4vbmV0c3RhdC9uZXRzdGF0 LjEJMTUgTWF5IDIwMDggMDI6NTQ6MjUgLTAwMDAKQEAgLTQ5LDcgKzQ5LDcgQEAKIC5JdCBYbwog LkJrIC13b3JkcwogLk5tCi0uT3AgRmwgQWFMblNXCisuT3AgRmwgQWFMblNXeAogLk9wIEZsIGYg QXIgcHJvdG9jb2xfZmFtaWx5IHwgRmwgcCBBciBwcm90b2NvbAogLk9wIEZsIE0gQXIgY29yZQog Lk9wIEZsIE4gQXIgc3lzdGVtCkBAIC04NSw2ICs4NSw5IEBACiBzaG93IG5ldHdvcmsgYWRkcmVz c2VzIGFzIG51bWJlcnMgKGFzIHdpdGgKIC5GbCBuICkKIGJ1dCBzaG93IHBvcnRzIHN5bWJvbGlj YWxseS4KK0lmCisuRmwgeAoraXMgcHJlc2VudCBkaXNwbGF5IGZ1bGwgc29ja2V0IGJ1ZmZlciBz dGF0aXN0aWNzIGZvciBlYWNoIGludGVybmV0IHNvY2tldC4KIC5JdCBYbwogLkJrIC13b3Jkcwog Lk5tCkBAIC00NTQsNiArNDU3LDI2IEBACiAuUHAKIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IHRoZXNlIGZsYWdzLCBwbGVhc2UgcmVmZXIgdG8KIC5YciBicGYgNCAuCisuUHAKK1RoZQorLkZs IHgKK2ZsYWcgY2F1c2VzIG5ldHN0YXQgdG8gb3V0cHV0IGFsbCB0aGUgaW5mb3JtYXRpb24gcmVj b3JkZWQgYWJvdXQgZGF0YQorc3RvcmVkIGluIHRoZSBzb2NrZXQgYnVmZmVycy4gIFRoZSBmaWVs ZHMgYXJlOgorLkJsIC1jb2x1bW4gIi5MaSBSLU1CVUYiCisuSXQgTGkgUi1NQlVGIFRhIE51bWJl ciBvZiBtYnVmcyBpbiB0aGUgcmVjZWl2ZSBxdWV1ZS4KKy5JdCBMaSBTLU1CVUYgVGEgTnVtYmVy IG9mIG1idWZzIGluIHRoZSBzZW5kIHF1ZXVlLgorLkl0IExpIFItQ0xVUyBUYSBOdW1iZXIgb2Yg Y2x1c3RlcnMsIG9mIGFueSB0eXBlLCBpbiB0aGUgcmVjaWV2ZQorcXVldWUuCisuSXQgTGkgUy1D TFVTIFRhIE51bWJlciBvZiBjbHVzdGVycywgb2YgYW55IHR5cGUsIGluIHRoZSBzZW5kIHF1ZXVl LgorLkl0IExpIFItSElXQSBUYSBSZWNlaXZlIGJ1ZmZlciBoaWdoIHdhdGVyIG1hcmssIGluIGJ5 dGVzLgorLkl0IExpIFMtSElXQSBUYSBTZW5kIGJ1ZmZlciBoaWdoIHdhdGVyIG1hcmssIGluIGJ5 dGVzLgorLkl0IExpIFItTE9XQSBUYSBSZWNlaXZlIGJ1ZmZlciBsb3cgd2F0ZXIgbWFyaywgaW4g Ynl0ZXMuCisuSXQgTGkgUy1MT1dBIFRhIFNlbmQgYnVmZmVyIGxvdyB3YXRlciBtYXJrLCBpbiBi eXRlcy4KKy5JdCBMaSBSLUJDTlQgVGEgUmVjZWl2ZSBidWZmZXIgYnl0ZSBjb3VudC4KKy5JdCBM aSBTLUJDTlQgVGEgU2VuZCBidWZmZXIgYnl0ZSBjb3VudC4KKy5JdCBMaSBSLUJNQVggVGEgTWF4 aW11bSBieXRlcyB0aGF0IGNhbiBiZSB1c2VkIGluIHRoZSByZWNlaXZlIGJ1ZmZlci4KKy5JdCBM aSBTLUJNQVggVGEgTWF4aW11bSBieXRlcyB0aGF0IGNhbiBiZSB1c2VkIGluIHRoZSBzZW5kIGJ1 ZmZlci4KKy5FbAogLlNoIFNFRSBBTFNPCiAuWHIgZnN0YXQgMSAsCiAuWHIgbmZzc3RhdCAxICwK SW5kZXg6IHVzci5iaW4vbmV0c3RhdC9uZXRzdGF0LmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hv bWUvbmN2cy9zcmMvdXNyLmJpbi9uZXRzdGF0L25ldHN0YXQuaCx2CnJldHJpZXZpbmcgcmV2aXNp b24gMS41MwpkaWZmIC11IC1yMS41MyBuZXRzdGF0LmgKLS0tIHVzci5iaW4vbmV0c3RhdC9uZXRz dGF0LmgJNyBGZWIgMjAwOCAyMzowMDo0MCAtMDAwMAkxLjUzCisrKyB1c3IuYmluL25ldHN0YXQv bmV0c3RhdC5oCTE1IE1heSAyMDA4IDAyOjU0OjI1IC0wMDAwCkBAIC01MSw2ICs1MSw3IEBACiBl eHRlcm4gaW50CXNmbGFnOwkvKiBzaG93IHByb3RvY29sIHN0YXRpc3RpY3MgKi8KIGV4dGVybiBp bnQJdGZsYWc7CS8qIHNob3cgaS9mIHdhdGNoZG9nIHRpbWVycyAqLwogZXh0ZXJuIGludAlXZmxh ZzsJLyogd2lkZSBkaXNwbGF5ICovCitleHRlcm4gaW50ICAgICAgeGZsYWc7ICAvKiBleHRlbmRl ZCBkaXNwbGF5LCBpbmNsdWRlcyBhbGwgc29ja2V0IGJ1ZmZlciBpbmZvICovCiBleHRlcm4gaW50 CXpmbGFnOwkvKiB6ZXJvIHN0YXRzICovCiAKIGV4dGVybiBpbnQJaW50ZXJ2YWw7IC8qIHJlcGVh dCBpbnRlcnZhbCBmb3IgaS9mIHN0YXRzICovCg== --Multipart_Wed_May_14_23:14:17_2008-1-- From owner-freebsd-net@FreeBSD.ORG Thu May 15 08:50:12 2008 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 216581065674; Thu, 15 May 2008 08:50:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id EB8018FC0A; Thu, 15 May 2008 08:50:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 67EEC108D8E; Thu, 15 May 2008 04:50:11 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 15 May 2008 04:50:11 -0400 X-Sasl-enc: XPx5MkqR3sAE6IgP0ktPsbv9XwRZu4U7QyZpn8jPgLmF 1210841410 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 39F2F1E82; Thu, 15 May 2008 04:50:10 -0400 (EDT) Message-ID: <482BF941.30108@FreeBSD.org> Date: Thu, 15 May 2008 09:50:09 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: gnn@freebsd.org References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Proposed patch to the kernel and to netstat... 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, 15 May 2008 08:50:12 -0000 gnn@freebsd.org wrote: > ... > Please email me comments. I'd like to commit this to HEAD soon. It > can't be put into 7 without removing the cluster and mbuf counting, > but I might do that as well if there is interest. > People writing servers are going to find the watermark stuff useful. I'm thinking being able to watch the the buffer stats (possibly also in a way which we can graph) for a single socket, given its inpcb or so address, would also be a neat trick... cheers BMS From owner-freebsd-net@FreeBSD.ORG Thu May 15 16:08:16 2008 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 68FDE1065674 for ; Thu, 15 May 2008 16:08:16 +0000 (UTC) (envelope-from john@roof1.dnepro.net) Received: from roof1.dnepro.net (a66.dnepro.net [212.3.111.66]) by mx1.freebsd.org (Postfix) with ESMTP id DA9348FC29 for ; Thu, 15 May 2008 16:08:15 +0000 (UTC) (envelope-from john@roof1.dnepro.net) Received: from roof1.dnepro.net (localhost [127.0.0.1]) by roof1.dnepro.net (8.14.1/8.14.1) with ESMTP id m4FFQ7hW052124 for ; Thu, 15 May 2008 18:26:08 +0300 (EEST) (envelope-from john@roof1.dnepro.net) Received: (from john@localhost) by roof1.dnepro.net (8.14.1/8.14.1/Submit) id m4FFQ7Ha052123 for freebsd-net@freebsd.org; Thu, 15 May 2008 18:26:07 +0300 (EEST) (envelope-from john) Date: Thu, 15 May 2008 18:26:07 +0300 From: Eugene Perevyazko To: freebsd-net@freebsd.org Message-ID: <20080515152607.GA36663@roof1.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on roof1.dnepro.net X-Virus-Status: Clean Subject: How to inject fullsize 802.1q-tagged frame through BPF? 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, 15 May 2008 16:08:16 -0000 Hello, I have an ethernet interface with several vlans on it (FreeBSD 6.2-RELEASE #0). My program opens BPF on the parent device, receives tagged frames and responds by writing tagged frame to the BPF fd. It all works good, until size of response frame w/o tag becomes larger than 1496 bytes (1500 with tag inserted) - mtu of parent device.i I'm a bit confused as mtu is 1500 on both vlanN and it's parent fxp0. I've tried to "ifconfig fxp0 mtu 1504" to make room for vlan tag, but the response is ifconfig: ioctl (set mtu): Invalid argument Trying "ifconfig fxp0 -vlanmtu" also makes no difference. Is there a way to inject full-mtu vlan-tagged frame through BPF on parent device? I'd like not to open several tenths of BPFs for each vlanN if it's possible. I've tried on bge also with same results, so that is not connected with fxp driver. Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Thu May 15 16:21:31 2008 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 5A2F61065672 for ; Thu, 15 May 2008 16:21:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 315B58FC1E for ; Thu, 15 May 2008 16:21:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-3.local (039sub223.uottawa.ca [137.122.39.151]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m4FGLT2F077986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 May 2008 09:21:30 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <482C6303.9000904@freebsd.org> Date: Thu, 15 May 2008 12:21:23 -0400 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20080515152607.GA36663@roof1.dnepro.net> In-Reply-To: <20080515152607.GA36663@roof1.dnepro.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Subject: Re: How to inject fullsize 802.1q-tagged frame through BPF? 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, 15 May 2008 16:21:31 -0000 Eugene Perevyazko wrote: > Hello, > I have an ethernet interface with several vlans on it (FreeBSD 6.2-RELEASE #0). > My program opens BPF on the parent device, receives tagged frames and responds > by writing tagged frame to the BPF fd. > It all works good, until size of response frame w/o tag becomes larger than > 1496 bytes (1500 with tag inserted) - mtu of parent device.i > I'm a bit confused as mtu is 1500 on both vlanN and it's parent fxp0. > I've tried to "ifconfig fxp0 mtu 1504" to make room for vlan tag, but > the response is > ifconfig: ioctl (set mtu): Invalid argument > > Trying "ifconfig fxp0 -vlanmtu" also makes no difference. > > Is there a way to inject full-mtu vlan-tagged frame through BPF on parent > device? > I'd like not to open several tenths of BPFs for each vlanN if it's possible. > > I've tried on bge also with same results, so that is not connected with fxp > driver. bpf write code in the kernel calculates header size when packets are injected. This is likely based on the frames being stock 802.3 so would require mods to the bpf code to handle the additional space for the tag. Sam From owner-freebsd-net@FreeBSD.ORG Fri May 16 02:30:03 2008 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 CEBA8106566B for ; Fri, 16 May 2008 02:30:03 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.NET [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id BC0608FC16 for ; Fri, 16 May 2008 02:30:03 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-76-227-18-120.dsl.pltn13.sbcglobal.net [76.227.18.120]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id m4G25OhI075297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 May 2008 19:05:25 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <482CEC29.9000509@monkeybrains.net> Date: Thu, 15 May 2008 19:06:33 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.12 (X11/20080310) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on pita.monkeybrains.net X-Virus-Status: Clean Subject: carp oddness... BACKUP is ARPing! 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, 16 May 2008 02:30:03 -0000 The CARP in BACKUP is arping... why? Rudy First, arp -d ns2, then ping ns2 to refresh arp to machine testing. # arp ns2; arp jamon; arp cabrillo ns2.monkeybrains.NET (208.69.40.4) at 00:30:48:88:e7:98 on em0 [ethernet] jamon.monkeybrains.NET (208.69.40.5) at 00:15:f2:4b:60:49 on em0 [ethernet] cabrillo.monkeybrains.NET (208.69.40.7) at 00:30:48:88:e7:98 on em0 [ethernet] CABRILLO# ifconfig bge0: flags=8943 mtu 1500 options=1b inet 208.69.40.7 netmask 0xffffff00 broadcast 208.69.40.255 ether 00:30:48:88:e7:98 media: Ethernet autoselect (100baseTX ) status: active carp1: flags=49 mtu 1500 inet 208.69.40.4 netmask 0xffffffff carp: BACKUP vhid 2 advbase 4 advskew 180 JAMON# ifconfig fxp0: flags=8943 mtu 1500 options=8 inet 208.69.40.5 netmask 0xffffff00 broadcast 208.69.40.255 ether 00:15:f2:4b:60:49 media: Ethernet autoselect (100baseTX ) status: active carp1: flags=41 mtu 1500 inet 208.69.40.4 netmask 0xffffffff carp: MASTER vhid 2 advbase 4 advskew 0 FreeBSD jamon.monkeybrains.net 5.5-STABLE FreeBSD cabrillo.monkeybrains.net 6.2-STABLE sysctl net.inet.carp net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 From owner-freebsd-net@FreeBSD.ORG Fri May 16 09:14:37 2008 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 897BA106564A for ; Fri, 16 May 2008 09:14:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 60B618FC0C for ; Fri, 16 May 2008 09:14:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 5ECC3109520; Fri, 16 May 2008 05:14:36 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 16 May 2008 05:14:36 -0400 X-Sasl-enc: wPiKf/O/iJVcebG/4qOhu9ux3zGeJwIbd6XTL0E1a8m7 1210929275 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 81E5019674; Fri, 16 May 2008 05:14:35 -0400 (EDT) Message-ID: <482D5079.60608@FreeBSD.org> Date: Fri, 16 May 2008 10:14:33 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Rudy References: <482CEC29.9000509@monkeybrains.net> In-Reply-To: <482CEC29.9000509@monkeybrains.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: carp oddness... BACKUP is ARPing! 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, 16 May 2008 09:14:37 -0000 Rudy wrote: > > The CARP in BACKUP is arping... why? Without looking at the carp code, I can tell you that its addressing hook is implemented as a pass-through in ether_input(). carps are not IFT_ETHER, therefore they shouldn't emit gratuitous ARP or otherwise when an address is configured on one. So I'll leave this up to someone who knows the carp code, as this is most likely where the ARP originated from. cheers BMS From owner-freebsd-net@FreeBSD.ORG Fri May 16 15:29:30 2008 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 5A0FE1065670 for ; Fri, 16 May 2008 15:29:30 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from logos.sky.od.ua (logos.sky.od.ua [81.25.224.11]) by mx1.freebsd.org (Postfix) with ESMTP id 80B9B8FC19 for ; Fri, 16 May 2008 15:29:29 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from localhost (localhost [127.0.0.1]) by logos.sky.od.ua (Postfix) with ESMTP id 35C62102CD3 for ; Fri, 16 May 2008 18:03:46 +0300 (EEST) Date: Fri, 16 May 2008 18:03:46 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-net@freebsd.org Message-ID: <20080516164544.Y80938@logos.sky.od.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: em0: watchdog timeout -- resetting 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, 16 May 2008 15:29:30 -0000 Hi All! I have a problem with Intel NIC after upgrade from 7-STABLE(25Mar2008,) to 7-STABLE(5May2008,) on motherboard Supermicro PDSMi-LN4+ http://www.supermicro.com/products/motherboard/Xeon3000/3000/PDSMi-LN4+.cfm The NIC em0 is hangup at 16May with messages: May 16 12:57:18 sphinx kernel: em0: watchdog timeout -- resetting May 16 12:57:18 sphinx kernel: em0: Hardware Initialization Failed May 16 12:57:18 sphinx kernel: em0: Unable to initialize the hardware May 16 12:59:09 sphinx kernel: em0: link state changed to DOWN >kenv | grep smbios: smbios.bios.reldate="08/27/2007" smbios.bios.vendor="Phoenix Technologies LTD" smbios.bios.version="6.00" smbios.chassis.maker="Supermicro" smbios.chassis.serial="0123456789" smbios.chassis.tag=" " smbios.chassis.version="0123456789" smbios.planar.maker="Supermicro" smbios.planar.product="PDSMi-LN4+" smbios.planar.serial="0123456789" smbios.planar.version="PCB Version" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Supermicro" smbios.system.product="PDSMi-LN4" smbios.system.serial="0123456789" smbios.system.uuid="7634a964-b127-0430-c299-0030489144c8" smbios.system.version="0123456789" >pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x828015d9 chip=0x27788086 rev=0xc0 hdr=0x00 vendor = 'Intel Corporation' device = 'E7230/3000/3010 Processor to I/O Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x828015d9 chip=0x27798086 rev=0xc0 hdr=0x01 vendor = 'Intel Corporation' device = 'E7230/3000/3010 PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:0: class=0x060400 card=0x828015d9 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:1: class=0x060400 card=0x00000000 chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:2: class=0x060400 card=0x00000000 chip=0x27d48086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:3: class=0x060400 card=0x828015d9 chip=0x27d68086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib7@pci0:0:30:0: class=0x060401 card=0x828015d9 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x828015d9 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface Controller - 27B8' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x828015d9 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x010601 card=0x828015d9 chip=0x27c18086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub SATA cc=AHCI' class = mass storage ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x828015d9 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6702PXH PCI Express-to-PCI Express Bridge' class = bridge subclass = PCI-PCI ioapic0@pci0:1:0:1: class=0x080020 card=0x828015d9 chip=0x03268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '6700/6702PXH I/OxAPIC Interrupt Controller A' class = base peripheral subclass = interrupt controller em0@pci0:9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci0:10:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em2@pci0:11:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em3@pci0:12:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet vgapci0@pci0:15:0:0: class=0x030000 card=0x828015d9 chip=0x002018ca rev=0x00 hdr=0x00 vendor = 'XGI Technology Inc' class = display subclass = VGA >dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #1: Mon May 5 15:48:42 EEST 2008 proks@sphinx.sky.od.ua:/usr/obj/usr/src/sys/SPHINX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2394.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2094850048 (1997 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 est0: Setting 1200 MHz p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Setting 1200 MHz p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 17 at device 28.0 on pci0 pci9: on pcib3 em0: port 0x4000-0x401f mem 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:91:44:c8 pcib4: irq 16 at device 28.1 on pci0 pci10: on pcib4 em1: port 0x5000-0x501f mem 0xee300000-0xee31ffff irq 17 at device 0.0 on pci10 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:91:44:c9 pcib5: irq 18 at device 28.2 on pci0 pci11: on pcib5 em2: port 0x6000-0x601f mem 0xee400000-0xee41ffff irq 18 at device 0.0 on pci11 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:91:44:ca pcib6: irq 19 at device 28.3 on pci0 pci12: on pcib6 em3: port 0x7000-0x701f mem 0xee500000-0xee51ffff irq 19 at device 0.0 on pci12 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:91:44:cb pcib7: at device 30.0 on pci0 pci15: on pcib7 vgapci0: port 0x8000-0x807f mem 0xef000000-0xefffffff,0xee600000-0xee63ffff at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3020-0x302f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x3068-0x306f,0x305c-0x305f,0x3060-0x3067,0x3058-0x305b,0x3030-0x303f mem 0xee000000-0xee0003ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 NULL mp in getnewvnode() Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 200 packets/entry by default acd0: CDROM at ata0-master UDMA33 ad4: 239372MB at ata2-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a Sincerely yours, Sergey Prokofiev From owner-freebsd-net@FreeBSD.ORG Fri May 16 15:58:40 2008 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 EEA2E10656AF for ; Fri, 16 May 2008 15:58:40 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from logos.sky.od.ua (logos.sky.od.ua [81.25.224.11]) by mx1.freebsd.org (Postfix) with ESMTP id 52F9D8FC0A for ; Fri, 16 May 2008 15:58:40 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from localhost (localhost [127.0.0.1]) by logos.sky.od.ua (Postfix) with ESMTP id BC0B8102CD9 for ; Fri, 16 May 2008 18:58:38 +0300 (EEST) Date: Fri, 16 May 2008 18:58:38 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-net@freebsd.org Message-ID: <20080516185813.H866@logos.sky.od.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: em0: watchdog timeout -- resetting 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, 16 May 2008 15:58:41 -0000 Hi All! I have a problem with Intel NIC after upgrade from 7-STABLE(25Mar2008,) to 7-STABLE(5May2008,) on motherboard Supermicro PDSMi-LN4+ http://www.supermicro.com/products/motherboard/Xeon3000/3000/PDSMi-LN4+.cfm The NIC em0 is hangup at 16May with messages: May 16 12:57:18 sphinx kernel: em0: watchdog timeout -- resetting May 16 12:57:18 sphinx kernel: em0: Hardware Initialization Failed May 16 12:57:18 sphinx kernel: em0: Unable to initialize the hardware May 16 12:59:09 sphinx kernel: em0: link state changed to DOWN > kenv | grep smbios: smbios.bios.reldate="08/27/2007" smbios.bios.vendor="Phoenix Technologies LTD" smbios.bios.version="6.00" smbios.chassis.maker="Supermicro" smbios.chassis.serial="0123456789" smbios.chassis.tag=" " smbios.chassis.version="0123456789" smbios.planar.maker="Supermicro" smbios.planar.product="PDSMi-LN4+" smbios.planar.serial="0123456789" smbios.planar.version="PCB Version" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Supermicro" smbios.system.product="PDSMi-LN4" smbios.system.serial="0123456789" smbios.system.uuid="7634a964-b127-0430-c299-0030489144c8" smbios.system.version="0123456789" > pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x828015d9 chip=0x27788086 rev=0xc0 hdr=0x00 vendor = 'Intel Corporation' device = 'E7230/3000/3010 Processor to I/O Controller' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x828015d9 chip=0x27798086 rev=0xc0 hdr=0x01 vendor = 'Intel Corporation' device = 'E7230/3000/3010 PCIe Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:0: class=0x060400 card=0x828015d9 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:1: class=0x060400 card=0x00000000 chip=0x27d28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:2: class=0x060400 card=0x00000000 chip=0x27d48086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:3: class=0x060400 card=0x828015d9 chip=0x27d68086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCIe Root Port' class = bridge subclass = PCI-PCI pcib7@pci0:0:30:0: class=0x060401 card=0x828015d9 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x828015d9 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface Controller - 27B8' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x828015d9 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x010601 card=0x828015d9 chip=0x27c18086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub SATA cc=AHCI' class = mass storage ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x828015d9 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6702PXH PCI Express-to-PCI Express Bridge' class = bridge subclass = PCI-PCI ioapic0@pci0:1:0:1: class=0x080020 card=0x828015d9 chip=0x03268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '6700/6702PXH I/OxAPIC Interrupt Controller A' class = base peripheral subclass = interrupt controller em0@pci0:9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci0:10:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em2@pci0:11:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet em3@pci0:12:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet vgapci0@pci0:15:0:0: class=0x030000 card=0x828015d9 chip=0x002018ca rev=0x00 hdr=0x00 vendor = 'XGI Technology Inc' class = display subclass = VGA > dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #1: Mon May 5 15:48:42 EEST 2008 proks@sphinx.sky.od.ua:/usr/obj/usr/src/sys/SPHINX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2394.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2094850048 (1997 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 est0: Setting 1200 MHz p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Setting 1200 MHz p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 17 at device 28.0 on pci0 pci9: on pcib3 em0: port 0x4000-0x401f mem 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:91:44:c8 pcib4: irq 16 at device 28.1 on pci0 pci10: on pcib4 em1: port 0x5000-0x501f mem 0xee300000-0xee31ffff irq 17 at device 0.0 on pci10 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:91:44:c9 pcib5: irq 18 at device 28.2 on pci0 pci11: on pcib5 em2: port 0x6000-0x601f mem 0xee400000-0xee41ffff irq 18 at device 0.0 on pci11 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:91:44:ca pcib6: irq 19 at device 28.3 on pci0 pci12: on pcib6 em3: port 0x7000-0x701f mem 0xee500000-0xee51ffff irq 19 at device 0.0 on pci12 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:91:44:cb pcib7: at device 30.0 on pci0 pci15: on pcib7 vgapci0: port 0x8000-0x807f mem 0xef000000-0xefffffff,0xee600000-0xee63ffff at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3020-0x302f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x3068-0x306f,0x305c-0x305f,0x3060-0x3067,0x3058-0x305b,0x3030-0x303f mem 0xee000000-0xee0003ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 NULL mp in getnewvnode() Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 200 packets/entry by default acd0: CDROM at ata0-master UDMA33 ad4: 239372MB at ata2-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a Sincerely yours, Sergey Prokofiev From owner-freebsd-net@FreeBSD.ORG Fri May 16 16:05:35 2008 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 79D90106564A for ; Fri, 16 May 2008 16:05:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.freebsd.org (Postfix) with ESMTP id 316A98FC14 for ; Fri, 16 May 2008 16:05:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so446762wra.13 for ; Fri, 16 May 2008 09:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sv5THTRpn9u17hPyGstVztQ8dHq60vjuAh8R2cu3kHI=; b=JrCiqP9WUrFGe3OXmKC8wEHvl519U9lNUXI3vDLutmJs0sqAHBPelIvET8keQGwsUZuibZVH0D1dSS9uxZ3iVGQYGjf9Qetef3BgNXtkhlpbBPWACAzLZsnGw+hkt4fQ24GTfR8aj7Ufgi+d1n2CoEjRqLP0nfcRuIxSVv8XfX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SCceUQyBFIhLlLuysCwv+HZLRC48jUYWi16YRKMSiFJ9fi6BOtiCiOH6+d8QTQRaBQGfsBvbDqGobe/g/YR428hFGoSiqS/9dnyP1X8gW2jgmXjToEF2YBCRvI8ZsVst27w7wqcV5l7Vr6EJ/kCLwbPcaGdPMUYRyZhqlFups/k= Received: by 10.114.151.13 with SMTP id y13mr3877420wad.148.1210953897612; Fri, 16 May 2008 09:04:57 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Fri, 16 May 2008 09:04:57 -0700 (PDT) Message-ID: <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> Date: Fri, 16 May 2008 09:04:57 -0700 From: "Jack Vogel" To: "Prokofiev S.P." In-Reply-To: <20080516185813.H866@logos.sky.od.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080516185813.H866@logos.sky.od.ua> Cc: freebsd-net@freebsd.org Subject: Re: em0: watchdog timeout -- resetting 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, 16 May 2008 16:05:35 -0000 Did you ever install the fix to the 82573 NIC eeprom? If not search mail archive for 82573, it's a DOS binary that will patch your prom. Also check for BIOS update from SM. Jack On Fri, May 16, 2008 at 8:58 AM, Prokofiev S.P. wrote: > > Hi All! > > I have a problem with Intel NIC after upgrade from > 7-STABLE(25Mar2008,) > to 7-STABLE(5May2008,) > on motherboard Supermicro PDSMi-LN4+ > http://www.supermicro.com/products/motherboard/Xeon3000/3000/PDSMi-LN4+.cfm > > The NIC em0 is hangup at 16May with messages: > > May 16 12:57:18 sphinx kernel: em0: watchdog timeout -- resetting > May 16 12:57:18 sphinx kernel: em0: Hardware Initialization Failed > May 16 12:57:18 sphinx kernel: em0: Unable to initialize the hardware > May 16 12:59:09 sphinx kernel: em0: link state changed to DOWN > >> kenv | grep smbios: > > smbios.bios.reldate="08/27/2007" > smbios.bios.vendor="Phoenix Technologies LTD" > smbios.bios.version="6.00" > smbios.chassis.maker="Supermicro" > smbios.chassis.serial="0123456789" > smbios.chassis.tag=" " > smbios.chassis.version="0123456789" > smbios.planar.maker="Supermicro" > smbios.planar.product="PDSMi-LN4+" > smbios.planar.serial="0123456789" > smbios.planar.version="PCB Version" > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker="Supermicro" > smbios.system.product="PDSMi-LN4" > smbios.system.serial="0123456789" > smbios.system.uuid="7634a964-b127-0430-c299-0030489144c8" > smbios.system.version="0123456789" > >> pciconf -lv > > hostb0@pci0:0:0:0: class=0x060000 card=0x828015d9 chip=0x27788086 > rev=0xc0 hdr=0x00 > vendor = 'Intel Corporation' > device = 'E7230/3000/3010 Processor to I/O Controller' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0x828015d9 chip=0x27798086 > rev=0xc0 hdr=0x01 > vendor = 'Intel Corporation' > device = 'E7230/3000/3010 PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:28:0: class=0x060400 card=0x828015d9 chip=0x27d08086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:28:1: class=0x060400 card=0x00000000 chip=0x27d28086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib5@pci0:0:28:2: class=0x060400 card=0x00000000 chip=0x27d48086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib6@pci0:0:28:3: class=0x060400 card=0x828015d9 chip=0x27d68086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib7@pci0:0:30:0: class=0x060401 card=0x828015d9 chip=0x244e8086 > rev=0xe1 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface > to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0x828015d9 chip=0x27b88086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '945GL Intel 82801GB/GR (ICH7 Family) LPC Interface > Controller - 27B8' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:31:1: class=0x01018a card=0x828015d9 chip=0x27df8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) Ultra ATA Storage Controller' > class = mass storage > subclass = ATA > atapci1@pci0:0:31:2: class=0x010601 card=0x828015d9 chip=0x27c18086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801GB I/O Controller Hub SATA cc=AHCI' > class = mass storage > ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x828015d9 chip=0x27da8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) SMBus Controller' > class = serial bus > subclass = SMBus > pcib2@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 > rev=0x09 hdr=0x01 > vendor = 'Intel Corporation' > device = '6702PXH PCI Express-to-PCI Express Bridge' > class = bridge > subclass = PCI-PCI > ioapic0@pci0:1:0:1: class=0x080020 card=0x828015d9 chip=0x03268086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '6700/6702PXH I/OxAPIC Interrupt Controller A' > class = base peripheral > subclass = interrupt controller > em0@pci0:9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller > (Copper)' > class = network > subclass = ethernet > em1@pci0:10:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > em2@pci0:11:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > em3@pci0:12:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > vgapci0@pci0:15:0:0: class=0x030000 card=0x828015d9 chip=0x002018ca > rev=0x00 hdr=0x00 > vendor = 'XGI Technology Inc' > class = display > subclass = VGA > >> dmesg: > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-STABLE #1: Mon May 5 15:48:42 EEST 2008 > proks@sphinx.sky.od.ua:/usr/obj/usr/src/sys/SPHINX > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz (2394.02-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 > Features=0xbfebfbff > Features2=0xe39d > AMD Features=0x20100000 > AMD Features2=0x1 > Cores per package: 2 > real memory = 2146304000 (2046 MB) > avail memory = 2094850048 (1997 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > est0: on cpu0 > est0: Setting 1200 MHz > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est1: Setting 1200 MHz > p4tcc1: on cpu1 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > pcib3: irq 17 at device 28.0 on pci0 > pci9: on pcib3 > em0: port 0x4000-0x401f mem > 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:30:48:91:44:c8 > pcib4: irq 16 at device 28.1 on pci0 > pci10: on pcib4 > em1: port 0x5000-0x501f mem > 0xee300000-0xee31ffff irq 17 at device 0.0 on pci10 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:30:48:91:44:c9 > pcib5: irq 18 at device 28.2 on pci0 > pci11: on pcib5 > em2: port 0x6000-0x601f mem > 0xee400000-0xee41ffff irq 18 at device 0.0 on pci11 > em2: Using MSI interrupt > em2: [FILTER] > em2: Ethernet address: 00:30:48:91:44:ca > pcib6: irq 19 at device 28.3 on pci0 > pci12: on pcib6 > em3: port 0x7000-0x701f mem > 0xee500000-0xee51ffff irq 19 at device 0.0 on pci12 > em3: Using MSI interrupt > em3: [FILTER] > em3: Ethernet address: 00:30:48:91:44:cb > pcib7: at device 30.0 on pci0 > pci15: on pcib7 > vgapci0: port 0x8000-0x807f mem > 0xef000000-0xefffffff,0xee600000-0xee63ffff at device 0.0 on pci15 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3020-0x302f at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x3068-0x306f,0x305c-0x305f,0x3060-0x3067,0x3058-0x305b,0x3030-0x303f mem > 0xee000000-0xee0003ff irq 19 at device 31.2 on pci0 > atapci1: [ITHREAD] > atapci1: AHCI Version 01.10 controller with 4 ports detected > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > ichsmb0: port 0x1100-0x111f irq 19 > at device 31.3 on pci0 > ichsmb0: [GIANT-LOCKED] > ichsmb0: [ITHREAD] > smbus0: on ichsmb0 > smb0: on smbus0 > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > NULL mp in getnewvnode() > Timecounters tick every 1.000 msec > ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding > enabled, default to accept, logging limited to 200 packets/entry by default > acd0: CDROM at ata0-master UDMA33 > ad4: 239372MB at ata2-master SATA300 > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad4s1a > > Sincerely yours, > Sergey Prokofiev > _______________________________________________ > 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 Fri May 16 18:09:54 2008 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 63486106564A for ; Fri, 16 May 2008 18:09:54 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from logos.sky.od.ua (logos.sky.od.ua [81.25.224.11]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8BD8FC1A for ; Fri, 16 May 2008 18:09:53 +0000 (UTC) (envelope-from proks@logos.sky.od.ua) Received: from localhost (localhost [127.0.0.1]) by logos.sky.od.ua (Postfix) with ESMTP id 567F4102CCE; Fri, 16 May 2008 21:09:52 +0300 (EEST) Date: Fri, 16 May 2008 21:09:52 +0300 (EEST) From: "Prokofiev S.P." To: Jack Vogel In-Reply-To: <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> Message-ID: <20080516210223.A19166@logos.sky.od.ua> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em0: watchdog timeout -- resetting 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, 16 May 2008 18:09:54 -0000 How install the fix to the 82573 NIC eeprom? Please help... On Fri, 16 May 2008, Jack Vogel wrote: > Did you ever install the fix to the 82573 NIC eeprom? If not > search mail archive for 82573, it's a DOS binary that will > patch your prom. Also check for BIOS update from SM. > > Jack > From owner-freebsd-net@FreeBSD.ORG Fri May 16 18:51:22 2008 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 E70D4106567A for ; Fri, 16 May 2008 18:51:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id BBD1F8FC29 for ; Fri, 16 May 2008 18:51:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so331003wah.3 for ; Fri, 16 May 2008 11:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UMbGRmVoGHOQa4kGTzGCv5wMA6J1BAg7iL5h9CY4KqQ=; b=hNW0CTgspasG3MtlIlDPJxBz60UBBMYGKC2tvgt0V2MlgjRcE8EhsKzLaCXAoQqd1JwmjeUgtTmIHyNS9zp5Ude9GEYUmX2x50gsFKbMCySJCGKn4njpMSfpUadH3z+Gtcd3MBfO03jaf0aahHWq6Owy5x/Rtg/7ShoVY+GXh8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tLF8jEPwPjWR7FUmKCBQcvmihG3X5NW70AfaMj94UPzwlrxrt/lDRJJuDvBMh3fnxqlcSEVwEnWzmQcSMnzCtExBgUg84RSUruLJip8UcIxVLlU+qTw8bYehwQyMff+Tix0+vTPzR3HKG36uMhRCO8SrcBQIM79Ji1KKA8G0RpA= Received: by 10.114.181.6 with SMTP id d6mr4059141waf.50.1210963882358; Fri, 16 May 2008 11:51:22 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Fri, 16 May 2008 11:51:22 -0700 (PDT) Message-ID: <2a41acea0805161151l5b51d2edl84d0ac30fa77cad5@mail.gmail.com> Date: Fri, 16 May 2008 11:51:22 -0700 From: "Jack Vogel" To: "Prokofiev S.P." In-Reply-To: <20080516210223.A19166@logos.sky.od.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <20080516210223.A19166@logos.sky.od.ua> Cc: freebsd-net@freebsd.org Subject: Re: em0: watchdog timeout -- resetting 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, 16 May 2008 18:51:23 -0000 On Fri, May 16, 2008 at 11:09 AM, Prokofiev S.P. wrote: > > > How install the fix to the 82573 NIC eeprom? > Please help... Once you locate the fix its a zip file as I recall, when unzipped it is a DOS executable, you can make a driver diskette and then put the patcher on that (or a USB drive if you have one that is bootable) then run the patcher from DOS. I am not sure this is the source of your problem, but absolutely any SuperMicro system that has an 82573 should have this fix applied. Regards, Jack > On Fri, 16 May 2008, Jack Vogel wrote: > >> Did you ever install the fix to the 82573 NIC eeprom? If not >> search mail archive for 82573, it's a DOS binary that will >> patch your prom. Also check for BIOS update from SM. >> >> Jack >> > From owner-freebsd-net@FreeBSD.ORG Fri May 16 22:58:08 2008 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 18E5C1065672; Fri, 16 May 2008 22:58:08 +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 E4A0E8FC1D; Fri, 16 May 2008 22:58:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4GMw7Vr000248; Fri, 16 May 2008 22:58:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4GMw7Yr000244; Fri, 16 May 2008 22:58:07 GMT (envelope-from linimon) Date: Fri, 16 May 2008 22:58:07 GMT Message-Id: <200805162258.m4GMw7Yr000244@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd 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, 16 May 2008 22:58:08 -0000 Synopsis: [netgraph] [panic] kernel panic due to netgraph mpd Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 16 22:57:55 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123741 From owner-freebsd-net@FreeBSD.ORG Sat May 17 01:45:01 2008 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 573E9106566C; Sat, 17 May 2008 01:45:01 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1A38FC19; Sat, 17 May 2008 01:45:01 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4H1j1Y3015243; Sat, 17 May 2008 01:45:01 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4H1j1Zs015239; Sat, 17 May 2008 01:45:01 GMT (envelope-from remko) Date: Sat, 17 May 2008 01:45:01 GMT Message-Id: <200805170145.m4H1j1Zs015239@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/123726: page fault after ppp restart and pf resync 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, 17 May 2008 01:45:01 -0000 Synopsis: page fault after ppp restart and pf resync Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat May 17 01:44:37 UTC 2008 Responsible-Changed-Why: This could be something for the networking team. http://www.freebsd.org/cgi/query-pr.cgi?pr=123726 From owner-freebsd-net@FreeBSD.ORG Sat May 17 08:40:03 2008 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 A04921065671 for ; Sat, 17 May 2008 08:40:03 +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 8E7B78FC19 for ; Sat, 17 May 2008 08:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4H8e39w077768 for ; Sat, 17 May 2008 08:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4H8e3NM077767; Sat, 17 May 2008 08:40:03 GMT (envelope-from gnats) Date: Sat, 17 May 2008 08:40:03 GMT Message-Id: <200805170840.m4H8e3NM077767@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alexander Motin Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Motin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2008 08:40:03 -0000 The following reply was made to PR kern/123741; it has been noted by GNATS. From: Alexander Motin To: bug-followup@FreeBSD.org, mimielliot@gmail.com Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Date: Sat, 17 May 2008 11:33:29 +0300 Alexander Motin wrote: > It looks like crash due to unchecked netgraph data items exhaustion. > Attached patch should fix this crash, but problem may remain in some > other symptoms. It would be good to investigate the reason of this > exhaustion. It could be or just high netgraph load or some resource leak. I was wrong. Bug actually is not there. This patch was going to hide original items allocation problem with NG_WAITOK. That was already fixed in HEAD and going to be merged. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sat May 17 08:50:03 2008 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 2136A1065673 for ; Sat, 17 May 2008 08:50:03 +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 0F9938FC15 for ; Sat, 17 May 2008 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4H8o2s0078821 for ; Sat, 17 May 2008 08:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4H8o293078819; Sat, 17 May 2008 08:50:02 GMT (envelope-from gnats) Date: Sat, 17 May 2008 08:50:02 GMT Message-Id: <200805170850.m4H8o293078819@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/123741: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2008 08:50:03 -0000 The following reply was made to PR kern/123741; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123741: commit references a PR Date: Sat, 17 May 2008 08:43:56 +0000 (UTC) mav 2008-05-17 08:43:50 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/netgraph ng_base.c Log: MFC rev. 1.158 Use separate UMA zone for data items allocation. It is a partial rev. 1.149 rework. It allows to save several percents of CPU time on SMP by using UMA's internal per-CPU allocation limits instead of own global variable each time updated with atomics. Also it restores NG_WAITOK flag processing. PR: kern/123741 Revision Changes Path 1.135.2.9 +70 -40 src/sys/netgraph/ng_base.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat May 17 08:50:05 2008 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 2D7E9106564A for ; Sat, 17 May 2008 08:50:05 +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 1BE298FC14 for ; Sat, 17 May 2008 08:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4H8o4PP078838 for ; Sat, 17 May 2008 08:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4H8o4MF078837; Sat, 17 May 2008 08:50:04 GMT (envelope-from gnats) Date: Sat, 17 May 2008 08:50:04 GMT Message-Id: <200805170850.m4H8o4MF078837@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/123741: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2008 08:50:05 -0000 The following reply was made to PR kern/123741; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/123741: commit references a PR Date: Sat, 17 May 2008 08:46:05 +0000 (UTC) mav 2008-05-17 08:45:58 UTC FreeBSD src repository Modified files: (Branch: RELENG_6) sys/netgraph ng_base.c Log: MFC rev. 1.158 Use separate UMA zone for data items allocation. It is a partial rev. 1.149 rework. It allows to save several percents of CPU time on SMP by using UMA's internal per-CPU allocation limits instead of own global variable each time updated with atomics. Also it restores NG_WAITOK flag processing. PR: kern/123741 Revision Changes Path 1.102.2.20 +70 -40 src/sys/netgraph/ng_base.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat May 17 09:20:03 2008 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 BA6951065676 for ; Sat, 17 May 2008 09:20:03 +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 A88F48FC19 for ; Sat, 17 May 2008 09:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4H9K3RQ081330 for ; Sat, 17 May 2008 09:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4H9K39h081328; Sat, 17 May 2008 09:20:03 GMT (envelope-from gnats) Date: Sat, 17 May 2008 09:20:03 GMT Message-Id: <200805170920.m4H9K39h081328@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alexander Motin Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Motin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2008 09:20:03 -0000 The following reply was made to PR kern/123741; it has been noted by GNATS. From: Alexander Motin To: bug-followup@FreeBSD.org, mimielliot@gmail.com Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Date: Sat, 17 May 2008 11:15:52 +0300 This is a multi-part message in MIME format. --------------070906020506060104050902 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit It looks like crash due to unchecked netgraph data items exhaustion. Attached patch should fix this crash, but problem may remain in some other symptoms. It would be good to investigate the reason of this exhaustion. It could be or just high netgraph load or some resource leak. -- Alexander Motin --------------070906020506060104050902 Content-Type: text/plain; name="ng_socket.c.enomem.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ng_socket.c.enomem.patch" --- ng_socket.c.prev 2008-03-11 23:58:48.000000000 +0200 +++ ng_socket.c 2008-05-17 10:36:46.000000000 +0300 @@ -732,7 +732,8 @@ ng_connect_data(struct sockaddr *nam, st sap = (struct sockaddr_ng *) nam; /* The item will hold the node reference. */ - item = ng_package_data(NULL, NG_WAITOK); + if ((item = ng_package_data(NULL, NG_WAITOK)) == NULL) + return (ENOMEM); if ((error = ng_address_path(NULL, item, sap->sg_data, 0))) return (error); /* item is freed on failure */ --------------070906020506060104050902-- From owner-freebsd-net@FreeBSD.ORG Sat May 17 09:46:45 2008 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 C2CFD106567C; Sat, 17 May 2008 09:46:45 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9939C8FC13; Sat, 17 May 2008 09:46:45 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (mav@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4H9kjog083815; Sat, 17 May 2008 09:46:45 GMT (envelope-from mav@freefall.freebsd.org) Received: (from mav@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4H9kjhd083811; Sat, 17 May 2008 09:46:45 GMT (envelope-from mav) Date: Sat, 17 May 2008 09:46:45 GMT Message-Id: <200805170946.m4H9kjhd083811@freefall.freebsd.org> To: mimielliot@gmail.com, mav@FreeBSD.org, freebsd-net@FreeBSD.org From: mav@FreeBSD.org Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd 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, 17 May 2008 09:46:45 -0000 Synopsis: [netgraph] [panic] kernel panic due to netgraph mpd State-Changed-From-To: open->patched State-Changed-By: mav State-Changed-When: Sat May 17 09:44:34 UTC 2008 State-Changed-Why: Problem should be fixed with recent commits. http://www.freebsd.org/cgi/query-pr.cgi?pr=123741 From owner-freebsd-net@FreeBSD.ORG Sat May 17 10:52:53 2008 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 BBADE1065671; Sat, 17 May 2008 10:52:53 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 91F668FC14; Sat, 17 May 2008 10:52:53 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (matteo@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4HAqriE091594; Sat, 17 May 2008 10:52:53 GMT (envelope-from matteo@freefall.freebsd.org) Received: (from matteo@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4HAqrto091588; Sat, 17 May 2008 10:52:53 GMT (envelope-from matteo) Date: Sat, 17 May 2008 10:52:53 GMT Message-Id: <200805171052.m4HAqrto091588@freefall.freebsd.org> To: ggg_mail@inbox.ru, matteo@FreeBSD.org, freebsd-net@FreeBSD.org From: matteo@FreeBSD.org Cc: Subject: Re: kern/116185: [iwi] if_iwi driver leads system to reboot 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, 17 May 2008 10:52:53 -0000 Synopsis: [iwi] if_iwi driver leads system to reboot State-Changed-From-To: open->feedback State-Changed-By: matteo State-Changed-When: Sab 17 Mag 2008 10:52:14 UTC State-Changed-Why: Can you still experience this problem on newer FreeBSD releases? http://www.freebsd.org/cgi/query-pr.cgi?pr=116185 From owner-freebsd-net@FreeBSD.ORG Sat May 17 12:32:52 2008 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 28A991065674; Sat, 17 May 2008 12:32:52 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F264A8FC3A; Sat, 17 May 2008 12:32:51 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (matteo@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4HCWpCP001743; Sat, 17 May 2008 12:32:51 GMT (envelope-from matteo@freefall.freebsd.org) Received: (from matteo@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4HCWp9M001730; Sat, 17 May 2008 12:32:51 GMT (envelope-from matteo) Date: Sat, 17 May 2008 12:32:51 GMT Message-Id: <200805171232.m4HCWp9M001730@freefall.freebsd.org> To: ggg_mail@inbox.ru, matteo@FreeBSD.org, freebsd-net@FreeBSD.org From: matteo@FreeBSD.org Cc: Subject: Re: kern/116185: [iwi] if_iwi driver leads system to reboot 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, 17 May 2008 12:32:52 -0000 Synopsis: [iwi] if_iwi driver leads system to reboot State-Changed-From-To: feedback->closed State-Changed-By: matteo State-Changed-When: Sab 17 Mag 2008 12:32:07 UTC State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=116185 From owner-freebsd-net@FreeBSD.ORG Sat May 17 12:33:27 2008 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 24499106567C; Sat, 17 May 2008 12:33:27 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EE8278FC0A; Sat, 17 May 2008 12:33:26 +0000 (UTC) (envelope-from matteo@FreeBSD.org) Received: from freefall.freebsd.org (matteo@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4HCXQtI002065; Sat, 17 May 2008 12:33:26 GMT (envelope-from matteo@freefall.freebsd.org) Received: (from matteo@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4HCXQYb002061; Sat, 17 May 2008 12:33:26 GMT (envelope-from matteo) Date: Sat, 17 May 2008 12:33:26 GMT Message-Id: <200805171233.m4HCXQYb002061@freefall.freebsd.org> To: ggg_mail@inbox.ru, matteo@FreeBSD.org, freebsd-net@FreeBSD.org From: matteo@FreeBSD.org Cc: Subject: Re: kern/116185: [iwi] if_iwi driver leads system to reboot 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, 17 May 2008 12:33:27 -0000 Synopsis: [iwi] if_iwi driver leads system to reboot State-Changed-From-To: closed->open State-Changed-By: matteo State-Changed-When: Sab 17 Mag 2008 12:32:55 UTC State-Changed-Why: I wrongly closed this PR. Submitter cannot upgrade to 7.x so we still need to keep this open. http://www.freebsd.org/cgi/query-pr.cgi?pr=116185 From owner-freebsd-net@FreeBSD.ORG Sat May 17 14:48:56 2008 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 43D491065672; Sat, 17 May 2008 14:48:56 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from core.stromnet.se (core.stromnet.se [83.218.84.131]) by mx1.freebsd.org (Postfix) with ESMTP id ED7BF8FC24; Sat, 17 May 2008 14:48:55 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from localhost (core.stromnet.se [83.218.84.131]) by core.stromnet.se (Postfix) with ESMTP id AAC5CF58CF1; Sat, 17 May 2008 16:33:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at stromnet.se X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=0 required=6.2 tests=[AWL=2.181, BAYES_00=-2.599, RDNS_DYNAMIC=0.1, SPF_FAIL=0.693] Received: from core.stromnet.se ([83.218.84.131]) by localhost (core.stromnet.se [83.218.84.131]) (amavisd-new, port 10024) with ESMTP id 09knv3Onvj+d; Sat, 17 May 2008 16:33:23 +0200 (CEST) Received: from johan-mp.stromnet.se (90-224-172-102-no129.tbcn.telia.com [90.224.172.102]) by core.stromnet.se (Postfix) with ESMTP id 92DD4F58BC1; Sat, 17 May 2008 16:33:22 +0200 (CEST) Message-Id: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> From: =?ISO-8859-1?Q?Johan_Str=F6m?= To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 17 May 2008 16:33:20 +0200 X-Mailer: Apple Mail (2.919.2) Cc: Subject: connect(): Operation not permitted 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, 17 May 2008 14:48:56 -0000 Hello I got a FreeBSD 7 machine running mail services (among other things). =20= This machine recently replaced a FreeBSD 6.2 machine doing the same =20 tasks. Now and then I need to send alot of mail to customers (mailing list), =20= and one thing i've noticed now after the change is that when I use a =20 lot of connections subsequently (high connection rate, even if they =20 are very shortlived) inside a jail (dunno if that has anything to do =20 with it though), I start to get Operation not permitted in return to =20 connect(). I've seen this in the PHP app that sends mail, when it tried to =20 connect to localhost, as well as from postfix when it have been trying =20= to connect to amavisd on localhost, but also from postfix when it has =20= tried to connect to remote SMTP servers. I do have PF for filtering, but there are no max-src-conn-rate limits =20= enabled for any rules that is used for this. However, from one of the =20= jail I do have a hfsc queue limiting the outgoing mail traffic from =20 one jailed IP. But I'm not sure that this would be the problem, since =20= I've also seen the problem when doing localhost connects in the jail, =20= and also in other jails on an entierly different IP that is not =20 affected. Does anyone have any clues about what I can look at and tune to fix =20 this? Thanks! -- Johan Str=F6m Stromnet johan@stromnet.se http://www.stromnet.se/ From owner-freebsd-net@FreeBSD.ORG Sat May 17 15:36:54 2008 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 763061065673; Sat, 17 May 2008 15:36:54 +0000 (UTC) (envelope-from alex@trull.org) Received: from mail.internationalconspiracy.org (mail.internationalconspiracy.org [85.234.142.62]) by mx1.freebsd.org (Postfix) with ESMTP id 09EE18FC19; Sat, 17 May 2008 15:36:53 +0000 (UTC) (envelope-from alex@trull.org) Received: from localhost (mail.internationalconspiracy.org [85.234.142.62]) by mail.internationalconspiracy.org (Postfix) with ESMTP id 19770646F5; Sat, 17 May 2008 16:19:50 +0100 (BST) X-Virus-Scanned: amavisd-new at mail.internationalconspiracy.org Received: from mail.internationalconspiracy.org ([85.234.142.62]) by localhost (mail.internationalconspiracy.org [85.234.142.62]) (amavisd-new, port 10024) with LMTP id vpQpBUVHZVOI; Sat, 17 May 2008 16:19:29 +0100 (BST) Received: from [192.168.124.200] (77-96-69-222.cable.ubr09.croy.blueyonder.co.uk [77.96.69.222]) by mail.internationalconspiracy.org (Postfix) with ESMTPSA id 1C2BB646DD; Sat, 17 May 2008 16:19:29 +0100 (BST) From: Alex Trull To: Johan =?ISO-8859-1?Q?Str=F6m?= , freebsd-net@freebsd.org, freebsd-stable In-Reply-To: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4WU6AqCfRhU+2u6n9jki" Date: Sat, 17 May 2008 16:19:23 +0100 Message-Id: <1211037564.6326.27.camel@porksoda> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: Subject: Re: connect(): Operation not permitted 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, 17 May 2008 15:36:54 -0000 --=-4WU6AqCfRhU+2u6n9jki Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Johan and List, In my case a few months ago it was pahu. Don't give that fine fellow an account on your precious system ! But seriously, I had a pf-firewalled jail being being used for DNS testing, with large numbers of udp "connections" hanging around in pf state. While the default udp timeout settings in PF are lower than those of the tcp timeouts, it is was still too high for it to to remove the states in time before hitting the default 10k state limit! If this is the case with you - run 'pfctl -s state | wc -l' - when there is traffic load you may see that hitting 10k states if you've not tuned that variable. What to do next - up the state limit or lower the state timeouts. I did both, to be safe. in /etc/pf.conf these must be at the very top of the file: # options # 10k is insanely low, lets raise it.. set limit { frags 16384, states 32768 } # timeouts - see 'pfctl -s timeouts' for options - you will want to=20 # change the tcp ones rather than the udp ones for your smtp setup.=20 # but these are mine, I set them for the dns traffic. set timeout { udp.first 15, udp.single 5, udp.multiple 30 } don't forget to: $ /etc/rc.d/pf check && =EF=BB=BF/etc/rc.d/pf reload HTH, Alex On Sat, 2008-05-17 at 16:33 +0200, Johan Str=C3=B6m wrote: > Hello >=20 > I got a FreeBSD 7 machine running mail services (among other things). =20 > This machine recently replaced a FreeBSD 6.2 machine doing the same =20 > tasks. > Now and then I need to send alot of mail to customers (mailing list), =20 > and one thing i've noticed now after the change is that when I use a =20 > lot of connections subsequently (high connection rate, even if they =20 > are very shortlived) inside a jail (dunno if that has anything to do =20 > with it though), I start to get Operation not permitted in return to =20 > connect(). > I've seen this in the PHP app that sends mail, when it tried to =20 > connect to localhost, as well as from postfix when it have been trying =20 > to connect to amavisd on localhost, but also from postfix when it has =20 > tried to connect to remote SMTP servers. >=20 > I do have PF for filtering, but there are no max-src-conn-rate limits =20 > enabled for any rules that is used for this. However, from one of the =20 > jail I do have a hfsc queue limiting the outgoing mail traffic from =20 > one jailed IP. But I'm not sure that this would be the problem, since =20 > I've also seen the problem when doing localhost connects in the jail, =20 > and also in other jails on an entierly different IP that is not =20 > affected. >=20 > Does anyone have any clues about what I can look at and tune to fix =20 > this? >=20 > Thanks! >=20 > -- > Johan Str=C3=B6m > Stromnet > johan@stromnet.se > http://www.stromnet.se/ >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --=-4WU6AqCfRhU+2u6n9jki Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBILvd7ey4m6/eWxTQRAhuWAJ9MaVHRQkza3Hdb25CtQhHiz09KMwCfQzVw dSLK+Ik5TadrYUpngZeyQS4= =7Fyq -----END PGP SIGNATURE----- --=-4WU6AqCfRhU+2u6n9jki-- From owner-freebsd-net@FreeBSD.ORG Sat May 17 15:40:18 2008 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 18F86106567E for ; Sat, 17 May 2008 15:40:18 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0554C8FC1A for ; Sat, 17 May 2008 15:40:17 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 28AF21CC033; Sat, 17 May 2008 08:23:48 -0700 (PDT) Date: Sat, 17 May 2008 08:23:48 -0700 From: Jeremy Chadwick To: Johan =?iso-8859-1?Q?Str=F6m?= Message-ID: <20080517152348.GA64850@eos.sc1.parodius.com> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: connect(): Operation not permitted 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, 17 May 2008 15:40:18 -0000 On Sat, May 17, 2008 at 04:33:20PM +0200, Johan Ström wrote: > Hello > > I got a FreeBSD 7 machine running mail services (among other things). This > machine recently replaced a FreeBSD 6.2 machine doing the same tasks. > Now and then I need to send alot of mail to customers (mailing list), and > one thing i've noticed now after the change is that when I use a lot of > connections subsequently (high connection rate, even if they are very > shortlived) inside a jail (dunno if that has anything to do with it > though), I start to get Operation not permitted in return to connect(). > I've seen this in the PHP app that sends mail, when it tried to connect to > localhost, as well as from postfix when it have been trying to connect to > amavisd on localhost, but also from postfix when it has tried to connect to > remote SMTP servers. > > I do have PF for filtering, but there are no max-src-conn-rate limits > enabled for any rules that is used for this. However, from one of the jail > I do have a hfsc queue limiting the outgoing mail traffic from one jailed > IP. But I'm not sure that this would be the problem, since I've also seen > the problem when doing localhost connects in the jail, and also in other > jails on an entierly different IP that is not affected. > > Does anyone have any clues about what I can look at and tune to fix this? Operation not permitted is most commonly seen on machines using pf(4), where there are rules blocking certain outbound traffic. I believe this has nothing to do with max-src-conn-rate. Chances are some of your pf(4) rules are wrong. There is also the possibility that jails are causing your problem. I have no experience with jails, so I cannot comment on that. I'd consider re-posting your problem to freebsd-pf@freebsd.org, and include your entire pf ruleset, so people could analyse it. Output from "pfctl -s info" would also be benefitial. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Sat May 17 16:01:19 2008 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 B1A3E106564A; Sat, 17 May 2008 16:01:19 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from core.stromnet.se (core.stromnet.se [83.218.84.131]) by mx1.freebsd.org (Postfix) with ESMTP id 30C848FC0A; Sat, 17 May 2008 16:01:18 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from localhost (core.stromnet.se [83.218.84.131]) by core.stromnet.se (Postfix) with ESMTP id BBDCEF59403; Sat, 17 May 2008 18:01:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at stromnet.se X-Spam-Flag: NO X-Spam-Score: 0.294 X-Spam-Level: X-Spam-Status: No, score=0.294 tagged_above=0 required=6.2 tests=[AWL=2.100, BAYES_00=-2.599, RDNS_DYNAMIC=0.1, SPF_FAIL=0.693] Received: from core.stromnet.se ([83.218.84.131]) by localhost (core.stromnet.se [83.218.84.131]) (amavisd-new, port 10024) with ESMTP id Y9G3KTO53EEo; Sat, 17 May 2008 18:01:14 +0200 (CEST) Received: from johan-mp.stromnet.se (90-224-172-102-no129.tbcn.telia.com [90.224.172.102]) by core.stromnet.se (Postfix) with ESMTP id BAEE3F58D78; Sat, 17 May 2008 18:01:12 +0200 (CEST) Message-Id: <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> From: =?ISO-8859-1?Q?Johan_Str=F6m?= To: Alex Trull In-Reply-To: <1211037564.6326.27.camel@porksoda> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 17 May 2008 18:01:10 +0200 References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-net@freebsd.org, freebsd-stable , freebsd-pf@freebsd.org Subject: Re: connect(): Operation not permitted 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, 17 May 2008 16:01:19 -0000 First of all, for freebsd-pf subscribers, I posted my original problem =20= (in the bottom) to freebsd-net earlier, but replies seems to point to =20= PF so I'll CC there too.. On May 17, 2008, at 5:19 PM, Alex Trull wrote: > Hi Johan and List, > > In my case a few months ago it was pahu. Don't give that fine fellow =20= > an > account on your precious system ! > > > But seriously, I had a pf-firewalled jail being being used for DNS > testing, with large numbers of udp "connections" hanging around in pf > state. While the default udp timeout settings in PF are lower than =20 > those > of the tcp timeouts, it is was still too high for it to to remove the > states in time before hitting the default 10k state limit! > > If this is the case with you - run 'pfctl -s state | wc -l' - when =20 > there > is traffic load you may see that hitting 10k states if you've not =20 > tuned > that variable. > > What to do next - up the state limit or lower the state timeouts. I =20= > did > both, to be safe. > > in /etc/pf.conf these must be at the very top of the file: > > # options > # 10k is insanely low, lets raise it.. > set limit { frags 16384, states 32768 } > # timeouts - see 'pfctl -s timeouts' for options - you will want to > # change the tcp ones rather than the udp ones for your smtp setup. > # but these are mine, I set them for the dns traffic. > set timeout { udp.first 15, udp.single 5, udp.multiple 30 } > > > don't forget to: > > $ /etc/rc.d/pf check && /etc/rc.d/pf reload Ok, looked over the PF states now, but I'm not quite sure thats what =20 causing it. I have default limit on 10k states, normally I seem to =20 have around ~800 states, and when I start my test script that tries to =20= send as many mails as possible (using PHP's Pear::Mail, creating a =20 connection, sending, disconnecting, creating new connection.. and so =20 on), I can clearly see the PF state counter (pfctl -vsi) increase, but =20= the script aborts with Operation not permitted way before I hit 10k, =20 its rather around 3-4k.. If I then wait a few seconds and run the script again, I can see the =20 number of states increase even more, and if I do this enough times I =20 finally hit around 9700 states. But at this point (states exhausted), =20= I don't get Operation not permitted, instead it just seems that the =20 script blocks up a few seconds while states clear up, then continues =20 running until it gets a Operation not permitted. So, from the above results, I cant say that it looks like its the =20 states? Just tried to disable the altq rule now too, no changes (not that I =20 expected one, since its on bce0 not lo0). Another thing, which might be more approriate in freebsd-pf though.. =20 Why would it create states at all for this traffic, when my pf.conf =20 rule is "pass on lo0 inet from $jail to $jail" (i have a block drop in =20= rule to drop all traffic)? A check with pfctl -vsr reveals that the =20 actual rule inserted is "pass on lo0 inet from 123.123.123.123 to =20 123.123.123.123 flags S/SA keep state". Where did that "keep state" =20 come from? Thanks for ideas :) > > > HTH, > > Alex > > On Sat, 2008-05-17 at 16:33 +0200, Johan Str=F6m wrote: >> Hello >> >> I got a FreeBSD 7 machine running mail services (among other things). >> This machine recently replaced a FreeBSD 6.2 machine doing the same >> tasks. >> Now and then I need to send alot of mail to customers (mailing list), >> and one thing i've noticed now after the change is that when I use a >> lot of connections subsequently (high connection rate, even if they >> are very shortlived) inside a jail (dunno if that has anything to do >> with it though), I start to get Operation not permitted in return to >> connect(). >> I've seen this in the PHP app that sends mail, when it tried to >> connect to localhost, as well as from postfix when it have been =20 >> trying >> to connect to amavisd on localhost, but also from postfix when it has >> tried to connect to remote SMTP servers. >> >> I do have PF for filtering, but there are no max-src-conn-rate limits >> enabled for any rules that is used for this. However, from one of the >> jail I do have a hfsc queue limiting the outgoing mail traffic from >> one jailed IP. But I'm not sure that this would be the problem, since >> I've also seen the problem when doing localhost connects in the jail, >> and also in other jails on an entierly different IP that is not >> affected. >> >> Does anyone have any clues about what I can look at and tune to fix >> this? >> >> Thanks! >> >> -- >> Johan Str=F6m >> Stromnet >> johan@stromnet.se >> http://www.stromnet.se/ >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org=20 >> " From owner-freebsd-net@FreeBSD.ORG Sat May 17 23:51:05 2008 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 9D6301065675; Sat, 17 May 2008 23:51:05 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 75A6C8FC1F; Sat, 17 May 2008 23:51:05 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4HNp5Cr067627; Sat, 17 May 2008 23:51:05 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4HNp51n067623; Sat, 17 May 2008 23:51:05 GMT (envelope-from remko) Date: Sat, 17 May 2008 23:51:05 GMT Message-Id: <200805172351.m4HNp51n067623@freefall.freebsd.org> To: gavin@freebsd.org, remko@FreeBSD.org, freebsd-net@FreeBSD.org, remko@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/123147: [ti] [patch] ti(4) doesn't use mii, but kernel configs say it does 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, 17 May 2008 23:51:05 -0000 Synopsis: [ti] [patch] ti(4) doesn't use mii, but kernel configs say it does State-Changed-From-To: open->patched State-Changed-By: remko State-Changed-When: Sat May 17 23:50:45 UTC 2008 State-Changed-Why: reassign to myself after having this committed to HEAD Responsible-Changed-From-To: freebsd-net->remko Responsible-Changed-By: remko Responsible-Changed-When: Sat May 17 23:50:45 UTC 2008 Responsible-Changed-Why: reassign to myself after having this committed to HEAD http://www.freebsd.org/cgi/query-pr.cgi?pr=123147