From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 12:12:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27939106564A for ; Sun, 26 Aug 2012 12:12:53 +0000 (UTC) (envelope-from djmitche@gmail.com) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx1.freebsd.org (Postfix) with ESMTP id AC7C08FC0A for ; Sun, 26 Aug 2012 12:12:52 +0000 (UTC) Received: by wgbed3 with SMTP id ed3so1924520wgb.8 for ; Sun, 26 Aug 2012 05:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=QcjSuooSij49DmtKFyUHV2ZtgQjVZJSeHCUDEK2uSok=; b=MTTeqK+ny4Jx2wmA4X65oOd3nerYK7HMSYyIbTCzL8TQVfuCJQNwsZSWXtgFJaIj5g cguoIK/nw21TDZZVoRdzuAvTglBwzH/axXP95FfKGpFU2lghb/lUq+pqdjLrvxwTVp/B 2ZXRVI3HK+YULtzShW/qCofbgBrs9tRnxRyuI0ppPGtbUXJ9hk/nMbZ2c80/t5km+btF oocFzZ/AkQ32rZoAsaWeNikdfxnHgsKJh9oKWx8ZBf1dLEZJffP73/Yl8DKmsDuiSvuK ffL64KPWbQHUPkZaRHskLlIc9eDpYhrKtkmZZoqr5smoey0FAk2iJe+KGFzuj/mXXlwN JlNQ== MIME-Version: 1.0 Received: by 10.216.41.195 with SMTP id h45mr5704682web.74.1345983171402; Sun, 26 Aug 2012 05:12:51 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.223.4.215 with HTTP; Sun, 26 Aug 2012 05:12:51 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Aug 2012 08:12:51 -0400 X-Google-Sender-Auth: cV70YZFUGWIMY5HEQDDOwcyrdfk Message-ID: From: "Dustin J. Mitchell" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: bridging VLAN interfaces and STP 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, 26 Aug 2012 12:12:53 -0000 On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell wrote: > Hey folks. I'm trying to set up a system with one 802.1q-tagged > upstream, and a few untagged interfaces. So I'd like to bridge the > vlan(4) interfaces on vr1 to specific other interfaces. > > hilbert ~ # ifconfig bridge10 > bridge10: flags=8843 metric 0 mtu 1500 > ether 02:f4:a1:63:5a:0a > inet 172.16.1.21 netmask 0xffffff00 broadcast 172.16.1.255 > nd6 options=21 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: vr3 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 55 > member: vr2 flags=143 > ifmaxaddr 0 port 3 priority 128 path cost 55 > member: vr1.10 flags=143 > ifmaxaddr 0 port 8 priority 128 path cost 200000 > > Now, if I try to enable STP on these: > > hilbert ~ # ifconfig bridge10 stp vr2 > hilbert ~ # ifconfig bridge10 stp vr3 > hilbert ~ # ifconfig bridge10 stp vr1.20 > ifconfig: unable to get bridge flags: No such file or directory > > and, indeed, the first two succeeded and the third did not: > ... > member: vr3 flags=147 > ifmaxaddr 0 port 4 priority 128 path cost 55 proto rstp > role disabled state discarding > member: vr2 flags=147 > ifmaxaddr 0 port 3 priority 128 path cost 55 proto rstp > role disabled state discarding > member: vr1.10 flags=143 > ifmaxaddr 0 port 8 priority 128 path cost 200000 > > I tried a bridge interface with vlan'd members only (vr2.10 and > vr1.10, to be exact), and still saw this error. > > So it looks like you can't run STP on vlan interfaces? Can someone > confirm? Or is there a secret sysctl to enable this? > > I'll admit this is a minor point - I'll just leave STP off and not > make loops - but it'd be nice to do the right thing :) > > Dustin And I can verify that STP's *not* working on those interfaces because I just inadvertently created a forwarding loop. Incidentally, it makes sense in retrospect, but the if_bridge(4) manpage doesn't mention that gateway_enable is required for bridging to actually forward packets. Dustin From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 08:14:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4F18106564A for ; Mon, 27 Aug 2012 08:14:59 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 685DD8FC15 for ; Mon, 27 Aug 2012 08:14:59 +0000 (UTC) Received: by ialo14 with SMTP id o14so9616436ial.13 for ; Mon, 27 Aug 2012 01:14:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8OeOGoajBUobwVr60lv0mIZ86D9lJ1U2Uv4tX8oVdkA=; b=B3MPfQnVAkc1sqWJjYmR7RHgTRMNJc+t2iVzgmJ7M9c3UVr7aBvE0pSCcb1ep3S+bg NLFCtyObSVKscto+y6l7+QuVranrczgoIbEuxVKSkaZizEjlxIV0IpwTtt+tyCDyCSQ4 HRc1pklA9LfT/XS33shZvmxbCLeAa0A0H7Fgu65hs2+1y3BRadGFQNsIPOGagYOMvBsh CEJSr/l172HNMoaYTv0qa4mdbf1pPoKko/kiBZWq6C5xOj1LkpuPue5yDpKlj7S65T/2 Q7OBATguunj5jyURAr4joiARcHodcKa0PQnCo/khW6v0aiy5ea3+VSAVe5p1zVUTioBr v2gw== MIME-Version: 1.0 Received: by 10.42.156.1 with SMTP id x1mr10119816icw.51.1346055298825; Mon, 27 Aug 2012 01:14:58 -0700 (PDT) Received: by 10.64.96.131 with HTTP; Mon, 27 Aug 2012 01:14:58 -0700 (PDT) In-Reply-To: References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> Date: Mon, 27 Aug 2012 10:14:58 +0200 Message-ID: From: Damien Fleuriot To: Giulio Ferro Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl7+vUBN/XNhR0Of8+J2ghTgHcJZlCJYytqOE42wz+4XNy0za7fKhmayX4JHbSrbCuqb+wZ Cc: "freebsd-net@freebsd.org" Subject: Re: Problem with link aggregation + sshd 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, 27 Aug 2012 08:14:59 -0000 Hey Giulio, Have you had any chance to run the commands I supplied ? I'm curious as to wether you're running the same network on the 1 physical and 1 logical interface, or running 2 different ones, like 192.168.0.0/24 and 192.168.1.0/24. Removing -stable from the cc list so as to not crosspost. On 25 August 2012 13:22, Damien Fleuriot wrote: > In the meantime kindly post: > > > Ifconfig for your igb0 > Netstat -rn > Netstat -aln | grep 22 > > > > On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: > >> I'll get back to you regarding link aggregation when I'm done with groceries. >> >> We use it here in production and it works flawlessly. >> >> >> >> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >> >>> No answer, so it seems that link aggregation doesn't really work in freebsd, >>> this may help others with the same problem... >>> >>> I reverted back to one link for management and one for service, and ssh >>> works as it should... >>> >>> >>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) >>>> >>>> 1 nic is connected standalone to the management switch, the 3 other nics >>>> are connected to a switch configured for aggregation. >>>> >>>> If I configure the first nic (igb0) there is no problem, I can operate >>>> as I normally do and sshd functions normally. >>>> >>>> The problems start when I configure the 3 other nics for aggregation: >>>> >>>> in /etc/rc.conf >>>> ... >>>> ifconfig_igb1="up" >>>> ifconfig_igb2="up" >>>> ifconfig_igb3="up" >>>> >>>> cloned_interfaces=lagg0 >>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.12.7/24" >>>> ... >>>> >>>> I restart the server and the aggregation seems to work correctly, in >>>> fact ifconfig returns the correct lagg0 interface with the aggregated >>>> links, the correct protocol (lacp) and the correct ip address and the >>>> status is active. I can ping other IPs on the aggregated link. >>>> >>>> Also the other (standalone) link seems to work correctly. I can ping >>>> that address from other machines, and I can ping other IPs from that >>>> server. >>>> >>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>> servers so there seems to be no problem on the network stack. >>>> >>>> But if I try to connect to the sshd service on that server, it hangs >>>> indefinitely. On the server I find two sshd processes: >>>> /usr/sbin/sshd >>>> /usr/sbin/sshd -R >>>> >>>> There is no message in the logs. >>>> >>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there >>>> forever waiting for the pid to die (it never does) >>>> >>>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>>> another server, the ssh client may start to work correctly, then soon >>>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>> >>>> No firewall is configured, there is nothing else working on this server. >>>> >>>> Thanks for any suggestions... >>>> _______________________________________________ >>>> 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" >>> >>> _______________________________________________ >>> 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" From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 09:50:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C85E81065670 for ; Mon, 27 Aug 2012 09:50:10 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB3B8FC15 for ; Mon, 27 Aug 2012 09:50:08 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7R9o5sb045125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Aug 2012 19:50:06 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7R9nwe9094017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 19:49:58 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7R9nu7i094016; Mon, 27 Aug 2012 19:49:56 +1000 (EST) (envelope-from peter) Date: Mon, 27 Aug 2012 19:49:56 +1000 From: Peter Jeremy To: "Dustin J. Mitchell" Message-ID: <20120827094956.GA93853@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: bridging VLAN interfaces and STP 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, 27 Aug 2012 09:50:10 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" wro= te: >On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell wr= ote: >> Hey folks. I'm trying to set up a system with one 802.1q-tagged >> upstream, and a few untagged interfaces. So I'd like to bridge the >> vlan(4) interfaces on vr1 to specific other interfaces. Can you provide ifconfig output covering all the relevant interfaces. >And I can verify that STP's *not* working on those interfaces because >I just inadvertently created a forwarding loop. I'm not sure if this is intentional. >Incidentally, it makes sense in retrospect, but the if_bridge(4) >manpage doesn't mention that gateway_enable is required for bridging >to actually forward packets. If this is true, it's definitely wrong and a regression. gateway_enable relates to routing not bridging. --=20 Peter Jeremy --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA7QsQACgkQ/opHv/APuIcqHwCdEX33tbONaiwwTLuoQU16WJr2 yooAnRd9KFL/SgWeGczqLx0oMcEDVOJR =mGaY -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 09:53:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C224A1065675 for ; Mon, 27 Aug 2012 09:53:46 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 517CA8FC1A for ; Mon, 27 Aug 2012 09:53:45 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7R9ridn045154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Aug 2012 19:53:44 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7R9rcUi094068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 19:53:38 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7R9rcs4094067; Mon, 27 Aug 2012 19:53:38 +1000 (EST) (envelope-from peter) Date: Mon, 27 Aug 2012 19:53:38 +1000 From: Peter Jeremy To: Giulio Ferro Message-ID: <20120827095338.GB93853@server.rulingia.com> References: <5033FB17.7020600@zirakzigil.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <5033FB17.7020600@zirakzigil.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" Subject: Re: Problem with link aggregation + sshd 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, 27 Aug 2012 09:53:46 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-21 23:18:15 +0200, Giulio Ferro wrote: >Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) I have used lagg/lacp on 7.x, 8.x, 9.x and 10.x and haven't seen this problem. Can you please provide ifconfig output for all interfaces. --=20 Peter Jeremy --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA7Q6IACgkQ/opHv/APuIdM3QCeIEhf/ivep+VVo5SuKFl/jnjk kmgAmwXMnPbPWr+XKn4L5oVIXNec12Fa =BztU -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 11:07:17 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39A8B1065678 for ; Mon, 27 Aug 2012 11:07:17 +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 21EA58FC2E for ; Mon, 27 Aug 2012 11:07:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7RB7HcD085928 for ; Mon, 27 Aug 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7RB7GCU085926 for freebsd-net@FreeBSD.org; Mon, 27 Aug 2012 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Aug 2012 11:07:16 GMT Message-Id: <201208271107.q7RB7GCU085926@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, 27 Aug 2012 11:07:17 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/170713 net [cxgb] Driver must be loaded after boot due to timing o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169634 net [bge] Network unavailable when booting directly to Fre o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not o kern/168742 net [vlan] [panic] detaching of ethernet adapter with conf p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 415 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 11:45:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44A65106564A for ; Mon, 27 Aug 2012 11:45:49 +0000 (UTC) (envelope-from djmitche@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id C44AA8FC08 for ; Mon, 27 Aug 2012 11:45:48 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so3530336wgb.1 for ; Mon, 27 Aug 2012 04:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mRdCbdx2Hmic+koeJDogqv//Me/WTq8s84O1rE5zlog=; b=m1OUxqQJXi2Iz45wSJ1siAjFMyiLZ1MS2QNiir5PBiO3RsX6QThf4zvaeAK7jzX2Lg cWFq0ZRIjxCETGl3ljVM8IV8hYsdQ+p4lWTC3ZpUhcv2kvYWbDS+5SOmoox23aYqFt34 pSEAjPfB07I3Rpcg8blXkwCdF9G5OY0fECQXLjtmqUyVcnsRCIZG1F7/VJPt6+N0+VzG v1o2l8/dmVybxysnenP5/h35Zicj51PCjYN4yAlPH/tiRDqMD61DBq+mX3gRYqsjs9Iy gj8Q/RWToulPtMB70YTPZH7/TnzPhaCvILD9jyHaOhgRZsW5G7a1FbSpwkLxy83QfOCR sFMw== MIME-Version: 1.0 Received: by 10.216.198.10 with SMTP id u10mr6765061wen.80.1346067941598; Mon, 27 Aug 2012 04:45:41 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.223.4.215 with HTTP; Mon, 27 Aug 2012 04:45:41 -0700 (PDT) In-Reply-To: <20120827094956.GA93853@server.rulingia.com> References: <20120827094956.GA93853@server.rulingia.com> Date: Mon, 27 Aug 2012 07:45:41 -0400 X-Google-Sender-Auth: qwvbKlz4kjpdyWz4LIo7RPZIAeY Message-ID: From: "Dustin J. Mitchell" To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: bridging VLAN interfaces and STP 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, 27 Aug 2012 11:45:49 -0000 On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy wrote: > On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" wrote: >>On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell wrote: >>> Hey folks. I'm trying to set up a system with one 802.1q-tagged >>> upstream, and a few untagged interfaces. So I'd like to bridge the >>> vlan(4) interfaces on vr1 to specific other interfaces. > > Can you provide ifconfig output covering all the relevant interfaces. Sure: vr0: flags=8943 metric 0 mtu 1500 options=82809 ether 00:00:24:ce:ec:94 inet6 fe80::200:24ff:fece:ec94%vr0 prefixlen 64 scopeid 0x1 nd6 options=21 media: Ethernet autoselect (none) status: no carrier vr1: flags=8943 metric 0 mtu 1500 options=8280b ether 00:00:24:ce:ec:95 inet6 fe80::200:24ff:fece:ec95%vr1 prefixlen 64 scopeid 0x2 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active vr2: flags=8843 metric 0 mtu 1500 options=8280b ether 00:00:24:ce:ec:96 inet6 fe80::200:24ff:fece:ec96%vr2 prefixlen 64 scopeid 0x3 nd6 options=21 media: Ethernet autoselect (none) status: no carrier vr3: flags=8843 metric 0 mtu 1500 options=8280b ether 00:00:24:ce:ec:97 inet6 fe80::200:24ff:fece:ec97%vr3 prefixlen 64 scopeid 0x4 nd6 options=21 media: Ethernet autoselect (none) status: no carrier vr1.10: flags=8843 metric 0 mtu 1500 ether 00:00:24:ce:ec:95 inet 172.16.1.21 netmask 0xffffff00 broadcast 172.16.1.255 inet6 fe80::200:24ff:fece:ec95%vr1.10 prefixlen 64 scopeid 0x9 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active vlan: 10 parent interface: vr1 vr1.20: flags=8943 metric 0 mtu 1500 ether 00:00:24:ce:ec:95 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::200:24ff:fece:ec95%vr1.20 prefixlen 64 scopeid 0xa nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active vlan: 20 parent interface: vr1 bridge10: flags=8843 metric 0 mtu 1500 ether 02:f4:a1:63:5a:0a nd6 options=21 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr3 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 55 member: vr2 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 55 member: vr1.10 flags=143 ifmaxaddr 0 port 9 priority 128 path cost 200000 bridge20: flags=8843 metric 0 mtu 1500 ether 02:f4:a1:63:5a:14 nd6 options=21 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 55 member: vr1.20 flags=143 ifmaxaddr 0 port 10 priority 128 path cost 200000 >>And I can verify that STP's *not* working on those interfaces because >>I just inadvertently created a forwarding loop. > > I'm not sure if this is intentional. The forwarding loop certainly wasn't! It occurred when I had vr0 connected to a vlan 20 port, so bridge20 was involved. >>Incidentally, it makes sense in retrospect, but the if_bridge(4) >>manpage doesn't mention that gateway_enable is required for bridging >>to actually forward packets. > > If this is true, it's definitely wrong and a regression. > gateway_enable relates to routing not bridging. My reason for thinking this was that the loop began immediately after a reboot, having added gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" to rc.conf and ipfw_load="YES" ipdivert_load="YES" net.inet.ip.fw.default_to_accept="1" to loader.conf. So there could be other causes. It made so much sense, I assumed it was the case! Dustin From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 15:30:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 352D61065670 for ; Mon, 27 Aug 2012 15:30:36 +0000 (UTC) (envelope-from bthigonnet@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id BBCF08FC0A for ; Mon, 27 Aug 2012 15:30:35 +0000 (UTC) Received: by eeke52 with SMTP id e52so1624403eek.13 for ; Mon, 27 Aug 2012 08:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=s3vW2fZD6Sc0oDFTErw3rk6QbLhRkWpL8L3PHvzsyEo=; b=V1DyrbwPD19ctuBpLGU4xwPbi4rDWkfkGbEVkbvhXXfTpTMYZseX2PQa91r2zlYhL+ qE5AxHG8svst6VWTezURwgOw9aa3DVwkV8ivO7I2WIIMmTBglLJLW/dT68dDfROnjvbk KzJ+jtQnW1VbXKmMyXETmBuHHWVOlu0cOChN+Oodra2I/0vKCgIvCKwuzbRh3y6IhRpd Ousac8RSqw4kKD8Bns2JXgA2iNEw+QrplYGdbD6lfelv6vC2LyRp+EG/jmg/hysnGhms cX4a9gmPTkJgCgE46fkfGmZbUN4WXLcrCmo1+UXvDMNsPJIpaHL9BIg8+5l6FQ9tL9Zj SvwA== Received: by 10.14.203.70 with SMTP id e46mr18391326eeo.2.1346081435005; Mon, 27 Aug 2012 08:30:35 -0700 (PDT) Received: from [192.168.4.96] (uze30-1-88-126-129-209.fbx.proxad.net. [88.126.129.209]) by mx.google.com with ESMTPS id h2sm53349960eeo.3.2012.08.27.08.30.32 (version=SSLv3 cipher=OTHER); Mon, 27 Aug 2012 08:30:33 -0700 (PDT) Message-ID: <503B9298.5060602@gmail.com> Date: Mon, 27 Aug 2012 17:30:32 +0200 From: Bernard Higonnet User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Seems DHCP request is ignoring default route info FreeBSD 9.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: Mon, 27 Aug 2012 15:30:36 -0000 Hello, I have two machines running 9.0 and which use DHCP. The DHCP server is on a third machine using dnsmasq, also under 9.0, and provides an explicit default router address. dnsmasq is sending the right stuff, as evidenced by the dnsmasq log on the one hand, and by the fact that a Windows7 machine and a Windows XP machine are using the same DHCP server and those machines get the proper default gateway info on the other hand. Here is output from dnsmasq.log Aug 27 16:32:19 dnsmasq-dhcp[922]: 4078691060 sent size: 4 option: 3 router 192.168.4.1 What happens on the two FreeBSD machines is that I end up with no default gateway at all! When the same DHCP server used to provide its default gateway (i.e. the machine dnsmasq is running on) everything was OK. TIA Bernard Higonnet From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 19:22:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58BBA1065670; Mon, 27 Aug 2012 19:22:41 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id EDEB38FC14; Mon, 27 Aug 2012 19:22:40 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id 28DDE7382F; Mon, 27 Aug 2012 21:22:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id 2wz4yVuiiZ04; Mon, 27 Aug 2012 21:22:31 +0200 (CEST) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 6972C73824; Mon, 27 Aug 2012 21:22:31 +0200 (CEST) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 2B50F19BDA0; Mon, 27 Aug 2012 21:18:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id vpKMhPtnNxgB; Mon, 27 Aug 2012 21:18:11 +0200 (CEST) Received: from [192.168.231.11] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 0F49119BD9B; Mon, 27 Aug 2012 21:18:10 +0200 (CEST) Message-ID: <503BC8F5.3040208@zirakzigil.org> Date: Mon, 27 Aug 2012 21:22:29 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd 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, 27 Aug 2012 19:22:41 -0000 Hi, thanks for the answer Here is what you asked for: # ifconfig igb0 igb0: flags=8843 metric 0 mtu 1500 options=4401bb ether ... inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 inet6 .... prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.9.1 UGS 0 0 igb0 127.0.0.1 link#12 UH 0 0 lo0 192.168.9.0/24 link#1 U 0 14 igb0 192.168.9.60 link#1 UHS 0 0 lo0 192.168.12.0/24 link#13 U 0 109 lagg0 192.168.12.21 link#13 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#12 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%igb0/64 link#1 U igb0 fe80::ea39:35ff:feb6:a0d4%igb0 link#1 UHS lo0 fe80::%igb1/64 link#2 U igb1 fe80::ea39:35ff:feb6:a0d5%igb1 link#2 UHS lo0 fe80::%igb2/64 link#3 U igb2 fe80::ea39:35ff:feb6:a0d6%igb2 link#3 UHS lo0 fe80::%igb3/64 link#4 U igb3 fe80::ea39:35ff:feb6:a0d7%igb3 link#4 UHS lo0 fe80::%lo0/64 link#12 U lo0 fe80::1%lo0 link#12 UHS lo0 fe80::%lagg0/64 link#13 U lagg0 fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff01::%lo0/32 ::1 U lo0 ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 ff02::/16 ::1 UGRS lo0 ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff02::%lo0/32 ::1 U lo0 ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 # netstat -aln | grep 22 tcp4 0 0 *.22 *.* LISTEN tcp6 0 0 *.22 *.* LISTEN Note that I already tried to only listen on igb0 interface (192.168.9.60) in sshd_config, but the results are exactly the same described below. On 08/25/2012 01:22 PM, Damien Fleuriot wrote: > In the meantime kindly post: > > > Ifconfig for your igb0 > Netstat -rn > Netstat -aln | grep 22 > > > > On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: > >> I'll get back to you regarding link aggregation when I'm done with groceries. >> >> We use it here in production and it works flawlessly. >> >> >> >> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >> >>> No answer, so it seems that link aggregation doesn't really work in freebsd, >>> this may help others with the same problem... >>> >>> I reverted back to one link for management and one for service, and ssh >>> works as it should... >>> >>> >>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) >>>> >>>> 1 nic is connected standalone to the management switch, the 3 other nics >>>> are connected to a switch configured for aggregation. >>>> >>>> If I configure the first nic (igb0) there is no problem, I can operate >>>> as I normally do and sshd functions normally. >>>> >>>> The problems start when I configure the 3 other nics for aggregation: >>>> >>>> in /etc/rc.conf >>>> ... >>>> ifconfig_igb1="up" >>>> ifconfig_igb2="up" >>>> ifconfig_igb3="up" >>>> >>>> cloned_interfaces=lagg0 >>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.12.7/24" >>>> ... >>>> >>>> I restart the server and the aggregation seems to work correctly, in >>>> fact ifconfig returns the correct lagg0 interface with the aggregated >>>> links, the correct protocol (lacp) and the correct ip address and the >>>> status is active. I can ping other IPs on the aggregated link. >>>> >>>> Also the other (standalone) link seems to work correctly. I can ping >>>> that address from other machines, and I can ping other IPs from that >>>> server. >>>> >>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>> servers so there seems to be no problem on the network stack. >>>> >>>> But if I try to connect to the sshd service on that server, it hangs >>>> indefinitely. On the server I find two sshd processes: >>>> /usr/sbin/sshd >>>> /usr/sbin/sshd -R >>>> >>>> There is no message in the logs. >>>> >>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there >>>> forever waiting for the pid to die (it never does) >>>> >>>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>>> another server, the ssh client may start to work correctly, then soon >>>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>> >>>> No firewall is configured, there is nothing else working on this server. >>>> >>>> Thanks for any suggestions... >>>> _______________________________________________ >>>> 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" >>> >>> _______________________________________________ >>> 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" From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 22:37:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AE6F106566C for ; Mon, 27 Aug 2012 22:37:24 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7B78FC12 for ; Mon, 27 Aug 2012 22:37:23 +0000 (UTC) Received: by obbun3 with SMTP id un3so12208815obb.13 for ; Mon, 27 Aug 2012 15:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dogwood.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fKc0DrasDLqvmvJIAeUxxdZrAmtaba/YtECmpovyS3I=; b=UKW+jl6ZahAIUJFZSLW0ef2Jw+uuTFWVjNUsCBkdjgPk/y2qwZnpsG3T11BOAqr3oO wjAsSvcP24IvIG3CWK32MzQu+cStSWEIXdUbX8Mf2DxxH4X43xdt2ay3NPwDtvGSNe3u xkESe/KdpOTyucrnUS+smAfzOinkXP8cPv84I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=fKc0DrasDLqvmvJIAeUxxdZrAmtaba/YtECmpovyS3I=; b=lbBZVs2tcE7cmtfMi8f1HdIjehmt81aibwylVfpo8S92ivue1St2yV+ut39j4NN5cc RCEIQBj43QDkZM4O9jUQxgTwZfb6b3oTu+1Ma5R/8cKXZ0UrV3AJoxvMPeS37u8DTqFm +oR4Nl1Rw2lxr0sglip2s1QizQOavvLIJeDCJKwnkLRs9CKibgH8phopKf5VA7xlU5vC eCYpAkV9pzP7FT5rTfIWx5E3DzGaNxxyT/JQStHA18lEOyB+s7i1cntMAOG+/uXGo5ni UiUgUWnR76eCYNi0qIFH1R0P1VnDhVKboLbb14h97MCho2AZLR+3weE3lmX24ubXDayo 7XcQ== MIME-Version: 1.0 Received: by 10.60.9.134 with SMTP id z6mr10207465oea.90.1346107043086; Mon, 27 Aug 2012 15:37:23 -0700 (PDT) Received: by 10.60.148.196 with HTTP; Mon, 27 Aug 2012 15:37:23 -0700 (PDT) X-Originating-IP: [67.53.203.242] In-Reply-To: <503B9298.5060602@gmail.com> References: <503B9298.5060602@gmail.com> Date: Mon, 27 Aug 2012 12:37:23 -1000 Message-ID: From: David Cornejo To: Bernard Higonnet X-Gm-Message-State: ALoCoQnpj98/NUYDPFxfYgvew+scn4LLERqaLvq1sL31NEEMiNcf4J06kxTpuGCUpfjtPlQJyJjl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Seems DHCP request is ignoring default route info FreeBSD 9.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: Mon, 27 Aug 2012 22:37:24 -0000 On Mon, Aug 27, 2012 at 5:30 AM, Bernard Higonnet wrote: > Hello, > > I have two machines running 9.0 and which use DHCP. The DHCP server is on > a third machine using dnsmasq, also under 9.0, and provides an explicit > default router address. > > dnsmasq is sending the right stuff, as evidenced by the dnsmasq log on the > one hand, and by the fact that a Windows7 machine and a Windows XP machine > are using the same DHCP server and those machines get the proper default > gateway info on the other hand. > > Here is output from dnsmasq.log > > Aug 27 16:32:19 dnsmasq-dhcp[922]: 4078691060 sent size: 4 option: 3 > router 192.168.4.1 > > What happens on the two FreeBSD machines is that I end up with no default > gateway at all! > > When the same DHCP server used to provide its default gateway (i.e. the > machine dnsmasq is running on) everything was OK. > > TIA > Bernard Higonnet > ______________________________**_________________ > 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 > " > Can you supply the output of "netstat -nr" from the machine that is missing a default route please? From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:12:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366A01065676 for ; Tue, 28 Aug 2012 09:12:08 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB3A58FC14 for ; Tue, 28 Aug 2012 09:12:07 +0000 (UTC) Received: by ialo14 with SMTP id o14so12956987ial.13 for ; Tue, 28 Aug 2012 02:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lBH6YS4ZVhKpAODA1kyBPr7eMzjNOfwX0UXIILyyCtA=; b=QrSnI669C1wxUdH/keZZiJgUXhF+zhbp62/16rfTgl3iSp2oFeOIXwTzP0rOnTtkjT K9wT96dQOmPS+UHhZh6+1ifIm8Mu9JdZSLjKK/v8l5NNMttvy6dItvoBIklQ4UPLYBm4 HdoBFKsRuG137YSZ6UacFKrzZzhVCQy0CaMXkL/cXGtX/2Gjz013nIMDCXRNxac3Pv3Q UEx7EfGtC4dXQvdXhcq1AClgcPEP5K0iyPVjBDsQIbKwuPZUiAJtUxVlx0G0J/Z7VvvE 10mYguLmW0jVO4QASsEdLqTziXB8DJ91Pc3+FMrJ7MofpkGadU8L5RF7Xykkdyruccch /dag== MIME-Version: 1.0 Received: by 10.42.156.1 with SMTP id x1mr13079767icw.51.1346145127251; Tue, 28 Aug 2012 02:12:07 -0700 (PDT) Received: by 10.64.96.131 with HTTP; Tue, 28 Aug 2012 02:12:07 -0700 (PDT) In-Reply-To: <503BC8F5.3040208@zirakzigil.org> References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> Date: Tue, 28 Aug 2012 11:12:07 +0200 Message-ID: From: Damien Fleuriot To: Giulio Ferro Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkfZmwx37isHZLWARWiMqRO588WHPpe0PgDyQJnTSvTXYk0oswO0kRxpQFUDfOkKg2yHpjL Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd 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, 28 Aug 2012 09:12:08 -0000 Hi Giulio, Just to clear things up: igb0: 192.168.9.60/24 lagg0: 192.168.12.21/24 What's the IP of the host you're trying ssh connections from ? Also, just in case, did you enable any firewall ? (PF, ipfw) On 27 August 2012 21:22, Giulio Ferro wrote: > Hi, thanks for the answer > > Here is what you asked for: > > # ifconfig igb0 > igb0: flags=8843 metric 0 mtu 1500 > > options=4401bb > ether ... > inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 > inet6 .... prefixlen 64 scopeid 0x1 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.9.1 UGS 0 0 igb0 > 127.0.0.1 link#12 UH 0 0 lo0 > 192.168.9.0/24 link#1 U 0 14 igb0 > 192.168.9.60 link#1 UHS 0 0 lo0 > 192.168.12.0/24 link#13 U 0 109 lagg0 > 192.168.12.21 link#13 UHS 0 0 lo0 > > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS lo0 > ::1 link#12 UH lo0 > ::ffff:0.0.0.0/96 ::1 UGRS lo0 > fe80::/10 ::1 UGRS lo0 > fe80::%igb0/64 link#1 U igb0 > fe80::ea39:35ff:feb6:a0d4%igb0 link#1 UHS lo0 > fe80::%igb1/64 link#2 U igb1 > fe80::ea39:35ff:feb6:a0d5%igb1 link#2 UHS lo0 > fe80::%igb2/64 link#3 U igb2 > fe80::ea39:35ff:feb6:a0d6%igb2 link#3 UHS lo0 > fe80::%igb3/64 link#4 U igb3 > fe80::ea39:35ff:feb6:a0d7%igb3 link#4 UHS lo0 > fe80::%lo0/64 link#12 U lo0 > fe80::1%lo0 link#12 UHS lo0 > fe80::%lagg0/64 link#13 U lagg0 > fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 > ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 > ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 > ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 > ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 > ff01::%lo0/32 ::1 U lo0 > ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U > lagg0 > ff02::/16 ::1 UGRS lo0 > ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 > ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 > ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 > ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 > ff02::%lo0/32 ::1 U lo0 > ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U > lagg0 > > > > # netstat -aln | grep 22 > tcp4 0 0 *.22 *.* LISTEN > tcp6 0 0 *.22 *.* LISTEN > > Note that I already tried to only listen on igb0 interface (192.168.9.60) in > sshd_config, but the results are exactly > the same described below. > > > > > > > > On 08/25/2012 01:22 PM, Damien Fleuriot wrote: >> >> In the meantime kindly post: >> >> >> Ifconfig for your igb0 >> Netstat -rn >> Netstat -aln | grep 22 >> >> >> >> On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: >> >>> I'll get back to you regarding link aggregation when I'm done with >>> groceries. >>> >>> We use it here in production and it works flawlessly. >>> >>> >>> >>> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >>> >>>> No answer, so it seems that link aggregation doesn't really work in >>>> freebsd, >>>> this may help others with the same problem... >>>> >>>> I reverted back to one link for management and one for service, and ssh >>>> works as it should... >>>> >>>> >>>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>>> >>>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic >>>>> (igb) >>>>> >>>>> 1 nic is connected standalone to the management switch, the 3 other >>>>> nics >>>>> are connected to a switch configured for aggregation. >>>>> >>>>> If I configure the first nic (igb0) there is no problem, I can operate >>>>> as I normally do and sshd functions normally. >>>>> >>>>> The problems start when I configure the 3 other nics for aggregation: >>>>> >>>>> in /etc/rc.conf >>>>> ... >>>>> ifconfig_igb1="up" >>>>> ifconfig_igb2="up" >>>>> ifconfig_igb3="up" >>>>> >>>>> cloned_interfaces=lagg0 >>>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport >>>>> igb3 192.168.12.7/24" >>>>> ... >>>>> >>>>> I restart the server and the aggregation seems to work correctly, in >>>>> fact ifconfig returns the correct lagg0 interface with the aggregated >>>>> links, the correct protocol (lacp) and the correct ip address and the >>>>> status is active. I can ping other IPs on the aggregated link. >>>>> >>>>> Also the other (standalone) link seems to work correctly. I can ping >>>>> that address from other machines, and I can ping other IPs from that >>>>> server. >>>>> >>>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>>> servers so there seems to be no problem on the network stack. >>>>> >>>>> But if I try to connect to the sshd service on that server, it hangs >>>>> indefinitely. On the server I find two sshd processes: >>>>> /usr/sbin/sshd >>>>> /usr/sbin/sshd -R >>>>> >>>>> There is no message in the logs. >>>>> >>>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays >>>>> there >>>>> forever waiting for the pid to die (it never does) >>>>> >>>>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>>>> another server, the ssh client may start to work correctly, then soon >>>>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>>> >>>>> No firewall is configured, there is nothing else working on this >>>>> server. >>>>> >>>>> Thanks for any suggestions... >>>>> _______________________________________________ >>>>> 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" >>>> >>>> >>>> _______________________________________________ >>>> 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" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:24:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFF31065670 for ; Tue, 28 Aug 2012 09:24:33 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by mx1.freebsd.org (Postfix) with SMTP id A4E608FC14 for ; Tue, 28 Aug 2012 09:24:31 +0000 (UTC) Received: from [98.139.212.144] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:24:25 -0000 Received: from [98.139.213.5] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:24:25 -0000 Received: from [127.0.0.1] by smtp105.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:24:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1346145865; bh=3KK3NuarPP1Aq3tVdzNtGQHVvVlH3gd+mT8ry9HGwj8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=s4YlEWAqY2GLOwLQVnNwUybv82mK9wMnDLckFhMWQXkwcKnWpKrrPSBZlcV7iEFzfmz5qyUaf7Ih8Pumok+TPt+ZTZdZBSLph/aVrEVhOI9ZVmEBePLQ4gYXtOFPF9zFxXzxEkfFiDhcF18JnA2soNvSJWyqm9YFvX8n5uXQi9w= X-Yahoo-Newman-Id: 432194.21404.bm@smtp105.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9njmQGwVM1kRcJPgWhIy87ao4_ffksZx3Ptr0qhXMPl2oJ7 KLhNpcGz.Qks2IXKgXWYS7EAkbyWR2_P5TwW0VgcMlULmOJNsxErM0Q1zEnK PSIQ2A0hyVAMe9ZA8g.21C5xq3b1GfaIZTE3NwnUigknNPXTLKbVT1SIfq84 Dds5LoZs66ynV6aFGDBbN4MU_Qz9QClqTS.QnWFyCigyrlyaFw0L1.E74yoU a1z35DtjNVYCl4QpPBjRmle1RdFXJ_Ijj1mzg7EWE5JLrWtLRTNnO9GitI7t dTGJKC2gtPNAs2QnXwpTP8SpRDtIHgMAMrOkgKq7u6OVRX1_zvTE2MdeC1TF bPcbJd2QXHMqWBaNnq5PUII.7bTvP4xvT1FiZR2cINOosBfb6hlCucqz5DVF zseVmD0i2F_XbEMuB.7mw7XLdQXswokSC9jqaN0Shw7BdLdNGrQdp2W2jl4l SoJMhPe3u62A5yFg6G1fFvqhvswfLBEnOvjIdJWrLCuX9eO3TAf0jiOJstxa qy7JRQy9g76rnH8_ZEgyCTyZP6_w- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vc0-f182.google.com (moonlightakkiy@209.85.220.182 with plain) by smtp105.mail.bf1.yahoo.com with SMTP; 28 Aug 2012 02:24:25 -0700 PDT Received: by vcbgb22 with SMTP id gb22so7090621vcb.13 for ; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.40 with SMTP id a8mr11824140vdf.4.1346145864784; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) Received: by 10.58.114.111 with HTTP; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) Date: Tue, 28 Aug 2012 03:24:24 -0600 Message-ID: From: PseudoCylon To: Anuranjan Shukla Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Proposal for changes to network device drivers and network stack (RFC) 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, 28 Aug 2012 09:24:33 -0000 > ------------------------------ > > Message: 2 > Date: Fri, 24 Aug 2012 21:11:45 -0700 > From: Anuranjan Shukla > Subject: Proposal for changes to network device drivers and network > stack (RFC) > To: "freebsd-net@freebsd.org" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > At Juniper Networks, we've been using FreeBSD to build JUNOS (Juniper's > network operating system). So far the additions and changes to the > functionality were made inline, making the task of upgrading to new > versions of FreeBSD progressively difficult. We've been looking at JUNOS > to see if we can build it off of a clean FreeBSD base rather than making > changes to the OS inline. As part of that work, we've come up with a few > expansive change proposals to FreeBSD kernel that will make this task > possible for us, and hopefully also contribute something of interest to > the community. If the community is in agreement with these, we'd like to > contribute/commit them to FreeBSD. > > This is a proposal and an RFC. The actual nomenclature is open to ideas > (naming etc). From Juniper, Marcel (marcel@freebsd.org) will be attending > the upcoming DevSummit at Cambridge. He's indicated that interested folks > are welcome to chat with him about this stuff during the summit. > > The changes we propose are (the code/diffs etc are indicated > at the end of this email): > > - Network Device Drivers > - Building FreeBSD kernel without network stack, network stack as a module > - Changes to mbuf and socket structures (minor member additions) > > Network Device Drivers: > ----------------------- > As we indicated during DevSummit 2012, JUNOS extended the interface > functionality in a big way to support logical interfaces, interface > hierarchies and scaling in general. Not surprisingly this resulted in > changing the drivers to use our custom interface structure(s). A simple > way to resolve this without impacting the rest of the large codebase is to > avoid directly accessing (get/set) the ifnet structure from the drivers. > Using get/set functions to update the functionality would make the driver > more 'flexible' for the network stack to work with in situations where the > stack wants to extend the interface functionality. > > For eg, > > em_start_locked(struct ifnet *ifp, struct tx_ring *txr) > { > - struct adapter *adapter = ifp->if_softc; > + struct adapter *adapter = if_getsoftc(ifp); > struct mbuf *m_head; > > EM_TX_LOCK_ASSERT(txr); > > - if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) != > + if ((if_getdrvflags(ifp) & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) != > IFF_DRV_RUNNING) > return; > > if (!adapter->link_active) > return; > > - while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > + while (!if_sendq_empty(ifp)) { > /* Call cleanup if number of TX descriptors low */ > if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > em_txeof(txr); > if (txr->tx_avail < EM_MAX_SCATTER) { > - ifp->if_drv_flags |= IFF_DRV_OACTIVE; > + if_setdrvflagbits(ifp,IFF_DRV_OACTIVE, 0); > break; > } > - IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); > + m_head = if_dequeue(ifp); > if (m_head == NULL) > break; > /* > @@ -1010,7 +1009,7 @@ em_start_locked(struct ifnet *ifp, struct tx_ring > if (em_xmit(txr, &m_head)) { > if (m_head == NULL) > break; > - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > + if_sendq_prepend(ifp, m_head); > break; > > This allows Juniper to have its own interface structure(s) instead of > ifnet, and still be able to use the driver without modification. Since the > notion of ifnet is abstracted away, other users can also find this useful > in plugging in functionality without having muck around in the driver code. > > The ifnet split/restructuring was discussed in DevSummit at BSDCan in May > 2012. This change can also aid in that work. > Non-attendees like me would better read the minutes before commenting anything, but http://wiki.freebsd.org/201205DevSummit/Network indicates the result is TBD. So, I will just dump my thought. Wouldn't using prepossessor macro or hooking be more flexible? (Could support multiple functionality.) i.e. #ifndef LOOK_MA_NEW_IFNET #define IF_GETDRVFLAGS(f) f->if_drv_flags ... #else #define IF_GETDRVFLAGS(f) new_getdrvflags(f) ... #endif or init somewhere ifp->if_getdrvflags = new_getdrvflags; ... and call if ((ifp->if_getdrvflags(ifp) & ... AK From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:45:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A18106564A for ; Tue, 28 Aug 2012 09:45:39 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8DADC8FC0A for ; Tue, 28 Aug 2012 09:45:38 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q7S9jaUg017214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Aug 2012 11:45:37 +0200 Received: from portgus.lan (51.Red-79-159-211.staticIP.rima-tde.net [79.159.211.51]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q7S9jZqE003935 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 11:45:36 +0200 Message-ID: <503C930C.3010405@entel.upc.edu> Date: Tue, 28 Aug 2012 11:44:44 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 28 Aug 2012 11:45:37 +0200 (CEST) Subject: Problem adding more than 8 network adapters 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, 28 Aug 2012 09:45:39 -0000 Hi, I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm facing is that I can't use more than 8 network adapters plugged to the virtual machine. Recent VirtualBox releases (since the 4.2RC1) allow, with the ICH9 chipset, to plug more than 8 network adapters. It doesn't matter what type of network adapter I use, FreeBSD seems not to see more than 8. I tried the same configuration (virtual machine with ICH9 chipset and ten network adapters) with a Linux distribution (ubuntu). Linux seems to see all the network adapters. That makes me think I don't need to contact emulation@. I don't know if it's a net@ problem or maybe it is a problem with the emulated PCI-bridge and then stable@ should be contacted. Also, I'm not sure if a real machine would support more than 8 network adapters or not. Any hints would be appreciated. Best, Gustau -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau PИrez i Querol O O O Departament d'Enginyeria TelemЮtica O O O Universitat PolitХcnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:49:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7B231065670; Tue, 28 Aug 2012 09:48:59 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id 670858FC08; Tue, 28 Aug 2012 09:48:59 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1T6IPp-000GWe-UA; Tue, 28 Aug 2012 10:48:58 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6IPp-00068O-TS; Tue, 28 Aug 2012 10:48:57 +0100 To: auryn@zirakzigil.org, freebsd-net@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <503884A0.50708@zirakzigil.org> Message-Id: From: Pete French Date: Tue, 28 Aug 2012 10:48:57 +0100 Cc: Subject: Re: Problem with link aggregation + sshd 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, 28 Aug 2012 09:49:00 -0000 > No answer, so it seems that link aggregation doesn't really work in freebsd, > this may help others with the same problem... I used to use LCAP a lot - this was a few years ago, but the critical point was that it only worked if all the cables went to the same logcial switch. Using a pair of switches for redundancy works fine, as long as they are of the type which stacvk and look like a single physical switch software-wise. Saying "it doesnt really work in freebsd" is, to be honest, not so far off the mark (if somewhat harshly phrased) - but it can be made to behave if you do it in a certain way, and when it does it runs very nicely. Note that I havent tried it since 2008, so it maye have been improved since then, or had regressions, but I suggest trying it into a single switch and seeing what happens. cheers, -pete. From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 15:40:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 871B8106566C for ; Tue, 28 Aug 2012 15:40:38 +0000 (UTC) (envelope-from bthigonnet@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9CE8FC1A for ; Tue, 28 Aug 2012 15:40:37 +0000 (UTC) Received: by eeke52 with SMTP id e52so2127581eek.13 for ; Tue, 28 Aug 2012 08:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KKQy63a/rp0jDbazRoBxbNpwX2FRPdAIcI91FcvBN/8=; b=Ewi3v9TTR/fGO8jEBZPpl2BxhFymoQmWojM1H0QzKhM4hzNb9WLRP3nhTAOfRGiWA2 jSdaZvgrjb5JhyBKZgn9+7NxJhSJg9dwbm7SIjqDaqN2KmLEBtnlkXGgnZmiOfxXeAR6 upHx1aHmqcl7a4uzwpe0u/jsOz9RZlCE57Z6y+8B0XmuDJmNIPF4x70RylUJo3oUr5t5 sXuNbq5ONsId7J2deI30VQ/eiOE4MqMsv81k1g/YZHbQltOEMQKWFXvPoYPIdHRb1Ko8 KVwfvQx7zdt5Xi+MoSlSEiYrEgpYplO+nMxlsA1xS+ZDn0b95cEa6mvU1Z8PqVL04mAk 0RKg== Received: by 10.14.204.72 with SMTP id g48mr22667334eeo.45.1346168431271; Tue, 28 Aug 2012 08:40:31 -0700 (PDT) Received: from [192.168.4.96] (uze30-1-88-126-129-209.fbx.proxad.net. [88.126.129.209]) by mx.google.com with ESMTPS id h42sm62170941eem.5.2012.08.28.08.40.29 (version=SSLv3 cipher=OTHER); Tue, 28 Aug 2012 08:40:30 -0700 (PDT) Message-ID: <503CE66B.8000702@gmail.com> Date: Tue, 28 Aug 2012 17:40:27 +0200 From: Bernard Higonnet User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <503B9298.5060602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Seems DHCP request is ignoring default route info FreeBSD 9.0 - more info... 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, 28 Aug 2012 15:40:38 -0000 On 28/08/2012 00:37, David Cornejo wrote: > > > On Mon, Aug 27, 2012 at 5:30 AM, Bernard Higonnet > wrote: > > Hello, > > I have two machines running 9.0 and which use DHCP. The DHCP server > is on a third machine using dnsmasq, also under 9.0, and provides an > explicit default router address. > > dnsmasq is sending the right stuff, as evidenced by the dnsmasq log > on the one hand, and by the fact that a Windows7 machine and a > Windows XP machine are using the same DHCP server and those machines > get the proper default gateway info on the other hand. > > Here is output from dnsmasq.log > > Aug 27 16:32:19 dnsmasq-dhcp[922]: 4078691060 sent > size: 4 option: 3 router 192.168.4.1 > > What happens on the two FreeBSD machines is that I end up with no > default gateway at all! > > When the same DHCP server used to provide its default gateway (i.e. > the machine dnsmasq is running on) everything was OK. > > TIA > Bernard Higonnet > _________________________________________________ > 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 > " > > > Can you supply the output of "netstat -nr" from the machine that is > missing a default route please? I hope I shall not be flamed too severely, but I did not mention something in my original email because I thought it not pertinent, but it turns out to have been... I have instructed dnsmasq to a) specify a non-standard default gateway and b) add a classless-static-route Each of these instructions are handled correctly by the FreeBSD machines making a DHCP request, but not both at the same time. If dnsmasq sends both, only the classless-static-route will be correctly handled and there will be no default gateway at all. If dnsmasq does not provide the classless-static-route, the desired default gateway works fine ?? Bernard Higonnet From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 18:46:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5284F106566C for ; Tue, 28 Aug 2012 18:46:14 +0000 (UTC) (envelope-from thciobanu@nth.ro) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C3AC58FC08 for ; Tue, 28 Aug 2012 18:46:13 +0000 (UTC) Received: by weyx56 with SMTP id x56so12351411wey.13 for ; Tue, 28 Aug 2012 11:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nth.ro; s=ga; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=Sats1dvDH0XDSWPrzv9qnW7mig2lZ02vgrr1G7RhtqE=; b=Z49haNJnQOLprucwkmOxiOFS+wNnPPP9AU9mT8BJjGULaWX3k4HG8rfiimTCp3GSIq IbymmitOyDvjRyWuMyeUPPfKFH96QrQ36TWdhtm0L5WePmN76bSzAuNqttIa0OQRkYBb +GmGKEvzI8IpnZf+XvbeWcGGlKa5cwBHaHo9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=Sats1dvDH0XDSWPrzv9qnW7mig2lZ02vgrr1G7RhtqE=; b=GzCjoEIV54TreKPbHGzizPMVTHINIlisac0O9g6b8fDL/rMZezZEzTpth8sPjilKhO Nahjo6QGVFBqNqA0r32mkTcKAR6ZfUtMPPo/MH1+8wIQUoxSp3r7TJx7N806j1qtE5kW axIvr56zGiwCJ6DhRDvne0dvhEESF/ETYkVzUV27c40GtGQ0DUDAuiSxE+AKAgKhT8N+ onh+Uj1eIRqTU8S32ApF2d6f6YtjyA7X9R1zjlpP7/OBj6u873y7AavE5Txwd19sliK0 1na1AGq7D6E4qWnZy1r4saz7mvxm4RSVfkIw6Gzs8s541LzasywVYi5py4ih6AQxQrlG HkrQ== Received: by 10.216.242.196 with SMTP id i46mr8938709wer.140.1346179566929; Tue, 28 Aug 2012 11:46:06 -0700 (PDT) Received: from unknown ([86.121.79.151]) by mx.google.com with ESMTPS id ef5sm9242871wib.3.2012.08.28.11.46.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 11:46:06 -0700 (PDT) Date: Tue, 28 Aug 2012 21:45:38 +0300 From: Theodor-Iulian Ciobanu To: Bernard Higonnet Message-ID: <20120828214538.00006729@unknown> In-Reply-To: <503CE66B.8000702@gmail.com> References: <503B9298.5060602@gmail.com> <503CE66B.8000702@gmail.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.24.8; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmjqYA+fwY/FM1oaAf7DSApZ/bFr4cFrU8FpmKNTim0C9JC1B2HuXgPdcV2XCggnQ1rEJ+D Cc: freebsd-net@freebsd.org Subject: Re: Seems DHCP request is ignoring default route info FreeBSD 9.0 - more info... 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, 28 Aug 2012 18:46:14 -0000 On Tue, 28 Aug 2012 17:40:27 +0200 Bernard Higonnet wrote: > On 28/08/2012 00:37, David Cornejo wrote: > > > > > > On Mon, Aug 27, 2012 at 5:30 AM, Bernard Higonnet > > > wrote: > > > > Hello, > > > > I have two machines running 9.0 and which use DHCP. The DHCP > > server is on a third machine using dnsmasq, also under 9.0, and > > provides an explicit default router address. > > > > dnsmasq is sending the right stuff, as evidenced by the dnsmasq > > log on the one hand, and by the fact that a Windows7 machine and a > > Windows XP machine are using the same DHCP server and those > > machines get the proper default gateway info on the other hand. > > > > Here is output from dnsmasq.log > > > > Aug 27 16:32:19 dnsmasq-dhcp[922]: 4078691060 > > sent size: 4 option: 3 router 192.168.4.1 > > > > What happens on the two FreeBSD machines is that I end up with > > no default gateway at all! > > > > When the same DHCP server used to provide its default gateway > > (i.e. the machine dnsmasq is running on) everything was OK. > > > > TIA > > Bernard Higonnet > > _________________________________________________ > > 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 > > " > > > > > > Can you supply the output of "netstat -nr" from the machine that is > > missing a default route please? > > I hope I shall not be flamed too severely, but I did not mention > something in my original email because I thought it not pertinent, > but it turns out to have been... > > I have instructed dnsmasq to > > a) specify a non-standard default gateway and > b) add a classless-static-route This actually changes everything. :) The RFC requires DHCP clients to ignore the default route option when a classless route option exists.[1] So when using the latter, you actually have to specify at least two routes - the one you need to notify the clients of and 0.0.0.0/0, the default. Linux (or at least the distro I worked with) doesn't respect this, as it accepts the default gateway option even when classless routes are sent and some versions of Windows use a completely different option for classless routes than the standard (249 instead of 121 IIRC). FreeBSD > Each of these instructions are handled correctly by the FreeBSD > machines making a DHCP request, but not both at the same time. If > dnsmasq sends both, only the classless-static-route will be correctly > handled and there will be no default gateway at all. > > If dnsmasq does not provide the classless-static-route, the desired > default gateway works fine > > ?? > > Bernard Higonnet -- Theo [1] From page 5 of http://tools.ietf.org/html/rfc3442 If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option. From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 08:12:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2A0106566B; Wed, 29 Aug 2012 08:12:07 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 71CB28FC14; Wed, 29 Aug 2012 08:12:06 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q7T8CVgR044816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 10:12:32 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <503DCEA4.5070305@omnilan.de> Date: Wed, 29 Aug 2012 10:11:16 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC9EB048CDD20BADFA44B3D8A" Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd 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, 29 Aug 2012 08:12:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9EB048CDD20BADFA44B3D8A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Pete French am 28.08.2012 11:48 (localtime): >> No answer, so it seems that link aggregation doesn't really work in fr= eebsd, >> this may help others with the same problem... > I used to use LCAP a lot - this was a few years ago, but the critical > point was that it only worked if all the cables went to the same > logcial switch. Using a pair of switches for redundancy works fine, as > long as they are of the type which stacvk and look like a single physic= al > switch software-wise. Link aggregation can never work with two separate switches! LACP and static trunking require both sides to bundle the same trunk. which is impossible for two separate switches. For redundancy, there is the SpanningTreeProtocol, which FreeBSD supports in bridge (4) (more preferrably RSTP). > Saying "it doesnt really work in freebsd" is, to be honest, not so > far off the mark (if somewhat harshly phrased) - but it can be made to > behave if you do it in a certain way, and when it does it runs very nic= ely. In that case, it's nothing to do with FreeBSD! -Harry --------------enigC9EB048CDD20BADFA44B3D8A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlA9ztAACgkQLDqVQ9VXb8hyUQCeOhhyP5SrY/smTLa8t9+IkzLs D60An25gzXOFipcOL6wMS9wP9AKtjqtt =wKtp -----END PGP SIGNATURE----- --------------enigC9EB048CDD20BADFA44B3D8A-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 09:02:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AF07106568B for ; Wed, 29 Aug 2012 09:02:33 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9A54B8FC19 for ; Wed, 29 Aug 2012 09:02:31 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7T92Bhw069017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 19:02:11 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7T925RS075226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 19:02:06 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7T925RD075225; Wed, 29 Aug 2012 19:02:05 +1000 (EST) (envelope-from peter) Date: Wed, 29 Aug 2012 19:02:05 +1000 From: Peter Jeremy To: Gustau =?iso-8859-1?Q?P=E9rez?= i Querol Message-ID: <20120829090205.GA75022@server.rulingia.com> References: <503C930C.3010405@entel.upc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <503C930C.3010405@entel.upc.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: Problem adding more than 8 network adapters 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, 29 Aug 2012 09:02:33 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-28 11:44:44 +0200, Gustau P=E9rez i Querol wrote: > I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm=20 >facing is that I can't use more than 8 network adapters plugged to the=20 >virtual machine. =2E.. > I don't know if it's a net@ problem or maybe it is a problem with=20 >the emulated PCI-bridge and then stable@ should be contacted. Also, I'm=20 >not sure if a real machine would support more than 8 network adapters or= =20 >not. Any hints would be appreciated. I don't think I've ever used more than 6 physical NICs in a host but don't know of any reason for >8 to not work. Can you please post a "pciconf -lv" from FreeBSD and the equivalent "lspci" from Linux. A FreeBSD verbose boot log might also help. --=20 Peter Jeremy --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA92o0ACgkQ/opHv/APuIcfbQCgiGhicTqf0UycncC+3IKMtemk pVAAoKtnN41K5OGGw0aJ8MQYPvbPzHfa =Icv+ -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 09:16:21 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5189C106564A for ; Wed, 29 Aug 2012 09:16:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 105458FC16 for ; Wed, 29 Aug 2012 09:16:20 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b893:d73f:3750:2064]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id DA4A74AC2D for ; Wed, 29 Aug 2012 13:16:13 +0400 (MSK) Date: Wed, 29 Aug 2012 13:16:10 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1865271844.20120829131610@serebryakov.spb.ru> To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 09:16:21 -0000 Hello, Freebsd-net. I have interface (vr1), most of traffic on which is PPPoE. I have ipfw firewall, which splits traffic by interfaces via: add 2000 skipto 5000 all from any to any via em0 add 2010 skipto 7000 all from any to any via wlan0 add 2020 skipto 11000 all from any to any via vr1 add 2030 skipto 13000 all from any to any via ng0 add 2040 skipto 15000 ipv6 from any to any via gif0 add 2999 deny all from any to any ... And later here are some basic checks, nat, "check-state" and some stateful rules. Does PPPoE packets match rule 2020, and other rules like "nat 1 ip from any to any"? ipfw(8) says, that "all" is synonym to "ip" but means "Matches any packet.". Does it mean really _any_ packer and all PPPoE traffic goes through NAT (useless) and "check-state" (useless too)? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 09:33:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 661DF1065673 for ; Wed, 29 Aug 2012 09:33:50 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 29FA58FC15 for ; Wed, 29 Aug 2012 09:33:48 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q7T9Xeck004524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2012 11:33:40 +0200 Received: from portgus.lan (51.Red-79-159-211.staticIP.rima-tde.net [79.159.211.51]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q7T9Xaib000911 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 11:33:39 +0200 Message-ID: <503DE1BC.4050907@entel.upc.edu> Date: Wed, 29 Aug 2012 11:32:44 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: Peter Jeremy References: <503C930C.3010405@entel.upc.edu> <20120829090205.GA75022@server.rulingia.com> In-Reply-To: <20120829090205.GA75022@server.rulingia.com> Content-Type: multipart/mixed; boundary="------------060805010707000003070607" X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 29 Aug 2012 11:33:41 +0200 (CEST) Cc: freebsd-net@freebsd.org Subject: Re: Problem adding more than 8 network adapters 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, 29 Aug 2012 09:33:50 -0000 This is a multi-part message in MIME format. --------------060805010707000003070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Al 29/08/2012 11:02, En/na Peter Jeremy ha escrit: > On 2012-Aug-28 11:44:44 +0200, Gustau PИrez i Querol wrote: >> I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm >> facing is that I can't use more than 8 network adapters plugged to the >> virtual machine. > ... >> I don't know if it's a net@ problem or maybe it is a problem with >> the emulated PCI-bridge and then stable@ should be contacted. Also, I'm >> not sure if a real machine would support more than 8 network adapters or >> not. Any hints would be appreciated. > I don't think I've ever used more than 6 physical NICs in a host but don't > know of any reason for >8 to not work. > Can you please post a "pciconf -lv" from FreeBSD and the equivalent > "lspci" from Linux. A FreeBSD verbose boot log might also help. > Sure. I'm attaching them to this mail. I hope the mailing list doesn't eat them. If it does, I will post them online and send the URL to the mailing list. I noted all the nics went to the pcib0. In linux all registered well. The test was made using PCNet interfaces, but the same happens with the Intels 82540EM|82543GC|82545EM models or with the virtio interfaces. Best, Gustau -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau PИrez i Querol O O O Departament d'Enginyeria TelemЮtica O O O Universitat PolitХcnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona --------------060805010707000003070607 Content-Type: text/plain; charset=UTF-8; name="dmesg.freebsd.verbose" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.freebsd.verbose" Table 'FACP' at 0x3fff0110 Table 'APIC' at 0x3fff0280 APIC: Found table at 0x3fff0280 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) Copyright (c) 1992-2012 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 9.0-STABLE #0 r232547: Mon Mar 5 17:46:14 UTC 2012 root@hast1:/usr/obj/usr/src/sys/GENERIC amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8168e000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff8168e180. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff8168e828. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff8168ee58. Preloaded elf obj module "/boot/modules/virtio.ko" at 0xffffffff8168eeb8. Preloaded elf obj module "/boot/modules/virtio_pci.ko" at 0xffffffff8168f420. Preloaded elf obj module "/boot/modules/virtio_blk.ko" at 0xffffffff8168f950. Preloaded elf obj module "/boot/modules/if_vtnet.ko" at 0xffffffff8168fec0. Calibrating TSC clock ... TSC clock: 2390626999 Hz CPU: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz (2390.63-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20655 Family = 6 Model = 25 Stepping = 5 Features=0x783fbff Features2=0x209 AMD Features=0x28100800 AMD Features2=0x1 real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x00000000016bf000 - 0x000000003e18ffff, 1017974784 bytes (248529 pages) avail memory = 1008267264 (961 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000203000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 ULE: setup cpu 0 ACPI: RSDP 0xe0000 00024 (v02 VBOX ) ACPI: XSDT 0x3fff0040 0004C (v01 VBOX VBOXXSDT 00000001 ASL 00000061) ACPI: FACP 0x3fff0110 000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061) ACPI: DSDT 0x3fff0530 01B96 (v01 VBOX VBOXBIOS 00000002 INTL 20120816) ACPI: FACS 0x3fff0240 00040 ACPI: APIC 0x3fff0280 00054 (v02 VBOX VBOXAPIC 00000001 ASL 00000061) ACPI: HPET 0x3fff02e0 00038 (v01 VBOX VBOXHPET 00000001 ASL 00000061) ACPI: MCFG 0x3fff0320 0003C (v01 VBOX VBOXMCFG 00000001 ASL 00000061) ACPI: SSDT 0x3fff0360 001CC (v01 VBOX VBOXCPUT 00000002 INTL 20120816) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device mem: CPU supports MTRRs but not enabled io: null: random: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xdc000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route hpet0: t0: irqs 0xffffffff (0), 64bit, periodic hpet0: t1: irqs 0xffffffff (0) hpet0: t2: irqs 0xffffffff (0) hpet0: t3: irqs 0x00000000 (0) Timecounter "HPET" frequency 14318180 Hz quality 950 cpu0: on acpi0 cpu0: switching to generic Cx mode attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 Event timer "RTC" frequency 32768 Hz quality 0 ACPI timer: 1/5 1/367 1/37 1/1 1/36 1/7 1/309 1/87 1/32 1/44 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 9 10 11 Validation 0 11 N 0 5 9 10 11 After Disable 0 255 N 0 5 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 5 9 10 11 Validation 0 9 N 0 5 9 10 11 After Disable 0 255 N 0 5 9 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 9 10 11 Validation 0 11 N 0 5 9 10 11 After Disable 0 255 N 0 5 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 9 10 11 Validation 0 11 N 0 5 9 10 11 After Disable 0 255 N 0 5 9 10 11 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0x40000000-0xffdfffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x80ee, dev=0xbeef, revid=0x00 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 23, enabled pcib0: allocated type 3 (0xe0000000-0xe07fffff) for rid 10 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=3, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=9 map[10]: type I/O Port, range 32, base 0xd000, size 5, enabled pcib0: allocated type 4 (0xd000-0xd01f) for rid 10 of pci0:0:3:0 map[14]: type Memory, range 32, base 0xf0000000, size 12, enabled pcib0: allocated type 3 (0xf0000000-0xf0000fff) for rid 14 of pci0:0:3:0 map[18]: type Memory, range 32, base 0xf0080000, size 19, enabled pcib0: allocated type 3 (0xf0080000-0xf00fffff) for rid 18 of pci0:0:3:0 pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 19 found-> vendor=0x80ee, dev=0xcafe, revid=0x00 domain=0, bus=0, slot=4, func=0 class=08-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type I/O Port, range 32, base 0xd020, size 5, enabled pcib0: allocated type 4 (0xd020-0xd03f) for rid 10 of pci0:0:4:0 map[14]: type Memory, range 32, base 0xf0400000, size 22, enabled pcib0: allocated type 3 (0xf0400000-0xf07fffff) for rid 14 of pci0:0:4:0 map[18]: type Prefetchable Memory, range 32, base 0xf0800000, size 14, enabled pcib0: allocated type 3 (0xf0800000-0xf0803fff) for rid 18 of pci0:0:4:0 pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x7113, revid=0x08 domain=0, bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 23 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=5 map[10]: type I/O Port, range 32, base 0xd040, size 5, enabled pcib0: allocated type 4 (0xd040-0xd05f) for rid 10 of pci0:0:8:0 map[14]: type Memory, range 32, base 0xf0804000, size 12, enabled pcib0: allocated type 3 (0xf0804000-0xf0804fff) for rid 14 of pci0:0:8:0 map[18]: type Memory, range 32, base 0xf0880000, size 19, enabled pcib0: allocated type 3 (0xf0880000-0xf08fffff) for rid 18 of pci0:0:8:0 pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 16 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 map[10]: type I/O Port, range 32, base 0xd060, size 5, enabled pcib0: allocated type 4 (0xd060-0xd07f) for rid 10 of pci0:0:9:0 map[14]: type Memory, range 32, base 0xf0900000, size 12, enabled pcib0: allocated type 3 (0xf0900000-0xf0900fff) for rid 14 of pci0:0:9:0 map[18]: type Memory, range 32, base 0xf0980000, size 19, enabled pcib0: allocated type 3 (0xf0980000-0xf09fffff) for rid 18 of pci0:0:9:0 pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 17 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=10 map[10]: type I/O Port, range 32, base 0xd080, size 5, enabled pcib0: allocated type 4 (0xd080-0xd09f) for rid 10 of pci0:0:10:0 map[14]: type Memory, range 32, base 0xf0a00000, size 12, enabled pcib0: allocated type 3 (0xf0a00000-0xf0a00fff) for rid 14 of pci0:0:10:0 map[18]: type Memory, range 32, base 0xf0a80000, size 19, enabled pcib0: allocated type 3 (0xf0a80000-0xf0afffff) for rid 18 of pci0:0:10:0 pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=16, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=5 map[10]: type I/O Port, range 32, base 0xd0a0, size 5, enabled pcib0: allocated type 4 (0xd0a0-0xd0bf) for rid 10 of pci0:0:16:0 map[14]: type Memory, range 32, base 0xf0b00000, size 12, enabled pcib0: allocated type 3 (0xf0b00000-0xf0b00fff) for rid 14 of pci0:0:16:0 map[18]: type Memory, range 32, base 0xf0b80000, size 19, enabled pcib0: allocated type 3 (0xf0b80000-0xf0bfffff) for rid 18 of pci0:0:16:0 pcib0: matched entry for 0.16.INTA pcib0: slot 16 INTA hardwired to IRQ 16 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=17, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 map[10]: type I/O Port, range 32, base 0xd0c0, size 5, enabled pcib0: allocated type 4 (0xd0c0-0xd0df) for rid 10 of pci0:0:17:0 map[14]: type Memory, range 32, base 0xf0c00000, size 12, enabled pcib0: allocated type 3 (0xf0c00000-0xf0c00fff) for rid 14 of pci0:0:17:0 map[18]: type Memory, range 32, base 0xf0c80000, size 19, enabled pcib0: allocated type 3 (0xf0c80000-0xf0cfffff) for rid 18 of pci0:0:17:0 pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 17 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=10 map[10]: type I/O Port, range 32, base 0xd0e0, size 5, enabled pcib0: allocated type 4 (0xd0e0-0xd0ff) for rid 10 of pci0:0:18:0 map[14]: type Memory, range 32, base 0xf0d00000, size 12, enabled pcib0: allocated type 3 (0xf0d00000-0xf0d00fff) for rid 14 of pci0:0:18:0 map[18]: type Memory, range 32, base 0xf0d80000, size 19, enabled pcib0: allocated type 3 (0xf0d80000-0xf0dfffff) for rid 18 of pci0:0:18:0 pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 18 found-> vendor=0x1022, dev=0x2000, revid=0x10 domain=0, bus=0, slot=19, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=9 map[10]: type I/O Port, range 32, base 0xd100, size 5, enabled pcib0: allocated type 4 (0xd100-0xd11f) for rid 10 of pci0:0:19:0 map[14]: type Memory, range 32, base 0xf0e00000, size 12, enabled pcib0: allocated type 3 (0xf0e00000-0xf0e00fff) for rid 14 of pci0:0:19:0 map[18]: type Memory, range 32, base 0xf0e80000, size 19, enabled pcib0: allocated type 3 (0xf0e80000-0xf0efffff) for rid 18 of pci0:0:19:0 pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1000, dev=0x0054, revid=0x00 domain=0, bus=0, slot=22, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 MSI supports 1 message, vector masks map[10]: type I/O Port, range 32, base 0xd200, size 8, enabled pcib0: allocated type 4 (0xd200-0xd2ff) for rid 10 of pci0:0:22:0 map[14]: type Memory, range 32, base 0xf0f00000, size 17, enabled pcib0: allocated type 3 (0xf0f00000-0xf0f1ffff) for rid 14 of pci0:0:22:0 map[18]: type Memory, range 32, base 0xf0f20000, size 17, enabled pcib0: allocated type 3 (0xf0f20000-0xf0f3ffff) for rid 18 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2448, revid=0xf2 domain=0, bus=0, slot=24, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2448, revid=0xf2 domain=0, bus=0, slot=25, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2829, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, vector masks map[10]: type I/O Port, range 32, base 0xe000, size 3, enabled pcib0: allocated type 4 (0xe000-0xe007) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0xe008, size 2, enabled pcib0: allocated type 4 (0xe008-0xe00b) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0xe010, size 3, enabled pcib0: allocated type 4 (0xe010-0xe017) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0xe018, size 2, enabled pcib0: allocated type 4 (0xe018-0xe01b) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0xe020, size 4, enabled pcib0: allocated type 4 (0xe020-0xe02f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xf1000000, size 13, enabled pcib0: allocated type 3 (0xf1000000-0xf1001fff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 23 found-> vendor=0x106b, dev=0x003f, revid=0x00 domain=0, bus=0, slot=31, func=4 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 MSI supports 1 message, vector masks map[10]: type Memory, range 32, base 0xf1002000, size 12, enabled pcib0: allocated type 3 (0xf1002000-0xf1002fff) for rid 10 of pci0:0:31:4 pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 23 vgapci0: mem 0xe0000000-0xe07fffff irq 18 at device 2.0 on pci0 le0: port 0xd000-0xd01f mem 0xf0000000-0xf0000fff,0xf0080000-0xf00fffff irq 19 at device 3.0 on pci0 le0: 16 receive buffers, 4 transmit buffers le0: bpf attached le0: Ethernet address: 08:00:27:07:fe:dc ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 51 pci0: at device 4.0 (no driver attached) pci0: at device 7.0 (no driver attached) le1: port 0xd040-0xd05f mem 0xf0804000-0xf0804fff,0xf0880000-0xf08fffff irq 16 at device 8.0 on pci0 le1: 16 receive buffers, 4 transmit buffers le1: bpf attached le1: Ethernet address: 08:00:27:28:ae:ca ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 le2: port 0xd060-0xd07f mem 0xf0900000-0xf0900fff,0xf0980000-0xf09fffff irq 17 at device 9.0 on pci0 le2: 16 receive buffers, 4 transmit buffers le2: bpf attached le2: Ethernet address: 08:00:27:5a:0e:64 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 53 le3: port 0xd080-0xd09f mem 0xf0a00000-0xf0a00fff,0xf0a80000-0xf0afffff irq 18 at device 10.0 on pci0 le3: 16 receive buffers, 4 transmit buffers le3: bpf attached le3: Ethernet address: 08:00:27:8f:1a:d7 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 54 le4: port 0xd0a0-0xd0bf mem 0xf0b00000-0xf0b00fff,0xf0b80000-0xf0bfffff irq 16 at device 16.0 on pci0 le4: 16 receive buffers, 4 transmit buffers le4: bpf attached le4: Ethernet address: 08:00:27:59:77:ec le5: port 0xd0c0-0xd0df mem 0xf0c00000-0xf0c00fff,0xf0c80000-0xf0cfffff irq 17 at device 17.0 on pci0 le5: 16 receive buffers, 4 transmit buffers le5: bpf attached le5: Ethernet address: 08:00:27:02:9d:41 le6: port 0xd0e0-0xd0ff mem 0xf0d00000-0xf0d00fff,0xf0d80000-0xf0dfffff irq 18 at device 18.0 on pci0 le6: 16 receive buffers, 4 transmit buffers le6: bpf attached le6: Ethernet address: 08:00:27:22:bb:c7 le7: port 0xd100-0xd11f mem 0xf0e00000-0xf0e00fff,0xf0e80000-0xf0efffff irq 19 at device 19.0 on pci0 le7: 16 receive buffers, 4 transmit buffers le7: bpf attached le7: Ethernet address: 08:00:27:9a:0a:4e mpt0: port 0xd200-0xd2ff mem 0xf0f00000-0xf0f1ffff,0xf0f20000-0xf0f3ffff irq 22 at device 22.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 55 mpt0: MPI Version=1.5.0.0 mpt0: chain depth limited to 3 (from 510) mpt0: Maximum Segment Count: 123, Maximum CAM Segment Count: 33 mpt0: MsgLength=15 IOCNumber = 0 mpt0: IOCFACTS: GlobalCredits=256 BlockSize=12 bytes Request Frame Size 512 bytes Max Chain Depth 3 mpt0: IOCFACTS: Num Ports 8, FWImageSize 0, Flags=0 mpt0: PORTFACTS[1]: Type 30 PFlags 9 IID 8 MaxDev 8 mpt0: PORTFACTS[2]: Type 30 PFlags 9 IID 8 MaxDev 8 mpt0: PORTFACTS[3]: Type 30 PFlags 9 IID 8 MaxDev 8 mpt0: PORTFACTS[4]: Type 30 PFlags 9 IID 8 MaxDev 8 mpt0: PORTFACTS[5]: Type 30 PFlags 9 IID 8 MaxDev 8 mpt0: PORTFACTS[6]: Type 30 PFlags 9 IID 8 MaxDev 8 mpt0: PORTFACTS[7]: Type 30 PFlags 9 IID 8 MaxDev 8 mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). pcib1: at device 24.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: no prefetched decode pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 25.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 3 pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: domain=0, physical bus=2 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe000-0xe007,0xe008-0xe00b,0xe010-0xe017,0xe018-0xe01b,0xe020-0xe02f mem 0xf1000000-0xf1001fff irq 23 at device 31.2 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 56 ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SS 3Gbps 32cmd CCC 1ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: Caps: ohci0: mem 0xf1002000-0xf1002fff irq 23 at device 31.4 on pci0 usbus0: on ohci0 usbus0: bpf attached ohci0: usbpf: Attached battery0: on acpi0 acpi_acad0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0045 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 57 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0045 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 58 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 ppc0: using extended I/O port range acpi0: wakeup code va 0xffffff8049ede000 pa 0x4000 ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 2: ioport 0x2c00 alloc failed ahc_isa_probe 3: ioport 0x3c00 alloc failed ahc_isa_probe 4: ioport 0x4c00 alloc failed ahc_isa_probe 5: ioport 0x5c00 alloc failed ahc_isa_probe 6: ioport 0x6c00 alloc failed ahc_isa_probe 7: ioport 0x7c00 alloc failed ahc_isa_probe 8: ioport 0x8c00 alloc failed ahc_isa_probe 9: ioport 0x9c00 alloc failed ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff,0xe2000-0xe6fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices ctl: CAM Target Layer loaded Device configuration finished. procfs registered ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 lapic: Divisor 2, Frequency 500009333 Hz Timecounters tick every 10.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. usbus0: 12Mbps Full Speed USB v1.0 ahcich0: AHCI reset... ahcich0: SATA connect time=0us status=00000123 ahcich0: AHCI reset: device found ahcich0: AHCI reset: device ready after 0ms ugen0.1: at usbus0 uhub0: on usbus0 (aprobe0:ahcich0:0:0:0): SIGNATURE: eb14 battery0: battery initialization start battery0: battery initialization done, tried 1 times acpi_acad0: acline initialization start system power profile changed to 'economy' acpi_acad0: Off Line acpi_acad0: acline initialization done, tried 1 times uhub0: 8 ports with 8 removable, self powered (probe8:ctl2cam0:0:1:0): Error 6, Unretryable error pass0 at mpt0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SCSI-5 device pass0: 300.000MB/s transfers pass0: Command Queueing enabled pass1 at ahcich0 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: Serial Number VB0-1a2b3c4d pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) pass1: Command Queueing enabled da0 at mpt0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C) GEOM: new disk da0 cd0 at ahcich0 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number VB0-1a2b3c4d cd0: 300.000MB/s transfers (SATA 2.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) cd0: Command Queueing enabled cd0: cd present [82272 x 2048 byte records] Timecounter "TSC" frequency 2390626999 Hz quality 800 GEOM: new disk cd0 Trying to mount root from zfs:sistema []... start_init: trying /sbin/init --------------060805010707000003070607 Content-Type: text/plain; charset=UTF-8; name="pciconf.freebsd" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pciconf.freebsd" vgapci0@pci0:0:2:0: class=0x030000 card=0x00000000 chip=0xbeef80ee rev=0x00 hdr=0x00 vendor = 'InnoTek Systemberatung GmbH' device = 'VirtualBox Graphics Adapter' class = display subclass = VGA le0@pci0:0:3:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet none0@pci0:0:4:0: class=0x088000 card=0x00000000 chip=0xcafe80ee rev=0x00 hdr=0x00 vendor = 'InnoTek Systemberatung GmbH' device = 'VirtualBox Guest Service' class = base peripheral none1@pci0:0:7:0: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4 ACPI' class = bridge le1@pci0:0:8:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet le2@pci0:0:9:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet le3@pci0:0:10:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet le4@pci0:0:16:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet le5@pci0:0:17:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet le6@pci0:0:18:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet le7@pci0:0:19:0: class=0x020000 card=0x20001022 chip=0x20001022 rev=0x10 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = '79c970 [PCnet32 LANCE]' class = network subclass = ethernet mpt0@pci0:0:22:0: class=0x010000 card=0x80001000 chip=0x00541000 rev=0x00 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS1068 PCI-X Fusion-MPT SAS' class = mass storage subclass = SCSI pcib1@pci0:0:24:0: class=0x060401 card=0x00000000 chip=0x24488086 rev=0xf2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Mobile PCI Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:0:25:0: class=0x060401 card=0x00000000 chip=0x24488086 rev=0xf2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Mobile PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x72708086 chip=0x27b98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM (ICH7-M) LPC Interface Bridge' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x00000000 chip=0x28298086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller' class = mass storage subclass = SATA ohci0@pci0:0:31:4: class=0x0c0310 card=0x00000000 chip=0x003f106b rev=0x00 hdr=0x00 vendor = 'Apple Computer Inc.' device = 'KeyLargo/Intrepid USB' class = serial bus subclass = USB --------------060805010707000003070607 Content-Type: text/plain; charset=UTF-8; name="lspci.linux" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lspci.linux" 00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at e0000000 (32-bit, prefetchable) [size=8M] Expansion ROM at [disabled] 00:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at d000 [size=32] Memory at f0000000 (32-bit, non-prefetchable) [size=4K] Memory at f0080000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service Flags: bus master, fast devsel, latency 0, IRQ 5 I/O ports at d020 [size=32] Memory at f0400000 (32-bit, non-prefetchable) [size=4M] Memory at f0800000 (32-bit, prefetchable) [size=16K] 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08) Flags: bus master, medium devsel, latency 0, IRQ 9 Kernel modules: i2c-piix4 00:08.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 16 I/O ports at d040 [size=32] Memory at f0804000 (32-bit, non-prefetchable) [size=4K] Memory at f0880000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:09.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 17 I/O ports at d060 [size=32] Memory at f0900000 (32-bit, non-prefetchable) [size=4K] Memory at f0980000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:0a.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at d080 [size=32] Memory at f0a00000 (32-bit, non-prefetchable) [size=4K] Memory at f0a80000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:10.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 16 I/O ports at d0a0 [size=32] Memory at f0b00000 (32-bit, non-prefetchable) [size=4K] Memory at f0b80000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:11.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 17 I/O ports at d0c0 [size=32] Memory at f0c00000 (32-bit, non-prefetchable) [size=4K] Memory at f0c80000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:12.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at d0e0 [size=32] Memory at f0d00000 (32-bit, non-prefetchable) [size=4K] Memory at f0d80000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:13.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at d100 [size=32] Memory at f0e00000 (32-bit, non-prefetchable) [size=4K] Memory at f0e80000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 00:16.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS Subsystem: LSI Logic / Symbios Logic Device 8000 Flags: bus master, fast devsel, latency 64, IRQ 22 I/O ports at d200 [disabled] [size=256] Memory at f0f00000 (32-bit, non-prefetchable) [size=128K] Memory at f0f20000 (32-bit, non-prefetchable) [size=128K] Capabilities: Kernel driver in use: mptsas Kernel modules: mptsas 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 00001000-00001fff Memory behind bridge: 40000000-400fffff 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) Subsystem: Intel Corporation Device 7270 Flags: bus master, medium devsel, latency 0 Kernel modules: leds-ss4200, iTCO_wdt, intel-rng 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02) (prog-if 01 [AHCI 1.0]) Flags: bus master, fast devsel, latency 64, IRQ 40 I/O ports at e000 [size=8] I/O ports at e008 [size=4] I/O ports at e010 [size=8] I/O ports at e018 [size=4] I/O ports at e020 [size=16] Memory at f1000000 (32-bit, non-prefetchable) [size=8K] Capabilities: Kernel driver in use: ahci 00:1f.4 USB controller: Apple Inc. KeyLargo/Intrepid USB (prog-if 10 [OHCI]) Flags: bus master, fast devsel, latency 64, IRQ 23 Memory at f1002000 (32-bit, non-prefetchable) [size=4K] Capabilities: Kernel driver in use: ohci_hcd 02:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 64, IRQ 17 I/O ports at 1000 [size=32] Memory at 40080000 (32-bit, non-prefetchable) [size=4K] Memory at 40000000 (32-bit, non-prefetchable) [size=512K] Kernel driver in use: pcnet32 Kernel modules: pcnet32 --------------060805010707000003070607-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 09:38:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B2F8106566C; Wed, 29 Aug 2012 09:38:30 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id ADAC08FC1E; Wed, 29 Aug 2012 09:38:29 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1T6eiz-0006ZK-UY; Wed, 29 Aug 2012 10:38:14 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6eiz-000FgC-TV; Wed, 29 Aug 2012 10:38:13 +0100 To: h.schmalzbauer@omnilan.de, petefrench@ingresso.co.uk In-Reply-To: <503DCEA4.5070305@omnilan.de> Message-Id: From: Pete French Date: Wed, 29 Aug 2012 10:38:13 +0100 Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd 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, 29 Aug 2012 09:38:30 -0000 > Link aggregation can never work with two separate switches! LACP and > static trunking require both sides to bundle the same trunk. which is > impossible for two separate switches. These switches had a port where you could connect them together and then configure each to know about the other switch, and to do LACP across the pair of them. Or at least thats what it looked like it was capable of doing, and it appeared to be doing LACP when configured that way and connected to Windows machines, just not FreeBSD ones. But I'm not a Cisco person by any stretch of the imagination, so if that config is actually not possible then that would kind of explain why it didn't work ;-) Sorry for the misinformation! -pete. [feeling a bit foolish now] From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 10:18:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3B05106564A; Wed, 29 Aug 2012 10:18:02 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 536B68FC0A; Wed, 29 Aug 2012 10:18:01 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q7TAIW0v046920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 12:18:32 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <503DEC58.1050609@omnilan.de> Date: Wed, 29 Aug 2012 12:18:00 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB2100205CAE4CC6704DAFA3F" Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd 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, 29 Aug 2012 10:18:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2100205CAE4CC6704DAFA3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Pete French am 29.08.2012 11:38 (localtime): >> Link aggregation can never work with two separate switches! LACP and >> static trunking require both sides to bundle the same trunk. which is >> impossible for two separate switches. > These switches had a port where you could connect them together and > then configure each to know about the other switch, and to do LACP > across the pair of them. Or at least thats what it looked like it > was capable of doing, and it appeared to be doing LACP when configured > that way and connected to Windows machines, just not FreeBSD ones. But = I'm What you desciribe is well known as =E2=80=9Estacking=E2=80=9C (not to mi= x with =E2=80=9Evirtual stacking=E2=80=9C) and sorry that I haven't made clear that in such a cas= e LACP (also static trunking of course) works well and is a fantastic way to gain redundancy. When you create a physical switch stack, the individual switches are no separate switches anymore, but act like one big switch. With the advantage, that in case of a failure, and a trunk configured over two different units of the stack, the link remains active. But like mentioned, these switches are then not considered to be separate (=E2=80=9Evirtual stacking=E2=80=9C only combine them in managem= ent regards, _not_ physically, so be carefull when you look for switches with =E2=80=9Estacking=E2=80=9C capabilities!). The disadvantage of the real hardware stackable switch is the price. The cheapest way I've found is two DGS-3120 (~700$ each plus 200$ stacking cable). Ciscos and Junipers and the bigger HPs are all much above afaik. -Harry --------------enigB2100205CAE4CC6704DAFA3F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlA97FgACgkQLDqVQ9VXb8gG1wCgqn3xBuUpgGMdH2p3Zyx3ALWJ UG4Ani2Uxayyzbu4NHRo+NXWEujmT22G =4o6x -----END PGP SIGNATURE----- --------------enigB2100205CAE4CC6704DAFA3F-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 10:24:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 651491065673; Wed, 29 Aug 2012 10:24:52 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E3BDD8FC22; Wed, 29 Aug 2012 10:24:50 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q7TAPLIK047058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 12:25:21 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <503DEDF1.2020406@omnilan.de> Date: Wed, 29 Aug 2012 12:24:49 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Pete French References: <503DEC58.1050609@omnilan.de> In-Reply-To: <503DEC58.1050609@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF43D9C6B09CD2D4AB4838903" Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd 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, 29 Aug 2012 10:24:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF43D9C6B09CD2D4AB4838903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 29.08.2012 12:18 (localtime): > schrieb Pete French am 29.08.2012 11:38 (localtime): >>> Link aggregation can never work with two separate switches! LACP and >>> static trunking require both sides to bundle the same trunk. which is= >>> impossible for two separate switches. >> These switches had a port where you could connect them together and >> then configure each to know about the other switch, and to do LACP >> across the pair of them. Or at least thats what it looked like it >> was capable of doing, and it appeared to be doing LACP when configured= >> that way and connected to Windows machines, just not FreeBSD ones. But= I'm Have you checked that Windows really did LACP in your case? Sounds like it was no real hardware stack, so probably Windos just activated RSTP. FreeBSD doesn't detect any LACP/RSTP configuration features, but windows does with some NIC verndor's drivers. -Harry P.S.: Sorry for that additional answer, just forgot it in my last email. --------------enigF43D9C6B09CD2D4AB4838903 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlA97fEACgkQLDqVQ9VXb8gMgACgzrjGi0TNwuxFSZaAp07dGDhA EgEAmwYtrpmvKeSb9EMzoDDLvZK8LjTF =5bB2 -----END PGP SIGNATURE----- --------------enigF43D9C6B09CD2D4AB4838903-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 10:44:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E1C0106564A; Wed, 29 Aug 2012 10:44:33 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id DECF28FC14; Wed, 29 Aug 2012 10:44:32 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1T6fku-0007nX-5S; Wed, 29 Aug 2012 11:44:16 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6fku-000FAI-4J; Wed, 29 Aug 2012 11:44:16 +0100 To: h.schmalzbauer@omnilan.de, petefrench@ingresso.co.uk In-Reply-To: <503DEDF1.2020406@omnilan.de> Message-Id: From: Pete French Date: Wed, 29 Aug 2012 11:44:16 +0100 Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd 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, 29 Aug 2012 10:44:33 -0000 > Have you checked that Windows really did LACP in your case? Sounds like > it was no real hardware stack, so probably Windos just activated RSTP. > FreeBSD doesn't detect any LACP/RSTP configuration features, but windows > does with some NIC verndor's drivers. That is quite possible - I didnt set any of that side up, so am just trying to remember what the networking people said was going on. We may well have had some kind of magic drivers on the Windows side of things - indeed recall that there was some HP specific thing to manage the ethernet cards on those severs (DL360s). Actually I went and looked out my old emails - Cisco 3750 switches worked as a pair with LACP, Cisco 3560 ones didn't. Whatever the difference is between those two, thats the difference between working and not working :) Is that real stacking vs virtual stacking by any chance ? -pete. From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 12:33:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9C8106564A; Wed, 29 Aug 2012 12:33:01 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id DCC728FC20; Wed, 29 Aug 2012 12:33:00 +0000 (UTC) Received: by wicr5 with SMTP id r5so4683756wic.13 for ; Wed, 29 Aug 2012 05:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+N5KdQJPdBUachnjArYmyRVUm3nXLTqUbRqiqAmzkuw=; b=MnmhlV1MkSGmIXrEp/m/Oh0wxij8HFXIvYfRI1ui6Wdk5X1kEbrBhk0iiD4vs/YC/Q PBDif8eU0cIPlrTDZZeRQ3I1oEfMWfjsF6CnVQZqpLD5yih87KxqZO8kRCpnkE2S4DRp j2h4UVuiLp9dw0R9PVpx9wA7wGKRJHtowkZTwA35q2fpF0KxePp/Rn+cG7QIdI0OBzHa QzBXJkVDJRudgh/QTxX5b57N58L46Xaj2hIw1CXYM0yrCfk7PiRMmOeOz7R5QhFzKhQJ T8EfqsiZLBHP31bBKZy68nhTpNMizTOiTwfyJY98S2ielzbzv3Trh32x6on35bHp5x5H D6KA== Received: by 10.217.2.133 with SMTP id p5mr878653wes.143.1346243579421; Wed, 29 Aug 2012 05:32:59 -0700 (PDT) Received: from [10.129.32.13] (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id cl8sm10057353wib.10.2012.08.29.05.32.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 05:32:55 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=windows-1252 From: Nikolay Denev In-Reply-To: <503DEC58.1050609@omnilan.de> Date: Wed, 29 Aug 2012 15:31:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4AAF36-46D6-439A-8122-DD305B77CBB9@gmail.com> References: <503DEC58.1050609@omnilan.de> To: Harald Schmalzbauer X-Mailer: Apple Mail (2.1486) Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org, Pete French Subject: Re: Problem with link aggregation + sshd 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, 29 Aug 2012 12:33:01 -0000 On Aug 29, 2012, at 1:18 PM, Harald Schmalzbauer = wrote: > schrieb Pete French am 29.08.2012 11:38 (localtime): >>> Link aggregation can never work with two separate switches! LACP and >>> static trunking require both sides to bundle the same trunk. which = is >>> impossible for two separate switches. >> These switches had a port where you could connect them together and >> then configure each to know about the other switch, and to do LACP >> across the pair of them. Or at least thats what it looked like it >> was capable of doing, and it appeared to be doing LACP when = configured >> that way and connected to Windows machines, just not FreeBSD ones. = But I'm >=20 > What you desciribe is well known as =84stacking=93 (not to mix with = =84virtual > stacking=93) and sorry that I haven't made clear that in such a case = LACP > (also static trunking of course) works well and is a fantastic way to > gain redundancy. > When you create a physical switch stack, the individual switches are = no > separate switches anymore, but act like one big switch. > With the advantage, that in case of a failure, and a trunk configured > over two different units of the stack, the link remains active. > But like mentioned, these switches are then not considered to be > separate (=84virtual stacking=93 only combine them in management = regards, > _not_ physically, so be carefull when you look for switches with > =84stacking=93 capabilities!). > The disadvantage of the real hardware stackable switch is the price. = The > cheapest way I've found is two DGS-3120 (~700$ each plus 200$ stacking > cable). Ciscos and Junipers and the bigger HPs are all much above = afaik. >=20 > -Harry >=20 Not always. For example Extreme Networks's MLAG allows link aggregation = between two switches, that are not stacked. You just have to create a special vlan between them and = configure them for MLAG. But of course this is proprietary protocol. From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 12:44:15 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AA43106566B; Wed, 29 Aug 2012 12:44:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2A78FC1E; Wed, 29 Aug 2012 12:44:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7TCiFN8071574; Wed, 29 Aug 2012 12:44:15 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7TCiEhf071570; Wed, 29 Aug 2012 12:44:14 GMT (envelope-from jhb) Date: Wed, 29 Aug 2012 12:44:14 GMT Message-Id: <201208291244.q7TCiEhf071570@freefall.freebsd.org> To: bu7cher@yandex.ru, jhb@FreeBSD.org, freebsd-net@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: kern/168742: [vlan] [panic] detaching of ethernet adapter with configured vlans leads to 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, 29 Aug 2012 12:44:15 -0000 Synopsis: [vlan] [panic] detaching of ethernet adapter with configured vlans leads to panic State-Changed-From-To: open->closed State-Changed-By: jhb State-Changed-When: Wed Aug 29 12:44:01 UTC 2012 State-Changed-Why: Fix committed to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=168742 From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 15:01:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED8F8106566C for ; Wed, 29 Aug 2012 15:01:10 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79E978FC15 for ; Wed, 29 Aug 2012 15:01:09 +0000 (UTC) Received: by weyx56 with SMTP id x56so553720wey.13 for ; Wed, 29 Aug 2012 08:01:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=a0tPtnSyvyCOFBqy6J9ItdULiRI1246vkCWW9D/6Vgs=; b=Kbd+tD1j9zdto7LwuJsc/oPlcqaa7iosOS4ArH5+ZOqofpWX/pZFDwFWxOvFbKkX4V qG9+Z+cuhsO6NuuzyKzRgz15U/ZG8fB1yU+AqHSjmtTU4DTtEHLiBxasftXBNShh3oL7 jBWUtJXj8HrM5rAAi9dQDr9N9rSXXBEGMRrn1NEy6VYoelbGjSWd4KUiKO+xecJ0FtRm +K3WVLXFc7Gakf5on4iOBv+mUVjTFhvguxuC0sjmPahaoQve0ic4pJmxPzR5D/PrZfsK FQQbYwroSaQWCjc3q7QaSrLC630GHaNOEjihh5dmGVPROGnUbtXvcRjbIMTVgiZUvrqy z+/Q== MIME-Version: 1.0 Received: by 10.180.96.199 with SMTP id du7mr4296558wib.21.1346252469059; Wed, 29 Aug 2012 08:01:09 -0700 (PDT) Received: by 10.223.160.9 with HTTP; Wed, 29 Aug 2012 08:01:08 -0700 (PDT) In-Reply-To: <1865271844.20120829131610@serebryakov.spb.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> Date: Wed, 29 Aug 2012 08:01:08 -0700 Message-ID: From: Michael Sierchio To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmyxx2tsv3POm7ulV3RVN89q0tgSqYCZcnnuNR1aHTiJ3Uo/DBFBDtFnx+jPPU7c3c9MaGc Cc: freebsd-net@freebsd.org Subject: Re: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw? 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, 29 Aug 2012 15:01:11 -0000 On Wed, Aug 29, 2012 at 2:16 AM, Lev Serebryakov wrote: > I have interface (vr1), most of traffic on which is PPPoE. I have ipfw > firewall, which splits traffic by interfaces via: > > add 2000 skipto 5000 all from any to any via em0 > add 2010 skipto 7000 all from any to any via wlan0 > add 2020 skipto 11000 all from any to any via vr1 > add 2030 skipto 13000 all from any to any via ng0 > add 2040 skipto 15000 ipv6 from any to any via gif0 > add 2999 deny all from any to any > ... > And later here are some basic checks, nat, "check-state" and some > stateful rules. Consider separating traffic not only by interface but also direction 'via' can match traffic four different ways (at least), so match incoming traffic on an interface ip from any to any in recv vr0 and outgoing ip from any to any out xmit vr0 > Does PPPoE packets match rule 2020, and other rules like "nat 1 ip > from any to any"? Yes, and it seems that that is not what you want. The packets will be seen first by the firewall, then passed to whatever is handling PPPoE on the local box, then re-injected into the IP stack, etc. for processing by firewall rules again. Is there a pppX pseudo-interface? From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 15:01:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC019106566B for ; Wed, 29 Aug 2012 15:01:51 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 453CC8FC0A for ; Wed, 29 Aug 2012 15:01:51 +0000 (UTC) Received: by weyx56 with SMTP id x56so554364wey.13 for ; Wed, 29 Aug 2012 08:01:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dX5Y0Bod445VfU7eorUGAJprICtpEeQ7btRwVonJYh8=; b=fjDTV1Fk1gfofsz8rCFllYX8n1fkUJQARj2bwqasOgGZuUxsEHCD2hkY1qD+TfvFCs tp0l0cb+gEvRPy6Opcqz1ZqWs52Yf0ux/n4uTI1GztDsSESVyLLeocU/JF9T62pFoWc8 8KABRXjb5Ac55KMIxkHHgSMK9w8vqaQxcuq4CJRg7caeP3hEaGqSeqy5W8WzQTWyGWbx +Yrw6TAFVJDqOJiJQrr+OkMoWrrSPzZgWtkNy60qkbB4rSwCu450vpb4nUkGzv3aN9Fr v1DMb2c8eQ+UOETKRAmnhWOtsO67j7w/I0HCW8jiUQrEL4/aw363dILxdjKlWbNBh0sR TENQ== MIME-Version: 1.0 Received: by 10.180.97.106 with SMTP id dz10mr4307095wib.21.1346252510415; Wed, 29 Aug 2012 08:01:50 -0700 (PDT) Received: by 10.223.160.9 with HTTP; Wed, 29 Aug 2012 08:01:50 -0700 (PDT) In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> Date: Wed, 29 Aug 2012 08:01:50 -0700 Message-ID: From: Michael Sierchio To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm0+F0tsgL1XkDJOoyaghqhsjolAPw6PEWTkVNbfUmngTkF0qaE0eTaw9ZtM1U9eeQW83D0 Cc: freebsd-net@freebsd.org Subject: Re: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw? 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, 29 Aug 2012 15:01:51 -0000 On Wed, Aug 29, 2012 at 8:01 AM, Michael Sierchio wrote: > ip from any to any in recv vr0 "any" here is also not appropriate... From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 16:17:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7408106566B for ; Wed, 29 Aug 2012 16:17:01 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 81FB08FC17 for ; Wed, 29 Aug 2012 16:17:01 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id B0665B038228 for ; Wed, 29 Aug 2012 11:49:49 -0400 (EDT) thread-index: Ac2F/eu7fA1En7AfTReaztTxYYULtw== Received: from hometx-733b1p1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Aug 2012 11:49:48 -0400 Received: by hometx-733b1p1.corp.verio.net (sSMTP sendmail emulation); Wed, 29 Aug 2012 10:49:47 -0500 Date: Wed, 29 Aug 2012 10:49:47 -0500 Content-Transfer-Encoding: 7bit From: "David DeSimone" To: Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Message-ID: <20120829154946.GR5500@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <503DEDF1.2020406@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline In-Reply-To: Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 29 Aug 2012 15:49:48.0099 (UTC) FILETIME=[EB171130:01CD85FD] Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:17:01 -0000 Pete French wrote: > > Actually I went and looked out my old emails - Cisco 3750 switches > worked as a pair with LACP, Cisco 3560 ones didn't. Whatever the > difference is between those two, thats the difference between working > and not working :) Is that real stacking vs virtual stacking by any > chance ? The Cisco 3750 and 3560 are nearly identical; the very difference between them is that the 3750 is stackable, and the 3560 is not. So you can expect to set up working LACP bundles across stack members on the 3750, but you cannot set up working LACP bundles across two 3560 switches. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 17:30:50 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8888C106566B for ; Wed, 29 Aug 2012 17:30:50 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 208AE8FC16 for ; Wed, 29 Aug 2012 17:30:49 +0000 (UTC) Received: by eaak11 with SMTP id k11so283296eaa.13 for ; Wed, 29 Aug 2012 10:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ayaeLBWyyaPgi0rPMFkAFYykC/pQCllOjuknPPQd1oY=; b=yqD10ds8x1XSXCarYH+nUulOVKrNoKET2pZHV0e3t4GanyqY7TJ7ZlUxAfXkCBWWlh B9UAepYZZRj0E/IQxjOm5Ob5FV7sGc1pkrWle6IQMva2uAksB2wpT3tnUnaV5zuAB5pH FLDSntgCOjho7fl848gkFIMt8NRNl6RLtB3k655E1rTDVx+ExlCdxaZe5ZbLmJPgUGe0 ArpyNK6zM5OoJC4CVbkJNGA+5Clue39apwEQoKnI7Lk+xbxeJb6vc+IqfnCOlRbgR3PN p/0XYeJ4ldn3lFVcZFcCWFPzZyFWkrIhpte776YU7ByWQfY6WCqJYdXmk8jvlVTdGaeR AMOQ== MIME-Version: 1.0 Received: by 10.14.203.73 with SMTP id e49mr2955475eeo.27.1346261448850; Wed, 29 Aug 2012 10:30:48 -0700 (PDT) Received: by 10.14.219.134 with HTTP; Wed, 29 Aug 2012 10:30:48 -0700 (PDT) Date: Wed, 29 Aug 2012 10:30:48 -0700 Message-ID: From: Vijay Singh To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: witness warning in arp processing 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, 29 Aug 2012 17:30:50 -0000 All, I am seeing this warning on my 8.2 based system. taskqueue_drain with the following non-sleepable locks held: exclusive rw lle (lle) r = 0 (0xffffff0014dc9110) locked @ sys/netinet/in.c:1760 KDB: stack backtrace: kdb_backtrace() at kdb_backtrace+0x3e _witness_debugger() at _witness_debugger+0x24 witness_warn() at witness_warn+0x402 taskqueue_drain() at taskqueue_drain+0x36 cancel_delayed_work() at cancel_delayed_work+0x56 set_timeout() at set_timeout+0x18 netevent_callback() at netevent_callback+0x29 _handle_arp_update_event() at _handle_arp_update_event+0x31 in_arpinput() at in_arpinput+0xe92 arpintr() at arpintr+0x255 netisr_dispatch_src() at netisr_dispatch_src+0x14a netisr_dispatch() at netisr_dispatch+0x20 ether_demux() at ether_demux+0x281 ether_input_internal() at ether_input_internal+0x60c ether_nh_input() at ether_nh_input+0x1d netisr_dispatch_src() at netisr_dispatch_src+0x14a netisr_dispatch() at netisr_dispatch+0x20 ether_input() at ether_input+0xef lem_rxeof() at lem_rxeof+0x6ee lem_handle_rxtx() at lem_handle_rxtx+0x4f taskqueue_run_locked() at taskqueue_run_locked+0x145 taskqueue_thread_loop() at taskqueue_thread_loop+0x73 fork_exit() at fork_exit+0x180 fork_trampoline() at fork_trampoline+0xe Is this a known issue? Has it been fixed? -vijay From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 18:31:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47ED51065673 for ; Wed, 29 Aug 2012 18:31:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 01DDC8FC1D for ; Wed, 29 Aug 2012 18:31:30 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b893:d73f:3750:2064]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0F73D4AC2D; Wed, 29 Aug 2012 22:31:28 +0400 (MSK) Date: Wed, 29 Aug 2012 22:31:25 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1807373989.20120829223125@serebryakov.spb.ru> To: Michael Sierchio In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:31:31 -0000 Hello, Michael. You wrote 29 =E0=E2=E3=F3=F1=F2=E0 2012 =E3., 19:01:08: >> I have interface (vr1), most of traffic on which is PPPoE. I have ipfw >> firewall, which splits traffic by interfaces via: >> >> add 2000 skipto 5000 all from any to any via em0 >> add 2010 skipto 7000 all from any to any via wlan0 >> add 2020 skipto 11000 all from any to any via vr1 >> add 2030 skipto 13000 all from any to any via ng0 >> add 2040 skipto 15000 ipv6 from any to any via gif0 >> add 2999 deny all from any to any >> ... >> And later here are some basic checks, nat, "check-state" and some >> stateful rules. MS> Consider separating traffic not only by interface but also direction It is done in rules 1000 and 1010, 2xxx is for incoming, 3xxx for outgoing. It is only a sample/ MS> ip from any to any in recv vr0 MS> and outgoing MS> ip from any to any out xmit vr0 Yep, I'll collapse my two-rule chains in one rule. >> Does PPPoE packets match rule 2020, and other rules like "nat 1 ip >> from any to any"? MS> Yes, and it seems that that is not what you want. The packets will be MS> seen first by the firewall, then passed to whatever is handling PPPoE But there is no rule for it, and default policy is "deny"... But it works. MS> on the local box, then re-injected into the IP stack, etc. for MS> processing by firewall rules again. MS> Is there a pppX pseudo-interface? ng0, as I'm using mpd5, not system ppp. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 18:32:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29373106566C for ; Wed, 29 Aug 2012 18:32:34 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id B34458FC15 for ; Wed, 29 Aug 2012 18:32:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b893:d73f:3750:2064]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 8C42F4AC31; Wed, 29 Aug 2012 22:32:31 +0400 (MSK) Date: Wed, 29 Aug 2012 22:32:28 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <642968723.20120829223228@serebryakov.spb.ru> To: Michael Sierchio In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:32:34 -0000 Hello, Michael. You wrote 29 =E0=E2=E3=F3=F1=F2=E0 2012 =E3., 19:01:50: >> ip from any to any in recv vr0 MS> "any" here is also not appropriate... Additional checks (for correct addresses, etc) are performed at rules 11xxx :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 20:22:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4B41065673; Wed, 29 Aug 2012 20:22:59 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id 36D208FC18; Wed, 29 Aug 2012 20:22:59 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id 1F817733E4; Wed, 29 Aug 2012 22:22:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id m109XxCBAXxQ; Wed, 29 Aug 2012 22:22:49 +0200 (CEST) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 646DC733CE; Wed, 29 Aug 2012 22:22:49 +0200 (CEST) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id AA6B319B890; Wed, 29 Aug 2012 10:37:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id jjIuchcbDYlO; Wed, 29 Aug 2012 10:37:27 +0200 (CEST) Received: from [192.168.231.11] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 9609519B88A; Wed, 29 Aug 2012 10:37:26 +0200 (CEST) Message-ID: <503E7A16.6030600@zirakzigil.org> Date: Wed, 29 Aug 2012 22:22:46 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Damien Fleuriot References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd 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, 29 Aug 2012 20:23:00 -0000 On 08/28/2012 11:12 AM, Damien Fleuriot wrote: > Hi Giulio, > > > > Just to clear things up: > igb0: 192.168.9.60/24 > lagg0: 192.168.12.21/24 > Yes. Actually I notice now that the lagg0 address is different from what I wrote below in my rc.conf (192.168.12.7). I've just made many test with different configuration, but no matter, it just doesn't work... > > What's the IP of the host you're trying ssh connections from ? I'm just trying to connect to and from management interface igb0 (192.168.9.60). From external pc I do : ssh myuser@192.168.9.60 From that server I do : ssh myuser@pcaddress Just to be more precise, the consequences are: 1) daemon sshd on the server gets stuck and becomes unkillable 2) the first connection may work, but then the program ssh on the server becomes unresponsive and unkillable If I don't create a lagg0 interface and just connect (say) igb1 to the data switch, I've no problem and everything works. Just to answer others' question, I connect igb1, igb2 and igb3 to the same data switch in ports configured for aggregation. I connect igb0 to another management switch (of course not configured for aggregation) > > Also, just in case, did you enable any firewall ? (PF, ipfw) As I already said, no. Nothing is working/active on this server, just sshd. Thank you. > > > > On 27 August 2012 21:22, Giulio Ferro wrote: >> Hi, thanks for the answer >> >> Here is what you asked for: >> >> # ifconfig igb0 >> igb0: flags=8843 metric 0 mtu 1500 >> >> options=4401bb >> ether ... >> inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 >> inet6 .... prefixlen 64 scopeid 0x1 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> >> >> # netstat -rn >> Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 192.168.9.1 UGS 0 0 igb0 >> 127.0.0.1 link#12 UH 0 0 lo0 >> 192.168.9.0/24 link#1 U 0 14 igb0 >> 192.168.9.60 link#1 UHS 0 0 lo0 >> 192.168.12.0/24 link#13 U 0 109 lagg0 >> 192.168.12.21 link#13 UHS 0 0 lo0 >> >> Internet6: >> Destination Gateway Flags >> Netif Expire >> ::/96 ::1 UGRS lo0 >> ::1 link#12 UH lo0 >> ::ffff:0.0.0.0/96 ::1 UGRS lo0 >> fe80::/10 ::1 UGRS lo0 >> fe80::%igb0/64 link#1 U igb0 >> fe80::ea39:35ff:feb6:a0d4%igb0 link#1 UHS lo0 >> fe80::%igb1/64 link#2 U igb1 >> fe80::ea39:35ff:feb6:a0d5%igb1 link#2 UHS lo0 >> fe80::%igb2/64 link#3 U igb2 >> fe80::ea39:35ff:feb6:a0d6%igb2 link#3 UHS lo0 >> fe80::%igb3/64 link#4 U igb3 >> fe80::ea39:35ff:feb6:a0d7%igb3 link#4 UHS lo0 >> fe80::%lo0/64 link#12 U lo0 >> fe80::1%lo0 link#12 UHS lo0 >> fe80::%lagg0/64 link#13 U lagg0 >> fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 >> ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 >> ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 >> ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 >> ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 >> ff01::%lo0/32 ::1 U lo0 >> ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >> lagg0 >> ff02::/16 ::1 UGRS lo0 >> ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 >> ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 >> ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 >> ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 >> ff02::%lo0/32 ::1 U lo0 >> ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >> lagg0 >> >> >> >> # netstat -aln | grep 22 >> tcp4 0 0 *.22 *.* LISTEN >> tcp6 0 0 *.22 *.* LISTEN >> >> Note that I already tried to only listen on igb0 interface (192.168.9.60) in >> sshd_config, but the results are exactly >> the same described below. >> >> >> >> >> >> >> >> On 08/25/2012 01:22 PM, Damien Fleuriot wrote: >>> >>> In the meantime kindly post: >>> >>> >>> Ifconfig for your igb0 >>> Netstat -rn >>> Netstat -aln | grep 22 >>> >>> >>> >>> On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: >>> >>>> I'll get back to you regarding link aggregation when I'm done with >>>> groceries. >>>> >>>> We use it here in production and it works flawlessly. >>>> >>>> >>>> >>>> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >>>> >>>>> No answer, so it seems that link aggregation doesn't really work in >>>>> freebsd, >>>>> this may help others with the same problem... >>>>> >>>>> I reverted back to one link for management and one for service, and ssh >>>>> works as it should... >>>>> >>>>> >>>>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>>>> >>>>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic >>>>>> (igb) >>>>>> >>>>>> 1 nic is connected standalone to the management switch, the 3 other >>>>>> nics >>>>>> are connected to a switch configured for aggregation. >>>>>> >>>>>> If I configure the first nic (igb0) there is no problem, I can operate >>>>>> as I normally do and sshd functions normally. >>>>>> >>>>>> The problems start when I configure the 3 other nics for aggregation: >>>>>> >>>>>> in /etc/rc.conf >>>>>> ... >>>>>> ifconfig_igb1="up" >>>>>> ifconfig_igb2="up" >>>>>> ifconfig_igb3="up" >>>>>> >>>>>> cloned_interfaces=lagg0 >>>>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport >>>>>> igb3 192.168.12.7/24" >>>>>> ... >>>>>> >>>>>> I restart the server and the aggregation seems to work correctly, in >>>>>> fact ifconfig returns the correct lagg0 interface with the aggregated >>>>>> links, the correct protocol (lacp) and the correct ip address and the >>>>>> status is active. I can ping other IPs on the aggregated link. >>>>>> >>>>>> Also the other (standalone) link seems to work correctly. I can ping >>>>>> that address from other machines, and I can ping other IPs from that >>>>>> server. >>>>>> >>>>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>>>> servers so there seems to be no problem on the network stack. >>>>>> >>>>>> But if I try to connect to the sshd service on that server, it hangs >>>>>> indefinitely. On the server I find two sshd processes: >>>>>> /usr/sbin/sshd >>>>>> /usr/sbin/sshd -R >>>>>> >>>>>> There is no message in the logs. >>>>>> >>>>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays >>>>>> there >>>>>> forever waiting for the pid to die (it never does) >>>>>> >>>>>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>>>>> another server, the ssh client may start to work correctly, then soon >>>>>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>>>> >>>>>> No firewall is configured, there is nothing else working on this >>>>>> server. >>>>>> >>>>>> Thanks for any suggestions... >>>>>> _______________________________________________ >>>>>> 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" >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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" >> >> >> _______________________________________________ >> 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 Aug 29 20:45:33 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1E22106566B for ; Wed, 29 Aug 2012 20:45:33 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9119C8FC1F for ; Wed, 29 Aug 2012 20:45:33 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1921466pbb.13 for ; Wed, 29 Aug 2012 13:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kSZgu/51wC4aX6X7uDfqFk3xdtcekT5NSVoXbOXbw2s=; b=Id2VPcqLAZERiEEcJbbCW+vacS6aX+UBHFu6z/njdhrL6EHVl1oAysYuj0xdlg1bqs /IbRXCYkBkYX7Q5M2Q3Mzn/6xr+tcqZax8CTd0FOrglD1KrbBzMtcOTYl/oHysiTD7Xw 3eEUxYtSOpe0c8/9uVdYpAy0Vb5t4BUAnTZuJUey/Zp2VyxFzDkbmF+e8bXzH5fTQn1S YphmTCFbrsYIp2uA+yfmHKSgxVMaRM23MQ5SYWKt/STN65lAAebOFX4ToWIAdrLCKPQt OLfFtC1KtdLZKHViCYO4+Vk0ockHKlK3x/DUf1rsMHn6opWcYP94o8Bp21bxfhy3eVZZ T1RQ== Received: by 10.68.241.228 with SMTP id wl4mr6981391pbc.51.1346273132774; Wed, 29 Aug 2012 13:45:32 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id tw5sm3576977pbc.48.2012.08.29.13.45.30 (version=SSLv3 cipher=OTHER); Wed, 29 Aug 2012 13:45:31 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <503E7F69.9070108@FreeBSD.org> Date: Wed, 29 Aug 2012 13:45:29 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120821 Thunderbird/14.0 MIME-Version: 1.0 To: Vijay Singh References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: witness warning in arp processing 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, 29 Aug 2012 20:45:33 -0000 On 08/29/12 10:30, Vijay Singh wrote: > All, I am seeing this warning on my 8.2 based system. > > taskqueue_drain with the following non-sleepable locks held: > exclusive rw lle (lle) r = 0 (0xffffff0014dc9110) locked @ sys/netinet/in.c:1760 > KDB: stack backtrace: > kdb_backtrace() at kdb_backtrace+0x3e > _witness_debugger() at _witness_debugger+0x24 > witness_warn() at witness_warn+0x402 > taskqueue_drain() at taskqueue_drain+0x36 > cancel_delayed_work() at cancel_delayed_work+0x56 > set_timeout() at set_timeout+0x18 > netevent_callback() at netevent_callback+0x29 > _handle_arp_update_event() at _handle_arp_update_event+0x31 > in_arpinput() at in_arpinput+0xe92 > arpintr() at arpintr+0x255 > netisr_dispatch_src() at netisr_dispatch_src+0x14a > netisr_dispatch() at netisr_dispatch+0x20 > ether_demux() at ether_demux+0x281 > ether_input_internal() at ether_input_internal+0x60c > ether_nh_input() at ether_nh_input+0x1d > netisr_dispatch_src() at netisr_dispatch_src+0x14a > netisr_dispatch() at netisr_dispatch+0x20 > ether_input() at ether_input+0xef > lem_rxeof() at lem_rxeof+0x6ee > lem_handle_rxtx() at lem_handle_rxtx+0x4f > taskqueue_run_locked() at taskqueue_run_locked+0x145 > taskqueue_thread_loop() at taskqueue_thread_loop+0x73 > fork_exit() at fork_exit+0x180 > fork_trampoline() at fork_trampoline+0xe > > Is this a known issue? Has it been fixed? This is a bug in the OFED code. The event handler it registers for the ARP update is not supposed to do anything that could sleep.. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 00:23:45 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05CF11065670 for ; Thu, 30 Aug 2012 00:23:45 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5038FC14 for ; Thu, 30 Aug 2012 00:23:44 +0000 (UTC) Received: by eaak11 with SMTP id k11so379788eaa.13 for ; Wed, 29 Aug 2012 17:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Lq0LIsc0SrP5RJ5+1YIeKVqSBSgsHVfQKTvCTbcWttA=; b=MJaIIepn4SZIBNOCf0VOlL1NmVsFasFlNgMivxvYPHGsGjx6NCCRh+gbSNa1j4+ecP d5IRRPnuZMKFeghdyFp0KMA/9p2JNnnvd2VC1Uym8e7Ahur27aiT3w1IyVYIL+VujNMh FQKPD7ihoXBudbJ4fRuWvmU2fbiV7OZUBh/E92KwVC6J/gUBUNd0Bb4How6fUcVTX12G p8OSJA3RgTK2gjHryGoGI07ypKMIOhoYP9SZ9foTRc352Q+zi1RU+QU9I3IE+Eo0pNj3 w0jTr4Diwl0Bev/WM1A785EsMbf401Ia7DflsHPz5468ym9Gb5n1fOC02brTzj/M/+kD 5vXA== MIME-Version: 1.0 Received: by 10.14.205.6 with SMTP id i6mr930396eeo.13.1346286223202; Wed, 29 Aug 2012 17:23:43 -0700 (PDT) Received: by 10.14.219.134 with HTTP; Wed, 29 Aug 2012 17:23:43 -0700 (PDT) Date: Wed, 29 Aug 2012 17:23:43 -0700 Message-ID: From: Vijay Singh To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: sorele() and ACCEPT_LOCK() 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, 30 Aug 2012 00:23:45 -0000 Is there any reason why sorele() needs the accept lock to be held? 231 #define sorele(so) do { \ 232 ACCEPT_LOCK_ASSERT(); \ 233 SOCK_LOCK_ASSERT(so); \ 234 if ((so)->so_count <= 0) \ 235 panic("sorele"); \ 236 if (--(so)->so_count == 0) \ 237 sofree(so); \ 238 else { \ 239 SOCK_UNLOCK(so); \ 240 ACCEPT_UNLOCK(); \ 241 } \ 242 } while (0) -vijay From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 06:24:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66AAA1065670; Thu, 30 Aug 2012 06:24:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id B12A18FC1F; Thu, 30 Aug 2012 06:24:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q7U6Nuh6078803; Thu, 30 Aug 2012 16:23:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 30 Aug 2012 16:23:56 +1000 (EST) From: Ian Smith To: Lev Serebryakov In-Reply-To: <1807373989.20120829223125@serebryakov.spb.ru> Message-ID: <20120830152726.A33776@sola.nimnet.asn.au> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Michael Sierchio Subject: Re: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw? 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, 30 Aug 2012 06:24:06 -0000 On Wed, 29 Aug 2012 22:31:25 +0400, Lev Serebryakov wrote: > Hello, Michael. > You wrote 29 ??????? 2012 ?., 19:01:08: > > > >> I have interface (vr1), most of traffic on which is PPPoE. I have ipfw > >> firewall, which splits traffic by interfaces via: > >> > >> add 2000 skipto 5000 all from any to any via em0 > >> add 2010 skipto 7000 all from any to any via wlan0 > >> add 2020 skipto 11000 all from any to any via vr1 > >> add 2030 skipto 13000 all from any to any via ng0 > >> add 2040 skipto 15000 ipv6 from any to any via gif0 > >> add 2999 deny all from any to any > >> ... > >> And later here are some basic checks, nat, "check-state" and some > >> stateful rules. > MS> Consider separating traffic not only by interface but also direction > It is done in rules 1000 and 1010, 2xxx is for incoming, 3xxx for > outgoing. It is only a sample/ Hi Lev, Glad you mentioned that, but I hope you're not using 'via' on your 3xxx outgoing rules, since it also applies to packets that earlier came in on that specified interface, which can be confusing or at least ambiguous. I generally only use 'via' on deny rules where packets may not traverse an interface either inbound or outbound, eg anti-spoofing rules. > MS> ip from any to any in recv vr0 > MS> and outgoing > MS> ip from any to any out xmit vr0 > Yep, I'll collapse my two-rule chains in one rule. I guess if the issue persists, we may need to see more of your ruleset. > >> Does PPPoE packets match rule 2020, and other rules like "nat 1 ip > >> from any to any"? > MS> Yes, and it seems that that is not what you want. The packets will be > MS> seen first by the firewall, then passed to whatever is handling PPPoE > But there is no rule for it, and default policy is "deny"... But it > works. > > MS> on the local box, then re-injected into the IP stack, etc. for > MS> processing by firewall rules again. > MS> Is there a pppX pseudo-interface? > ng0, as I'm using mpd5, not system ppp. Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface mpd5 uses to connect with your DSL modem/bridge. Nor would you expect to see pppoe traffic on any other interface. Below is mpd4 syntax for mpd.links on an older box, not sure if it's still the same for mpd5: lPPPoE: set link type pppoe set pppoe iface fxp0 set pppoe service "" set pppoe disable incoming set pppoe enable originate So I only see PPPoE traffic on fxp0 with tcpdump (along with occasional TCP 80 when taking to the modem itself); mpd should only talk IP on ng0. Take care not to route the (here fxp0) PPPoE traffic to anywhere else. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 08:01:18 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB5E9106566C for ; Thu, 30 Aug 2012 08:01:18 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF5B18FC0C for ; Thu, 30 Aug 2012 08:01:18 +0000 (UTC) Received: by ialo14 with SMTP id o14so3550176ial.13 for ; Thu, 30 Aug 2012 01:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YBZRkFol7dDBVf1NUQ/dnhOM8d73QLztN/7VpAzA6UY=; b=hD+lgwVKE+TY/O69vOhCMb8ejB1WCw3AZVPewchXL2HqMPlufxmwjwmeKBB3IOXHfy TH27dCBGYTfPrChLvLrFhXJsBrFmUlr0z6PA3R0kj8z2P7QY/nrpM8iLzzBfIrF3h6H2 xk230viaoamnq0dBRls2m6fRDftoYEcyzp770o4ewoDL/Inm5qAnZXReZkoseW1sWQQX Egljt+iaRMX4rsAxKNtnvFr8QJE/XgBl+/AwxYyFu7F6QDiWqilGsRR/Cb0lgwc03Yxj J8qZ0RkZCZ6HCiVsNzlP1cfWdDOo38S0kLWXnDSjYdUJek6dhwC/AOUjijgbe+q4F2q3 Lq1A== MIME-Version: 1.0 Received: by 10.50.40.225 with SMTP id a1mr4574375igl.51.1346313677641; Thu, 30 Aug 2012 01:01:17 -0700 (PDT) Received: by 10.64.165.34 with HTTP; Thu, 30 Aug 2012 01:01:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Aug 2012 12:01:17 +0400 Message-ID: From: Sergey Kandaurov To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: sorele() and ACCEPT_LOCK() 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, 30 Aug 2012 08:01:19 -0000 On 30 August 2012 04:23, Vijay Singh wrote: > Is there any reason why sorele() needs the accept lock to be held? > > 231 #define sorele(so) do { \ > 232 ACCEPT_LOCK_ASSERT(); \ > 233 SOCK_LOCK_ASSERT(so); \ > 234 if ((so)->so_count <= 0) \ > 235 panic("sorele"); \ > 236 if (--(so)->so_count == 0) \ > 237 sofree(so); \ > 238 else { \ > 239 SOCK_UNLOCK(so); \ > 240 ACCEPT_UNLOCK(); \ > 241 } \ > 242 } while (0) sofree() needs accept lock to be held to operate on a qstate field. sofree() callers cannot be changed to push accept lock acquisition into sofree() because that would require to reacquire sock lock around accept lock to take locks in order; this in turn opens race. See r136682 for details. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 09:12:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FE57106566C for ; Thu, 30 Aug 2012 09:12:09 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 279998FC22 for ; Thu, 30 Aug 2012 09:12:08 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b893:d73f:3750:2064]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id ED2644AC2D; Thu, 30 Aug 2012 13:12:01 +0400 (MSK) Date: Thu, 30 Aug 2012 13:11:58 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <534292400.20120830131158@serebryakov.spb.ru> To: Ian Smith In-Reply-To: <20120830152726.A33776@sola.nimnet.asn.au> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 09:12:09 -0000 Hello, Ian. You wrote 30 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2012 =D0=B3., 10:23= :56: >> Yep, I'll collapse my two-rule chains in one rule. IS> I guess if the issue persists, we may need to see more of your ruleset. Not a problem at all, here it is: http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect Yep. I didn't see it. My question is, really: why vr1 (my physical interface, used to connect to my ISP) takes 50%+ of CPU when traffic is only 40mbit/s down and about 20mbit/s up (with many connections)? I was afraid, that all PPPoE traffic is inspected by ipfw and it causes additional CPU load. Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and 4.5Kpps in both directions, nothing like full 100Mbit or more, and I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) for softrouters, So, theoretically, 40mbit should not be a problem at all for this hardware. And now I have not-working WiFi (this box is also AP) when wired traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s without wired traffic), userland freezes under load (very bad with ULE, better with 4BSD), and inability to pass through 40Mbit in both directions simultaneously. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 09:40:04 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54BC7106566B for ; Thu, 30 Aug 2012 09:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 24C418FC15 for ; Thu, 30 Aug 2012 09:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7U9e2f0046334 for ; Thu, 30 Aug 2012 09:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7U9e2NO046333; Thu, 30 Aug 2012 09:40:02 GMT (envelope-from gnats) Date: Thu, 30 Aug 2012 09:40:02 GMT Message-Id: <201208300940.q7U9e2NO046333@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Eugene M. Zheganin" Cc: Subject: Re: kern/164475: [gre] gre misses RUNNING flag after a reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Eugene M. Zheganin" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 09:40:04 -0000 The following reply was made to PR kern/164475; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/164475: [gre] gre misses RUNNING flag after a reboot Date: Thu, 30 Aug 2012 15:30:04 +0600 Guys, it's still there. FreeBSD alix-panicbox 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Mon Jul 23 03:02:45 YEKT 2012 emz@zombie.hq.norma.perm.ru:/usr/obj/nanobsd.alix/usr/src/sys/ALIX i386 From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 13:01:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 976AF106566C; Thu, 30 Aug 2012 13:01:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BEBF8FC08; Thu, 30 Aug 2012 13:01:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CCFFDB946; Thu, 30 Aug 2012 09:01:15 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 30 Aug 2012 08:59:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <503E7F69.9070108@FreeBSD.org> In-Reply-To: <503E7F69.9070108@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208300859.09759.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 30 Aug 2012 09:01:15 -0400 (EDT) Cc: net@freebsd.org, Navdeep Parhar , Vijay Singh Subject: Re: witness warning in arp processing 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, 30 Aug 2012 13:01:16 -0000 On Wednesday, August 29, 2012 4:45:29 pm Navdeep Parhar wrote: > On 08/29/12 10:30, Vijay Singh wrote: > > All, I am seeing this warning on my 8.2 based system. > > > > taskqueue_drain with the following non-sleepable locks held: > > exclusive rw lle (lle) r = 0 (0xffffff0014dc9110) locked @ sys/netinet/in.c:1760 > > KDB: stack backtrace: > > kdb_backtrace() at kdb_backtrace+0x3e > > _witness_debugger() at _witness_debugger+0x24 > > witness_warn() at witness_warn+0x402 > > taskqueue_drain() at taskqueue_drain+0x36 > > cancel_delayed_work() at cancel_delayed_work+0x56 > > set_timeout() at set_timeout+0x18 > > netevent_callback() at netevent_callback+0x29 > > _handle_arp_update_event() at _handle_arp_update_event+0x31 > > in_arpinput() at in_arpinput+0xe92 > > arpintr() at arpintr+0x255 > > netisr_dispatch_src() at netisr_dispatch_src+0x14a > > netisr_dispatch() at netisr_dispatch+0x20 > > ether_demux() at ether_demux+0x281 > > ether_input_internal() at ether_input_internal+0x60c > > ether_nh_input() at ether_nh_input+0x1d > > netisr_dispatch_src() at netisr_dispatch_src+0x14a > > netisr_dispatch() at netisr_dispatch+0x20 > > ether_input() at ether_input+0xef > > lem_rxeof() at lem_rxeof+0x6ee > > lem_handle_rxtx() at lem_handle_rxtx+0x4f > > taskqueue_run_locked() at taskqueue_run_locked+0x145 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x73 > > fork_exit() at fork_exit+0x180 > > fork_trampoline() at fork_trampoline+0xe > > > > Is this a known issue? Has it been fixed? > > This is a bug in the OFED code. The event handler it registers for the > ARP update is not supposed to do anything that could sleep.. You could try this: Index: ofed/include/linux/workqueue.h =================================================================== --- ofed/include/linux/workqueue.h (revision 239905) +++ ofed/include/linux/workqueue.h (working copy) @@ -184,9 +184,9 @@ cancel_delayed_work(struct delayed_work *work) { callout_stop(&work->timer); - if (work->work.taskqueue && - taskqueue_cancel(work->work.taskqueue, &work->work.work_task, NULL)) - taskqueue_drain(work->work.taskqueue, &work->work.work_task); + if (work->work.taskqueue) + taskqueue_cancel(work->work.taskqueue, &work->work.work_task, + NULL); return 0; } This changes the code to match the comment above cancel_delayed_work() and should fix this warning: /* * This may leave work running on another CPU as it does on Linux. */ static inline int cancel_delayed_work(struct delayed_work *work) -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 13:01:16 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 976AF106566C; Thu, 30 Aug 2012 13:01:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BEBF8FC08; Thu, 30 Aug 2012 13:01:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CCFFDB946; Thu, 30 Aug 2012 09:01:15 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 30 Aug 2012 08:59:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <503E7F69.9070108@FreeBSD.org> In-Reply-To: <503E7F69.9070108@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208300859.09759.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 30 Aug 2012 09:01:15 -0400 (EDT) Cc: net@freebsd.org, Navdeep Parhar , Vijay Singh Subject: Re: witness warning in arp processing 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, 30 Aug 2012 13:01:16 -0000 On Wednesday, August 29, 2012 4:45:29 pm Navdeep Parhar wrote: > On 08/29/12 10:30, Vijay Singh wrote: > > All, I am seeing this warning on my 8.2 based system. > > > > taskqueue_drain with the following non-sleepable locks held: > > exclusive rw lle (lle) r = 0 (0xffffff0014dc9110) locked @ sys/netinet/in.c:1760 > > KDB: stack backtrace: > > kdb_backtrace() at kdb_backtrace+0x3e > > _witness_debugger() at _witness_debugger+0x24 > > witness_warn() at witness_warn+0x402 > > taskqueue_drain() at taskqueue_drain+0x36 > > cancel_delayed_work() at cancel_delayed_work+0x56 > > set_timeout() at set_timeout+0x18 > > netevent_callback() at netevent_callback+0x29 > > _handle_arp_update_event() at _handle_arp_update_event+0x31 > > in_arpinput() at in_arpinput+0xe92 > > arpintr() at arpintr+0x255 > > netisr_dispatch_src() at netisr_dispatch_src+0x14a > > netisr_dispatch() at netisr_dispatch+0x20 > > ether_demux() at ether_demux+0x281 > > ether_input_internal() at ether_input_internal+0x60c > > ether_nh_input() at ether_nh_input+0x1d > > netisr_dispatch_src() at netisr_dispatch_src+0x14a > > netisr_dispatch() at netisr_dispatch+0x20 > > ether_input() at ether_input+0xef > > lem_rxeof() at lem_rxeof+0x6ee > > lem_handle_rxtx() at lem_handle_rxtx+0x4f > > taskqueue_run_locked() at taskqueue_run_locked+0x145 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x73 > > fork_exit() at fork_exit+0x180 > > fork_trampoline() at fork_trampoline+0xe > > > > Is this a known issue? Has it been fixed? > > This is a bug in the OFED code. The event handler it registers for the > ARP update is not supposed to do anything that could sleep.. You could try this: Index: ofed/include/linux/workqueue.h =================================================================== --- ofed/include/linux/workqueue.h (revision 239905) +++ ofed/include/linux/workqueue.h (working copy) @@ -184,9 +184,9 @@ cancel_delayed_work(struct delayed_work *work) { callout_stop(&work->timer); - if (work->work.taskqueue && - taskqueue_cancel(work->work.taskqueue, &work->work.work_task, NULL)) - taskqueue_drain(work->work.taskqueue, &work->work.work_task); + if (work->work.taskqueue) + taskqueue_cancel(work->work.taskqueue, &work->work.work_task, + NULL); return 0; } This changes the code to match the comment above cancel_delayed_work() and should fix this warning: /* * This may leave work running on another CPU as it does on Linux. */ static inline int cancel_delayed_work(struct delayed_work *work) -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 13:11:04 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 039B9106564A for ; Thu, 30 Aug 2012 13:11:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 82F4F8FC15 for ; Thu, 30 Aug 2012 13:11:00 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q7UDAvBh091860 for ; Thu, 30 Aug 2012 17:10:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q7UDAvbl091859 for net@FreeBSD.org; Thu, 30 Aug 2012 17:10:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 30 Aug 2012 17:10:57 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20120830131057.GE90597@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [CFT] if_transmit method for if_bridge(4) 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, 30 Aug 2012 13:11:04 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hi, I have a patch laying around, that makes if_bridge(4) utilize if_transmit method. That should improvide performance. I'd appreciate if someone who actually do use if_bridge(4) tests this patch. -- Totus tuus, Glebius. --9amGYk9869ThD9tj Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_bridge_transmit.diff" Index: if_bridge.c =================================================================== --- if_bridge.c (revision 239904) +++ if_bridge.c (working copy) @@ -245,11 +245,12 @@ static void bridge_init(void *); static void bridge_dummynet(struct mbuf *, struct ifnet *); static void bridge_stop(struct ifnet *, int); -static void bridge_start(struct ifnet *); +static int bridge_transmit(struct ifnet *, struct mbuf *); +static void bridge_qflush(struct ifnet *); static struct mbuf *bridge_input(struct ifnet *, struct mbuf *); static int bridge_output(struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *); -static void bridge_enqueue(struct bridge_softc *, struct ifnet *, +static int bridge_enqueue(struct bridge_softc *, struct ifnet *, struct mbuf *); static void bridge_rtdelete(struct bridge_softc *, struct ifnet *ifp, int); @@ -600,12 +601,10 @@ if_initname(ifp, ifc->ifc_name, unit); ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = bridge_ioctl; - ifp->if_start = bridge_start; + ifp->if_transmit = bridge_transmit; + ifp->if_qflush = bridge_qflush; ifp->if_init = bridge_init; ifp->if_type = IFT_BRIDGE; - IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); - ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; - IFQ_SET_READY(&ifp->if_snd); /* * Generate an ethernet address with a locally administered address. @@ -1780,7 +1779,7 @@ * Enqueue a packet on a bridge member interface. * */ -static void +static int bridge_enqueue(struct bridge_softc *sc, struct ifnet *dst_ifp, struct mbuf *m) { int len, err = 0; @@ -1823,6 +1822,8 @@ if (mflags & M_MCAST) sc->sc_ifp->if_omcasts++; } + + return (err); } /* @@ -1981,44 +1982,43 @@ } /* - * bridge_start: + * bridge_transmit: * - * Start output on a bridge. + * Do output on a bridge. * */ -static void -bridge_start(struct ifnet *ifp) +static int +bridge_transmit(struct ifnet *ifp, struct mbuf *m) { struct bridge_softc *sc; - struct mbuf *m; - struct ether_header *eh; - struct ifnet *dst_if; + int error = 0; sc = ifp->if_softc; - ifp->if_drv_flags |= IFF_DRV_OACTIVE; - for (;;) { - IFQ_DEQUEUE(&ifp->if_snd, m); - if (m == 0) - break; - ETHER_BPF_MTAP(ifp, m); + ETHER_BPF_MTAP(ifp, m); + + BRIDGE_LOCK(sc); + if ((m->m_flags & (M_BCAST|M_MCAST)) == 0) { + struct ether_header *eh; + struct ifnet *dst_if; + eh = mtod(m, struct ether_header *); - dst_if = NULL; + dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1); + BRIDGE_UNLOCK(sc); + error = bridge_enqueue(sc, dst_if, m); + } else + bridge_broadcast(sc, ifp, m, 0); - BRIDGE_LOCK(sc); - if ((m->m_flags & (M_BCAST|M_MCAST)) == 0) { - dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1); - } + return (error); +} - if (dst_if == NULL) - bridge_broadcast(sc, ifp, m, 0); - else { - BRIDGE_UNLOCK(sc); - bridge_enqueue(sc, dst_if, m); - } - } - ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; +/* + * The ifp->if_qflush entry point for if_bridge(4) is no-op. + */ +static void +bridge_qflush(struct ifnet *ifp __unused) +{ } /* --9amGYk9869ThD9tj-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 19:01:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 175D8106564A; Thu, 30 Aug 2012 19:01:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id D54968FC12; Thu, 30 Aug 2012 19:01:12 +0000 (UTC) Received: by dadr6 with SMTP id r6so1400048dad.13 for ; Thu, 30 Aug 2012 12:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IpEyXqw1BJkRIVqr6LQKsNcW1xNCDwvJQ3L20Wd9dXg=; b=qH8mY45pspvTZofTB49Q3xHFMKDYYvIQR6oOod0DFUT+RTjCpvKMWTthLfKH8FFSu0 q+Br4T6BM+2WAvlyenmHr/SGqnnUyvlkS9OP4scvjkyrm/gK0KGWdwFQAQ/fBPkebP/G 2Dt1d/fZVwwxUENpEAUWRk8i6b4cQTyicytrZr0aKtzMksvB572JCnGYglZ2ll/EZ3FX 8lbIbwdU21j6CaazzFzyfEtoGXkRXus54vuT4Ji3w52WCrx7H52nKzlzpEb7CaYpemrq ty6hSkA1dDqqtKcZjCDqOAM4Qy8OUXmwMc4jOFYd1DO6dQxlwsv63jbuARM4cauqpDru XfVg== MIME-Version: 1.0 Received: by 10.68.227.233 with SMTP id sd9mr12862408pbc.48.1346353272639; Thu, 30 Aug 2012 12:01:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 30 Aug 2012 12:01:12 -0700 (PDT) In-Reply-To: <534292400.20120830131158@serebryakov.spb.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> Date: Thu, 30 Aug 2012 12:01:12 -0700 X-Google-Sender-Auth: 6L83-ftMvfJ4XXmZ7MSdpnYGzmk Message-ID: From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) 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, 30 Aug 2012 19:01:13 -0000 On 30 August 2012 02:11, Lev Serebryakov wrote: > Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and > 4.5Kpps in both directions, nothing like full 100Mbit or more, and > I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) > for softrouters, So, theoretically, 40mbit should not be a problem at > all for this hardware. It honestly shouldn't be that bad, but without dumping a bunch of effort into profiling (even if it's just sampled profiling via gprof) I won't know whether that's "good" or not. > And now I have not-working WiFi (this box is also AP) when wired > traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s > without wired traffic), userland freezes under load (very bad with > ULE, better with 4BSD), and inability to pass through 40Mbit in both > directions simultaneously. Hm. What about disabling preemption and see if that helps? I still haven't fully debugged/diagnosed why preemption acts weirdly on my mips24k boards (which is why all the mips24k Atheros SoC's have 4BSD + no PREEMPT.) Adrian From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 20:17:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8319C106566B; Thu, 30 Aug 2012 20:17:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 163568FC0A; Thu, 30 Aug 2012 20:17:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:49ee:4a:4b3c:6f58]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D788D4AC2D; Fri, 31 Aug 2012 00:17:15 +0400 (MSK) Date: Fri, 31 Aug 2012 00:17:11 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1435570640.20120831001711@serebryakov.spb.ru> To: Adrian Chadd In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:17:18 -0000 Hello, Adrian. You wrote 30 =E0=E2=E3=F3=F1=F2=E0 2012 =E3., 23:01:12: >> Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and >> 4.5Kpps in both directions, nothing like full 100Mbit or more, and >> I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) >> for softrouters, So, theoretically, 40mbit should not be a problem at >> all for this hardware. AC> It honestly shouldn't be that bad, but without dumping a bunch of AC> effort into profiling (even if it's just sampled profiling via gprof) Is it possible to use gprof with kernel? As here is no userland processes involved: PPPoE is porcessed by netgrpah, routing & ipfw is kernel stuff too... AC> I won't know whether that's "good" or not. >> And now I have not-working WiFi (this box is also AP) when wired >> traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s >> without wired traffic), userland freezes under load (very bad with >> ULE, better with 4BSD), and inability to pass through 40Mbit in both >> directions simultaneously. AC> Hm. What about disabling preemption and see if that helps? I still AC> haven't fully debugged/diagnosed why preemption acts weirdly on my AC> mips24k boards (which is why all the mips24k Atheros SoC's have 4BSD + AC> no PREEMPT.) I'll try it. Also, I noticed, that with any scheduler it could not route 40Mbit in BOTH directions simultaneously, and downstream has priority. When there is no much of downstream, it upload at 40-45Mibt/s, and when downstream is 40-45Mibt/s upstream could be only about 20Mbit/s. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 20:32:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A80C9106566B; Thu, 30 Aug 2012 20:32:26 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50A568FC12; Thu, 30 Aug 2012 20:32:26 +0000 (UTC) Received: by obbun3 with SMTP id un3so5484965obb.13 for ; Thu, 30 Aug 2012 13:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vfsq/X69JOqWLUc67ATt0OoVwUh8YhRyj86UKKEjyAU=; b=YMSVleBTc7tzRmpJ5KLRHytWI4e3EArQoYoZ/9jHvRIeiJxVSWVhHPXvdaEBFrj3E3 4dSfeDulZxYwW8WsxQTSEGL8+CZUwoSNwFKpfcpAbpDosumpTgW0/QcxKvjPX/2pZMYL a1mw7BILiHCHZkc+yBI6+GXJ+Wesf1yLTJPLIt/fJ3Kul+JMHipa0ICLjcvla3QolRUy /xdupl/csfK4UF6gDw81On6q82jusZLJ72o9MjL8ASk1/hzyTNPps4l6QWijf2pUINjG egxQ4lHRarxwM2ihFfgkoCUSZBCx9ewwHOjAEz9crDCEbjILkUj1otep64MNn/6Pc6yD lnlA== MIME-Version: 1.0 Received: by 10.182.218.37 with SMTP id pd5mr5980583obc.24.1346358745826; Thu, 30 Aug 2012 13:32:25 -0700 (PDT) Received: by 10.76.83.130 with HTTP; Thu, 30 Aug 2012 13:32:25 -0700 (PDT) In-Reply-To: <534292400.20120830131158@serebryakov.spb.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> Date: Thu, 30 Aug 2012 15:32:25 -0500 Message-ID: From: Adam Vande More To: lev@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) 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, 30 Aug 2012 20:32:26 -0000 On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov wrote: > Hello, Ian. > You wrote 30 =C1=D7=C7=D5=D3=D4=C1 2012 =C7., 10:23:56: > > >> Yep, I'll collapse my two-rule chains in one rule. > IS> I guess if the issue persists, we may need to see more of your rulese= t. > Not a problem at all, here it is: > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interfac= e > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expec= t > Yep. I didn't see it. My question is, really: why vr1 (my physical > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > is only 40mbit/s down and about 20mbit/s up (with many connections)? Have you taken this into account from vr(4)? BUGS The vr driver always copies transmit mbuf chains into longword-aligned buffers prior to transmission in order to pacify the Rhine chips. If buffers are not aligned correctly, the chip will round the supplied buffer address and begin DMAing from the wrong location. This buffer copying impairs transmit performance on slower systems but cannot be avoided. On faster machines (e.g. a Pentium II), the performance impact is much less noticeable. --=20 Adam Vande More From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 20:51:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09FB51065673; Thu, 30 Aug 2012 20:51:54 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B803F8FC0A; Thu, 30 Aug 2012 20:51:53 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A15FF7300A; Thu, 30 Aug 2012 23:11:07 +0200 (CEST) Date: Thu, 30 Aug 2012 23:11:07 +0200 From: Luigi Rizzo To: Michael Sierchio Message-ID: <20120830211107.GB97191@onelab2.iet.unipi.it> References: <1865271844.20120829131610@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw? 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, 30 Aug 2012 20:51:54 -0000 On Wed, Aug 29, 2012 at 08:01:50AM -0700, Michael Sierchio wrote: > On Wed, Aug 29, 2012 at 8:01 AM, Michael Sierchio wrote: > > > ip from any to any in recv vr0 > > "any" here is also not appropriate... it is just sintactic sugar, "from any to any" corresponds is just printed by default to make the rule look like the 'old style' (pre-2003) ipfw syntax, but otherwise has zero cost at runtime. cheers luigi > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 20:54:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 150D7106566B; Thu, 30 Aug 2012 20:54:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C41D68FC17; Thu, 30 Aug 2012 20:54:49 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 444A07300B; Thu, 30 Aug 2012 23:14:09 +0200 (CEST) Date: Thu, 30 Aug 2012 23:14:09 +0200 From: Luigi Rizzo To: Adam Vande More Message-ID: <20120830211409.GC97191@onelab2.iet.unipi.it> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, lev@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) 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, 30 Aug 2012 20:54:50 -0000 On Thu, Aug 30, 2012 at 03:32:25PM -0500, Adam Vande More wrote: > On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov wrote: > > > Hello, Ian. > > You wrote 30 ??????? 2012 ?., 10:23:56: > > > > >> Yep, I'll collapse my two-rule chains in one rule. > > IS> I guess if the issue persists, we may need to see more of your ruleset. > > Not a problem at all, here it is: > > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > > Yep. I didn't see it. My question is, really: why vr1 (my physical > > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > > is only 40mbit/s down and about 20mbit/s up (with many connections)? > > > Have you taken this into account from vr(4)? I was indeed going to mention something like this. Old/slow machines often have very low memory bandwidth, so the rule 1GHz<->1 Gbit/s does not really apply. cheers luigi > BUGS > The vr driver always copies transmit mbuf chains into longword-aligned > buffers prior to transmission in order to pacify the Rhine chips. If > buffers are not aligned correctly, the chip will round the supplied > buffer address and begin DMAing from the wrong location. This buffer > copying impairs transmit performance on slower systems but cannot be > avoided. On faster machines (e.g. a Pentium II), the performance > impact > is much less noticeable. > -- > Adam Vande More > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 22:46:03 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59F64106566B for ; Thu, 30 Aug 2012 22:46:03 +0000 (UTC) (envelope-from kaltheat@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.103]) by mx1.freebsd.org (Postfix) with ESMTP id 436038FC1A for ; Thu, 30 Aug 2012 22:46:03 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:subject:message-id:mime-version:content-type:sender; b=TR9NtgFkli3o4JzQW8ujpVt5IyOyiEqjvyQsXp4fAQrh6mOBJohbTXflMv4PW+ZatRf7IqExX/93 47EXwy63IgQs2Munzh6tKrvisAjGn978PpgwszvJslQ3jDRAgaCg Received: from - (106-147-103-86.dynamic.dsl.tng.de [86.103.147.106]) by mx.zohomail.com with SMTPS id 1346363515853909.155745057947; Thu, 30 Aug 2012 14:51:55 -0700 (PDT) Date: Thu, 30 Aug 2012 23:51:47 +0200 From: kaltheat@googlemail.com To: net@freebsd.org Message-ID: <20120830215147.GA2383@-> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: kaltheat@zoho.com X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Cc: Subject: lagg failover issue 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, 30 Aug 2012 22:46:03 -0000 Hi, I'm using following devices: bge0 - NetLink BCM57780 Gigabit Ethernet PCIe ndis0 - BCM43225 802.11b/g/n As far as I've tested it, each of them work fine for itself. I want to aggregate them using lagg in failover mode as explained here[1][2]. But when I remove the wire (wireless connection is established), I can't put any traffic through lagg0. What might be the problem? Can you give me some hints on how to debug this lagg-issue further? Regards, kaltheat [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html Example 32-3. Failover Mode Between Wired and Wireless Interfaces [2] http://www.freebsd.org/cgi/man.cgi?query=lagg#EXAMPLES Second example From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 01:35:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6493D106566C; Fri, 31 Aug 2012 01:35:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 25B7E8FC0A; Fri, 31 Aug 2012 01:35:39 +0000 (UTC) Received: by dadr6 with SMTP id r6so1577098dad.13 for ; Thu, 30 Aug 2012 18:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=EpyrkZMAnPQZF/evt+51EJkC3aypkM3HnBVKwCi24LI=; b=S21hxC+wSldLKVeTInUfnEpGlY7tc0rYtXBa0VR5OaOS6+m61npOe8TUz1Ev1IQx4A CkSaHEnoe6Cm82zqV8iiNCWVIU0BtBxY3wsHhbpWgCqhlXyOCviiTh9u+G/LIW5UPJVZ syDDorGNftOZOJZQFbYKney1uWe4Lzukx4JLk5tTXtKhYVYbC+2q65Q0FwyO/CC+mboR BrlKFD3B7Ren2XjR1Pgs/MtB0EVMpuJ7Czymd3Sne73v4srBQAdDQE0EIz3Z0tY4idve uKq8zl+Dex9u21yUWcKWVux+LZHz7UdRVfzfKilgrhFU3+KlRLRnpmae/V6p2ovVqWNb KenA== Received: by 10.68.130.65 with SMTP id oc1mr14526095pbb.29.1346376933566; Thu, 30 Aug 2012 18:35:33 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id pk9sm2512892pbb.4.2012.08.30.18.35.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2012 18:35:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 31 Aug 2012 10:35:24 -0700 From: YongHyeon PYUN Date: Fri, 31 Aug 2012 10:35:24 -0700 To: Adam Vande More Message-ID: <20120831173524.GA3208@michelle.cdnetworks.com> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, lev@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 01:35:40 -0000 On Thu, Aug 30, 2012 at 03:32:25PM -0500, Adam Vande More wrote: > On Thu, Aug 30, 2012 at 4:11 AM, Lev Serebryakov wrote: > > > Hello, Ian. > > You wrote 30 п╟п╡пЁя┐я│я┌п╟ 2012 пЁ., 10:23:56: > > > > >> Yep, I'll collapse my two-rule chains in one rule. > > IS> I guess if the issue persists, we may need to see more of your ruleset. > > Not a problem at all, here it is: > > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > > Yep. I didn't see it. My question is, really: why vr1 (my physical > > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > > is only 40mbit/s down and about 20mbit/s up (with many connections)? > > > Have you taken this into account from vr(4)? > > BUGS > The vr driver always copies transmit mbuf chains into longword-aligned > buffers prior to transmission in order to pacify the Rhine chips. If > buffers are not aligned correctly, the chip will round the supplied > buffer address and begin DMAing from the wrong location. This buffer > copying impairs transmit performance on slower systems but cannot be > avoided. On faster machines (e.g. a Pentium II), the performance > impact > is much less noticeable. I'm not sure what controller is used in Geode LX but newer vr(4) controllers such as VT6105/VT6105M do not have such DMA alignment limitation of TX buffer. vr(4) selectively enables software workaround based on controller revision. Manual software padding for short frames(< 60 bytes) is still required for all VIA fast ethernet controllers though. vr_attach() will show what quirks are activated so you would be able to tell whether your controller has TX DMA buffer alignment limitation or not. From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 01:57:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4701A106566B for ; Fri, 31 Aug 2012 01:57:09 +0000 (UTC) (envelope-from djmitche@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CB5EE8FC08 for ; Fri, 31 Aug 2012 01:57:08 +0000 (UTC) Received: by weyx56 with SMTP id x56so1794703wey.13 for ; Thu, 30 Aug 2012 18:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Q+Snu7ZWSlZ7XUYdTz8cdTd6KICtqCuFxX7aNz5q4ic=; b=vxQVTrOofO3KvvoJ7spkIhNxB+7swMnfzj5jTEL4rj9qw4uG4JMoGzb6qIX1CPJyUd srreeChkuZGEOnDxCZ7qcT/z95zHLQOlkD3Ov+qdTECY2U/thENFzOsDfmzlDw4/NelT G0F2gQY4K+bNhZnWArmZaAra1JGE3G+PNn8Qz1MjBnFh6ZEOnkWU+fx1IghNMUUQyz9W jwM6VMTKQUdHMpC1D/u6kJvgDHkUvA+YLTt6GGEFlsaAkPZY+xyKiWltEGEGSPKp50wk dbZALSTZT3V2ArqIg1+bBqrXOsFT1sxMRrRbom60a8mSVp+LuOsyU4EoRxrsmyublKuv Drog== MIME-Version: 1.0 Received: by 10.180.24.197 with SMTP id w5mr948501wif.22.1346378227513; Thu, 30 Aug 2012 18:57:07 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.223.4.215 with HTTP; Thu, 30 Aug 2012 18:57:07 -0700 (PDT) In-Reply-To: References: <20120827094956.GA93853@server.rulingia.com> Date: Thu, 30 Aug 2012 21:57:07 -0400 X-Google-Sender-Auth: ePsfMAaV7ZgrHMM7fo9PDSVvmrE Message-ID: From: "Dustin J. Mitchell" To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: bridging VLAN interfaces and STP 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, 31 Aug 2012 01:57:09 -0000 On Mon, Aug 27, 2012 at 7:45 AM, Dustin J. Mitchell wrote: > On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy wrote: >> On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" wrote: >>>On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell wrote: >>>> Hey folks. I'm trying to set up a system with one 802.1q-tagged >>>> upstream, and a few untagged interfaces. So I'd like to bridge the >>>> vlan(4) interfaces on vr1 to specific other interfaces. >> >> Can you provide ifconfig output covering all the relevant interfaces. > > Sure: Peter, or anyone else -- any thoughts on this issue? Dustin From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 02:07:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1777E106564A; Fri, 31 Aug 2012 02:07:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE2CF8FC08; Fri, 31 Aug 2012 02:07:37 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so4155277pbb.13 for ; Thu, 30 Aug 2012 19:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=BYVtSqPwiYB+K2CqRzJJ/R7HQEhI+2NaR0O6gbHKT2c=; b=oXmnqedse1/59YjEhKPVOhq93D/an/U3n6CggbgMZSkc9tSquEZwwuSMC7O1lLQNYw 9eNgUO1iUmrNLknjLkZmPVznWnD+TW4PKy2vHKBiNiqKE98dQssrAb3ZkPNZmZeuAOSJ D62Rj9d5p5HUL6J+oK2eCJ1xDYGSKLQrm7b7VvMXHI4ip+DrTl2biFEwFJwU30zswubc fL6+GRwj8SVxC+RWzC2eTgWBniph3qExxfFrOoK8DVlQSe3SEkuOiLyRN4PvqrzLiuGp H7T2oKf1o8l8m/TF37+UgclhpxD6p/wDgfaPiPPVsB+jsCPylx0FudE9DWcxPsJz8yF6 bLnQ== Received: by 10.66.85.167 with SMTP id i7mr12894239paz.8.1346378851220; Thu, 30 Aug 2012 19:07:31 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id iq1sm2539623pbc.37.2012.08.30.19.07.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2012 19:07:29 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 31 Aug 2012 11:07:21 -0700 From: YongHyeon PYUN Date: Fri, 31 Aug 2012 11:07:21 -0700 To: Lev Serebryakov Message-ID: <20120831180721.GB3208@michelle.cdnetworks.com> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <534292400.20120830131158@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 02:07:38 -0000 On Thu, Aug 30, 2012 at 01:11:58PM +0400, Lev Serebryakov wrote: > Hello, Ian. > You wrote 30 п╟п╡пЁя┐я│я┌п╟ 2012 пЁ., 10:23:56: > > >> Yep, I'll collapse my two-rule chains in one rule. > IS> I guess if the issue persists, we may need to see more of your ruleset. > Not a problem at all, here it is: > http://lev.serebryakov.spb.ru/_sklad/firewall.ipfw > > IS> Hmm, you shouldn't see ANY pppoe traffic on ng0, only on the interface > IS> mpd5 uses to connect with your DSL modem/bridge. Nor would you expect > Yep. I didn't see it. My question is, really: why vr1 (my physical > interface, used to connect to my ISP) takes 50%+ of CPU when traffic > is only 40mbit/s down and about 20mbit/s up (with many connections)? I > was afraid, that all PPPoE traffic is inspected by ipfw and it causes > additional CPU load. It would be interesting to know whether there is any difference before/after taskq change made in r235334. I was told that taskq conversion for vr(4) resulted in better performance but I think taskq shall add more burden on slow hardware. Pre-r235334 interrupt handler still has issues since it wouldn't exit interrupt handler if there are any pending interrupts. It shall consume most of its CPU cycles in the interrupt handler under extreme network load. If pre-r235334 shows better result, you are probably able to implement interrupt mitigation by using VT6102/VT6105's timer interrupt. I guess some frames would be lost with the interrupt mitigation under high network load but other part of kernel would have more chance to run important tasks. Anyway, vr(4) controllers wouldn't be one of best choice for slow machines due to DMA alignment limitation and driver assisted padding requirement. > > Yes, it is only 500Mhz Geode LX, but it is only 40 mbit/s and > 4.5Kpps in both directions, nothing like full 100Mbit or more, and > I've learned "empirical" rule/heuristics about 1Gbit(!) per 1Ghz(!) > for softrouters, So, theoretically, 40mbit should not be a problem at > all for this hardware. > > And now I have not-working WiFi (this box is also AP) when wired > traffic is high (wifi speed drops down to 100KB/s from 2.5-3MB/s > without wired traffic), userland freezes under load (very bad with > ULE, better with 4BSD), and inability to pass through 40Mbit in both > directions simultaneously. > > -- > // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 05:19:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C08AE106564A; Fri, 31 Aug 2012 05:19:23 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id E86F08FC0A; Fri, 31 Aug 2012 05:19:22 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q7V5JJ4J093305; Fri, 31 Aug 2012 12:19:19 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <50404957.302@rdtc.ru> Date: Fri, 31 Aug 2012 12:19:19 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> In-Reply-To: <20120831180721.GB3208@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 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, 31 Aug 2012 05:19:23 -0000 01.09.2012 01:07, YongHyeon PYUN пишет: > It would be interesting to know whether there is any difference > before/after taskq change made in r235334. I was told that taskq > conversion for vr(4) resulted in better performance but I think > taskq shall add more burden on slow hardware. > Pre-r235334 interrupt handler still has issues since it wouldn't > exit interrupt handler if there are any pending interrupts. > It shall consume most of its CPU cycles in the interrupt handler > under extreme network load. If pre-r235334 shows better result, > you are probably able to implement interrupt mitigation by using > VT6102/VT6105's timer interrupt. I guess some frames would be lost > with the interrupt mitigation under high network load but other > part of kernel would have more chance to run important tasks. > Anyway, vr(4) controllers wouldn't be one of best choice for slow > machines due to DMA alignment limitation and driver assisted > padding requirement. I also have AMD Geode LX8-based system having two on-board vr(4) interfaces. I've just tried it with vr(4) driver from HEAD built as module for my 8.3-STABLE/i386. It builds just fine with minor change: --- if_vr.c.orig 2012-08-29 23:36:05.000000000 +0700 +++ if_vr.c 2012-08-29 22:51:01.000000000 +0700 @@ -2176,7 +2176,7 @@ VR_LOCK(sc); mii = device_get_softc(sc->vr_miibus); LIST_FOREACH(miisc, &mii->mii_phys, mii_list) - PHY_RESET(miisc); + mii_phy_reset(miisc); sc->vr_flags &= ~(VR_F_LINK | VR_F_TXPAUSE); error = mii_mediachg(mii); VR_UNLOCK(sc); dmesg says: vr0: port 0xe000-0xe0ff mem 0xef024000-0xef0240ff irq 10 at device 12.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x86 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr0: Ethernet address: 00:10:f3:13:72:c6 vr0: [ITHREAD] vr1: port 0xe400-0xe4ff mem 0xef025000-0xef0250ff irq 11 at device 13.0 on pci0 vr1: Quirks: 0x0 vr1: Revision: 0x86 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr1: Ethernet address: 00:10:f3:13:72:c7 vr1: [ITHREAD] This is industrial Nexcom NICE-3120-LX8 fanless PC system used as home router, the only miniPCI expansion slot is occupied with ath0 WiFi card. http://www.orbitmicro.com/global/system-4423.html I have to say that HEAD driver runs MUCH worse. With stock 8.3 driver I have same 3.35MByte/s one-thread http transfer through this system but LA=1.7 only and userland is pretty responsive. top(1) shows: last pid: 29696; load averages: 1.70, 1.08, 0.88 up 2+00:11:31 22:21:46 94 processes: 2 running, 78 sleeping, 14 waiting CPU: 7.7% user, 0.0% nice, 0.0% system, 15.4% interrupt, 76.9% idle Mem: 51M Active, 671M Inact, 188M Wired, 18M Cache, 110M Buf, 60M Free Swap: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root -68 - 0K 112K WAIT 235:11 51.56% intr{irq11: vr1} 10 root 171 ki31 0K 8K RUN 24.4H 31.15% idle 11 root -44 - 0K 112K WAIT 0:51 9.38% intr{swi1: netisr 0} 11 root -68 - 0K 112K WAIT 0:30 6.40% intr{irq10: vr0} 29688 root 44 0 3628K 1708K RUN 0:00 0.10% top With HEAD driver, for same test LA pikes to 8 and higher and it takes up to 10 seconds for userland applications like shell or screen(1) to respond to physical console events: last pid: 1335; load averages: 8.27, 4.05, 2.04 up 0+00:14:21 23:31:18 97 processes: 2 running, 83 sleeping, 12 waiting CPU: 0.1% user, 0.0% nice, 55.7% system, 43.6% interrupt, 0.6% idle Mem: 40M Active, 21M Inact, 175M Wired, 2512K Cache, 109M Buf, 749M Free Swap: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 12 root -16 - 0K 8K sleep 1:12 44.87% ng_queue 11 root -28 - 0K 96K WAIT 1:45 35.60% intr{swi5: +} 11 root -44 - 0K 96K WAIT 1:03 18.80% intr{swi1: netisr 0} 10 root 171 ki31 0K 8K RUN 6:34 0.39% idle 13 root -16 - 0K 8K - 0:07 0.10% yarrow That's with direct NETISR mode, indirect mode makes it only worse (LA is higher for both drivers, up to 4.5 for old one and up to 9+ for new). I ran tests with same custom kernel, loading/unloading old/new drivers as modules without reboot. Schedules is default SCHED_ULE. Another note: I run mpd/PPPoE/ng0 over vr1 and http transfer were through ng0. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 05:45:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39BD6106566B; Fri, 31 Aug 2012 05:45:56 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4965D8FC12; Fri, 31 Aug 2012 05:45:55 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q7V5jr9F093506; Fri, 31 Aug 2012 12:45:53 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <50404F91.8080302@rdtc.ru> Date: Fri, 31 Aug 2012 12:45:53 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> In-Reply-To: <20120831180721.GB3208@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: vr(4) troubles for AMD Geode CS5536 chipset 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, 31 Aug 2012 05:45:56 -0000 In previous letter I've described my attempts to try vr(4) from HEAD. Now I'd like to explain why I've tried it. The problem is that stock vr(4) from 8.3-STABLE/i386 has serious issues for my system. I have home router with two vr interfaces, vr0 is for LAN (IPoE) and vr1 is for WAN (PPPoE/mpd). Presently, every day my WAN vr interface stops running correctly: sometimes it stops receiving all packets - tcpdump shows none of them. Sometimes, it receives some but with great delay - up to 10 seconds (not miliseconds) and even more. tcpdump shows that delay occurs on receive path. Sometimes, it even rearranges packets - tcpdump shows that some incoming ICMP echo requests with lower sequence numbers come in later that already answered higher-numbered requests. ifconfig vr1 down/up revives interface completely until next morning. sysctl net.inet.ip.fw.enable=0 does not solve the problem. I have control over WAN switching/routing network and may assure it runs just fine. However, I can't guarantee it has no "soft" anomalies like short storms or some silly broadcasts. I've tried to make incoming flood with ng_source(4) generated UDP flood at 100M rate for 60 seconds and failed to reproduce the problem artificially. I've tried to move WAN from vr1 to vr0 and the problem has moved to vr0 too. My LAN has very little traffic and corresponding vr interface exhibits no problems. This router also routinely runs transmission (torrent client from ports) serving torrents from USB-attached HDD making severe CPU load, so I suspect the problem may be related with CPU load. I've also checked mbuf/mbuf clusters usage and they are all right: # netstat -m 1539/2076/3615 mbufs in use (current/cache/total) 1200/1278/2478/65536 mbuf clusters in use (current/cache/total/max) 1200/306 mbuf+clusters out of packet secondary zone in use (current/cache) 318/181/499/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 4056K/3799K/7855K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines # vmstat -z | egrep -i 'ITEM|mbuf' ITEM SIZE LIMIT USED FREE REQUESTS FAILURES mbuf_packet: 256, 0, 1429, 77, 112854470, 0 mbuf: 256, 0, 489, 1620, 369073316, 0 mbuf_cluster: 2048, 65536, 1506, 604, 5401864, 0 mbuf_jumbo_page: 4096, 12800, 469, 158, 8306777, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 NetGraph items: 36, 4130, 1, 117, 263123, 0 NetGraph data items: 36, 531, 0, 295, 106663377, 0 While ifconfig vr1 down/up solves the problem completely (for some long time), taking link down/up using switch solves it "in half" - huge packet delays disappear and turn to 25% packet loss happening in regular short intervals, once a second of like. ifconfig down/up clears this mess too. Please help me to debug this, it's pretty annoying. I had a hope new vr(4) driver would help but it takes my system down under average load and is unusable. Here is start of dmesg.boot: Copyright (c) 1992-2012 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 8.3-STABLE #1: Wed Aug 29 22:49:45 NOVT 2012 root@grosbein.pp.ru:/usr/local/obj/nanobsd.gw/i386/usr/local/src/sys/GW i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Family = 5 Model = a Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 1065025536 (1015 MB) avail memory = 1032929280 (985 MB) K6-family MTRR support enabled (2 registers) I must also note that this system runs with ACPI disabled in /boot/loader.conf: hint.acpi.0.disabled=1 Otherwise, its timekeeping becomes broken. Eugene Gtosbein From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 05:50:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69981106564A; Fri, 31 Aug 2012 05:50:08 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id C068F8FC12; Fri, 31 Aug 2012 05:50:07 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q7V5o5Om093548; Fri, 31 Aug 2012 12:50:06 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5040508D.9080107@rdtc.ru> Date: Fri, 31 Aug 2012 12:50:05 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404957.302@rdtc.ru> In-Reply-To: <50404957.302@rdtc.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 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, 31 Aug 2012 05:50:08 -0000 31.08.2012 12:19, Eugene Grosbein пишет: > With HEAD driver, for same test LA pikes to 8 and higher and it takes up to 10 seconds > for userland applications like shell or screen(1) to respond to physical console events: > > last pid: 1335; load averages: 8.27, 4.05, 2.04 up 0+00:14:21 23:31:18 > 97 processes: 2 running, 83 sleeping, 12 waiting > CPU: 0.1% user, 0.0% nice, 55.7% system, 43.6% interrupt, 0.6% idle > Mem: 40M Active, 21M Inact, 175M Wired, 2512K Cache, 109M Buf, 749M Free > Swap: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND > 12 root -16 - 0K 8K sleep 1:12 44.87% ng_queue > 11 root -28 - 0K 96K WAIT 1:45 35.60% intr{swi5: +} > 11 root -44 - 0K 96K WAIT 1:03 18.80% intr{swi1: netisr 0} > 10 root 171 ki31 0K 8K RUN 6:34 0.39% idle > 13 root -16 - 0K 8K - 0:07 0.10% yarrow Not very representative screenshot; in fact, interrupt rate is at 90-100% level most of time for both of old and new vr(4) drivers during test and that's the reason of spiking Load Average. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 06:54:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1BB106566C; Fri, 31 Aug 2012 06:54:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F0698FC1E; Fri, 31 Aug 2012 06:54:50 +0000 (UTC) Received: by dadr6 with SMTP id r6so1713038dad.13 for ; Thu, 30 Aug 2012 23:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4EsAW7m96levRjpopyzZ4574FUPGGGKeCPZ56ytcLiA=; b=x7uAXBItIUD7kiPCuH1B9YQXlKDk8v/r4lkjAlEP8vbh7OhqZKMA0bQsPBw9ZNQmdM 5xZ/P84QmAIHDa843ZKaQlw4C5Y+SDXVMk4+lo5EWAtCqxW2t/lsDP4//4Ummbpseoty A9rC7Ko2nMTsEVdXt6Bk40LqHL68v5e05pKRmcmukT8lvj8Q++W3JD71t3ilh0QjQk/m W4yLbMYyRwY9C3dz3Dcd6evtmzjLgD4VEkqndb3wmkYdOHCsZVJjBMqRe9ep/e/kxXz5 dJ8ysqdBPU+Opno03JOFablTW0bz01QV/hUiV5xaDAUySHDBNrcaTDbQFusw11IvaHc0 j/aA== MIME-Version: 1.0 Received: by 10.66.89.36 with SMTP id bl4mr13735172pab.58.1346396089067; Thu, 30 Aug 2012 23:54:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 30 Aug 2012 23:54:49 -0700 (PDT) In-Reply-To: <5040508D.9080107@rdtc.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404957.302@rdtc.ru> <5040508D.9080107@rdtc.ru> Date: Thu, 30 Aug 2012 23:54:49 -0700 X-Google-Sender-Auth: Kk-U604DCXuggixmJtwo5vPofo4 Message-ID: From: Adrian Chadd To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 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, 31 Aug 2012 06:54:51 -0000 Just as a data point - disable preemption and try again? And run 4BSD + no preemption, try again? Adrian On 30 August 2012 22:50, Eugene Grosbein wrote: > 31.08.2012 12:19, Eugene Grosbein =D0=C9=DB=C5=D4: > >> With HEAD driver, for same test LA pikes to 8 and higher and it takes up= to 10 seconds >> for userland applications like shell or screen(1) to respond to physical= console events: >> >> last pid: 1335; load averages: 8.27, 4.05, 2.04 up 0+00:14:2= 1 23:31:18 >> 97 processes: 2 running, 83 sleeping, 12 waiting >> CPU: 0.1% user, 0.0% nice, 55.7% system, 43.6% interrupt, 0.6% idle >> Mem: 40M Active, 21M Inact, 175M Wired, 2512K Cache, 109M Buf, 749M Free >> Swap: >> >> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 12 root -16 - 0K 8K sleep 1:12 44.87% ng_queue >> 11 root -28 - 0K 96K WAIT 1:45 35.60% intr{swi5= : +} >> 11 root -44 - 0K 96K WAIT 1:03 18.80% intr{swi1= : netisr 0} >> 10 root 171 ki31 0K 8K RUN 6:34 0.39% idle >> 13 root -16 - 0K 8K - 0:07 0.10% yarrow > > Not very representative screenshot; in fact, interrupt rate is at 90-100%= level > most of time for both of old and new vr(4) drivers during test and > that's the reason of spiking Load Average. > > Eugene Grosbein > _______________________________________________ > 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 Aug 31 07:21:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6FEA106566B; Fri, 31 Aug 2012 07:21:08 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2493C8FC12; Fri, 31 Aug 2012 07:21:07 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q7V7L4GF094333; Fri, 31 Aug 2012 14:21:05 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <504065E0.4030907@rdtc.ru> Date: Fri, 31 Aug 2012 14:21:04 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404957.302@rdtc.ru> <5040508D.9080107@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 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, 31 Aug 2012 07:21:08 -0000 31.08.2012 13:54, Adrian Chadd пишет: > Just as a data point - disable preemption and try again? I'll try this evening. > And run 4BSD + no preemption, try again? With ULE old driver runs with low LA and userland is just fine. Shouldn't new driver behave nice with ULE too? Anyway, I'll try and compare. From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 08:10:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78630106566B for ; Fri, 31 Aug 2012 08:10:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7558FC0C for ; Fri, 31 Aug 2012 08:10:51 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:49ee:4a:4b3c:6f58]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D752F4AC2D; Fri, 31 Aug 2012 12:10:47 +0400 (MSK) Date: Fri, 31 Aug 2012 12:10:43 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <643110717.20120831121043@serebryakov.spb.ru> To: Adam Vande More In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 08:10:52 -0000 Hello, Adam. You wrote 31 =C1=D7=C7=D5=D3=D4=C1 2012 =C7., 0:32:25: AVM> BUGS AVM> The vr driver always copies transmit mbuf chains into longword-al= igned AVM> buffers prior to transmission in order to pacify the Rhine chips.= If AVM> buffers are not aligned correctly, the chip will round the suppli= ed AVM> buffer address and begin DMAing from the wrong location. This bu= ffer AVM> copying impairs transmit performance on slower systems but cannot= be AVM> avoided. On faster machines (e.g. a Pentium II), the performance AVM> impact AVM> is much less noticeable. Really, this is not truth. Or, to be more specific, it is not complete truth. Now if_vr copies data only for some chips (quirk VR_Q_NEEDALIGN in sources). My chips (VT6105M) don't need it, and driver doesn't copy data for them. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 10:45:44 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4879106564A for ; Fri, 31 Aug 2012 10:45:44 +0000 (UTC) (envelope-from kaltheat@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 91A528FC1A for ; Fri, 31 Aug 2012 10:45:44 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:subject:message-id:references:mime-version:content-type:in-reply-to:sender; b=BtjrhaYMXZSBGXh4B4TmAQmigS+9RvtQhJ43EOw0PQya5H/U+YuH3VcUCbC6Lc1LqI6jhe3fnrA4 NoOX/tIjA7jq0TSx7Sg6sA82G6gM7RXbn9WrKxuUVJqQjMyBBlW6 Received: from - (106-147-103-86.dynamic.dsl.tng.de [86.103.147.106]) by mx.zohomail.com with SMTPS id 1346409940723766.5973922673131; Fri, 31 Aug 2012 03:45:40 -0700 (PDT) Date: Fri, 31 Aug 2012 12:45:32 +0200 From: kaltheat@googlemail.com To: net@freebsd.org Message-ID: <20120831104532.GA1758@-> References: <20120830215147.GA2383@-> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120830215147.GA2383@-> Sender: kaltheat@zoho.com X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Cc: Subject: Re: lagg failover issue 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, 31 Aug 2012 10:45:44 -0000 On Thu, Aug 30, 2012 at 11:51:47PM +0200, kaltheat@googlemail.com wrote: > Hi, > > I'm using following devices: > > bge0 - NetLink BCM57780 Gigabit Ethernet PCIe > ndis0 - BCM43225 802.11b/g/n > > As far as I've tested it, each of them work fine for itself. > > I want to aggregate them using lagg in failover mode as explained here[1][2]. > But when I remove the wire (wireless connection is established), I can't put > any traffic through lagg0. > > What might be the problem? Can you give me some hints on how to debug this > lagg-issue further? > > Regards, > kaltheat > > [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html > Example 32-3. Failover Mode Between Wired and Wireless Interfaces > [2] http://www.freebsd.org/cgi/man.cgi?query=lagg#EXAMPLES > Second example > > Hi, I can provide some additional informations: I read somewhere that it might be a problem to change the ethernet address of a ndis-interface. On the accesspoint I saw that although I changed the ethernet address of the wireless nic to that one of the wired nic (checked with ifconfig) connection was tried to be established with the native mac of the wireless nic. Now I'm using the native mac of the wireless nic on the wired nic to avoid this problem. This didn't solve the lagg issue. While I was pinging a client reachable through wired and wireless lan I observed traffic on the three interfaces (bge0, wlan0, lagg0). With cable connected I saw ping traffic (in & out) on lagg0 and bge0. When removing cable after a small break I only saw outgoing packages on lagg0. IP and ethernet addresses of outgoing packages were the same in each case. Regards, kaltheat From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 11:29:54 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123751065670 for ; Fri, 31 Aug 2012 11:29:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DAFBA8FC12 for ; Fri, 31 Aug 2012 11:29:53 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so4725948pbb.13 for ; Fri, 31 Aug 2012 04:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zHlpMXGpfQDbUUoRVardx3exUtebc/IPAi7+vviZoAY=; b=ohTG/jOx3xEPHUIrBX5kPUFVst/72FIGuhA7DJYb6z6UydajhWyXClTdkdBZnm9Yin hMNRkg4gA/aomdiiI/nqvG40Fa9agwG3V75G9F6+dSJc/qsh0UVmtT0d+uRYFklP9wGl dIkbbrrXrNf9xlTZUXIHvLhTRLRHmoroHAwinmeus4IcB9VR4yX0lATeR5tyVDnZTRy3 ptZ9tDz9cbPCNYJV1xnP6jyHjHUrDmnicJuCI56Q5VC3VyGeEYYf/PloQ3WmxHBmTZ2j oDlugBy2DuoanvnI2DsPxES80l7hxxodKsR0JBydBVCqIOZhHFRnRjjmuB9HhwtxRVcn Vy+A== MIME-Version: 1.0 Received: by 10.68.129.131 with SMTP id nw3mr17059520pbb.43.1346412593387; Fri, 31 Aug 2012 04:29:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Fri, 31 Aug 2012 04:29:53 -0700 (PDT) In-Reply-To: <20120831104532.GA1758@-> References: <20120830215147.GA2383@-> <20120831104532.GA1758@-> Date: Fri, 31 Aug 2012 04:29:53 -0700 X-Google-Sender-Auth: sniAQ-nNEOiKUPgF7rIeQnkUHIc Message-ID: From: Adrian Chadd To: kaltheat@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: lagg failover issue 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, 31 Aug 2012 11:29:54 -0000 guys, You can't override set the outbound MAC address of a wireless station. It associates with the MAC address of the card/vap/device. The AP _will_ store that MAC address in its node table. When sending frames from a STA, the only available details are: * source address - STA MAC * destination BSS - the destination BSS MAC address, ie which AP to send to * destination address - the destnation MAC only in WDS (4-address) setups is there a fourth address, which is the "actual original source MAC address". In this instance, the STA is actually tunnelling traffic from other source MACs. I don't know who started that lagg hack, but let me just be really really clear - if you try sending the source frames out a wifi interface with a source MAC that isn't the STA mac, it won't work. By design. If it does work - it's a fluke and it's not portable. What you really want is for the same IP to exist but only both interfaces and have the source interface/MAC seamlessly change. There've been proposals in the past for the STA side code to "proxy STA" a bunch of other MACs behind it - using 3 address frames( ie, not WDS) but keeping state as to which IP traffic is going to which MAC address. No, net80211 in our tree doesn't have that support. I hope that puts this all to rest. Adrian On 31 August 2012 03:45, wrote: > On Thu, Aug 30, 2012 at 11:51:47PM +0200, kaltheat@googlemail.com wrote: >> Hi, >> >> I'm using following devices: >> >> bge0 - NetLink BCM57780 Gigabit Ethernet PCIe >> ndis0 - BCM43225 802.11b/g/n >> >> As far as I've tested it, each of them work fine for itself. >> >> I want to aggregate them using lagg in failover mode as explained here[1][2]. >> But when I remove the wire (wireless connection is established), I can't put >> any traffic through lagg0. >> >> What might be the problem? Can you give me some hints on how to debug this >> lagg-issue further? >> >> Regards, >> kaltheat >> >> [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html >> Example 32-3. Failover Mode Between Wired and Wireless Interfaces >> [2] http://www.freebsd.org/cgi/man.cgi?query=lagg#EXAMPLES >> Second example >> >> > > Hi, > > I can provide some additional informations: > > I read somewhere that it might be a problem to change the ethernet address of a > ndis-interface. On the accesspoint I saw that although I changed the ethernet > address of the wireless nic to that one of the wired nic (checked with ifconfig) > connection was tried to be established with the native mac of the wireless nic. > Now I'm using the native mac of the wireless nic on the wired nic to avoid this > problem. > This didn't solve the lagg issue. > > While I was pinging a client reachable through wired and wireless lan I observed > traffic on the three interfaces (bge0, wlan0, lagg0). With cable connected I saw > ping traffic (in & out) on lagg0 and bge0. When removing cable after a small > break I only saw outgoing packages on lagg0. IP and ethernet addresses of outgoing > packages were the same in each case. > > > Regards, > kaltheat > > > _______________________________________________ > 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 Aug 31 12:17:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08895106566B for ; Fri, 31 Aug 2012 12:17:17 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id DB5018FC2E for ; Fri, 31 Aug 2012 12:17:16 +0000 (UTC) Received: from [10.4.0.166] ([149.6.120.133]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q7VCHD5u043014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 05:17:15 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Marcel Moolenaar In-Reply-To: Date: Fri, 31 Aug 2012 13:17:22 +0100 Content-Transfer-Encoding: 7bit Message-Id: <8B6CCAD8-AFC8-46A3-A719-DDCDF5123984@xcllnt.net> References: To: PseudoCylon X-Mailer: Apple Mail (2.1486) Cc: freebsd-net@freebsd.org, Anuranjan Shukla Subject: Re: Proposal for changes to network device drivers and network stack (RFC) 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, 31 Aug 2012 12:17:17 -0000 On Aug 28, 2012, at 10:24 AM, PseudoCylon wrote: > Wouldn't using prepossessor macro or hooking be more flexible? (Could > support multiple functionality.) Macros make it impossible to treat ifnet as an opaque type. As such, it won't be possible to havr a single pre-compiled driver that can work with different network stacks. It's definitely been on our minds to make it possible to use macros for performance reasons when ABI stability is not a concern, but wanted to focus on ABI stability first. FYI, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 13:27:26 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FC58106566B; Fri, 31 Aug 2012 13:27:26 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 336BC8FC0C; Fri, 31 Aug 2012 13:27:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7VDRQfE018634; Fri, 31 Aug 2012 13:27:26 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7VDRPq5018630; Fri, 31 Aug 2012 13:27:25 GMT (envelope-from bz) Date: Fri, 31 Aug 2012 13:27:25 GMT Message-Id: <201208311327.q7VDRPq5018630@freefall.freebsd.org> To: jrblair@seed.net.tw, bz@FreeBSD.org, bz@FreeBSD.org, freebsd-net@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/122252: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) 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, 31 Aug 2012 13:27:26 -0000 Synopsis: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) State-Changed-From-To: closed->open State-Changed-By: bz State-Changed-When: Fri Aug 31 13:26:39 UTC 2012 State-Changed-Why: Re-open after years; probably people having touched the driver atey etc should look into this. Responsible-Changed-From-To: bz->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Fri Aug 31 13:26:39 UTC 2012 Responsible-Changed-Why: Re-open after years; probably people having touched the driver atey etc should look into this. http://www.freebsd.org/cgi/query-pr.cgi?pr=122252 From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 15:54:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 295A81065673; Fri, 31 Aug 2012 15:54:10 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4FF8FC17; Fri, 31 Aug 2012 15:54:09 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q7VFs5OI098479; Fri, 31 Aug 2012 22:54:05 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5040DE1D.7040700@rdtc.ru> Date: Fri, 31 Aug 2012 22:54:05 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404957.302@rdtc.ru> <5040508D.9080107@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 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, 31 Aug 2012 15:54:10 -0000 31.08.2012 13:54, Adrian Chadd пишет: > Just as a data point - disable preemption and try again? I've rebuilt by kernel with SCHED_ULE and excluded PREEMPTION. Stock driver works without changes in behaviour and driver from HEAD now works very similar to old one: LA is not higher than 2 and userland is pretty responsive. Also, transfer speed with new driver is several percent more. That's good. Care to explain such dramatic difference for new driver with/without PREEMPTION for relatively slow uniprocessor system? > And run 4BSD + no preemption, try again? I'll try that too in short time. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 16:33:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 946B11065670; Fri, 31 Aug 2012 16:33:15 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id E8C728FC12; Fri, 31 Aug 2012 16:33:14 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q7VGXDYv098738; Fri, 31 Aug 2012 23:33:13 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5040E749.9070200@rdtc.ru> Date: Fri, 31 Aug 2012 23:33:13 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404957.302@rdtc.ru> <5040508D.9080107@rdtc.ru> <5040DE1D.7040700@rdtc.ru> In-Reply-To: <5040DE1D.7040700@rdtc.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 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, 31 Aug 2012 16:33:15 -0000 31.08.2012 22:54, Eugene Grosbein пишет: > I've rebuilt by kernel with SCHED_ULE and excluded PREEMPTION. > Stock driver works without changes in behaviour and driver from HEAD > now works very similar to old one: LA is not higher than 2 and > userland is pretty responsive. Also, transfer speed with new driver is > several percent more. That's good. > > Care to explain such dramatic difference for new driver > with/without PREEMPTION for relatively slow uniprocessor system? > >> And run 4BSD + no preemption, try again? I've tried 4BSD without preemption too. Can't see any difference from ULE without preemption. Should I stick with 4BSD for UP system? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 18:09:31 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F23106564A; Fri, 31 Aug 2012 18:09:31 +0000 (UTC) (envelope-from kaltheat@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 486738FC1D; Fri, 31 Aug 2012 18:09:30 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to:sender; b=qm1s5GOyKJt0TpoBV+vV9VQcLl9ROtXvPlmk2fyKPECa10aab0+FRVm4CKhleACAKzjnZ88DWsT3 ZkinZaRclb+xmPVyoQVQLTShQoQ8YlXI/RrQXrU5v2fqpVjyT/wu Received: from - (106-147-103-86.dynamic.dsl.tng.de [86.103.147.106]) by mx.zohomail.com with SMTPS id 1346436570207794.4817511890449; Fri, 31 Aug 2012 11:09:30 -0700 (PDT) Date: Fri, 31 Aug 2012 20:09:20 +0200 From: kaltheat@googlemail.com To: Adrian Chadd Message-ID: <20120831180920.GA8171@-> References: <20120830215147.GA2383@-> <20120831104532.GA1758@-> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: kaltheat@zoho.com X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Cc: net@freebsd.org Subject: Re: lagg failover issue 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, 31 Aug 2012 18:09:31 -0000 On Fri, Aug 31, 2012 at 04:29:53AM -0700, Adrian Chadd wrote: > guys, > > You can't override set the outbound MAC address of a wireless station. > It associates with the MAC address of the card/vap/device. The AP > _will_ store that MAC address in its node table. > > When sending frames from a STA, the only available details are: > > * source address - STA MAC > * destination BSS - the destination BSS MAC address, ie which AP to send to > * destination address - the destnation MAC > > only in WDS (4-address) setups is there a fourth address, which is the > "actual original source MAC address". In this instance, the STA is > actually tunnelling traffic from other source MACs. > > I don't know who started that lagg hack, but let me just be really > really clear - if you try sending the source frames out a wifi > interface with a source MAC that isn't the STA mac, it won't work. By > design. If it does work - it's a fluke and it's not portable. > > What you really want is for the same IP to exist but only both > interfaces and have the source interface/MAC seamlessly change. > > There've been proposals in the past for the STA side code to "proxy > STA" a bunch of other MACs behind it - using 3 address frames( ie, not > WDS) but keeping state as to which IP traffic is going to which MAC > address. No, net80211 in our tree doesn't have that support. > > I hope that puts this all to rest. > > > > Adrian > -- cutted here --------- Hi Adrian, Maybe I don't understand you, but this summarizes what I think I understood: Changing the wireless NIC's MAC is not possible. Only in some cases, but those cases are exceptions and shouldn't exist. I don't understand how this is pushing me further to solve my problem. As I mentioned I'm now changing the MAC of the wired NIC to that one of the wireless NIC. So your remarks don't apply to this situation, I think. Am I right? By the way: Do you think the configuration examples (in handbook and manpage) I provided earlier in this thread are misleading and should be changed? kaltheat From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 18:15:48 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8432D106566C; Fri, 31 Aug 2012 18:15:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8D38FC08; Fri, 31 Aug 2012 18:15:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C34D7B945; Fri, 31 Aug 2012 14:15:47 -0400 (EDT) From: John Baldwin To: net@freebsd.org Date: Fri, 31 Aug 2012 14:15:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201208311415.47225.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 31 Aug 2012 14:15:47 -0400 (EDT) Cc: darrenr@freebsd.org Subject: [PATCH] Convert ipfilter from timeout(9) to callout(9) 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, 31 Aug 2012 18:15:48 -0000 I have a patch to switch the ipfilter code from using the deprecated timeout(9) API to using callout(9) instead. Is anyone able to test this? http://www.FreeBSD.org/~jhb/patches/ipfilter_callout.patch -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Sep 1 21:55:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2B811065670 for ; Sat, 1 Sep 2012 21:55:31 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECB58FC16 for ; Sat, 1 Sep 2012 21:55:30 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q81LtLRh011859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Sep 2012 07:55:22 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q81LtFfp061176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Sep 2012 07:55:15 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q81LtEex061174; Sun, 2 Sep 2012 07:55:14 +1000 (EST) (envelope-from peter) Date: Sun, 2 Sep 2012 07:55:14 +1000 From: Peter Jeremy To: "Dustin J. Mitchell" Message-ID: <20120901215514.GA84970@server.rulingia.com> References: <20120827094956.GA93853@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: bridging VLAN interfaces and STP 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, 01 Sep 2012 21:55:32 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry for the delay, Real Life=E2=84=A2 intervened. On 2012-Aug-27 07:45:41 -0400, "Dustin J. Mitchell" wro= te: >On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy wrote: >> On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" = wrote: >>>On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell = wrote: >>>> Hey folks. I'm trying to set up a system with one 802.1q-tagged >>>> upstream, and a few untagged interfaces. So I'd like to bridge the >>>> vlan(4) interfaces on vr1 to specific other interfaces. =2E.. >bridge10: flags=3D8843 metric 0 mt= u 1500 > ether 02:f4:a1:63:5a:0a > nd6 options=3D21 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: vr3 flags=3D143 > ifmaxaddr 0 port 4 priority 128 path cost 55 > member: vr2 flags=3D143 > ifmaxaddr 0 port 3 priority 128 path cost 55 > member: vr1.10 flags=3D143 > ifmaxaddr 0 port 9 priority 128 path cost 200000 >bridge20: flags=3D8843 metric 0 mt= u 1500 > ether 02:f4:a1:63:5a:14 > nd6 options=3D21 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: vr0 flags=3D143 > ifmaxaddr 0 port 1 priority 128 path cost 55 > member: vr1.20 flags=3D143 > ifmaxaddr 0 port 10 priority 128 path cost 200000 That looks like RSTP is enabled on both bridge10 and bridge20 but is not seeing incoming [R]STP packets. Are you sure the switch connected to vr1 is configured with per-VLAN STP (this is probably not the switch default). Have you tried running tcpdump on vr1 and checked that you are seeing STP packets within the VLANs. >gateway_enable=3D"YES" >firewall_enable=3D"YES" >firewall_type=3D"OPEN" gateway_enable=3D"YES" will let the system route packets between bridge10 and bridge20 but shouldn't have any effect on bridging packets between (eg) vr1.10, vr2 & vr3. --=20 Peter Jeremy --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBChEIACgkQ/opHv/APuIf8qwCgtEu8+0uuCfU0BbeDOJiJ6YGU ml4An1KET0o4371JU/qoERDxglvUfye8 =6Vtb -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 1 23:13:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3A7B106564A for ; Sat, 1 Sep 2012 23:13:03 +0000 (UTC) (envelope-from djmitche@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 181578FC08 for ; Sat, 1 Sep 2012 23:13:02 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3079937wgb.31 for ; Sat, 01 Sep 2012 16:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SOD4xPIrnriccnHHbgqtaS1OADDBONjzucskI6BpW98=; b=qRPKqk2DLCSSllMK6kiYsqV8R7fDXg6oS+p670140Gd68rnbJYArIE24crQ7psiI6u +bKQhttpfd2n9adgEM7sEPR39FbjG1BX/pzNsVmko0SrOnuTL3l3XRl9xLDR5c1zEDiL bGTX3Da7xLN4mCMni2gDC6Jdwju7LrV/9QJsGCdhf8MNdwqpB801aYYzkf0WcN+VBt67 af+DFuDdQSL4IhJLkD6roAvvDeDox2cZeiN22dov50KFti/1OraEdfSO2YDKQtawaKhT P493P+SSr7vozsnRBYJ6qKYmgRxke/wtHR14LxuMxKtcjGSUS/d7ibaZ/W1+/BwfT09O LZNA== MIME-Version: 1.0 Received: by 10.216.198.10 with SMTP id u10mr7105821wen.80.1346541181799; Sat, 01 Sep 2012 16:13:01 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.223.4.215 with HTTP; Sat, 1 Sep 2012 16:13:01 -0700 (PDT) In-Reply-To: <20120901215514.GA84970@server.rulingia.com> References: <20120827094956.GA93853@server.rulingia.com> <20120901215514.GA84970@server.rulingia.com> Date: Sat, 1 Sep 2012 19:13:01 -0400 X-Google-Sender-Auth: Dfb_Y2vfVakw-YIk1-BfiO0CKDM Message-ID: From: "Dustin J. Mitchell" To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: bridging VLAN interfaces and STP 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, 01 Sep 2012 23:13:03 -0000 On Sat, Sep 1, 2012 at 5:55 PM, Peter Jeremy wrote: > That looks like RSTP is enabled on both bridge10 and bridge20 but is > not seeing incoming [R]STP packets. Are you sure the switch connected > to vr1 is configured with per-VLAN STP (this is probably not the > switch default). > > Have you tried running tcpdump on vr1 and checked that you are seeing > STP packets within the VLANs. Actually, if you compare with my original ifconfig, you'll see that this particular arrangement shows STP as enabled on the bridge, but not on any of the members (no STP in their options. In the OP, you can see that the vr{2,3} get STP in their flags () while vr1.10 does not. That, and the error message from the 'ifconfig bridge10 stp vr1.10' command.. Dustin