From owner-freebsd-net@FreeBSD.ORG Sun Dec 16 01:06:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 119FA528; Sun, 16 Dec 2012 01:06:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9473F8FC12; Sun, 16 Dec 2012 01:06:12 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so5847238vba.13 for ; Sat, 15 Dec 2012 17:06:12 -0800 (PST) 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=N/bZrrusDVn50WWWxfFOelp7n2AkMKEeP/Nlu1fl1KA=; b=1KNENbmzzTX62QoprL5rr+omVp2JUbpX8aeTHov3M3STbAMVMi2sVeRU01TXraLNC6 8qOzZuMLeBzHfnCQ/T5MDkdpMx0FzzxHlXwi+1PNOZReQ8EP1KRc145R/qk7Has2q3IX bYZHPZuPGkzzJLgxLgBWnUge4IjSqaaj70ELs5swFmkg0GcaAKx4XzH956er6DkG7bbq BAC5/AvvPtZ0kuciHzjVP39kIX0TclyOW+zpdjqYX28pwV90hvEAixO5E56WavWabuht en+Oh1aWWcNwdZC90oJ9WE4hA07c9DsKHDTwxqCdHubgOWhmgdMB0WRXX7r5cRD2AL3L uKhw== MIME-Version: 1.0 Received: by 10.59.13.135 with SMTP id ey7mr17016187ved.37.1355619971891; Sat, 15 Dec 2012 17:06:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.58.201.202 with HTTP; Sat, 15 Dec 2012 17:06:11 -0800 (PST) In-Reply-To: <476652410abd01eff09cf38132ebd0f6.authenticated@ultimatedns.net> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> <476652410abd01eff09cf38132ebd0f6.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 17:06:11 -0800 X-Google-Sender-Auth: BgcoOouAERVsyY8ZdlOsAxX0sXk Message-ID: Subject: Re: MAC cloning available like Linux has? From: Adrian Chadd To: Chris H Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 01:06:13 -0000 Yes, please file a PR so that the documentation gets updated to reflect this. You can't be the only person who wishes to do this. As I said, I think it's worth extended rc.conf to have a specific "ether" field for ifconfig, so any device-specific weird crap (especially when creating cloned devices) can be done at the right point before the interface is brought up. Thanks, Adrian On 15 December 2012 14:11, Chris H wrote: >>> Hi, >>> >>> Please file a PR for this. I think this (and mac address >> Greetings Adrian, and thank you for your reply. >> >>> setup/changing on net80211, similar issues) needs both some better >>> documentation/FAQ entries and updates to the rc scripts. >>> >>> I think we may want to add an ifconfig_X_ether="" to set the L2 >>> address appropriately for an interface. >>> >>> Thanks, >>> >>> >>> >>> Adrian >> >> Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and >> experimented with installing 8.2. But I think I stumbled onto >> something. I don't know (yet) if this will carry over to 9.x yet. >> But here's what I discovered: >> >> in rc.conf, adding the following (order is important!), everything >> works as expected/desired/anticipated; >> >> --- begin rc,conf -------------------------------------------------------------- >> ifconfig_ue0="ether ##:##:##:##:##:##" >> >> ifconfig_ue0_alias0="DHCP" >> >> *** or *** >> >> ifconfig_ue0_alias0="inet ip4.add.ress.anticipated netmask kno.wn.net.mask" >> >> followed by >> defaultrouter="kno.wn.gate.way" --applies for static only >> --- end rc,conf -------------------------------------------------------------- >> >> So. It appears this will be the answer. _However_ I can't swear to it >> until I spin up && install a (fresh) copy of RELENG_9. >> I'll do so, and report back. >> >> Thanks again, for your reply. >> >> --Chris > > OK. The results are in -- > Using the RC(8) declarations I listed above work not only in RELENG_8, > but also in RELENG_9. I just performed an install from the 9.0 CD I > downloaded from freebsd.org on 12-12-14. Everything (both as STATIC, > and as DHCP) worked as expected/anticipated. > > Is this still worth a PR(1)? > > Best wishes, and thanks again, to everyone that took the time to help! > > --Chris > >> >> >> >>> >>> On 15 December 2012 10:36, Chris H wrote: >>>>> On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: >>>>>> Hello Glen, and thank you for your reply. >>>>>> > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >>>>>> >> ifconfig_ue0="DHCP" >>>>>> >> create_args_ue0="ether ##:##:##:##:##:##" >>>>>> >> create_args is simply ignored. >>>>>> >> >>>>>> > >>>>>> > Ignored how? What commands are you running to verify it works? >>>>>> > For me, create_args_IFNAME works fine on my firewall. >>>>>> >>>>>> Unfortunately, it had no affect for me. >>>>>> The ue0 maintained the same MAC it started with. >>>>>> Out of desperation, I even tried it in /boot/loader.conf. >>>>> >>>>> It is not a loader(8) tunable, it is part of the rc(8) system. >>>>> >>>>> You did not answer the important part of what I asked - how are you >>>>> testing? Are you rebooting the machine? Are you using the netif rc >>>>> script? >>>> >>>> Ahh. Sorry, my bad. Rebooting. >>>> >>>> I have no difficulty issuing: >>>> ifconfig ue0 down >>>> ifconfig ue0 ether ##:##:##:##:##:## >>>> dhclient ue0 >>>> >>>> This method will always return the expected/desired results. >>>> >>>>> >>>>> Glen >>>>> >>>>> >>>> Thanks for the reply. >>>> >>>> --Chris >>>> >>>> >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Sun Dec 16 02:00: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 F2F38D8C; Sun, 16 Dec 2012 02:00:25 +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 44D1B8FC12; Sun, 16 Dec 2012 02:00:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id qBG20CqR026692; Sun, 16 Dec 2012 13:00:13 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 16 Dec 2012 13:00:12 +1100 (EST) From: Ian Smith To: Chris H Subject: Re: MAC cloning available like Linux has? In-Reply-To: <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> Message-ID: <20121216124603.H4345@sola.nimnet.asn.au> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Glen Barber , Adrian Chadd , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 02:00:26 -0000 On Sat, 15 Dec 2012 12:51:11 -0800, Chris H wrote: > in rc.conf, adding the following (order is important!), everything > works as expected/desired/anticipated; > > --- begin rc,conf -------------------------------------------------------------- > ifconfig_ue0="ether ##:##:##:##:##:##" > > ifconfig_ue0_alias0="DHCP" > > *** or *** > > ifconfig_ue0_alias0="inet ip4.add.ress.anticipated netmask kno.wn.net.mask" > > followed by > defaultrouter="kno.wn.gate.way" --applies for static only > --- end rc,conf -------------------------------------------------------------- Just one thing that's important to understand: order in rc.conf is only important in one regard, that the _last_ assignment for any particular variable is the only one that matters. rc.conf is just an sh script, included by '.', and any later assignments override any earlier ones. In particular, the order of assignments to any _different_ variables in rc.conf is completely irrelevant. Glad you got it sorted out otherwise. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Dec 16 02:13: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 83144121; Sun, 16 Dec 2012 02:13:38 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id 453278FC0A; Sun, 16 Dec 2012 02:13:37 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBG2DY4r026785; Sat, 15 Dec 2012 18:13:40 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBG2DTuR026779; Sat, 15 Dec 2012 18:13:29 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 18:13:29 -0800 (PST) Message-ID: <37dc5c2f61dfe897d9ea5195e8c93ead.authenticated@ultimatedns.net> In-Reply-To: References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> <476652410abd01eff09cf38132ebd0f6.authenticated@ultimatedns.net> Date: Sat, 15 Dec 2012 18:13:29 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Adrian Chadd" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Glen Barber , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 02:13:38 -0000 > Yes, please file a PR so that the documentation gets updated to reflect this. > > You can't be the only person who wishes to do this. > > As I said, I think it's worth extended rc.conf to have a specific > "ether" field for ifconfig, so any device-specific weird crap > (especially when creating cloned devices) can be done at the right > point before the interface is brought up. > > Thanks, > > > > Adrian Done! Sent it about 45 minutes ago. :) Thanks again, to all who took the time to help me through this. --Chris > > > On 15 December 2012 14:11, Chris H wrote: >>>> Hi, >>>> >>>> Please file a PR for this. I think this (and mac address >>> Greetings Adrian, and thank you for your reply. >>> >>>> setup/changing on net80211, similar issues) needs both some better >>>> documentation/FAQ entries and updates to the rc scripts. >>>> >>>> I think we may want to add an ifconfig_X_ether="" to set the L2 >>>> address appropriately for an interface. >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Adrian >>> >>> Well, on a hunch regarding RC(8), I blew 9.0 off the drive, and >>> experimented with installing 8.2. But I think I stumbled onto >>> something. I don't know (yet) if this will carry over to 9.x yet. >>> But here's what I discovered: >>> >>> in rc.conf, adding the following (order is important!), everything >>> works as expected/desired/anticipated; >>> >>> --- begin rc,conf -------------------------------------------------------------- >>> ifconfig_ue0="ether ##:##:##:##:##:##" >>> >>> ifconfig_ue0_alias0="DHCP" >>> >>> *** or *** >>> >>> ifconfig_ue0_alias0="inet ip4.add.ress.anticipated netmask kno.wn.net.mask" >>> >>> followed by >>> defaultrouter="kno.wn.gate.way" --applies for static only >>> --- end rc,conf -------------------------------------------------------------- >>> >>> So. It appears this will be the answer. _However_ I can't swear to it >>> until I spin up && install a (fresh) copy of RELENG_9. >>> I'll do so, and report back. >>> >>> Thanks again, for your reply. >>> >>> --Chris >> >> OK. The results are in -- >> Using the RC(8) declarations I listed above work not only in RELENG_8, >> but also in RELENG_9. I just performed an install from the 9.0 CD I >> downloaded from freebsd.org on 12-12-14. Everything (both as STATIC, >> and as DHCP) worked as expected/anticipated. >> >> Is this still worth a PR(1)? >> >> Best wishes, and thanks again, to everyone that took the time to help! >> >> --Chris >> >>> >>> >>> >>>> >>>> On 15 December 2012 10:36, Chris H wrote: >>>>>> On Sat, Dec 15, 2012 at 10:11:41AM -0800, Chris H wrote: >>>>>>> Hello Glen, and thank you for your reply. >>>>>>> > On Fri, Dec 14, 2012 at 11:26:06PM -0800, Chris H wrote: >>>>>>> >> ifconfig_ue0="DHCP" >>>>>>> >> create_args_ue0="ether ##:##:##:##:##:##" >>>>>>> >> create_args is simply ignored. >>>>>>> >> >>>>>>> > >>>>>>> > Ignored how? What commands are you running to verify it works? >>>>>>> > For me, create_args_IFNAME works fine on my firewall. >>>>>>> >>>>>>> Unfortunately, it had no affect for me. >>>>>>> The ue0 maintained the same MAC it started with. >>>>>>> Out of desperation, I even tried it in /boot/loader.conf. >>>>>> >>>>>> It is not a loader(8) tunable, it is part of the rc(8) system. >>>>>> >>>>>> You did not answer the important part of what I asked - how are you >>>>>> testing? Are you rebooting the machine? Are you using the netif rc >>>>>> script? >>>>> >>>>> Ahh. Sorry, my bad. Rebooting. >>>>> >>>>> I have no difficulty issuing: >>>>> ifconfig ue0 down >>>>> ifconfig ue0 ether ##:##:##:##:##:## >>>>> dhclient ue0 >>>>> >>>>> This method will always return the expected/desired results. >>>>> >>>>>> >>>>>> Glen >>>>>> >>>>>> >>>>> Thanks for the reply. >>>>> >>>>> --Chris >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> > From owner-freebsd-net@FreeBSD.ORG Sun Dec 16 02:17:48 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 8114420C; Sun, 16 Dec 2012 02:17:48 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-197-124.wavecable.com [24.113.197.124]) by mx1.freebsd.org (Postfix) with ESMTP id F2EF68FC0A; Sun, 16 Dec 2012 02:17:47 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id qBG2HhHB026893; Sat, 15 Dec 2012 18:17:49 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id qBG2Hc8L026887; Sat, 15 Dec 2012 18:17:38 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.197.124]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 15 Dec 2012 18:17:38 -0800 (PST) Message-ID: <9f0417b535c274cfc1ae143bacadcb09.authenticated@ultimatedns.net> In-Reply-To: <20121216124603.H4345@sola.nimnet.asn.au> References: <22dff5a60850319d50ce4f1a07309562.authenticated@ultimatedns.net> <20121214230414.GF1959@glenbarber.us> <27119a9d879fd4fb124b517b1589d578.authenticated@ultimatedns.net> <20121215115343.GC1342@glenbarber.us> <31ed4a74f0e5c8f3156d725d86590379.authenticated@ultimatedns.net> <20121215181928.GC1344@glenbarber.us> <4206626b0eb77c1955c546d5cf91b4cc.authenticated@ultimatedns.net> <09d1faaf95a2644e1819a042b65ca360.authenticated@ultimatedns.net> <20121216124603.H4345@sola.nimnet.asn.au> Date: Sat, 15 Dec 2012 18:17:38 -0800 (PST) Subject: Re: MAC cloning available like Linux has? From: "Chris H" To: "Ian Smith" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Glen Barber , Adrian Chadd , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 02:17:48 -0000 > On Sat, 15 Dec 2012 12:51:11 -0800, Chris H wrote: > > > in rc.conf, adding the following (order is important!), everything > > works as expected/desired/anticipated; > > > > --- begin rc,conf -------------------------------------------------------------- > > ifconfig_ue0="ether ##:##:##:##:##:##" > > > > ifconfig_ue0_alias0="DHCP" > > > > *** or *** > > > > ifconfig_ue0_alias0="inet ip4.add.ress.anticipated netmask kno.wn.net.mask" > > > > followed by > > defaultrouter="kno.wn.gate.way" --applies for static only > > --- end rc,conf -------------------------------------------------------------- > > Just one thing that's important to understand: order in rc.conf is only > important in one regard, that the _last_ assignment for any particular > variable is the only one that matters. rc.conf is just an sh script, > included by '.', and any later assignments override any earlier ones. > > In particular, the order of assignments to any _different_ variables in > rc.conf is completely irrelevant. Thanks for taking the time to point that out. Good to know. Will help me _not_ make unnecessary moves when trying to sort out a problem like this in the future. :) > > Glad you got it sorted out otherwise. Me too. :) --Chris > > cheers, Ian > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 17 11:06:47 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC2259D0 for ; Mon, 17 Dec 2012 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1E98FC1E for ; Mon, 17 Dec 2012 11:06:47 +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 qBHB6ljG023524 for ; Mon, 17 Dec 2012 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBHB6l4R023522 for freebsd-net@FreeBSD.org; Mon, 17 Dec 2012 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Dec 2012 11:06:47 GMT Message-Id: <201212171106.qBHB6l4R023522@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Dec 2012 11:06:47 -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/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171697 net [ip6] [ndp] panic when changing routes o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues 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/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 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/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/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 f 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/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 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/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 428 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Dec 18 16:17:48 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75B931E3; Tue, 18 Dec 2012 16:17:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 41E488FC15; Tue, 18 Dec 2012 16:17:48 +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 qBIGHmoO021849; Tue, 18 Dec 2012 16:17:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBIGHmWI021845; Tue, 18 Dec 2012 16:17:48 GMT (envelope-from linimon) Date: Tue, 18 Dec 2012 16:17:48 GMT Message-Id: <201212181617.qBIGHmWI021845@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174535: [tcp] TCP fast retransmit feature works strange X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Dec 2012 16:17:48 -0000 Old Synopsis: TCP fast retransmit feature works strange New Synopsis: [tcp] TCP fast retransmit feature works strange Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 18 16:17:28 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174535 From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 16:22:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2699A9A; Wed, 19 Dec 2012 16:22:33 +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 5CB788FC14; Wed, 19 Dec 2012 16:22:31 +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 qBJGQoRo065793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 17:26:50 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50D1E9C6.2030501@omnilan.de> Date: Wed, 19 Dec 2012 17:22:30 +0100 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: "Alexander V. Chernikov" Subject: Re: [patch] permit fib to be set on interface References: <4DC695FC.3080700@ipfw.ru> In-Reply-To: <4DC695FC.3080700@ipfw.ru> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE59BB3BDCF208BA0ACEC341" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 16:22:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE59BB3BDCF208BA0ACEC341 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Alexander V. Chernikov am 08.05.2011 15:09 (localtime): > At the moment the only possible way to set packet fib from userland is > ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows > with every fib. > Additionally, there is no way to set packet fib before netgraph > processing: L2 ipfw hook is called after ng_ether_input() > > Those reasons (not mentioning kern/134931) makes it hard to use multipl= e > routing tables. > > The following path: > * adds SIOCGIFIB/SIOCSIFIB ioctl(2) calls to get/set per-interface fib > * adds IFF_CUSTOMFIB interface flags > * adds ifi_fib field to if_data structure > * adds 'fib' keyword for ifconfig(8) > > Example: > 16:42 [0] zfscurr0# ifconfig vlan2 create inet 10.11.12.13/30 fib 15 > vlan 2 vlandev em0 > 16:42 [0] zfscurr0# ifconfig vlan2 > vlan2: flags=3D808843= > metric 0 mtu 1500 fib 15 > options=3D3 > ether 08:00:27:c5:29:d4 > inet 10.11.12.13 netmask 0xfffffffc broadcast 10.11.12.15 > inet6 fe80::a00:27ff:fec5:29d4%vlan2 prefixlen 64 scopeid 0x4 > nd6 options=3D21 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 2 parent interface: em0 > > > Interface fib is applied on inbound only (for forwarded packets fib > decision should be done on inbound, for locally-originated packets ther= e > is setfib(1)) Could you please help me understanding the design? If I have a multihomed machine, with fib0 defaultrouter via nic0 and fib1 defaultrouter via nic1, and nic1 has fib1 assigned. What should happen if I connect to any service, by default assigned to fib0, but passing nic1? The incoming packet will be tagged with "FIB1", right? But does that affect the answer-path of services not assigned to fib1? If not, why would I want incoming packates tagged? Thanks, -Harry --------------enigEE59BB3BDCF208BA0ACEC341 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) iEYEARECAAYFAlDR6cYACgkQLDqVQ9VXb8gKxgCgg9Tuxin5SIxXGvH+XezafTLM yZUAoIwVBzYFrBYZwfOv3agzzDNcvboL =kKRk -----END PGP SIGNATURE----- --------------enigEE59BB3BDCF208BA0ACEC341-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 19:31: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 1D160D91 for ; Wed, 19 Dec 2012 19:31:09 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id A00058FC19 for ; Wed, 19 Dec 2012 19:31:08 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id b47so1300940eek.3 for ; Wed, 19 Dec 2012 11:31:02 -0800 (PST) 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=ob/8k7y7hP5FYMvP6T8lGlt2LPE7WAU+XEePvv41PyY=; b=oqcgyHJFvGOPd64nGDfHAWbkir4YFjbP0B+0yBdIjZuoJgr5OHVWkGNdY/UJryXbWX OTmb8hOZZY0TmOMxNkGY5zIWbcRI63CzEXra2UJ1AKoIej0qm7sYGPJ5cDCvhc7XiSuB WpYZW7xEiW2mQW+FPC3d+6KNkQ9KjJCwxk+sg+UgbsA2iZqqDmdlE/ujQRTqZ/C0pAH3 0F8YUDpxVVgg+6aLomKtv2lMrVksH9CnDd4BOys8Yvmt4Jcj/K60sEAhp55gmbiQ/Hoi RV+nFwkCFbO18uhSiUl9g6lVIxq/uQvabh2liZuBElut9ItH777yP6icClTi2bSdDsXT 1u2g== MIME-Version: 1.0 Received: by 10.14.223.135 with SMTP id v7mr16466273eep.41.1355945462071; Wed, 19 Dec 2012 11:31:02 -0800 (PST) Received: by 10.223.101.77 with HTTP; Wed, 19 Dec 2012 11:31:01 -0800 (PST) Date: Wed, 19 Dec 2012 11:31:01 -0800 Message-ID: Subject: use of V_tcbinfo lock for TCP syncache From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 19:31:09 -0000 As it is today, a socket upcall on a listener socket is made with the V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn -> sowakeup]. I feel that the use of the V_tcbinfo is not consistent in the syncache code. In syncache_add(), we drop the lock before doing the lookup: INP_WUNLOCK(inp); INP_INFO_WUNLOCK(&V_tcbinfo); [..snip..] sc = syncache_lookup(inc, &sch); /* returns locked entry */ However, when going through syncache_expand() or syncache_chkrst() we keep the V_tcbinfo lock. Since the syncache has its own lock, do we need to hold the V_tcbinfo lock when calling syncache_socket()? If there are ideas, or patches, I can give them a try. -vijay From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 19:42: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 CCE024B7 for ; Wed, 19 Dec 2012 19:42:59 +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 967BB8FC0A for ; Wed, 19 Dec 2012 19:42:59 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so1433157pbc.13 for ; Wed, 19 Dec 2012 11:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ERXM3BhhsugJArqLwEi/7Cd2EhaphWTwvD8X/3qExPI=; b=vaK29a1PsH5AY7Cpw0omYIA62WN0KPnFOUTc1VXe6h24T3RMkDtxLKJKRTM4U2yQZq fxI//QuVJ4wyO/AmTnGMEe1g2NAQDPWLQbAoiW0UKluJ/fdlCtXDdKRBC9N4Tee4MpVe HdNETJ6JbSSA57Y+SInBUDZ5A7OGQQnIZCKzgWI7bVMKcL4koObvV0garHnELNR2Zzb3 nss46I4r2BU+n/CAh6OFizCqILUP0tmTYpLnZCrGIEMfgmHlBU2Wl2tZwBumLNGln8IU govyBCah13rK/3KhU0qn9/2UGClNQ7/AfTgwhHIwvB+4nytm35VTxbU+4s3Tueop71AS nN4A== X-Received: by 10.68.227.41 with SMTP id rx9mr21569835pbc.121.1355946173743; Wed, 19 Dec 2012 11:42:53 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id ip8sm3587089pbc.36.2012.12.19.11.42.51 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 11:42:52 -0800 (PST) Sender: Navdeep Parhar Message-ID: <50D218BA.7080301@FreeBSD.org> Date: Wed, 19 Dec 2012 11:42:50 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: use of V_tcbinfo lock for TCP syncache References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 19:42:59 -0000 On 12/19/12 11:31, Vijay Singh wrote: > As it is today, a socket upcall on a listener socket is made with the > V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn -> > sowakeup]. > > I feel that the use of the V_tcbinfo is not consistent in the syncache code. > > In syncache_add(), we drop the lock before doing the lookup: > > INP_WUNLOCK(inp); > INP_INFO_WUNLOCK(&V_tcbinfo); > [..snip..] > sc = syncache_lookup(inc, &sch); /* returns locked entry */ > > However, when going through syncache_expand() or syncache_chkrst() we > keep the V_tcbinfo lock. > > Since the syncache has its own lock, do we need to hold the V_tcbinfo > lock when calling syncache_socket()? Holding the pcbinfo lock prevents races between syncache_socket() and accept(). See rwatson's comment just above tcp_usr_accept. I noted this too (the comment above tod->tod_offload_socket() in tcp_syncache.c) back when I updated the TOE code in the kernel. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 19:50:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 677A2622 for ; Wed, 19 Dec 2012 19:50:34 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 235908FC12 for ; Wed, 19 Dec 2012 19:50:33 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 17so3404185iea.16 for ; Wed, 19 Dec 2012 11:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=t9yoInCx4wO/sSNMFei8Iy7IItxqbfV0PKupac2Wzho=; b=YVNYXySiCu2PlmxPKQ/xr99KikgNrBSLvEw+vFtkFgt4YdLtYuVJnR/YYR0PlzP3wG 92wOeveIU9pXw3DHfNjggu2r/Sx3kXilImlldZcuMf8YqSDqEhzebMCjYZwqqvNASnK4 5ouplCFNQOWYEAbsFjfrxXL8nkcZFYCy+wPbyJr1+ef/u9k7Am6NRgBcS+zF7RnjFfg5 a3MAtkgwlRzYGAY9nT8O5fGTzslKJ3//0puUshdNnuB0VMd0xbXduwO1P9MSx7PdsR3D 92uyAXehiQFMmC8Bi03+BiDA44JKNbyvIH5LgMPMxSYA8ygC9WSmITn7ZXz/CX4APaOQ e+Mw== X-Received: by 10.50.161.169 with SMTP id xt9mr8238046igb.62.1355946627134; Wed, 19 Dec 2012 11:50:27 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id yf6sm4950719igb.0.2012.12.19.11.50.25 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 11:50:25 -0800 (PST) Message-ID: <50D21A75.1020403@gmail.com> Date: Wed, 19 Dec 2012 14:50:13 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: use of V_tcbinfo lock for TCP syncache References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 19:50:34 -0000 On 19/12/2012 2:31 PM, Vijay Singh wrote: > As it is today, a socket upcall on a listener socket is made with the > V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn -> > sowakeup]. > > I feel that the use of the V_tcbinfo is not consistent in the syncache code. > > In syncache_add(), we drop the lock before doing the lookup: > > INP_WUNLOCK(inp); > INP_INFO_WUNLOCK(&V_tcbinfo); > [..snip..] > sc = syncache_lookup(inc, &sch); /* returns locked entry */ > > However, when going through syncache_expand() or syncache_chkrst() we > keep the V_tcbinfo lock. > > Since the syncache has its own lock, do we need to hold the V_tcbinfo > lock when calling syncache_socket()? > > Every time the list of TCP control blocks (tcbinfo) is manipulated, a write lock must be held to protect it. syncache_expand() is responsible for 'expanding' the listening socket into a full blown accepted socket, including creating its associated control block in the process. By the way I don't think V_tcbinfo lock is held for syncache_chkrst() or needed for that matter but I could be wrong since I'm looking at 7.x code. Karim. From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 20:05: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 84850B18 for ; Wed, 19 Dec 2012 20:05:09 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9028FC17 for ; Wed, 19 Dec 2012 20:05:09 +0000 (UTC) Received: by mail-da0-f52.google.com with SMTP id f10so1094236dak.11 for ; Wed, 19 Dec 2012 12:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pvWmdi9tJDIqlVBov5HP+TrxLkWRTwEP/HBeGkoQsrM=; b=SsxwX+TpHt0CQGPFca0FRwkaA6WFPsx9IHM6vXuaOEq5ZDM8H6DTmxLJs35oXQMIht +HKpyCvLYxh3h/Z0ShIaPKYo+u7p9e31rbtieXUOgVV7K1JYOfT5vZ2G5SpcYr5UH2Uh iTIDuBamY0sf2Pv2S1zI/UnhrYr5MZUkUqU9iUEzXqDEuqhBNNT2FHt0xGUD7Ges/HRi uDNHTX2CrtfRXklJeZpuFwObsEWGqAIzjLHLJZhkb5bSugoi4nB5MhifA+AjL6wkJKmD 5VaXnKtoFDpPu/JT9uwTUhNtI/smQGvznqfc48cBLWXN7cTAj5209enve1/I2fuR0AQ4 JoFw== X-Received: by 10.68.138.229 with SMTP id qt5mr21481626pbb.122.1355947070341; Wed, 19 Dec 2012 11:57:50 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id l5sm3937876paz.14.2012.12.19.11.57.48 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 11:57:49 -0800 (PST) Message-ID: <50D21C3B.8020803@gmail.com> Date: Wed, 19 Dec 2012 11:57:47 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: use of V_tcbinfo lock for TCP syncache References: <50D218BA.7080301@FreeBSD.org> In-Reply-To: <50D218BA.7080301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 20:05:09 -0000 On 12/19/12 11:42, Navdeep Parhar wrote: > On 12/19/12 11:31, Vijay Singh wrote: >> As it is today, a socket upcall on a listener socket is made with the >> V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn -> >> sowakeup]. >> >> I feel that the use of the V_tcbinfo is not consistent in the syncache code. >> >> In syncache_add(), we drop the lock before doing the lookup: >> >> INP_WUNLOCK(inp); >> INP_INFO_WUNLOCK(&V_tcbinfo); >> [..snip..] >> sc = syncache_lookup(inc, &sch); /* returns locked entry */ >> >> However, when going through syncache_expand() or syncache_chkrst() we >> keep the V_tcbinfo lock. >> >> Since the syncache has its own lock, do we need to hold the V_tcbinfo >> lock when calling syncache_socket()? > > Holding the pcbinfo lock prevents races between syncache_socket() and > accept(). See rwatson's comment just above tcp_usr_accept. I noted > this too (the comment above tod->tod_offload_socket() in tcp_syncache.c) > back when I updated the TOE code in the kernel. er, I think I told you why tcp_usr_accept holds the pcbinfo lock, which wasn't your original question... :-) From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 22:06:07 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 53E68660 for ; Wed, 19 Dec 2012 22:06:07 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id D61378FC14 for ; Wed, 19 Dec 2012 22:06:06 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id c41so1322248eek.15 for ; Wed, 19 Dec 2012 14:06:00 -0800 (PST) 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=5WrX1sWXEhiPUmbRw0Wr+D1vbT0bO0b6i0TKquFc4b4=; b=dmDpXiObPydRKF34Te+dUhDo/vlobTO9DAZa5UqD368uIp7vHh0WBPJ/cysP2MjCO3 68tDMlO4+X2NUlkfvKBXkKLymhm/zFxgb2sg8Mz+9KMDziaApmLS/1hbrS54zJTN26KF Bt4H/KY92xs9wKLO9ZG7wCisSrRNkQvZbZURlrPNyUkyEicrT2AhcVRK3VNcsCue4lan IeMvVmWxwZrZ/+dGZMDL3tRnW7WT8wCd7/ySfZXYJTNze2iJs9u8+2h0i9LRNj4Mr5z4 ErGOO3lTOWj0MCJ2w5Ete3RNxnzBElJHX1HxUosrigyFfBkp22SlR7huHX+CWipIzqEo xYjQ== MIME-Version: 1.0 Received: by 10.14.173.69 with SMTP id u45mr17117540eel.21.1355950896111; Wed, 19 Dec 2012 13:01:36 -0800 (PST) Received: by 10.223.101.77 with HTTP; Wed, 19 Dec 2012 13:01:35 -0800 (PST) In-Reply-To: <50D21C3B.8020803@gmail.com> References: <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> Date: Wed, 19 Dec 2012 13:01:35 -0800 Message-ID: Subject: Re: use of V_tcbinfo lock for TCP syncache From: Vijay Singh To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 22:06:07 -0000 >> Holding the pcbinfo lock prevents races between syncache_socket() and >> accept(). See rwatson's comment just above tcp_usr_accept. I noted >> this too (the comment above tod->tod_offload_socket() in tcp_syncache.c) >> back when I updated the TOE code in the kernel. > > er, I think I told you why tcp_usr_accept holds the pcbinfo lock, which > wasn't your original question... :-) But it helped. So I am thinking about trying a change where syncache_socket() would call soalloc() first, get a socket, setup the inp, and then do a (modified) sonewconn to place the socket in the listener's queue. Robert's comment indicated that this would be a better way to eliminate the race since we wouldn't need the pcblock when we make the sonewconn call. -vijay From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 23:02:31 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 A40473A4 for ; Wed, 19 Dec 2012 23:02:31 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4F98FC1B for ; Wed, 19 Dec 2012 23:02:31 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id c14so3791681ieb.0 for ; Wed, 19 Dec 2012 15:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ii3oapiDCDDApTf3f3HlkBkMDcn4HKY/a6iHWI0XFjQ=; b=WlzrXLuR3Q6hPbqk+ICZegS+VVbrINms6HpfjTt8ZW1+S8UMUQRHW36wO+yTHaNrVO V+fVXbnEYvo+VqM5nd3cnzOprL4FwwkUkR7pFlJeWCsHEyy55D3afFl5gJ/G1SttsUh2 IbHqqn5k1towik9vdguPUlGL75GaADbaPQlLYnWiEKHLebn7ZFWaCZlMj5Y8XgvFfspX 03Kzc256vVIXbrycrdjow3FwxLrsJVLSvK8XvgdCVsjUXFazAXXj8qnDMdXa9CYsAyi9 u2EF9hMnlqPvodePLaby3mWHRa5JDeuqWWKHUw75zc0jHC7KKyiaK50U0eVr++1uRMRf 1llw== X-Received: by 10.50.40.225 with SMTP id a1mr8916137igl.7.1355958144767; Wed, 19 Dec 2012 15:02:24 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id gs6sm5349075igc.11.2012.12.19.15.02.22 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 15:02:23 -0800 (PST) Message-ID: <50D24774.80800@gmail.com> Date: Wed, 19 Dec 2012 18:02:12 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: use of V_tcbinfo lock for TCP syncache References: <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 23:02:31 -0000 On 19/12/2012 4:01 PM, Vijay Singh wrote: >>> Holding the pcbinfo lock prevents races between syncache_socket() and >>> accept(). See rwatson's comment just above tcp_usr_accept. I noted >>> this too (the comment above tod->tod_offload_socket() in tcp_syncache.c) >>> back when I updated the TOE code in the kernel. >> er, I think I told you why tcp_usr_accept holds the pcbinfo lock, which >> wasn't your original question... :-) > But it helped. > > So I am thinking about trying a change where syncache_socket() would > call soalloc() first, get a socket, setup the inp, and then do a > (modified) sonewconn to place the socket in the listener's queue. > Robert's comment indicated that this would be a better way to > eliminate the race since we wouldn't need the pcblock when we make the > sonewconn call. > > Sure but syncache_expand() is entered with the tcbinfo already write locked which also protects the unlocking of the listening connection and the locking of the newly created socket. Around this part: /* * Socket is created in state SYN_RECEIVED. * Unlock the listen socket, lock the newly * created socket and update the tp variable. */ INP_WUNLOCK(inp); /* listen socket */ inp = sotoinpcb(so); INP_WLOCK(inp); /* new connection */ tp = intotcpcb(inp); Without the tcbinfo lock the new socket could be closed (getting a reset) which would put it in INP_TIMEWAIT or INP_DROPPED _after_ the check is made in tcp_usr_accept since there is a period of time where tcbinfo is not locked and the new socket inp is not locked either. I could be wrong but it seems that without the tcbinfo lock a lot could happen between the unlocking of the listen socket and the locking of the new one. Karim. From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 23:40: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 70D1A5BB for ; Wed, 19 Dec 2012 23:40:46 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by mx1.freebsd.org (Postfix) with ESMTP id ED6088FC12 for ; Wed, 19 Dec 2012 23:40:45 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d49so1355017eek.18 for ; Wed, 19 Dec 2012 15:40:39 -0800 (PST) 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=cdxT3Uv36Ca4ItHcuCmTNKwLKxq/hcKIBlLsfijXGI4=; b=xnMVlnnlxr7kQuJwZCzvrA5vtJu1FYbn+7qQYzYmG1wa4D9nwEH8gfIGvgA84cPUbQ UL9MOsCibVDAmtXTq0wiSrteMhn5nqAqZ1SLjV9sMYjgby8E1HsrPCsu7+aPtMmM8a81 yt4sLirlWyScIgJGjdyGAsy2fTEvwiaer3ak1hYTXOpUUa1DItRkJLcr0kalQmq/nem4 ol9PG5wYDmDN4QqRFfZzR3JCMfJYgnGG8Wfuvh7A6ef6J63gPYukGl3bDaBLzU0D5iKp fZ5hNamQ4SPmpqL733wsPjcm3rjalKuvWTqijK2cADLnCnqtFilKs9G8lck/0RnrzLqJ SFeA== MIME-Version: 1.0 Received: by 10.14.1.195 with SMTP id 43mr18099531eed.31.1355960439432; Wed, 19 Dec 2012 15:40:39 -0800 (PST) Received: by 10.223.101.77 with HTTP; Wed, 19 Dec 2012 15:40:39 -0800 (PST) In-Reply-To: <50D24774.80800@gmail.com> References: <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> <50D24774.80800@gmail.com> Date: Wed, 19 Dec 2012 15:40:39 -0800 Message-ID: Subject: Re: use of V_tcbinfo lock for TCP syncache From: Vijay Singh To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Dec 2012 23:40:46 -0000 > Sure but syncache_expand() is entered with the tcbinfo already write locked > which also protects the unlocking of the listening connection and the > locking of the newly created socket. Around this part: > > /* > * Socket is created in state SYN_RECEIVED. > * Unlock the listen socket, lock the newly > * created socket and update the tp variable. > */ > INP_WUNLOCK(inp); /* listen socket */ > inp = sotoinpcb(so); > INP_WLOCK(inp); /* new connection */ > tp = intotcpcb(inp); > > Without the tcbinfo lock the new socket could be closed (getting a reset) > which would put it in INP_TIMEWAIT or INP_DROPPED _after_ the check is made > in tcp_usr_accept since there is a period of time where tcbinfo is not > locked and the new socket inp is not locked either. > > I could be wrong but it seems that without the tcbinfo lock a lot could > happen between the unlocking of the listen socket and the locking of the new Hopefully Robert will chime in. I am sorry that I was not clear. In my experiment, syncache_expand() is still entered with the V_tcbinfo lock held. In my (limited) view, sonewconn() is overleaded. It [1] allocates a new socket [2] initializes it using the listener socket [3] invokes the pru_attach routine, where the inp is allocated [4] it inserts the socket in the listeners queue [5] it, optionally, notifies the listener of the new connection When sonewconn returns, we do a bunch of things, [6] such as call in_pcbconnect() and set state in tp etc. What I am experimenting with is to separate out [4] & [5] from the list above, and move those to AFTER we do the inp processing in [6]. At that point I do not think that the pcbinfo lock should be required to be held. -vijay From owner-freebsd-net@FreeBSD.ORG Thu Dec 20 11:57:33 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 6AE56E01; Thu, 20 Dec 2012 11:57:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id BE6608FC0A; Thu, 20 Dec 2012 11:57:32 +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 qBKBvSmj033006; Thu, 20 Dec 2012 18:57:28 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <50D2FD23.90505@grosbein.net> Date: Thu, 20 Dec 2012 18:57:23 +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: "net@freebsd.org" Subject: libradius dead_time option Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Sergey Matveychuk X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Dec 2012 11:57:33 -0000 Hi! Recently libradius(3) got long-awaited 'dead_time' option that allows to skip 'dead' radius servers for 'dead_time' timeout while dealing with multiple servers. I'd like to ask for small improvement of the code. Presently it will fail without a try if all servers marked 'dead'. Instead, in that case it shoud ignore 'dead' state of servers and make at try as if all of them were marked 'alive'. That would greatly increase recovery time after great network disasters. Also, I'd like to be able to see notification of such disasters in system logs (as an option). Something like this (compile-tested only): --- radlib.c.orig 2012-12-20 18:13:25.000000000 +0700 +++ radlib.c 2012-12-20 18:54:43.000000000 +0700 @@ -55,6 +55,9 @@ #include #include #include +#ifdef LIBRADIUS_USE_SYSLOG +#include +#endif #include #include "radlib_private.h" @@ -686,9 +689,35 @@ if (h->servers[h->srv].num_tries >= h->servers[h->srv].max_tries) { /* Set next probe time for this server */ if (h->servers[h->srv].dead_time) { + int alldead = 1; + int i; +#ifdef LIBRADIUS_USE_SYSLOG + char host[13]; /* AF_INET in dot notation */ + syslog(LOG_INFO, + "RADIUS server %s:%u is not responding and is being marked dead.", + inet_ntop(AF_INET, &(h->servers[h->srv].addr.sin_addr), + host, sizeof(host)), + (int)ntohs(h->servers[h->srv].addr.sin_port)); +#endif h->servers[h->srv].is_dead = 1; h->servers[h->srv].next_probe = now + h->servers[h->srv].dead_time; + for (i = 0; i < h->num_servers; i++) { + if (!h->servers[i].is_dead) { + alldead = 0; + break; + } + } + if (alldead) { +#ifdef LIBRADIUS_USE_SYSLOG + syslog(LOG_NOTICE, "ALL RADIUS servers are dead."); +#endif + /* don't be idle */ + for (i = 0; i < h->num_servers; i++) { + h->servers[i].is_dead = 0; + h->servers[i].num_tries = 0; + } + } } do { h->srv++; @@ -698,6 +727,14 @@ break; if (h->servers[h->srv].dead_time && h->servers[h->srv].next_probe <= now) { +#ifdef LIBRADIUS_USE_SYSLOG + char host[13]; /* AF_INET in dot notation */ + syslog(LOG_INFO, + "RADIUS server %s:%u is being marked alive.", + inet_ntop(AF_INET, &(h->servers[h->srv].addr.sin_addr), + host, sizeof(host)), + (int)ntohs(h->servers[h->srv].addr.sin_port)); +#endif h->servers[h->srv].is_dead = 0; h->servers[h->srv].num_tries = 0; break; From owner-freebsd-net@FreeBSD.ORG Thu Dec 20 16:12: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 072F9195 for ; Thu, 20 Dec 2012 16:12:26 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id B39A48FC16 for ; Thu, 20 Dec 2012 16:12:25 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c13so4912619ieb.3 for ; Thu, 20 Dec 2012 08:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SyreUKPkOiCGcRIosJT02K8MWIufeiomlv6VDLLa5AE=; b=fa6h1OuMsCT71HLSr/+fU2wNkgb2+1vWUvl9+dA+30KjuhKuZoxcXOsszHHiM8c5Ei G7XkLQXIPf5ZaHrQc1pG9juDELzgFemt41B7dXhwlhSFoYxh82ErPr3NYg5PEyWpnIol oTJh/mFqbjOFDpG2ak80tygRbGgJsvd/W8yNgod3QXDBOz2y8P/rivlf/r8qpwBdv555 Gxci+RA9/YslTuYsQnc6ChfEZA/oxSaU3ksuJPb7vHmLovx2yJjWBaQXuXWIYm2eNBYq svPBYXsPf8B+Cdrked4GSjZ+PP4fieJ6sMx388A5oN9YZM336O48AOrDFZGXKwmXiDPO XZ4g== X-Received: by 10.50.53.175 with SMTP id c15mr6071001igp.106.1356019945145; Thu, 20 Dec 2012 08:12:25 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id l8sm7127517igo.13.2012.12.20.08.12.22 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 08:12:23 -0800 (PST) Message-ID: <50D338DB.5070907@gmail.com> Date: Thu, 20 Dec 2012 11:12:11 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: use of V_tcbinfo lock for TCP syncache References: <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> <50D24774.80800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Karim Fodil-Lemelin , freebsd-net@freebsd.org, Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Dec 2012 16:12:26 -0000 On 19/12/2012 6:40 PM, Vijay Singh wrote: >> Sure but syncache_expand() is entered with the tcbinfo already write locked >> which also protects the unlocking of the listening connection and the >> locking of the newly created socket. Around this part: >> >> /* >> * Socket is created in state SYN_RECEIVED. >> * Unlock the listen socket, lock the newly >> * created socket and update the tp variable. >> */ >> INP_WUNLOCK(inp); /* listen socket */ >> inp = sotoinpcb(so); >> INP_WLOCK(inp); /* new connection */ >> tp = intotcpcb(inp); >> >> Without the tcbinfo lock the new socket could be closed (getting a reset) >> which would put it in INP_TIMEWAIT or INP_DROPPED _after_ the check is made >> in tcp_usr_accept since there is a period of time where tcbinfo is not >> locked and the new socket inp is not locked either. >> >> I could be wrong but it seems that without the tcbinfo lock a lot could >> happen between the unlocking of the listen socket and the locking of the new > Hopefully Robert will chime in. > > I am sorry that I was not clear. In my experiment, syncache_expand() > is still entered with the V_tcbinfo lock held. > > In my (limited) view, sonewconn() is overleaded. It > > [1] allocates a new socket > [2] initializes it using the listener socket > [3] invokes the pru_attach routine, where the inp is allocated > [4] it inserts the socket in the listeners queue > [5] it, optionally, notifies the listener of the new connection > > When sonewconn returns, we do a bunch of things, [6] such as call > in_pcbconnect() and set state in tp etc. > > What I am experimenting with is to separate out [4] & [5] from the > list above, and move those to AFTER we do the inp processing in [6]. > At that point I do not think that the pcbinfo lock should be required > to be held. > > How do you plan to handle the fact that most of tcp_input() and tcp_do_segment() require at least a read lock held on the pcbinfo lock? Is your goal to reduce the amount of code that gets executed under the write lock protection of pcbinfo or completely get rid of the lock all together? Karim. From owner-freebsd-net@FreeBSD.ORG Thu Dec 20 18:06:08 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 E4C1843A for ; Thu, 20 Dec 2012 18:06:08 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3828FC0C for ; Thu, 20 Dec 2012 18:06:07 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id d13so1533142eaa.21 for ; Thu, 20 Dec 2012 10:06:07 -0800 (PST) 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=UwkYrxZBRpj4vYccpWXAGJ5lBDsmknB5ZWJakskfgiw=; b=d4550uN2j3jsZjCZ/Z4TnlG67lvMG6mg9owkBpc19iCScIXu7olOOVsHUU1kCV0Mki wi/VqPfq1rHvZVkrpgb/kGA8sf1w9dWMppOMNoOwrelXVNh8VE/Hy7N00NYUlNxhxz3C IurrcQcTgR3ODAjM56dqXZg15ozPLqaHQn7ZBZHy95VHotPhNT/OfIFpakPyQPndvs+f 7OhPMu++EngmlY/Qsq6pA1ciyjcz9UY4khy031XQA8U4udQExQYv/iVqmHqlsIwdpLeo r4JkegDvXqBYaeSfDMT6PnGTOVSERUxG9tzLhO/YayZH/Rf83ZHMEeCh6cOAo2lgV3Yg c0Rw== MIME-Version: 1.0 Received: by 10.14.216.70 with SMTP id f46mr25000238eep.12.1356026767289; Thu, 20 Dec 2012 10:06:07 -0800 (PST) Received: by 10.223.101.77 with HTTP; Thu, 20 Dec 2012 10:06:07 -0800 (PST) In-Reply-To: <50D338DB.5070907@gmail.com> References: <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> <50D24774.80800@gmail.com> <50D338DB.5070907@gmail.com> Date: Thu, 20 Dec 2012 10:06:07 -0800 Message-ID: Subject: Re: use of V_tcbinfo lock for TCP syncache From: Vijay Singh To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Dec 2012 18:06:09 -0000 > How do you plan to handle the fact that most of tcp_input() and > tcp_do_segment() require at least a read lock held on the pcbinfo lock? Yes, I realized that after some experiments yesterday. > Is your goal to reduce the amount of code that gets executed under the write > lock protection of pcbinfo or completely get rid of the lock all together? While these are good goals, mine is simply to avoid making the socket upcall with the pcbinfo lock held, due to peculiarities in my environment. From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 01:43:29 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 17A47C9A for ; Fri, 21 Dec 2012 01:43:29 +0000 (UTC) (envelope-from andre@mrx.com.br) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4F68FC0C for ; Fri, 21 Dec 2012 01:43:27 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id p9so4183808laa.18 for ; Thu, 20 Dec 2012 17:43:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=nHV7jsf8geMONa6goffbcjRN5aCCByd8Gg2uktgUzJA=; b=h9FfNfWaSzeZx86wBk9oS/+iEcLIMIA+5FOw3LL5SvoxCGPP9eQJfhwvqPVYuYfvYS B5pXI5r71Wqu0+XgzxUjhphfkM1zOGOXsOG3lpEhrJhj6Y4bXqK+Lxm+fk7fVmNabxHj bzphgIMcEPY+tYilR9O3Tj4JOc6/RCd0wv2GH56fOsDDc8P0bdGnhXxozPpoH3O+d9lx lywuQvd33SkBekYho2I1spu5nyW9lNAeXBr0/67002cwwtdfbwT9Wwfb1FeTUr9ae0JB ciAszHvZn2YBH09vc/Agyvtv+SPRu/7pV7Xi/MdQqf9guV9QIDn5lRURuMv+tLHkoQY2 tKDQ== Received: by 10.152.129.197 with SMTP id ny5mr10692808lab.43.1356054206728; Thu, 20 Dec 2012 17:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.24.195 with HTTP; Thu, 20 Dec 2012 17:43:05 -0800 (PST) From: =?ISO-8859-1?Q?Andr=E9_Gustavo_N=2E_Lopes?= Date: Thu, 20 Dec 2012 23:43:05 -0200 Message-ID: Subject: Panic using RADIX_MPATH and quagga To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQk45VZasXIEIPn1HQbpjQNOEN+X2eq2ChP0QtVrbxsY6oRz5i2h8gVC9Of3o8tkycrMLEPx Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 01:43:29 -0000 Hi all, I am facing some problems using RADIX_MPATH, and quagga. Doing some research I can see a some people had the same problem: like this: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026794.html unfortunatelly the patch is not available anymore. But this is not the worst part. The most curious thing is: I have 2 identical servers (DELL R410), with the same set of network interfaces (2x bce and 2x igb). I am using the same version of O.S (Freebsd 8.3-STABLE) on both of them and the kernel was built using the same config. The quagga (quagga-re) are exactly the same as well, and they are neighbors on my network by the way. Everything works great in one of them, but the kernel crashes in the other a couple minutes after get quagga running. The main difference between them is, the server who crashes, acts is a border router (EBGP, IBGP and OSPF), and the router working fine is a distribution router (OSPF only). I "GUESS" I would have the same crashes in the working router if I start an ibgp neighboring (and receive > 420K prefixes.) The crashes go away, when I remove RADIX_MPATH. Any thoughs are very welcome. From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 06:14:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70786155 for ; Fri, 21 Dec 2012 06:14:44 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe12.ukr.net (ffe12.ukr.net [195.214.192.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4C08FC0A for ; Fri, 21 Dec 2012 06:14:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=WWxekMGeFokhEv9Lrh8ZFWWbpnJDAPSSNya4+obi0Iw=; b=aBsQm4h1rlohFHbg5W4FJq9roNZ5V9lNQffDdjQSQdbCAS8EfJpe2vPMn77njlyPyN1v6ylPpEoxLFpggFYY08SkF96fmG3/NmE9dxXMEDluh4WuUnCVv4vQ2vucRZbwGGMi8k1VM/oj3ZTzKT8bSnc7VG7wy++eBAGGQ2vuR1Q=; Received: from mail by ffe12.ukr.net with local ID 1TlvsS-000DD3-12 ; Fri, 21 Dec 2012 08:14:36 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Re: Panic using RADIX_MPATH and quagga In-Reply-To: References: To: =?WINDOWS-1251?B?QW5kchogR3VzdGF2byBOLiBMb3Blcw==?= From: "wishmaster" X-Mailer: freemail.ukr.net 4.0 Message-Id: <47814.1356070476.6792568769913618432@ffe12.ukr.net> X-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Date: Fri, 21 Dec 2012 08:14:36 +0200 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 06:14:44 -0000 Hi, I had been using RADIX_MPATH as well until investigated that problem was in RADIX_MPATH. Also router had crashes after changing route weight (-weight key). The code is very unstable, therefore I had to switch to use FIBs. -- Cheers > Hi all, > > I am facing some problems using RADIX_MPATH, and quagga. Doing some > research I can see a some people had the same problem: > > like this: > http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026794.html > > unfortunatelly the patch is not available anymore. > > But this is not the worst part. The most curious thing is: > > I have 2 identical servers (DELL R410), with the same set of network > interfaces (2x bce and 2x igb). I am using the same version of O.S (Freebsd > 8.3-STABLE) on both of them and the kernel was built using the same config. > > The quagga (quagga-re) are exactly the same as well, and they are neighbors > on my network by the way. > > Everything works great in one of them, but the kernel crashes in the other > a couple minutes after get quagga running. > > The main difference between them is, the server who crashes, acts is a > border router (EBGP, IBGP and OSPF), and the router working fine is a > distribution router (OSPF only). > > I "GUESS" I would have the same crashes in the working router if I start an > ibgp neighboring (and receive > 420K prefixes.) > > The crashes go away, when I remove RADIX_MPATH. > > Any thoughs are very welcome. > _______________________________________________ > 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 Dec 21 09:37:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2910A19B for ; Fri, 21 Dec 2012 09:37:55 +0000 (UTC) (envelope-from andre@mrx.com.br) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by mx1.freebsd.org (Postfix) with ESMTP id B63998FC12 for ; Fri, 21 Dec 2012 09:37:53 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id m15so4694068lah.14 for ; Fri, 21 Dec 2012 01:37:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=tHa+ZnlsdT6APyXoA7hqgedmDC/DSj46lwe5HOHoyko=; b=TQL3QEgeh2Lj+ZEN/v4B4T9b4NxtKmirEKdIhKkfD3ihxZG3G3NOa8/vfy99/fg30S nCh+hFpPweTnBQnKeCAUzNW2kuRItxbuB0V/5T66BD6yDp2uxzLxcBJB/aE6243pag6K GkFkx/FkX4tBP4dFX/heirBjD0ZdaAWNKEuL5+qZRxzwNTwNjsxwTw4mPp/RRnH0kh7q 6N8G9wZ+wBfN3Hg1/dw6Sdvm3oviA957zcP3yqU17pRxK0TwWEryQIAe/0qBZUPG85uz Taij1fVMdfjahvBO/Q00P1A8m7pWeJDQ3abpsKYJykMVg9O/vM2vkMSvqJYzZxnQUYsh 2lUQ== Received: by 10.152.111.166 with SMTP id ij6mr11728284lab.47.1356082672123; Fri, 21 Dec 2012 01:37:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.24.195 with HTTP; Fri, 21 Dec 2012 01:37:31 -0800 (PST) In-Reply-To: <47814.1356070476.6792568769913618432@ffe12.ukr.net> References: <47814.1356070476.6792568769913618432@ffe12.ukr.net> From: =?ISO-8859-1?Q?Andr=E9_Gustavo_N=2E_Lopes?= Date: Fri, 21 Dec 2012 07:37:31 -0200 Message-ID: Subject: Re: Panic using RADIX_MPATH and quagga To: wishmaster X-Gm-Message-State: ALoCoQlcUo9LoAziBkI0FMUxK5I80kLqH29C3FZ3NkXz6QeEZSfhmptEifZXah4JRASiTdh/e2Zv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 09:37:55 -0000 I can confirm, the server that was "working fine" also crashes if I configure an ibgp session. It looks like some bgp operations are tricky to radix_mpath. I noticed some people saying ecmp is trivial and stable on OpenBSD, did someone test this? I really need this feature and the time is short. I'm considering migrate all routers to OpenBSD, Thanks in advance --=20 Andr=E9 Gustavo N. Lopes Cel: 55 (41) 8859-6616 A mensagem, incluindo seus anexos, pode conter informa=E7=F5es legais privilegiadas e/ou confidenciais, n=E3o podendo ser retransmitida, arquivad= a, divulgada ou copiada sem autoriza=E7=E3o expressa do remetente. Caso tenha recebido esta mensagem por engano, por favor, informe o remetente e em seguida apague-a do seu computador. On Fri, Dec 21, 2012 at 4:14 AM, wishmaster wrote: > > Hi, > I had been using RADIX_MPATH as well until investigated that problem was > in RADIX_MPATH. Also router had crashes after changing route weight > (-weight key). > The code is very unstable, therefore I had to switch to use FIBs. > > -- > Cheers > > > Hi all, > > > > I am facing some problems using RADIX_MPATH, and quagga. Doing some > > research I can see a some people had the same problem: > > > > like this: > > > http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026794.htm= l > > > > unfortunatelly the patch is not available anymore. > > > > But this is not the worst part. The most curious thing is: > > > > I have 2 identical servers (DELL R410), with the same set of network > > interfaces (2x bce and 2x igb). I am using the same version of O.S > (Freebsd > > 8.3-STABLE) on both of them and the kernel was built using the same > config. > > > > The quagga (quagga-re) are exactly the same as well, and they are > neighbors > > on my network by the way. > > > > Everything works great in one of them, but the kernel crashes in the > other > > a couple minutes after get quagga running. > > > > The main difference between them is, the server who crashes, acts is a > > border router (EBGP, IBGP and OSPF), and the router working fine is a > > distribution router (OSPF only). > > > > I "GUESS" I would have the same crashes in the working router if I star= t > an > > ibgp neighboring (and receive > 420K prefixes.) > > > > The crashes go away, when I remove RADIX_MPATH. > > > > Any thoughs are very welcome. > > _______________________________________________ > > 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 Dec 21 12:11:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17587EC4; Fri, 21 Dec 2012 12:11:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by mx1.freebsd.org (Postfix) with ESMTP id 783718FC12; Fri, 21 Dec 2012 12:11:49 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id x4so4403923obh.24 for ; Fri, 21 Dec 2012 04:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=jutCFm/CLZ6VK+QmE+wY4FuMHf7p6UV7FyP8uKLXfxA=; b=ccLRRdbNU8ypyX6n5ncivVN83nCVdXtQ9nS/ymig51ijVPZJacmLiIGe2uE++uPyXe WYySDBBi4GsD1Egmf/tN2dELlxFZ9CFZhuIvqCBpyDsp7SAEbyBw0S9Mtkbx8kI4PNq/ JwfMO5lDfCvaEFveAxsfOwPDVs2sAqVmKzxqZZraKY416Jx4+llGO25ke1UF5D9iUcnD ZnLGSXTABlkSHRaZoNKsnBKiJUm+w5Y5S3eA85q3x8YLyfsYVsLo4Xn7zUolwmpOGc0T l8AZ6tWc1dM6t2BabC3U7tVRobWcqAG2h0kw9UlHJrZ0YnjhIYyfP2n/ec3xLysu/puk HBig== MIME-Version: 1.0 Received: by 10.60.0.165 with SMTP id 5mr10985542oef.128.1356091908507; Fri, 21 Dec 2012 04:11:48 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 04:11:48 -0800 (PST) Date: Fri, 21 Dec 2012 04:11:48 -0800 Message-ID: Subject: Broken error handling with AF_* and socket(2) [was Re: svn commit: r243965 - in head/sys: kern sys] From: Garrett Cooper To: Kevin Lo Content-Type: multipart/mixed; boundary=e89a8ff2535c7d472104d15bc0b0 Cc: src-committers@freebsd.org, freebsd-net@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 12:11:50 -0000 --e89a8ff2535c7d472104d15bc0b0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 6, 2012 at 6:22 PM, Kevin Lo wrote: > Author: kevlo > Date: Fri Dec 7 02:22:48 2012 > New Revision: 243965 > URL: http://svnweb.freebsd.org/changeset/base/243965 > > Log: > - according to POSIX, make socket(2) return EAFNOSUPPORT rather than > EPROTONOSUPPORT if the address family is not supported. > - introduce pffinddomain() to find a domain by family and use it as > appropriate. > > Reviewed by: glebius This commit broke netgraph (and potentially more things). I fixed netgraph locally like so: $ git diff lib/libnetgraph/ diff --git a/lib/libnetgraph/sock.c b/lib/libnetgraph/sock.c index fca3900..5f9f563 100644 --- a/lib/libnetgraph/sock.c +++ b/lib/libnetgraph/sock.c @@ -71,10 +71,10 @@ NgMkSockNode(const char *name, int *csp, int *dsp) name = NULL; /* Create control socket; this also creates the netgraph node. - If we get an EPROTONOSUPPORT then the socket node type is + If we get an EAFNOSUPPORT then the socket node type is not loaded, so load it and try again. */ if ((cs = socket(AF_NETGRAPH, SOCK_DGRAM, NG_CONTROL)) < 0) { - if (errno == EPROTONOSUPPORT) { + if (errno == EAFNOSUPPORT) { if (kldload(NG_SOCKET_KLD) < 0) { errnosv = errno; if (_gNgDebugLevel >= 1) Reproing the issue was trivial using the ether.bridge example script setup with appropriate interfaces. I have the patch with the netgraph fix attached, along with other potential fixes that needs to be more properly tested. Thanks, -Garrett --e89a8ff2535c7d472104d15bc0b0 Content-Type: application/octet-stream; name="0001-Fix-socket-calls-on-error-post-r243965.patch" Content-Disposition: attachment; filename="0001-Fix-socket-calls-on-error-post-r243965.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_haza2zk10 RnJvbSBjYzZmNzRiMmIyMTlkMjgzZjM0NWViMzE5NjY5NDE0NWMzM2EzODVlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBHYXJyZXR0IENvb3BlciA8eWFuZWdvbWlAZ21haWwuY29tPgpE YXRlOiBGcmksIDIxIERlYyAyMDEyIDA0OjEwOjA3IC0wODAwClN1YmplY3Q6IFtQQVRDSF0gRml4 IHNvY2tldCBjYWxscyBvbiBlcnJvciBwb3N0LXIyNDM5NjUKClNpZ25lZC1vZmYtYnk6IEdhcnJl dHQgQ29vcGVyIDx5YW5lZ29taUBnbWFpbC5jb20+Ci0tLQogYmluL2RhdGUvbmV0ZGF0ZS5jICAg ICAgIHwgMiArLQogbGliL2xpYm5ldGdyYXBoL3NvY2suYyAgIHwgNCArKy0tCiBzYmluL2hhc3Rk L3BhcnNlLnkgICAgICAgfCAyICstCiBzYmluL2lmY29uZmlnL2FmX25kNi5jICAgfCAyICstCiBz YmluL2lmY29uZmlnL2lmY29uZmlnLmMgfCAyICstCiB1c3Iuc2Jpbi9tdGVzdC9tdGVzdC5jICAg fCA0ICsrLS0KIHVzci5zYmluL25mc2QvbmZzZC5jICAgICB8IDIgKy0KIDcgZmlsZXMgY2hhbmdl ZCwgOSBpbnNlcnRpb25zKCspLCA5IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2Jpbi9kYXRl L25ldGRhdGUuYyBiL2Jpbi9kYXRlL25ldGRhdGUuYwppbmRleCBiMDg1YmU0Li5lNTA2ZTZkIDEw MDY0NAotLS0gYS9iaW4vZGF0ZS9uZXRkYXRlLmMKKysrIGIvYmluL2RhdGUvbmV0ZGF0ZS5jCkBA IC04NSw3ICs4NSw3IEBAIG5ldHNldHRpbWUodGltZV90IHR2YWwpCiAJZGVzdC5zaW5fYWRkci5z X2FkZHIgPSBodG9ubCgodV9sb25nKUlOQUREUl9BTlkpOwogCXMgPSBzb2NrZXQoQUZfSU5FVCwg U09DS19ER1JBTSwgMCk7CiAJaWYgKHMgPCAwKSB7Ci0JCWlmIChlcnJubyAhPSBFUFJPVE9OT1NV UFBPUlQpCisJCWlmIChlcnJubyAhPSBFQUZOT1NVUFBPUlQpCiAJCQl3YXJuKCJ0aW1lZCIpOwog CQlyZXR1cm4gKHJldHZhbCA9IDIpOwogCX0KZGlmZiAtLWdpdCBhL2xpYi9saWJuZXRncmFwaC9z b2NrLmMgYi9saWIvbGlibmV0Z3JhcGgvc29jay5jCmluZGV4IGZjYTM5MDAuLjVmOWY1NjMgMTAw NjQ0Ci0tLSBhL2xpYi9saWJuZXRncmFwaC9zb2NrLmMKKysrIGIvbGliL2xpYm5ldGdyYXBoL3Nv Y2suYwpAQCAtNzEsMTAgKzcxLDEwIEBAIE5nTWtTb2NrTm9kZShjb25zdCBjaGFyICpuYW1lLCBp bnQgKmNzcCwgaW50ICpkc3ApCiAJCW5hbWUgPSBOVUxMOwogCiAJLyogQ3JlYXRlIGNvbnRyb2wg c29ja2V0OyB0aGlzIGFsc28gY3JlYXRlcyB0aGUgbmV0Z3JhcGggbm9kZS4KLQkgICBJZiB3ZSBn ZXQgYW4gRVBST1RPTk9TVVBQT1JUIHRoZW4gdGhlIHNvY2tldCBub2RlIHR5cGUgaXMKKwkgICBJ ZiB3ZSBnZXQgYW4gRUFGTk9TVVBQT1JUIHRoZW4gdGhlIHNvY2tldCBub2RlIHR5cGUgaXMKIAkg ICBub3QgbG9hZGVkLCBzbyBsb2FkIGl0IGFuZCB0cnkgYWdhaW4uICovCiAJaWYgKChjcyA9IHNv Y2tldChBRl9ORVRHUkFQSCwgU09DS19ER1JBTSwgTkdfQ09OVFJPTCkpIDwgMCkgewotCQlpZiAo ZXJybm8gPT0gRVBST1RPTk9TVVBQT1JUKSB7CisJCWlmIChlcnJubyA9PSBFQUZOT1NVUFBPUlQp IHsKIAkJCWlmIChrbGRsb2FkKE5HX1NPQ0tFVF9LTEQpIDwgMCkgewogCQkJCWVycm5vc3YgPSBl cnJubzsKIAkJCQlpZiAoX2dOZ0RlYnVnTGV2ZWwgPj0gMSkKZGlmZiAtLWdpdCBhL3NiaW4vaGFz dGQvcGFyc2UueSBiL3NiaW4vaGFzdGQvcGFyc2UueQppbmRleCBhMjBiNjFhLi4wNGVhN2FiIDEw MDY0NAotLS0gYS9zYmluL2hhc3RkL3BhcnNlLnkKKysrIGIvc2Jpbi9oYXN0ZC9wYXJzZS55CkBA IC03NjksNyArNzY5LDcgQEAgZmFtaWx5X3N1cHBvcnRlZChpbnQgZmFtaWx5KQogCWludCBzb2Nr OwogCiAJc29jayA9IHNvY2tldChmYW1pbHksIFNPQ0tfU1RSRUFNLCAwKTsKLQlpZiAoc29jayA9 PSAtMSAmJiBlcnJubyA9PSBFUFJPVE9OT1NVUFBPUlQpCisJaWYgKHNvY2sgPT0gLTEgJiYgZXJy bm8gPT0gRUFGTk9TVVBQT1JUKQogCQlyZXR1cm4gKGZhbHNlKTsKIAlpZiAoc29jayA+PSAwKQog CQkodm9pZCljbG9zZShzb2NrKTsKZGlmZiAtLWdpdCBhL3NiaW4vaWZjb25maWcvYWZfbmQ2LmMg Yi9zYmluL2lmY29uZmlnL2FmX25kNi5jCmluZGV4IDY1NGUyZDkuLjgwMDY1ZjYgMTAwNjQ0Ci0t LSBhL3NiaW4vaWZjb25maWcvYWZfbmQ2LmMKKysrIGIvc2Jpbi9pZmNvbmZpZy9hZl9uZDYuYwpA QCAtMTQ4LDcgKzE0OCw3IEBAIG5kNl9zdGF0dXMoaW50IHMpCiAJbWVtc2V0KCZuZCwgMCwgc2l6 ZW9mKG5kKSk7CiAJc3RybmNweShuZC5pZm5hbWUsIGlmci5pZnJfbmFtZSwgc2l6ZW9mKG5kLmlm bmFtZSkpOwogCWlmICgoczYgPSBzb2NrZXQoQUZfSU5FVDYsIFNPQ0tfREdSQU0sIDApKSA8IDAp IHsKLQkJaWYgKGVycm5vICE9IEVQUk9UT05PU1VQUE9SVCkKKwkJaWYgKGVycm5vICE9IEVBRk5P U1VQUE9SVCkKIAkJCXdhcm4oInNvY2tldChBRl9JTkVUNiwgU09DS19ER1JBTSkiKTsKIAkJcmV0 dXJuOwogCX0KZGlmZiAtLWdpdCBhL3NiaW4vaWZjb25maWcvaWZjb25maWcuYyBiL3NiaW4vaWZj b25maWcvaWZjb25maWcuYwppbmRleCA4NzBhY2RkLi45ODNlMjFmIDEwMDY0NAotLS0gYS9zYmlu L2lmY29uZmlnL2lmY29uZmlnLmMKKysrIGIvc2Jpbi9pZmNvbmZpZy9pZmNvbmZpZy5jCkBAIC01 MjAsNyArNTIwLDcgQEAgdG9wOgogCQlBRl9MT0NBTCA6IGFmcC0+YWZfYWY7CiAKIAlpZiAoKHMg PSBzb2NrZXQoaWZyLmlmcl9hZGRyLnNhX2ZhbWlseSwgU09DS19ER1JBTSwgMCkpIDwgMCAmJgot CSAgICAodWFmcCAhPSBOVUxMIHx8IGVycm5vICE9IEVQUk9UT05PU1VQUE9SVCB8fAorCSAgICAo dWFmcCAhPSBOVUxMIHx8IGVycm5vICE9IEVBRk5PU1VQUE9SVCB8fAogCSAgICAgKHMgPSBzb2Nr ZXQoQUZfTE9DQUwsIFNPQ0tfREdSQU0sIDApKSA8IDApKQogCQllcnIoMSwgInNvY2tldChmYW1p bHkgJXUsU09DS19ER1JBTSIsIGlmci5pZnJfYWRkci5zYV9mYW1pbHkpOwogCmRpZmYgLS1naXQg YS91c3Iuc2Jpbi9tdGVzdC9tdGVzdC5jIGIvdXNyLnNiaW4vbXRlc3QvbXRlc3QuYwppbmRleCA2 MGY3ZTA5Li5hMjhmYWI3IDEwMDY0NAotLS0gYS91c3Iuc2Jpbi9tdGVzdC9tdGVzdC5jCisrKyBi L3Vzci5zYmluL210ZXN0L210ZXN0LmMKQEAgLTIwNCwxMiArMjA0LDEyIEBAIG1haW4oaW50IGFy Z2MsIGNoYXIgKiphcmd2KQogCXM2ID0gLTE7CiAjaWZkZWYgSU5FVAogCXMgPSBzb2NrZXQoQUZf SU5FVCwgU09DS19ER1JBTSwgSVBQUk9UT19VRFApOwotCWlmIChzID09IC0xICYmIGVycm5vICE9 IEVQUk9UT05PU1VQUE9SVCkKKwlpZiAocyA9PSAtMSAmJiBlcnJubyAhPSBFQUZOT1NVUFBPUlQp CiAJCWVycigxLCAiY2FuJ3Qgb3BlbiBJUHY0IHNvY2tldCIpOwogI2VuZGlmCiAjaWZkZWYgSU5F VDYKIAlzNiA9IHNvY2tldChBRl9JTkVUNiwgU09DS19ER1JBTSwgSVBQUk9UT19VRFApOwotCWlm IChzNiA9PSAtMSAmJiBlcnJubyAhPSBFUFJPVE9OT1NVUFBPUlQpCisJaWYgKHM2ID09IC0xICYm IGVycm5vICE9IEVBRk5PU1VQUE9SVCkKIAkJZXJyKDEsICJjYW4ndCBvcGVuIElQdjYgc29ja2V0 Iik7CiAjZW5kaWYKIAlpZiAocyA9PSAtMSAmJiBzNiA9PSAtMSkKZGlmZiAtLWdpdCBhL3Vzci5z YmluL25mc2QvbmZzZC5jIGIvdXNyLnNiaW4vbmZzZC9uZnNkLmMKaW5kZXggNmEyZjc4NS4uMmZl ZjdmNSAxMDA2NDQKLS0tIGEvdXNyLnNiaW4vbmZzZC9uZnNkLmMKKysrIGIvdXNyLnNiaW4vbmZz ZC9uZnNkLmMKQEAgLTI2NCw3ICsyNjQsNyBAQCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikK IAlpcDZmbGFnID0gMTsKIAlzID0gc29ja2V0KEFGX0lORVQ2LCBTT0NLX0RHUkFNLCBJUFBST1RP X1VEUCk7CiAJaWYgKHMgPT0gLTEpIHsKLQkJaWYgKGVycm5vICE9IEVQUk9UT05PU1VQUE9SVCkK KwkJaWYgKGVycm5vICE9IEVBRk5PU1VQUE9SVCkKIAkJCWVycigxLCAic29ja2V0Iik7CiAJCWlw NmZsYWcgPSAwOwogCX0gZWxzZSBpZiAoZ2V0bmV0Y29uZmlnZW50KCJ1ZHA2IikgPT0gTlVMTCB8 fAotLSAKMS44LjAKCg== --e89a8ff2535c7d472104d15bc0b0-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 12:13:58 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 7F83616C for ; Fri, 21 Dec 2012 12:13:58 +0000 (UTC) (envelope-from telemat@extrim.it) Received: from fatboy.mirasystem.net (unknown [IPv6:2a02:17d0:af:ff01:1:2::]) by mx1.freebsd.org (Postfix) with ESMTP id E8D218FC12 for ; Fri, 21 Dec 2012 12:13:57 +0000 (UTC) Received: from tsar.itmh.local (unknown [172.16.64.37]) by fatboy.mirasystem.net (Postfix) with ESMTP id E2423126B76B for ; Fri, 21 Dec 2012 18:13:54 +0600 (YEKT) Message-ID: <50D45282.5080708@extrim.it> Date: Fri, 21 Dec 2012 18:13:54 +0600 From: Tsaregorodtsev Denis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: 'no buffer space available' after switch goes down on freeBSD 7.3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 12:13:58 -0000 Hello, I maintenance ISP's DNS server which works under FreeBSD 7.3 and BIND 9.9.1-P4. The network adapter is Intel(R) PRO/1000 Network Connection, driver - em. The server is connected to a Cisco 6500 switch. Sometimes the switch goes down (for maintenance) and is unavailable for 10 minutes. After the switch goes up the server is still unavailable through IP. When I open an IPMI console on the server and enter the ping command, I receive "no buffer space available" error message. And the network doesn't work until the server reboot. I tried to google this and found that the problem can be solved by increasing nmbclusters parameter. But I want to understand why this problem appears when the switch is rebooting . May be you can suggest something? Best regards, Tsaregorodtsev Denis From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 08:27: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 80DF9425 for ; Fri, 21 Dec 2012 08:27:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by mx1.freebsd.org (Postfix) with ESMTP id 427788FC0A for ; Fri, 21 Dec 2012 08:27:46 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id eh20so4196506obb.23 for ; Fri, 21 Dec 2012 00:27:45 -0800 (PST) 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=HhrbpsIsAS+K5SDTWCIHGhpx4sudcoFThaTNAG7gHrY=; b=x1s9QtTMObCWIcPK+59EMtNx8+FX8fkgKhfQxO2h/KecMh2mNBH/r/Qx02NV8THLdj 9F98Id1hzzHop8f6SPOzAIKRT9AH0SER9oo4ChK8AOR/PIkcvFS12J9NFWRQp0XxaCBl Q0CNuzqBIo4qLo2lR9NPvif4KoynEEK2PqAiscZcMuH+2Om4Gc/W6mkXLc1rgLkqS+ui 2FGpUYxSqCarStfKSR32HagP1dYAISbJF4Ks7ldf9KinQPGfXIdWhGsn7uIeB7MCpu+w bkI8YJyHoChLDayAX6Pnv46k2GAhNg3UgK/U6232b/c5mSrfXPHCEioH6YzxTEYdPR5i lqkQ== MIME-Version: 1.0 Received: by 10.182.114.71 with SMTP id je7mr10492879obb.20.1356078465544; Fri, 21 Dec 2012 00:27:45 -0800 (PST) Received: by 10.76.86.233 with HTTP; Fri, 21 Dec 2012 00:27:45 -0800 (PST) Date: Fri, 21 Dec 2012 03:27:45 -0500 Message-ID: Subject: BSD netmap side by side with Linux pfring/dna From: grarpamp To: ntop-misc@listgateway.unipi.it Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 21 Dec 2012 12:17:59 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 08:27:46 -0000 I notice a lot of users seemingly depending on Linux and some pfring/dna for some things. There is similar work in the field ongoing in FreeBSD which may be equally useful to consider. http://info.iet.unipi.it/~luigi/netmap/ From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 12:37:29 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 E0572777; Fri, 21 Dec 2012 12:37:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF998FC12; Fri, 21 Dec 2012 12:37:28 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n16so4553780oag.37 for ; Fri, 21 Dec 2012 04:37:22 -0800 (PST) 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=sdqCRhAxEylcDHRuphrrew3ErGWTr0a/H9pMqaPCwAc=; b=FM/tLioAejYY6N1Jt/ly8YsSfL+peIrHeU7aSeF1GwuBjjZk1UgFKEm1UejOztQRE+ n2Xr78HMm2balCZNIKLHaoOx2BMT8xHk5Xkj5dTyyIyiaX4II4AiW0JryyvHaHmkE0qT n7Ddqv6nZbpmiwxuTvnBci4fY+YCA/Z5z40DjBY39QWosIyWFuLa4F5a4f3lokvNDamQ 9QXeT4BUsRR1VhdqYlh3CWArtai8lh54WdwocRRGrAfDAE1gmdmqm/8x4lQhwXKKs8+M Q++7BCrjAiQ6tQPTV7uwbinvRzoSS6vthnwKYkIjbgIr/66UWy1sbhueuIDzB1JGFR+c 9VjQ== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr10871591obc.83.1356093442291; Fri, 21 Dec 2012 04:37:22 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 04:37:22 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 04:37:22 -0800 Message-ID: Subject: Re: Broken error handling with AF_* and socket(2) [was Re: svn commit: r243965 - in head/sys: kern sys] From: Garrett Cooper To: Kevin Lo Content-Type: text/plain; charset=ISO-8859-1 Cc: src-committers@freebsd.org, freebsd-net@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 12:37:29 -0000 (Don't know why I hit reply instead of reply-all, but oh well... I had one more reply anyhow) On Fri, Dec 21, 2012 at 4:28 AM, Garrett Cooper wrote: > On Fri, Dec 21, 2012 at 4:11 AM, Garrett Cooper wrote: >> On Thu, Dec 6, 2012 at 6:22 PM, Kevin Lo wrote: >>> Author: kevlo >>> Date: Fri Dec 7 02:22:48 2012 >>> New Revision: 243965 >>> URL: http://svnweb.freebsd.org/changeset/base/243965 >>> >>> Log: >>> - according to POSIX, make socket(2) return EAFNOSUPPORT rather than >>> EPROTONOSUPPORT if the address family is not supported. >>> - introduce pffinddomain() to find a domain by family and use it as >>> appropriate. >>> >>> Reviewed by: glebius >> >> This commit broke netgraph (and potentially more things). I fixed >> netgraph locally like so: >> >> $ git diff lib/libnetgraph/ >> diff --git a/lib/libnetgraph/sock.c b/lib/libnetgraph/sock.c >> index fca3900..5f9f563 100644 >> --- a/lib/libnetgraph/sock.c >> +++ b/lib/libnetgraph/sock.c >> @@ -71,10 +71,10 @@ NgMkSockNode(const char *name, int *csp, int *dsp) >> name = NULL; >> >> /* Create control socket; this also creates the netgraph node. >> - If we get an EPROTONOSUPPORT then the socket node type is >> + If we get an EAFNOSUPPORT then the socket node type is >> not loaded, so load it and try again. */ >> if ((cs = socket(AF_NETGRAPH, SOCK_DGRAM, NG_CONTROL)) < 0) { >> - if (errno == EPROTONOSUPPORT) { >> + if (errno == EAFNOSUPPORT) { >> if (kldload(NG_SOCKET_KLD) < 0) { >> errnosv = errno; >> if (_gNgDebugLevel >= 1) >> >> Reproing the issue was trivial using the ether.bridge example >> script setup with appropriate interfaces. >> I have the patch with the netgraph fix attached, along with other >> potential fixes that needs to be more properly tested. > > usr.sbin/mountd/mountd.c > usr.sbin/rpcbind/rpcbind.c > usr.sbin/ypserv/yp_main.c > > might be broken as well because they're calling __rpc_nconf2fd, > which just wraps socket(2) underneath it all. > At this point it might be wise to consider doing something about > the ABI because the contract has been grossly changed enough that > things that tried to make sense of sockets with EPROTONOSUPPORT are > going to have issues now on FreeBSD [potentially] in either positive > or negative cases. My fix wasn't necessarily the right answer for netgraph, et al. It was just what I needed in order to get it to function with the new socket(2) API. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 14:47:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DAA8E5 for ; Fri, 21 Dec 2012 14:47:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by mx1.freebsd.org (Postfix) with ESMTP id 2672C8FC14 for ; Fri, 21 Dec 2012 14:47:02 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id r5so2127306wey.21 for ; Fri, 21 Dec 2012 06:47:01 -0800 (PST) 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=S6Y6l+tpFLHAJRuAX55E5gKk317EnzIfi/hkdVnpp8c=; b=JnN88oAy574eNQkwA3KLghzWj135KkpQAvu8WlfxAv4uHG/Kb8K8Kb2KEcqyzWOASX BOPh/tx7ccMoLpejGzgRJBnwTKEBY3fi0Uni3bSyOw8BMMCWSI46XBPDkgSIoDe3HLfV VYKYdYpWa5u5ZD0d2J/sG08x7RlWYjLhphJzSlFGRjI9lRfzjD8fW/cy8eu8y+63kvTR JUXgrNiFUTBLLGiNZsRdtE2utmQ1ChreE76lReqy5QIl3P9PyeBK5bvpmnQvu2dxd6YF IkIoQSV6nmShmkQLzD6o1ba6Rl4SRDOFTIeRFpYKrRnBQcaZYH4nDQ1XFT3bEMKF+wdI E7AA== MIME-Version: 1.0 Received: by 10.180.72.146 with SMTP id d18mr15940506wiv.33.1356101221912; Fri, 21 Dec 2012 06:47:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 21 Dec 2012 06:47:01 -0800 (PST) In-Reply-To: <50D45282.5080708@extrim.it> References: <50D45282.5080708@extrim.it> Date: Fri, 21 Dec 2012 06:47:01 -0800 X-Google-Sender-Auth: zxQJc2Lgt3-AyLt6CLtb1VlCsS0 Message-ID: Subject: Re: 'no buffer space available' after switch goes down on freeBSD 7.3 From: Adrian Chadd To: Tsaregorodtsev Denis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 14:47:03 -0000 On 21 December 2012 04:13, Tsaregorodtsev Denis wrote: > Hello, > > I maintenance ISP's DNS server which works under FreeBSD 7.3 and BIND > 9.9.1-P4. The network adapter is Intel(R) PRO/1000 Network Connection, > driver - em. The server is connected to a Cisco 6500 switch. Sometimes the > switch goes down (for maintenance) and is unavailable for 10 minutes. After > the switch goes up the server is still unavailable through IP. When I open > an IPMI console on the server and enter the ping command, I receive "no > buffer space available" error message. And the network doesn't work until > the server reboot. > I tried to google this and found that the problem can be solved by > increasing nmbclusters parameter. But I want to understand why this problem > appears when the switch is rebooting . May be you can suggest something? > > Best regards, Tsaregorodtsev Denis Hi, It's quite likely because the mbufs have been allocated and sitting on some queue somewhere, but they're stuck and unable to transmit. Just try 'ifconfig em0 down; ifconfig em0 up' and see if that unwedges things? Adrian From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 14:52:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B438326 for ; Fri, 21 Dec 2012 14:52:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id CE2228FC13 for ; Fri, 21 Dec 2012 14:52:32 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so2084561wge.34 for ; Fri, 21 Dec 2012 06:52:26 -0800 (PST) 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=82QgTKpfw2xoseFRGCHnRDkiXH3C17RueXHhtU8UaaI=; b=jZQT8VSQCcvXv7RG59dHF/UW5zWaLFgeoA+UiH0pn7fuPp6+mMNGZlI4PhbVHa4w0e fYYndppvVRTwR1f3Iz0Ecfj7wPNBFvePMWH+Xgf8QGQjcJpL8QUtWpjl6TFt7WK8h45r A8/o/lvNowxxbh/OQzzpEFwsiCYZzVr8F04oG2AK7LXRi8ddyCgYl8CuNQCZezFh2dIw P4UXZtG8TUGvZgTTNze80LFj+fQxy7MTNXR4qckymwpDsN8oIejk4buaNj9NlBdDdeu0 1rgJUPtG2ZX+W/U+l6F4dxauyCOLK/VF9BxatVM121oKvN+lQvs0uTAKfHE6jcaCY0Pi 0Mpw== MIME-Version: 1.0 Received: by 10.194.83.36 with SMTP id n4mr23990962wjy.59.1356101164329; Fri, 21 Dec 2012 06:46:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 21 Dec 2012 06:46:04 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 06:46:04 -0800 X-Google-Sender-Auth: aQki_h5uJMiM8T2H6QsKKH0kABg Message-ID: Subject: Re: Panic using RADIX_MPATH and quagga From: Adrian Chadd To: =?ISO-8859-1?Q?Andr=E9_Gustavo_N=2E_Lopes?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 14:52:34 -0000 Hi, Can you provide further information on the nature of your specific crashes? A kernel backtrace and kernel panic message would be helpful. Have you tried FreeBSD-9? Adrian On 20 December 2012 17:43, Andr=E9 Gustavo N. Lopes wrot= e: > Hi all, > > I am facing some problems using RADIX_MPATH, and quagga. Doing some > research I can see a some people had the same problem: > > like this: > http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026794.htm= l > > unfortunatelly the patch is not available anymore. > > But this is not the worst part. The most curious thing is: > > I have 2 identical servers (DELL R410), with the same set of network > interfaces (2x bce and 2x igb). I am using the same version of O.S (Freeb= sd > 8.3-STABLE) on both of them and the kernel was built using the same confi= g. > > The quagga (quagga-re) are exactly the same as well, and they are neighbo= rs > on my network by the way. > > Everything works great in one of them, but the kernel crashes in the othe= r > a couple minutes after get quagga running. > > The main difference between them is, the server who crashes, acts is a > border router (EBGP, IBGP and OSPF), and the router working fine is a > distribution router (OSPF only). > > I "GUESS" I would have the same crashes in the working router if I start = an > ibgp neighboring (and receive > 420K prefixes.) > > The crashes go away, when I remove RADIX_MPATH. > > Any thoughs are very welcome. > _______________________________________________ > 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 Dec 21 15:52:11 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 030829C3; Fri, 21 Dec 2012 15:52:11 +0000 (UTC) (envelope-from kevlo@FreeBSD.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 691728FC0C; Fri, 21 Dec 2012 15:52:09 +0000 (UTC) Received: from srg.kevlo.org (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id qBLFpqV8091827; Fri, 21 Dec 2012 23:51:52 +0800 (CST) (envelope-from kevlo@FreeBSD.org) Message-ID: <50D485A1.8040006@FreeBSD.org> Date: Fri, 21 Dec 2012 23:52:01 +0800 From: Kevin Lo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: Broken error handling with AF_* and socket(2) [was Re: svn commit: r243965 - in head/sys: kern sys] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, freebsd-net@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 15:52:11 -0000 On 2012/12/21 20:11, Garrett Cooper wrote: > On Thu, Dec 6, 2012 at 6:22 PM, Kevin Lo wrote: >> Author: kevlo >> Date: Fri Dec 7 02:22:48 2012 >> New Revision: 243965 >> URL: http://svnweb.freebsd.org/changeset/base/243965 >> >> Log: >> - according to POSIX, make socket(2) return EAFNOSUPPORT rather than >> EPROTONOSUPPORT if the address family is not supported. >> - introduce pffinddomain() to find a domain by family and use it as >> appropriate. >> >> Reviewed by: glebius > This commit broke netgraph (and potentially more things). I fixed > netgraph locally like so: > > $ git diff lib/libnetgraph/ > diff --git a/lib/libnetgraph/sock.c b/lib/libnetgraph/sock.c > index fca3900..5f9f563 100644 > --- a/lib/libnetgraph/sock.c > +++ b/lib/libnetgraph/sock.c > @@ -71,10 +71,10 @@ NgMkSockNode(const char *name, int *csp, int *dsp) > name = NULL; > > /* Create control socket; this also creates the netgraph node. > - If we get an EPROTONOSUPPORT then the socket node type is > + If we get an EAFNOSUPPORT then the socket node type is > not loaded, so load it and try again. */ > if ((cs = socket(AF_NETGRAPH, SOCK_DGRAM, NG_CONTROL)) < 0) { > - if (errno == EPROTONOSUPPORT) { > + if (errno == EAFNOSUPPORT) { > if (kldload(NG_SOCKET_KLD) < 0) { > errnosv = errno; > if (_gNgDebugLevel >= 1) > > Reproing the issue was trivial using the ether.bridge example > script setup with appropriate interfaces. > I have the patch with the netgraph fix attached, along with other > potential fixes that needs to be more properly tested. Ah, seems I forgot to commit the change. Thanks for the patch, Garrett, I'll fix it right away. > Thanks, > -Garrett Kevin From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 16:08:14 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 383EF2FF for ; Fri, 21 Dec 2012 16:08:14 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D16008FC14 for ; Fri, 21 Dec 2012 16:08:13 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fy27so5318684vcb.13 for ; Fri, 21 Dec 2012 08:08:07 -0800 (PST) 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=nyNmHDcvP6qbvA9F/3PUzX8lWBlzPcS2NzuXUVatbGg=; b=B+IKUENp/85YfG57cQFk34dbVkrT0lDZ7LF2ahAhSz204bCY69TreJCUsL575k2NDk 2prEHNfnyCyS2lF7OwdoWrrZgRGZWtUjHUVM7X3ZCGuWao3qQAvkxw3O3Q8LH2BQGxH+ 8Cx2SK4ENfnegUHvBFjJ2UH2I/U0V+fgrMW6TrlhQTzjtgtaGU1J3N505KRaLTZi6m6X spuAKG3U7Ae4nMYO14xr2GeR2Iyd/ZV4vI0EZxFT/DpJ19Cgnh4kpGRYQ/4Nm7hTAEBb qKqtB21ZNEVOZqI0APz7f3/HTrdv9t5pzBmfsJQqYk91iFdegB07UIm0wrg3P6vxX4Br Z1eg== MIME-Version: 1.0 Received: by 10.220.240.141 with SMTP id la13mr20395692vcb.39.1356106087239; Fri, 21 Dec 2012 08:08:07 -0800 (PST) Received: by 10.58.161.83 with HTTP; Fri, 21 Dec 2012 08:08:07 -0800 (PST) In-Reply-To: <50D45282.5080708@extrim.it> References: <50D45282.5080708@extrim.it> Date: Fri, 21 Dec 2012 11:08:07 -0500 Message-ID: Subject: Re: 'no buffer space available' after switch goes down on freeBSD 7.3 From: Ryan Stone To: Tsaregorodtsev Denis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 16:08:14 -0000 On Fri, Dec 21, 2012 at 7:13 AM, Tsaregorodtsev Denis wrote: > Hello, > > I maintenance ISP's DNS server which works under FreeBSD 7.3 and BIND > 9.9.1-P4. The network adapter is Intel(R) PRO/1000 Network Connection, > driver - em. The server is connected to a Cisco 6500 switch. Sometimes the > switch goes down (for maintenance) and is unavailable for 10 minutes. After > the switch goes up the server is still unavailable through IP. When I open > an IPMI console on the server and enter the ping command, I receive "no > buffer space available" error message. And the network doesn't work until > the server reboot. > I tried to google this and found that the problem can be solved by > increasing nmbclusters parameter. But I want to understand why this problem > appears when the switch is rebooting . May be you can suggest something? > > Best regards, Tsaregorodtsev Denis > > ______________________________**_________________ > 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 > " > Do you have a non-production machine you can test with? Can you confirm that the follow (compile-tested only) patch of 7.3 resolves the issue: http://people.freebsd.org/~rstone/patches/e1000_link.diff From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 16:13:54 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 B46895CB for ; Fri, 21 Dec 2012 16:13:54 +0000 (UTC) (envelope-from chris@deathstar.vindaloo.com) Received: from deathstar.vindaloo.com (unknown [IPv6:2001:470:1f07:26b:20c:29ff:fe2f:14e0]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5D68FC14 for ; Fri, 21 Dec 2012 16:13:54 +0000 (UTC) Received: from deathstar.vindaloo.com (localhost [127.0.0.1]) by deathstar.vindaloo.com (8.14.5/8.14.5) with ESMTP id qBLGDrb0002162 for ; Fri, 21 Dec 2012 11:13:53 -0500 (EST) (envelope-from chris@deathstar.vindaloo.com) Received: (from chris@localhost) by deathstar.vindaloo.com (8.14.5/8.14.5/Submit) id qBLGDr7o002161 for net@freebsd.org; Fri, 21 Dec 2012 11:13:53 -0500 (EST) (envelope-from chris) Resent-From: Christopher Sean Hilton Resent-Date: Fri, 21 Dec 2012 11:13:53 -0500 Resent-Message-ID: <20121221161353.GB2144@deathstar.vindaloo.com> Resent-To: net@freebsd.org X-Original-To: chris@vindaloo.com Delivered-To: chris@vindaloo.com Received: from dagobah.vindaloo.com (unknown [IPv6:2001:470:1f07:26b:0:ac18:9141:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by geonosis.vindaloo.com (Postfix) with ESMTPS id B90D8BBE2; Wed, 19 Dec 2012 18:33:21 -0500 (EST) Received: from dagobah.vindaloo.com (localhost [127.0.0.1]) by dagobah.vindaloo.com (8.14.5/8.14.5) with ESMTP id qBJNW6Li004014; Wed, 19 Dec 2012 18:32:06 -0500 (EST) (envelope-from chris@dagobah.vindaloo.com) Received: (from chris@localhost) by dagobah.vindaloo.com (8.14.5/8.14.5/Submit) id qBJNW6jb004013; Wed, 19 Dec 2012 18:32:06 -0500 (EST) (envelope-from chris) Date: Wed, 19 Dec 2012 18:32:06 -0500 From: Christopher Sean Hilton To: questions@freebsd.org Subject: ath0 + wpa/wpa2 + apple airport extreme = no joy. Message-ID: <20121219233206.GA3920@dagobah.vindaloo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-filtered: geonosis.vindaloo.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 16:13:54 -0000 I posted on a similar subject last year but in the end it turned out to be irrelevant. I'm trying to get the combination of: a Soekris Net4511, FreeBSD 8-STABLE from Dec 2011, an Atheros AR5BMB-44 wifi interface (identified as AR5212 in dmesg), an Apple Airport Extreme (about 2010 vintage) with WPA/WPA2 security, to all play nicely. To start with I plan to look at the change logs for the wpa_supplicant suite to see if there were changes from last December to now. I will probably just upgrade this box to a later vintage of 8-STABLE. Still, hit me with a cluebat if this problem got fixed between December, 2011 and now. Anyhow, no matter what I've done, the result is the same: The atheros/wlan combo associates to my wireless network; The dhcp client on the soekris sends a request to the dhcp server. The dhcp server receives the negotiation and tries to offer a lease but the soekris never receives a reply; I've confirmed this by running tcpdump on the dhcp server where I've seen the requests arrive with the atheros' mac address and I've seen the replies go back out of the dhcp server but either the atheros isn't listening or the Airport Extreme isn't forwarding the traffic. I haven't sniffed the wifi to see if the Airport Extreme just isn't forwarding the reply or if the atheros isn't receiving it properly. I can convince this combination of hardware to work if I change the network security on the airport extreme from WPA/WPA2 to None. The configuration that I feel should make the atheros work with the Airport Extreme works just fine with my 2010 vintage Airport Express. The Express and the Extreme are basically creating the same network. The Extreme is on 2.4GHz channel 11, the Express on 2.4GHz 1. The reason I have both so you are always near an access point. I can get the atheros to work with WPA2 on my Mifi 4082. As a new data point, the combination of an Intel 2200bg + WPA works with the Airport Extreme. I've posted my configs after my signature if you want to look and I can provide more information if you need it. My hope in posting this is to try and figure out what's up with the atheros or the Airport Extreme that it isn't working in this configuration. If anyone has an atheros card working with WPA/WPA2 and an Apple Airport Extreme I'd love any assistance you'd be willing to give me with the configuration. Thanks for any help you can provide. -- -- Chris ---------------------------------------------------------------------------- "There will be an answer, Let it be." e: chris -at- vindaloo -dot- com This is the hacked /etc/rc.conf to work with the Intel card: ... wpa_supplicant_enable="YES" ## wlans_ath0="wlan0" wlans_iwi0="wlan0" ifconfig_wlan0="WPA DHCP" ... Here's my abridged /etc/wpa_supplicant.conf: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 ## Airport Extreme network={ ssid="FooBarBaz" bssid=f8:1e:df:xx:xx:xx psk="************" proto=RSN key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP priority=12 } ## Airport Express network={ ssid="FooBarBaz" bssid=00:1f:f3:xx:xx:xx psk="************" proto=RSN key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP priority=10 } ## Mifi 4082 network={ ssid="FooBarBaz-Mobile" psk="************" priority=0 } Finally, here's the result of ifconfig on wlan0/iwi0 associated and working with the Airport Extreme: ryloth chris $ ifconfig iwi0 iwi0: flags=8843 metric 0 mtu 2290 ether 00:15:00:xx:xx:xx media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ryloth chris $ ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:15:00:xx:xx:xx inet 10.59.145.87 netmask 0xfffffe00 broadcast 10.59.145.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid FooBarBaz channel 11 (2462 MHz 11g) bssid f8:1e:df:xx:xx:xx country US authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 3:128-bit txpower 0 bmiss 24 scanvalid 60 protmode CTS wme roaming MANUAL From owner-freebsd-net@FreeBSD.ORG Fri Dec 21 19:03:40 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0F685A4; Fri, 21 Dec 2012 19:03:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2B78FC16; Fri, 21 Dec 2012 19:03:40 +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 qBLJ3egW061691; Fri, 21 Dec 2012 19:03:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBLJ3e4A061687; Fri, 21 Dec 2012 19:03:40 GMT (envelope-from linimon) Date: Fri, 21 Dec 2012 19:03:40 GMT Message-Id: <201212211903.qBLJ3e4A061687@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/174602: [gif] [ipsec] traceroute issue on gif tunnel with ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Dec 2012 19:03:40 -0000 Old Synopsis: traceroute issue on gif tunnel with ipsec New Synopsis: [gif] [ipsec] traceroute issue on gif tunnel with ipsec Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Dec 21 19:03:26 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=174602 From owner-freebsd-net@FreeBSD.ORG Sat Dec 22 00:21:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 275D3A30; Sat, 22 Dec 2012 00:21:42 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mx1.freebsd.org (Postfix) with ESMTP id A848F8FC13; Sat, 22 Dec 2012 00:21:41 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id vb8so5090378obc.20 for ; Fri, 21 Dec 2012 16:21:41 -0800 (PST) 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=l6M4TRxaqLLzRP3jTZ8KU7X7i+53/8w+0Zx2scMdSpw=; b=KrX2FbDQgY3TQGCMhud1PjqS6afQh2ijg9ArtCkNBYkJ94JrZiJBXpYijecII2olDL mHXut5frSpPTgw5wefI6fTLGDDQWa4LxX5ySmn4xlRvL+WL/wlveeT1tRuq6jsBsn5Ll WYWB/pHOYp6MFj5YTzmpPGfJqP1mpmVTKYcGVdaU0bdOl3P6Udt4ZXUNXEvHLNJx+qiw tcGS9L+cgPQiw+gDZ+yOQ6OaW/qwbRspl5+PRip6CB10XnCK3hw32WWd+FpqdEvGSoOh MGTmDpY3nY8rItkVrMeQUAPe57IWZTUxb/gG3ZDNTptEezucKlBKC3QM38exmTLkwFvH lM6w== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr629480oeg.17.1356135700963; Fri, 21 Dec 2012 16:21:40 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 16:21:40 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 16:21:40 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 00:21:42 -0000 On Mon, Dec 10, 2012 at 3:18 PM, wrote: > On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >> after it's finalised/freed. >> >> I have a similar bug showing up on ath(4) RX. :( > > Compile with DEBUG_MEMGUARD in the kernel configuration, and then set > vm.memguard.desc to the name of the UMA zone used for the 9216 byte > allocations, mbuf_jumbo_9k. This should cause a panic when the memory > is touched after free. Tada (dang, that's nifty stuff)! # sysctl vm.memguard.desc=mbuf_jumbo_9k vm.memguard.descM: -> mbuf_jumboem_9k # ory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 Memory modified after free 0xffffff8000405000(9216) val=0 @ 0xffffff8000405000 Memory modified after free 0xffffff8000409000(9216) val=5a5a5a5a @ 0xffffff8000409000 Fatal trap 1: privileged instruction fault while in kernel mode Fatal trap 1: privileged instruction fault while in kernel mode Memory modified after free 0xffffff800040d000(9216) val=5a5a5a5a @ 0xffffff800040d000 Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 3; cpuid = 1; apic id = 02 cpuid = 0; apic id = 06 apic id = 00 instruction pointer = 0x20:0xffffffff80af5099 instruction pointer = 0x20:0xffffffff80af5099 instruction pointer = 0x20:0xffffffff80af5099 Fatal trap 1: privileged instruction fault while in kernel mode stack pointer = 0x28:0xffffff8496fff880 stack pointer = 0x28:0xffffff8496fe1880 cpuid = 2; frame pointer = 0x28:0xffffff8496fff8b0 frame pointer = 0x28:0xffffff8496fe18b0 stack pointer = 0x28:0xffffff849705d880 code segment = base 0x0, limit 0xfffff, type 0x1b frame pointer = 0x28:0xffffff849705d8b0 apic id = 04 code segment = base 0x0, limit 0xfffff, type 0x1b code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 = DPL 0, pres 1, long 1, def32 0, gran 1 instruction pointer = 0x20:0xffffffff80af5099 processor eflags = = DPL 0, pres 1, long 1, def32 0, gran 1 interrupt enabled, processor eflags = stack pointer = 0x28:0xffffff8497067880 interrupt enabled, resume, resume, frame pointer = 0x28:0xffffff84970678b0 IOPL = 0 code segment = base 0x0, limit 0xfffff, type 0x1b current process = = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = 12 (irq280: ix0:que 3) ilock order reversal: (Giant after non-sleepable) 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fff320 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff450 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 trap() at trap+0x836/frame 0xffffff8496fff7c0 calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fff880, rbp = 0xffffff8496fff8b0 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496fff8e0 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496fff960 m_getjcl() at m_getjcl+0xce/frame 0xffffff8496fff9a0 ixgbe_refresh_mbufs() at ixgbe_refresh_mbufs+0x77/frame 0xffffff8496fffa20 ixgbe_rxeof() at ixgbe_rxeof+0x5ce/frame 0xffffff8496fffad0 ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff8496fffb20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff8496fffb60 ithread_loop() at ithread_loop+0x161/frame 0xffffff8496fffbb0 fork_exit() at fork_exit+0x84/frame 0xffffff8496fffbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496fffbf0 --- trap 0, rip = 0, rsp = 0xffffff8496fffcb0, rbp = 0 --- [ thread pid 12 tid 100218 ] Stopped at uma_find_refcnt+0x79: db> This looks interesting: $ git diff sys/dev/ixgbe/ixgbe.c diff --git a/sys/dev/ixgbe/ixgbe.c b/sys/dev/ixgbe/ixgbe.c index 40f5488..19f842b 100644 --- a/sys/dev/ixgbe/ixgbe.c +++ b/sys/dev/ixgbe/ixgbe.c @@ -897,8 +897,10 @@ ixgbe_qflush(struct ifnet *ifp) for (int i = 0; i < adapter->num_queues; i++, txr++) { IXGBE_TX_LOCK(txr); - while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) + while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) { m_freem(m); + m = NULL; + } IXGBE_TX_UNLOCK(txr); } if_qflush(ifp); I'm going to recompile the driver and restart the network a few times (that's the sticking point) and see what happens. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Dec 22 00:53: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 9721EF17; Sat, 22 Dec 2012 00:53:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2610F8FC12; Sat, 22 Dec 2012 00:53:23 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n16so5328724oag.9 for ; Fri, 21 Dec 2012 16:53:23 -0800 (PST) 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=9JgngyOvVeZLjeXc+y1V73qebFBp1j080brh42f/4EY=; b=EGqaWcI1YF9ewIqArYO3liNyUd1QCmOzNsXS6HnsB9y4NZqt+PPxgpdyT3pDKr0h2w r/lHO1yNsD6l3v7aY5PJTMQ551d3Rzb2FuHOYlgrLqSVZrOuNofUwYbseMF8Z1kY1j7y to9yA6s3nneX4ro2Owe5vhiuyMGfbWMZRIkntPVd3kBPXvrqijI+w+KG0Q2bRmqSjqfg xvhgjR1U6e3YesjGDwH3JqLw8iskYBFj1CmZ4Vy28rawis0e9nyyKSc8gUI0FCDnSRQ3 rVLCE7x5YKYKqi26UBXClqfFMCbRC3pY83XOOzN96CjjndS40MU7sqgaVEJF9KiTjs2z oSzw== MIME-Version: 1.0 Received: by 10.60.6.226 with SMTP id e2mr1074515oea.56.1356137236378; Fri, 21 Dec 2012 16:47:16 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 16:47:15 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 16:47:15 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd , FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 00:53:24 -0000 On Fri, Dec 21, 2012 at 4:21 PM, Garrett Cooper wrote: > On Mon, Dec 10, 2012 at 3:18 PM, wrote: >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf >>> after it's finalised/freed. >>> >>> I have a similar bug showing up on ath(4) RX. :( >> >> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set >> vm.memguard.desc to the name of the UMA zone used for the 9216 byte >> allocations, mbuf_jumbo_9k. This should cause a panic when the memory >> is touched after free. > > Tada (dang, that's nifty stuff)! > > # sysctl vm.memguard.desc=mbuf_jumbo_9k > vm.memguard.descM: -> mbuf_jumboem_9k > # ory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 > Memory modified after free 0xffffff8000405000(9216) val=0 @ 0xffffff8000405000 > Memory modified after free 0xffffff8000409000(9216) val=5a5a5a5a @ > 0xffffff8000409000 > > > > > > > Fatal trap 1: privileged instruction fault while in kernel mode > Fatal trap 1: privileged instruction fault while in kernel mode > Memory modified after free 0xffffff800040d000(9216) val=5a5a5a5a @ > 0xffffff800040d000 > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 3; > cpuid = 1; > apic id = 02 > cpuid = 0; apic id = 06 > apic id = 00 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > Fatal trap 1: privileged instruction fault while in kernel mode > stack pointer = 0x28:0xffffff8496fff880 > stack pointer = 0x28:0xffffff8496fe1880 > cpuid = 2; frame pointer = 0x28:0xffffff8496fff8b0 > frame pointer = 0x28:0xffffff8496fe18b0 > stack pointer = 0x28:0xffffff849705d880 > code segment = base 0x0, limit 0xfffff, type 0x1b > frame pointer = 0x28:0xffffff849705d8b0 > apic id = 04 > code segment = base 0x0, limit 0xfffff, type 0x1b > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > = DPL 0, pres 1, long 1, def32 0, gran 1 > instruction pointer = 0x20:0xffffffff80af5099 > processor eflags = = DPL 0, pres 1, long > 1, def32 0, gran 1 > interrupt enabled, processor eflags = stack pointer = > 0x28:0xffffff8497067880 > interrupt enabled, resume, resume, frame pointer = > 0x28:0xffffff84970678b0 > IOPL = 0 > code segment = base 0x0, limit 0xfffff, type 0x1b > current process = = DPL 0, pres 1, long > 1, def32 0, gran 1 > processor eflags = 12 (irq280: ix0:que 3) > ilock order reversal: (Giant after non-sleepable) > 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fff320 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 > witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff450 > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 > ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 > cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 > kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 > trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 > trap() at trap+0x836/frame 0xffffff8496fff7c0 > calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 > --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fff880, rbp > = 0xffffff8496fff8b0 --- > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 > mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496fff8e0 > uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496fff960 > m_getjcl() at m_getjcl+0xce/frame 0xffffff8496fff9a0 > ixgbe_refresh_mbufs() at ixgbe_refresh_mbufs+0x77/frame 0xffffff8496fffa20 > ixgbe_rxeof() at ixgbe_rxeof+0x5ce/frame 0xffffff8496fffad0 > ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff8496fffb20 > intr_event_execute_handlers() at > intr_event_execute_handlers+0x90/frame 0xffffff8496fffb60 > ithread_loop() at ithread_loop+0x161/frame 0xffffff8496fffbb0 > fork_exit() at fork_exit+0x84/frame 0xffffff8496fffbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496fffbf0 > --- trap 0, rip = 0, rsp = 0xffffff8496fffcb0, rbp = 0 --- > [ thread pid 12 tid 100218 ] > Stopped at uma_find_refcnt+0x79: > db> > > This looks interesting: > > $ git diff sys/dev/ixgbe/ixgbe.c > diff --git a/sys/dev/ixgbe/ixgbe.c b/sys/dev/ixgbe/ixgbe.c > index 40f5488..19f842b 100644 > --- a/sys/dev/ixgbe/ixgbe.c > +++ b/sys/dev/ixgbe/ixgbe.c > @@ -897,8 +897,10 @@ ixgbe_qflush(struct ifnet *ifp) > > for (int i = 0; i < adapter->num_queues; i++, txr++) { > IXGBE_TX_LOCK(txr); > - while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) > + while ((m = buf_ring_dequeue_sc(txr->br)) != NULL) { > m_freem(m); > + m = NULL; > + } > IXGBE_TX_UNLOCK(txr); > } > if_qflush(ifp); > > I'm going to recompile the driver and restart the network a few > times (that's the sticking point) and see what happens. Now the T4 is angry: ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^CMemory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80af5099 stack pointer = 0x28:0xffffff8496f41910 frame pointer ^C = 0x28:0xffffff8496f41940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq265: t4nex0:1.0) lock order reversal: (Giant after non-sleepable) 1st 0xfffffe00790eb690 cxgbe1 rxq0-fl (cxgbe1 rxq0-fl) @ /usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_sge.c:1008 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496f413b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496f41460 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496f414e0 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496f41520 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496f41540 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496f41560 cngrab() at cngrab+0x35/frame 0xffffff8496f41580 kdb_trap() at kdb_trap+0x124/frame 0xffffff8496f415e0 trap_fatal() at trap_fatal+0x345/frame 0xffffff8496f41640 trap() at trap+0x836/frame 0xffffff8496f41850 calltrap() at calltrap+0x8/frame 0xffffff8496f41850 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496f41910, rbp = 0xffffff8496f41940 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496f41940 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496f41970 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496f419f0 refill_fl() at refill_fl+0x28f/frame 0xffffff8496f41a60 service_iq() at service_iq+0x821/frame 0xffffff8496f41b00 t4_intr() at t4_intr+0x2e/frame 0xffffff8496f41b20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff8496f41b60 ithread_loop() at ithread_loop+0x161/frame 0xffffff8496f41bb0 fork_exit() at fork_exit+0x84/frame 0xffffff8496f41bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8496f41bf0 --- trap 0, rip = 0, rsp = 0xffffff8496f41cb0, rbp = 0 --- [ thread pid 12 tid 100196 ] Stopped at uma_find_refcnt+0x79: Guess I'll rebuild the modules with the changes that np@ just made today and see if that changes anything... Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Dec 22 01:34:43 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 65993B84; Sat, 22 Dec 2012 01:34:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mx1.freebsd.org (Postfix) with ESMTP id 10A078FC0A; Sat, 22 Dec 2012 01:34:42 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id oi10so5079927obb.40 for ; Fri, 21 Dec 2012 17:34:42 -0800 (PST) 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=AuDKPsfPfAyYcLQXT7JSW//5g/py7FRN7WgfwBaFrXo=; b=wNPWLRiz+sf9dVWledFKaB1QsGNTllHxVHHYXLij/56vCm50TkqN2lMvv9AXa6oO9u 8fvQ015AXA33c9YPOAEVCiT8A0tk4xRzfOM14CtpIzrAs2pNPqVk0N+AlbPaoerezcXS TRuqs8hxsmhj7KenDTIJ6Fi2Io2+0KXB5k+2rSuhSelh5Crk6tUVr7sC5Td/E589VkHj ysNAvQ+y0gQFWrNm/9/wjzBdd1hEQpEKQNJAvlj/LtiweBoPMbNAlZw42AyTCD4swSim JZBVsvz/AuaJiIXekWCEi5AgmOq/cT1iYuMQgoqNzd2vr33w3QsiQHONfz0X6V4W/s9t Epzw== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr716801oeb.24.1356140082417; Fri, 21 Dec 2012 17:34:42 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 21 Dec 2012 17:34:42 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Dec 2012 17:34:42 -0800 Message-ID: Subject: Re: "Memory modified after free" - by whom? From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 01:34:43 -0000 (clipping off mdf and adrian so they don't get directly spammed :)..) Crud. Continuing the processor after panic didn't work, so it might be a case of cxgbe "shot the sheriff" or something else in the stack is doing something wonky: db> c Memory modified after free 0xffffff8000405000(9216) val=0 @ 0xffffff8000405000 Memory modified after free 0xffffff800040d000(9216) val=0 @ 0xffffff800040d000 Fatal trap 1: privileged instruction fault while in kernel mode Memory modified after free 0xffffff8000409000(9216) val=0 @ 0xffffff8000409000 cpuid = 0; Fatal trap 1: privileged instruction fault while in kernel mode apic id = 00 cpuid = 1; Fatal trap 1: privileged instruction fault while in kernel mode instruction pointer = 0x20:0xffffffff80af5099 cpuid = 2; stack pointer = 0x28:0xffffff8496f41910 apic id = 04 apic id = 02 instruction pointer = 0x20:0xffffffff80af5099 instruction pointer = 0x20:0xffffffff80af5099 stack pointer = 0x28:0xffffff849705d880 frame pointer = 0x28:0xffffff8496f41940 stack pointer = 0x28:0xffffff8497067880 code segment = base 0x0, limit 0xfffff, type 0x1b frame pointer = 0x28:0xffffff849705d8b0 = DPL 0, pres 1, long 1, def32 0, gran 1 frame pointer = 0x28:0xffffff84970678b0 Fatal trap 1: privileged instruction fault while in kernel mode code segment = base 0x0, limit 0xfffff, type 0x1b code segment = base 0x0, limit 0xfffff, type 0x1b processor eflags = = DPL 0, pres 1, long 1, def32 0, gran 1 = DPL 0, pres 1, long 1, def32 0, gran 1 cpuid = 3; interrupt enabled, processor eflags = processor eflags = resume, interrupt enabled, apic id = 06 interrupt enabled, instruction pointer = 0x20:0xffffffff80af5099 resume, resume, stack pointer = 0x28:0xffffff8497071880 IOPL = 0 frame pointer = 0x28:0xffffff84970718b0 IOPL = 0 current process = code segment = base 0x0, limit 0xfffff, type 0x1b 12 (irq283: ix1:que 1) Ilock order reversal: (Giant after non-sleepable) 1st 0xfffffe009a295918 ix1:rx(1) (ix1:rx(1)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4298 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff849705d320 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff849705d3d0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff849705d450 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff849705d490 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff849705d4b0 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff849705d4d0 cngrab() at cngrab+0x35/frame 0xffffff849705d4f0 kdb_trap() at kdb_trap+0x124/frame 0xffffff849705d550 trap_fatal() at trap_fatal+0x345/frame 0xffffff849705d5b0 trap() at trap+0x836/frame 0xffffff849705d7c0 calltrap() at calltrap+0x8/frame 0xffffff849705d7c0 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff849705d880, rbp = 0xffffff849705d8b0 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff849705d8b0 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff849705d8e0 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff849705d960 m_getjcl() at m_getjcl+0xce/frame 0xffffff849705d9a0 ixgbe_refresh_mbufs() at ixgbe_refresh_mbufs+0x77/frame 0xffffff849705da20 ixgbe_rxeof() at ixgbe_rxeof+0x4e9/frame 0xffffff849705dad0 ixgbe_msix_que() at ixgbe_msix_que+0x9b/frame 0xffffff849705db20 intr_event_execute_handlers() at intr_event_execute_handlers+0x90/frame 0xffffff849705db60 ithread_loop() at ithread_loop+0x161/frame 0xffffff849705dbb0 fork_exit() at fork_exit+0x84/frame 0xffffff849705dbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff849705dbf0 --- trap 0, rip = 0, rsp = 0xffffff849705dcb0, rbp = 0 --- [ thread pid 12 tid 100224 ] Stopped at uma_find_refcnt+0x79: I setup asymmetric MTUs to see if I can narrow down whether the issue is a jumbo frame or cxgbe/ixgbe issue and so far so good. Trying again with jumbo frames paniced on boot when loading the module (really...?): # Memory modified after free 0xffffff8000401000(9216) val=0 @ 0xffffff8000401000 Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 1; apic id = 02 instruction pointer = 0x20:0xffffffff80af5099 stack pointer = 0x28:0xffffff8496fc9750 frame pointer = 0x28:0xffffff8496fc9780 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3280 (ifconfig) lock order reversal: (Giant after non-sleepable) 1st 0xfffffe00462f7808 ix0:rx(0) (ix0:rx(0)) @ /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:3938 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fc91f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fc92a0 witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fc9320 __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fc9360 ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fc9380 kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fc93a0 cngrab() at cngrab+0x35/frame 0xffffff8496fc93c0 kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fc9420 trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fc9480 trap() at trap+0x836/frame 0xffffff8496fc9690 calltrap() at calltrap+0x8/frame 0xffffff8496fc9690 --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fc9750, rbp = 0xffffff8496fc9780 --- uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fc9780 mb_ctor_clust() at mb_ctor_clust+0x8f/frame 0xffffff8496fc97b0 uma_zalloc_arg() at uma_zalloc_arg+0xe7/frame 0xffffff8496fc9830 m_getjcl() at m_getjcl+0xce/frame 0xffffff8496fc9870 ixgbe_init_locked() at ixgbe_init_locked+0x62c/frame 0xffffff8496fc9930 ixgbe_ioctl() at ixgbe_ioctl+0x32d/frame 0xffffff8496fc9980 ifioctl() at ifioctl+0xc84/frame 0xffffff8496fc9a40 kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff8496fc9a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff8496fc9ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8496fc9bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8496fc9bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80118481a, rsp = 0x7fffffffd488, rbp = 0x7fffffffd4a0 --- [ thread pid 3280 tid 100220 ] Stopped at uma_find_refcnt+0x79: Setting the MTU exhibits the same problem... just with smaller mbufs: Memory modified after free 0xfffffe014ce86800(2048) val=cc0c0001 @ 0xfffffe014ce86800 Memory modified after free 0xfffffe00bd86f000(2048) val=cc0c0001 @ 0xfffffe00bd86f000 Memory modified after free 0xfffffe00bd3a4000(2048) val=cc0c0001 @ 0xfffffe00bd3a4000 Memory modified after free 0xfffffe011a55c000(2048) val=2d290c00 @ 0xfffffe011a55c000 Memory modified after free 0xfffffe011a5fa800(2048) val=cc0c0001 @ 0xfffffe011a5fa800 Memory modified after free 0xfffffe00bd018800(2048) val=ffffffff @ 0xfffffe00bd018800 Memory modified after free 0xfffffe00bd1c4000(2048) val=7f565000 @ 0xfffffe00bd1c4000 Memory modified after free 0xfffffe011a521800(2048) val=529c0a00 @ 0xfffffe011a521800 Memory modified after free 0xfffffe011a521800(2048) val=cc0c0001 @ 0xfffffe011a521800 Memory modified after free 0xfffffe00bd0ce800(2048) val=cc0c0001 @ 0xfffffe00bd0ce800 Memory modified after free 0xfffffe00bd9a3000(2048) val=ffffffff @ 0xfffffe00bd9a3000 Memory modified after free 0xfffffe00bd8b6800(2048) val=cc0c0001 @ 0xfffffe00bd8b6800 Memory modified after free 0xfffffe00bd923000(2048) val=cc0c0001 @ 0xfffffe00bd923000 Memory modified after free 0xfffffe0188f70800(2048) val=2d290c00 @ 0xfffffe0188f70800 Memory modified after free 0xfffffe0180452000(2048) val=ffffffff @ 0xfffffe0180452000 Memory modified after free 0xfffffe014cd6b800(2048) val=cc0c0001 @ 0xfffffe014cd6b800 Memory modified after free 0xfffffe014c967800(2048) val=cc0c0001 @ 0xfffffe014c967800 Memory modified after free 0xfffffe01800d1000(2048) val=cc0c0001 @ 0xfffffe01800d1000 Memory modified after free 0xfffffe014c967800(2048) val=cc0c0001 @ 0xfffffe014c967800 Memory modified after free 0xfffffe0188fdf000(2048) val=cc0c0001 @ 0xfffffe0188fdf000 Memory modified after free 0xfffffe0188fdf000(2048) val=cc0c0001 @ 0xfffffe0188fdf000 Memory modified after free 0xfffffe00bd9a3000(2048) val=cc0c0001 @ 0xfffffe00bd9a3000 Memory modified after free 0xfffffe011a6cb000(2048) val=cc0c0001 @ 0xfffffe011a6cb000 Setting sysctl vm.memguard.desc=mbuf sends the kernel into a spiral of "use-after-frees". FWIW, I was able to repro the issue with ixgbe kldloading the module after boot sometimes, so I'm thinking that the locking/memory management in the recent set of changes is potentially off. Thanks, -Garrett PS Thanks np for the recent fix for cxgbe :). From owner-freebsd-net@FreeBSD.ORG Sat Dec 22 11:08: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 63129288; Sat, 22 Dec 2012 11:08:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 57AE48FC14; Sat, 22 Dec 2012 11:08:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18035; Sat, 22 Dec 2012 13:08:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmMw9-000E0e-3s; Sat, 22 Dec 2012 13:08:13 +0200 Message-ID: <50D5949A.1060505@FreeBSD.org> Date: Sat, 22 Dec 2012 13:08:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Fatal trap 1 [Was: "Memory modified after free" - by whom?] References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 11:08:24 -0000 on 22/12/2012 02:21 Garrett Cooper said the following: > Fatal trap 1: privileged instruction fault while in kernel mode > Fatal trap 1: privileged instruction fault while in kernel mode Unrelated to the original topic - this looks very weird. I mean all the CPUs getting this unusual trap... Could you please do 'disassemble 0xffffffff80af5099' in kgdb with the same kernel. Or if you have a different kernel now, please use "instruction pointer" value from a trap with that kernel. > Memory modified after free 0xffffff800040d000(9216) val=5a5a5a5a @ > 0xffffff800040d000 > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 3; > cpuid = 1; > apic id = 02 > cpuid = 0; apic id = 06 > apic id = 00 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > instruction pointer = 0x20:0xffffffff80af5099 > Fatal trap 1: privileged instruction fault while in kernel mode > stack pointer = 0x28:0xffffff8496fff880 > stack pointer = 0x28:0xffffff8496fe1880 > cpuid = 2; frame pointer = 0x28:0xffffff8496fff8b0 > frame pointer = 0x28:0xffffff8496fe18b0 > stack pointer = 0x28:0xffffff849705d880 > code segment = base 0x0, limit 0xfffff, type 0x1b > frame pointer = 0x28:0xffffff849705d8b0 > apic id = 04 > code segment = base 0x0, limit 0xfffff, type 0x1b > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > = DPL 0, pres 1, long 1, def32 0, gran 1 > instruction pointer = 0x20:0xffffffff80af5099 > processor eflags = = DPL 0, pres 1, long > 1, def32 0, gran 1 > interrupt enabled, processor eflags = stack pointer = > 0x28:0xffffff8497067880 > interrupt enabled, resume, resume, frame pointer = > 0x28:0xffffff84970678b0 > IOPL = 0 > code segment = base 0x0, limit 0xfffff, type 0x1b > current process = = DPL 0, pres 1, long > 1, def32 0, gran 1 > processor eflags = 12 (irq280: ix0:que 3) > ilock order reversal: (Giant after non-sleepable) > 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:1946 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8496fff320 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 > witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff450 > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 > ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 > cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 > kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 > trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 > trap() at trap+0x836/frame 0xffffff8496fff7c0 > calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 > --- trap 0x1, rip = 0xffffffff80af5099, rsp = 0xffffff8496fff880, rbp > = 0xffffff8496fff8b0 --- > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Sat Dec 22 11:21:32 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 1304A659; Sat, 22 Dec 2012 11:21:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7535E8FC17; Sat, 22 Dec 2012 11:21:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBMBLO3s056016; Sat, 22 Dec 2012 13:21:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBMBLO3s056016 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBMBLOib056015; Sat, 22 Dec 2012 13:21:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2012 13:21:24 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Fatal trap 1 [Was: "Memory modified after free" - by whom?] Message-ID: <20121222112124.GN53644@kib.kiev.ua> References: <50D5949A.1060505@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zbynv6TNPa9FrOf6" Content-Disposition: inline In-Reply-To: <50D5949A.1060505@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Garrett Cooper , freebsd-net@freebsd.org, FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 11:21:32 -0000 --Zbynv6TNPa9FrOf6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 22, 2012 at 01:08:10PM +0200, Andriy Gapon wrote: > on 22/12/2012 02:21 Garrett Cooper said the following: > > Fatal trap 1: privileged instruction fault while in kernel mode > > Fatal trap 1: privileged instruction fault while in kernel mode >=20 > Unrelated to the original topic - this looks very weird. > I mean all the CPUs getting this unusual trap... > Could you please do 'disassemble 0xffffffff80af5099' in kgdb with the same > kernel. Or if you have a different kernel now, please use "instruction p= ointer" > value from a trap with that kernel. >=20 This is due to the vtoslab() returning NULL. Since slabref is dereferenced later, clang tries to be helpful as usual and converts the !(p->flags & PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab() result is NULL. So instead of KASSERT triggering the next line, you see this improvement. > > Memory modified after free 0xffffff800040d000(9216) val=3D5a5a5a5a @ > > 0xffffff800040d000 > > Fatal trap 1: privileged instruction fault while in kernel mode > > cpuid =3D 3; > > cpuid =3D 1; > > apic id =3D 02 > > cpuid =3D 0; apic id =3D 06 > > apic id =3D 00 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > Fatal trap 1: privileged instruction fault while in kernel mode > > stack pointer =3D 0x28:0xffffff8496fff880 > > stack pointer =3D 0x28:0xffffff8496fe1880 > > cpuid =3D 2; frame pointer =3D 0x28:0xffffff8496fff8b0 > > frame pointer =3D 0x28:0xffffff8496fe18b0 > > stack pointer =3D 0x28:0xffffff849705d880 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > frame pointer =3D 0x28:0xffffff849705d8b0 > > apic id =3D 04 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > instruction pointer =3D 0x20:0xffffffff80af5099 > > processor eflags =3D =3D DPL 0, pres 1, lo= ng > > 1, def32 0, gran 1 > > interrupt enabled, processor eflags =3D stack pointer =3D > > 0x28:0xffffff8497067880 > > interrupt enabled, resume, resume, frame pointer =3D > > 0x28:0xffffff84970678b0 > > IOPL =3D 0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > current process =3D =3D DPL 0, pres 1, lo= ng > > 1, def32 0, gran 1 > > processor eflags =3D 12 (irq280: ix0:que 3) > > ilock order reversal: (Giant after non-sleepable) > > 1st 0xfffffe0078148b38 ix0:rx(3) (ix0:rx(3)) @ > > /usr/src/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4296 > > 2nd 0xffffffff814457b8 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd= =2Ec:1946 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff849= 6fff320 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8496fff3d0 > > witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff8496fff4= 50 > > __mtx_lock_flags() at __mtx_lock_flags+0x89/frame 0xffffff8496fff490 > > ukbd_poll() at ukbd_poll+0x28/frame 0xffffff8496fff4b0 > > kbdmux_poll() at kbdmux_poll+0x5b/frame 0xffffff8496fff4d0 > > cngrab() at cngrab+0x35/frame 0xffffff8496fff4f0 > > kdb_trap() at kdb_trap+0x124/frame 0xffffff8496fff550 > > trap_fatal() at trap_fatal+0x345/frame 0xffffff8496fff5b0 > > trap() at trap+0x836/frame 0xffffff8496fff7c0 > > calltrap() at calltrap+0x8/frame 0xffffff8496fff7c0 > > --- trap 0x1, rip =3D 0xffffffff80af5099, rsp =3D 0xffffff8496fff880, r= bp > > =3D 0xffffff8496fff8b0 --- > > uma_find_refcnt() at uma_find_refcnt+0x79/frame 0xffffff8496fff8b0 >=20 >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Zbynv6TNPa9FrOf6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDVl7QACgkQC3+MBN1Mb4i/AACcDPDRTKUrOx+7sGBKr/uDvlWe guAAnAkEl1FAAovlA4oWmJZKvjbHSVs2 =0QM1 -----END PGP SIGNATURE----- --Zbynv6TNPa9FrOf6-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 22 11:44:55 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1031A91A; Sat, 22 Dec 2012 11:44:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1C88FC12; Sat, 22 Dec 2012 11:44:53 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18206; Sat, 22 Dec 2012 13:44:51 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmNVa-000E2o-Un; Sat, 22 Dec 2012 13:44:50 +0200 Message-ID: <50D59D31.6010302@FreeBSD.org> Date: Sat, 22 Dec 2012 13:44:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Fatal trap 1 References: <50D5949A.1060505@FreeBSD.org> <20121222112124.GN53644@kib.kiev.ua> In-Reply-To: <20121222112124.GN53644@kib.kiev.ua> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-net@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 11:44:55 -0000 on 22/12/2012 13:21 Konstantin Belousov said the following: > This is due to the vtoslab() returning NULL. Since slabref is dereferenced > later, clang tries to be helpful as usual and converts the !(p->flags & > PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab() > result is NULL. > > So instead of KASSERT triggering the next line, you see this improvement. Interesting. Thank you for the explanation. But looking at the code I think that slabref->us_keg access _before_ KASSERT is the culprit? I.e. even with GCC we could get a page fault before the KASSERT is reached (modulo reordering)? -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Sat Dec 22 11:49: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 B6DE8BEB; Sat, 22 Dec 2012 11:49:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 15E9D8FC0C; Sat, 22 Dec 2012 11:49:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBMBn5wm058431; Sat, 22 Dec 2012 13:49:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBMBn5wm058431 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBMBn4Ba058430; Sat, 22 Dec 2012 13:49:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2012 13:49:04 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Fatal trap 1 Message-ID: <20121222114904.GO53644@kib.kiev.ua> References: <50D5949A.1060505@FreeBSD.org> <20121222112124.GN53644@kib.kiev.ua> <50D59D31.6010302@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hOh8F6DNH/RZBSFD" Content-Disposition: inline In-Reply-To: <50D59D31.6010302@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Garrett Cooper , freebsd-net@freebsd.org, FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Dec 2012 11:49:09 -0000 --hOh8F6DNH/RZBSFD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 22, 2012 at 01:44:49PM +0200, Andriy Gapon wrote: > on 22/12/2012 13:21 Konstantin Belousov said the following: > > This is due to the vtoslab() returning NULL. Since slabref is dereferen= ced > > later, clang tries to be helpful as usual and converts the !(p->flags & > > PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtosla= b() > > result is NULL. > >=20 > > So instead of KASSERT triggering the next line, you see this improvemen= t. >=20 > Interesting. Thank you for the explanation. >=20 > But looking at the code I think that slabref->us_keg access _before_ KASS= ERT > is the culprit? I.e. even with GCC we could get a page fault before the > KASSERT is reached (modulo reordering)? May be, but I do not think it is matter. Because KASSERT() now can return, even if you reorder the assert and deref, I think that compiler authors still find an excuse. --hOh8F6DNH/RZBSFD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDVnjAACgkQC3+MBN1Mb4gW7wCgn9j92ij2YpljHo9NIj6IneHW 0pAAn1POvHv9NRfsLFExGGFpWzEmkN2a =vH3G -----END PGP SIGNATURE----- --hOh8F6DNH/RZBSFD--