From owner-freebsd-net@FreeBSD.ORG Sun Sep 30 20:20: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 2FEEC1065670 for ; Sun, 30 Sep 2012 20:20:03 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1248FC08 for ; Sun, 30 Sep 2012 20:20:02 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id 46F735093E; Sun, 30 Sep 2012 16:00:32 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id E2235508D8 for ; Sun, 30 Sep 2012 16:00:31 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Sun, 30 Sep 2012 16:00:31 -0400 From: Dominic Blais To: "freebsd-net@freebsd.org" Date: Sun, 30 Sep 2012 16:00:24 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2fRjp7XpMhWXhyQQWSNRXhRx3VYA== Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: multipart/related; boundary="_004_2DE61B0869B7484997BCA012845482C7EBE8E280DBWIN2008Domnta_"; type="multipart/alternative" MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 20:20:03 -0000 --_004_2DE61B0869B7484997BCA012845482C7EBE8E280DBWIN2008Domnta_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was just wondering if there was anything new about the bug of default rou= te changing without warning... Is there any test I can do to help fixing i= t? -- [cid:image001.gif@01CD9F24.B366CBF0] --_004_2DE61B0869B7484997BCA012845482C7EBE8E280DBWIN2008Domnta_-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 30 20:31:37 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 F1E35106566C for ; Sun, 30 Sep 2012 20:31:36 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8A57D8FC0A for ; Sun, 30 Sep 2012 20:31:36 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TIQEA-0004Gr-L2; Mon, 01 Oct 2012 00:35:02 +0400 Message-ID: <5068AC17.8020704@FreeBSD.org> Date: Mon, 01 Oct 2012 00:31:19 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Dominic Blais References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> In-Reply-To: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 20:31:37 -0000 On 01.10.2012 00:00, Dominic Blais wrote: > Hi, Hello! > > I was just wondering if there was anything new about the bug of default route changing without warning... Is there any test I can do to help fixing it? Can you be a bit more precise and specify FreeBSD version and address family? Are you sure that it is not changed by some other userland process (e.g. did you do some `route monitor` checks) ? > > -- > [cid:image001.gif@01CD9F24.B366CBF0] > > > > > > _______________________________________________ > 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 Sep 30 20:33:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55DC11065674; Sun, 30 Sep 2012 20:33:37 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2F68FC1B; Sun, 30 Sep 2012 20:33:36 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id 38BD85093E; Sun, 30 Sep 2012 16:33:36 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id D9C10508D8; Sun, 30 Sep 2012 16:33:35 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Sun, 30 Sep 2012 16:33:35 -0400 From: Dominic Blais To: "Alexander V. Chernikov" Date: Sun, 30 Sep 2012 16:33:30 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2fSpf+goVqW4/CQ8SxAX7goHJ/hAAAATVA Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> In-Reply-To: <5068AC17.8020704@FreeBSD.org> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 20:33:37 -0000 Yes, I'm very sure of it! A "route monitor" show no changes when it happens= . I've heard of another person with the same bug that has no traces in "rou= te monitor" either... We have in common that we're using IPFW and PF. -- -----Message d'origine----- De=A0: Alexander V. Chernikov [mailto:melifaro@FreeBSD.org]=20 Envoy=E9=A0: 30 septembre 2012 16:31 =C0=A0: Dominic Blais Cc=A0: freebsd-net@freebsd.org Objet=A0: Re: Default route destination changing without warning follow-up On 01.10.2012 00:00, Dominic Blais wrote: > Hi, Hello! > > I was just wondering if there was anything new about the bug of default r= oute changing without warning... Is there any test I can do to help fixing= it? Can you be a bit more precise and specify FreeBSD version and address famil= y? Are you sure that it is not changed by some other userland process (e.g.=20 did you do some `route monitor` checks) ? > > -- > [cid:image001.gif@01CD9F24.B366CBF0] > > > > > > _______________________________________________ > 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 Sep 30 20:38:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A1E7106566B for ; Sun, 30 Sep 2012 20:38:53 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 38F4D8FC08 for ; Sun, 30 Sep 2012 20:38:53 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TIQLD-0004JR-NG; Mon, 01 Oct 2012 00:42:19 +0400 Message-ID: <5068ADCC.5030105@FreeBSD.org> Date: Mon, 01 Oct 2012 00:38:36 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Dominic Blais References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> In-Reply-To: <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 20:38:53 -0000 On 01.10.2012 00:33, Dominic Blais wrote: > Yes, I'm very sure of it! A "route monitor" show no changes when it happens. I've heard of another person with the same bug that has no traces in "route monitor" either... We have in common that we're using IPFW and PF. So, are we talking about IPv4 or IPv6? > > > > -- > > > > -----Message d'origine----- > De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] > Envoyé : 30 septembre 2012 16:31 > À : Dominic Blais > Cc : freebsd-net@freebsd.org > Objet : Re: Default route destination changing without warning follow-up > > On 01.10.2012 00:00, Dominic Blais wrote: >> Hi, > Hello! >> >> I was just wondering if there was anything new about the bug of default route changing without warning... Is there any test I can do to help fixing it? > Can you be a bit more precise and specify FreeBSD version and address family? > > Are you sure that it is not changed by some other userland process (e.g. > did you do some `route monitor` checks) ? >> >> -- >> [cid:image001.gif@01CD9F24.B366CBF0] >> >> >> >> >> >> _______________________________________________ >> 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 Sep 30 20:59:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE5AF106564A; Sun, 30 Sep 2012 20:59:15 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1298FC08; Sun, 30 Sep 2012 20:59:15 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id D26A45093E; Sun, 30 Sep 2012 16:59:14 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id 7AEBE508E2; Sun, 30 Sep 2012 16:59:14 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Sun, 30 Sep 2012 16:59:14 -0400 From: Dominic Blais To: "Alexander V. Chernikov" Date: Sun, 30 Sep 2012 16:59:08 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2fS5uECXHAU1l9R62t6E8GbGOt4QAAs98A Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> In-Reply-To: <5068ADCC.5030105@FreeBSD.org> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 20:59:16 -0000 It's all about IPv4 in my case. -- -----Message d'origine----- De=A0: Alexander V. Chernikov [mailto:melifaro@FreeBSD.org]=20 Envoy=E9=A0: 30 septembre 2012 16:39 =C0=A0: Dominic Blais Cc=A0: freebsd-net@freebsd.org Objet=A0: Re: Default route destination changing without warning follow-up On 01.10.2012 00:33, Dominic Blais wrote: > Yes, I'm very sure of it! A "route monitor" show no changes when it happe= ns. I've heard of another person with the same bug that has no traces in "r= oute monitor" either... We have in common that we're using IPFW and PF. So, are we talking about IPv4 or IPv6? > > > > -- > > > > -----Message d'origine----- > De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] Envoy=E9 : 30=20 > septembre 2012 16:31 =C0 : Dominic Blais Cc : freebsd-net@freebsd.org=20 > Objet : Re: Default route destination changing without warning=20 > follow-up > > On 01.10.2012 00:00, Dominic Blais wrote: >> Hi, > Hello! >> >> I was just wondering if there was anything new about the bug of default = route changing without warning... Is there any test I can do to help fixin= g it? > Can you be a bit more precise and specify FreeBSD version and address fam= ily? > > Are you sure that it is not changed by some other userland process (e.g. > did you do some `route monitor` checks) ? >> >> -- >> [cid:image001.gif@01CD9F24.B366CBF0] >> >> >> >> >> >> _______________________________________________ >> 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 Sep 30 21:07: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 9DCB4106566B for ; Sun, 30 Sep 2012 21:07:43 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA9E8FC12 for ; Sun, 30 Sep 2012 21:07:43 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TIQn7-0004Up-SV; Mon, 01 Oct 2012 01:11:09 +0400 Message-ID: <5068B48E.2070303@FreeBSD.org> Date: Mon, 01 Oct 2012 01:07:26 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Dominic Blais References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> In-Reply-To: <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 21:07:43 -0000 On 01.10.2012 00:59, Dominic Blais wrote: > It's all about IPv4 in my case. It will be great to supply some more details (e.g. like FreeBSD version, interfaces configuration, netstat -rn output). How often does this happen ? (e.g. while true; do echo -n `date` ; route -n get default | grep gate; sleep 1; done can help) If this is reproducible, what actions precedes this change? Maybe some ARP traffic on that interface, or interface creation/deletion, or.. ? Is route monitor completely silent when the change happens? > > > -- > > > > -----Message d'origine----- > De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] > Envoyé : 30 septembre 2012 16:39 > À : Dominic Blais > Cc : freebsd-net@freebsd.org > Objet : Re: Default route destination changing without warning follow-up > > On 01.10.2012 00:33, Dominic Blais wrote: >> Yes, I'm very sure of it! A "route monitor" show no changes when it happens. I've heard of another person with the same bug that has no traces in "route monitor" either... We have in common that we're using IPFW and PF. > So, are we talking about IPv4 or IPv6? >> >> >> >> -- >> >> >> >> -----Message d'origine----- >> De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] Envoyé : 30 >> septembre 2012 16:31 À : Dominic Blais Cc : freebsd-net@freebsd.org >> Objet : Re: Default route destination changing without warning >> follow-up >> >> On 01.10.2012 00:00, Dominic Blais wrote: >>> Hi, >> Hello! >>> >>> I was just wondering if there was anything new about the bug of default route changing without warning... Is there any test I can do to help fixing it? >> Can you be a bit more precise and specify FreeBSD version and address family? >> >> Are you sure that it is not changed by some other userland process (e.g. >> did you do some `route monitor` checks) ? >>> >>> -- >>> [cid:image001.gif@01CD9F24.B366CBF0] >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Oct 1 11:07: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 E35511065694 for ; Mon, 1 Oct 2012 11:07:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C78C58FC25 for ; Mon, 1 Oct 2012 11:07:23 +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 q91B7NLP025046 for ; Mon, 1 Oct 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q91B7NZv025044 for freebsd-net@FreeBSD.org; Mon, 1 Oct 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Oct 2012 11:07:23 GMT Message-Id: <201210011107.q91B7NZv025044@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:07:24 -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/171697 net [ip6] [ndp] panic when changing routes o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow o kern/171520 net [alc] alc network driver + tso + vlan does not work. 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/170713 net [cxgb] Driver must be loaded after boot due to timing o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/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 418 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 11:30:10 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C35021065672 for ; Mon, 1 Oct 2012 11:30:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A3B7A8FC16 for ; Mon, 1 Oct 2012 11:30:10 +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 q91BUABI046475 for ; Mon, 1 Oct 2012 11:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q91BUAxm046466; Mon, 1 Oct 2012 11:30:10 GMT (envelope-from gnats) Date: Mon, 1 Oct 2012 11:30:10 GMT Message-Id: <201210011130.q91BUAxm046466@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Simonenko Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Simonenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 11:30:10 -0000 The following reply was made to PR bin/131567; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@freebsd.org Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg Date: Mon, 1 Oct 2012 14:20:11 +0300 Updated unix_cmsg: all assert() were removed. Verified correctness of unix_cmsg on 9.1-PRERELEASE and 10-CURRENT. diff -ruNp unix_cmsg.orig/README unix_cmsg/README --- unix_cmsg.orig/README 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/README 2012-10-01 13:47:51.000000000 +0300 @@ -1,7 +1,7 @@ $FreeBSD: src/tools/regression/sockets/unix_cmsg/README,v 1.1 2006/05/29 18:40:55 maxim Exp $ About unix_cmsg -================ +=============== This program is a collection of regression tests for ancillary (control) data for PF_LOCAL sockets (local domain or Unix domain sockets). There @@ -13,8 +13,8 @@ is correct in received message. Sometim messages to Server. It is better to change the owner of unix_cmsg to some safe user -(eg. nobody:nogroup) and set SUID and SGID bits, else some tests -can give correct results for wrong implementation. +(eg. nobody:nogroup) and set SUID and SGID bits, else some tests that +check credentials can give correct results for wrong implementation. Available options ================= @@ -24,13 +24,13 @@ Available options -h Output help message and exit. --t +-t socktype Run tests only for the given socket type: "stream" or "dgram". With this option it is possible to run only particular test, not all of them. -z Do not send real control data if possible. Struct cmsghdr{} - should be followed by real control data. It is not clear if + should be followed by real control data. It is not clear whether a sender should give control data in all cases (this is not documented and an arbitrary application can choose anything). @@ -90,6 +90,13 @@ For SOCK_STREAM sockets: message with data and control message with SCM_TIMESTAMP type followed by struct timeval{}. + 6: Check LOCAL_PEERCRED socket option + + This test does not use control data for PF_LOCAL sockets, but can be + implemented here. Client connects to Server. Both Client and Server + verify that credentials of the peer are correct using LOCAL_PEERCRED + socket option. + For SOCK_DGRAM sockets: ---------------------- @@ -110,7 +117,7 @@ For SOCK_DGRAM sockets: structure should contain correct information. 3: Sending cmsgcred, receiving sockcred - + Server creates datagram socket and set socket option LOCAL_CREDS for it. Client sends one message with data and control message with SOCK_CREDS type to Server. Server should receive one message with @@ -124,4 +131,4 @@ For SOCK_DGRAM sockets: message with SCM_TIMESTAMP type followed by struct timeval{}. - Andrey Simonenko -simon@comsys.ntu-kpi.kiev.ua +andreysimonenko@users.sourceforge.net diff -ruNp unix_cmsg.orig/unix_cmsg.c unix_cmsg/unix_cmsg.c --- unix_cmsg.orig/unix_cmsg.c 2006-05-31 11:10:34.000000000 +0300 +++ unix_cmsg/unix_cmsg.c 2012-10-01 13:49:59.000000000 +0300 @@ -27,27 +27,28 @@ #include __FBSDID("$FreeBSD: src/tools/regression/sockets/unix_cmsg/unix_cmsg.c,v 1.2 2006/05/31 08:10:34 maxim Exp $"); -#include +#include #include #include +#include #include +#include #include #include -#include #include #include #include +#include #include #include -#include #include #include +#include #include #include #include #include -#include #include /* @@ -68,7 +69,7 @@ __FBSDID("$FreeBSD: src/tools/regression * * Each function which can block, is run under TIMEOUT, if timeout * occurs, then test function returns -2 or a client process exits - * with nonzero return code. + * with non-zero return code. */ #ifndef LISTENQ @@ -76,46 +77,88 @@ __FBSDID("$FreeBSD: src/tools/regression #endif #ifndef TIMEOUT -# define TIMEOUT 60 +# define TIMEOUT 5 #endif #define EXTRA_CMSG_SPACE 512 /* Memory for not expected control data. */ -static int t_cmsgcred(void), t_sockcred_stream1(void); -static int t_sockcred_stream2(void), t_cmsgcred_sockcred(void); -static int t_sockcred_dgram(void), t_timestamp(void); +static int t_cmsgcred(void); +static int t_sockcred_stream1(void); +static int t_sockcred_stream2(void); +static int t_cmsgcred_sockcred(void); +static int t_sockcred_dgram(void); +static int t_timestamp(void); +static int t_peercred(void); struct test_func { - int (*func)(void); /* Pointer to function. */ - const char *desc; /* Test description. */ + int (*func)(void); /* Pointer to function. */ + const char *desc; /* Test description. */ }; -static struct test_func test_stream_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_stream1, " 2: Receiving sockcred (listening socket has LOCAL_CREDS)" }, - { t_sockcred_stream2, " 3: Receiving sockcred (accepted socket has LOCAL_CREDS)" }, - { t_cmsgcred_sockcred, " 4: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 5: Sending, receiving timestamp" }, - { NULL, NULL } +static const struct test_func test_stream_tbl[] = { + { + .func = NULL, + .desc = "All tests" + }, + { + .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { + .func = t_sockcred_stream1, + .desc = "Receiving sockcred (listening socket has LOCAL_CREDS)" + }, + { + .func = t_sockcred_stream2, + .desc = "Receiving sockcred (accepted socket has LOCAL_CREDS)" + }, + { + .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { + .func = t_timestamp, + .desc = "Sending, receiving timestamp" + }, + { + .func = t_peercred, + .desc = "Check LOCAL_PEERCRED socket option" + } }; -static struct test_func test_dgram_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_dgram, " 2: Receiving sockcred" }, - { t_cmsgcred_sockcred, " 3: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 4: Sending, receiving timestamp" }, - { NULL, NULL } +#define TEST_STREAM_TBL_SIZE \ + (sizeof(test_stream_tbl) / sizeof(test_stream_tbl[0])) + +static const struct test_func test_dgram_tbl[] = { + { + .func = NULL, + .desc = "All tests" + }, + { + .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { + .func = t_sockcred_dgram, + .desc = "Receiving sockcred" + }, + { + .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { + .func = t_timestamp, + .desc = "Sending, receiving timestamp" + } }; -#define TEST_STREAM_NO_MAX (sizeof(test_stream_tbl) / sizeof(struct test_func) - 2) -#define TEST_DGRAM_NO_MAX (sizeof(test_dgram_tbl) / sizeof(struct test_func) - 2) +#define TEST_DGRAM_TBL_SIZE \ + (sizeof(test_dgram_tbl) / sizeof(test_dgram_tbl[0])) -static const char *myname = "SERVER"; /* "SERVER" or "CLIENT" */ +static const char *myname; /* "SERVER" or "CLIENT" */ -static int debug = 0; /* 1, if -d. */ -static int no_control_data = 0; /* 1, if -z. */ +static bool debug = false; /* -d */ +static bool no_control_data = false;/* -z */ static u_int nfailed = 0; /* Number of failed tests. */ @@ -131,17 +174,11 @@ static char ipc_message[] = "hello"; static struct sockaddr_un servaddr; /* Server address. */ -static sigjmp_buf env_alrm; - static uid_t my_uid; static uid_t my_euid; static gid_t my_gid; static gid_t my_egid; -/* - * my_gids[0] is EGID, next items are supplementary GIDs, - * my_ngids determines valid items in my_gids array. - */ static gid_t my_gids[NGROUPS_MAX]; static int my_ngids; @@ -150,38 +187,35 @@ static pid_t client_pid; /* PID of fork #define dbgmsg(x) do { \ if (debug) \ logmsgx x ; \ -} while (/* CONSTCOND */0) +} while (0) static void logmsg(const char *, ...) __printflike(1, 2); static void logmsgx(const char *, ...) __printflike(1, 2); static void output(const char *, ...) __printflike(1, 2); -extern char *__progname; /* The name of program. */ - /* * Output the help message (-h switch). */ static void -usage(int quick) +usage(bool verbose) { - const struct test_func *test_func; + u_int i; - fprintf(stderr, "Usage: %s [-dhz] [-t ] [testno]\n", - __progname); - if (quick) + fprintf(stderr, "usage: %s [-dhz] [-t socktype] [testno]\n", + getprogname()); + if (!verbose) return; fprintf(stderr, "\n Options are:\n\ -d\t\t\tOutput debugging information\n\ -h\t\t\tOutput this help message and exit\n\ - -t \t\tRun test only for the given socket type:\n\ -\t\t\tstream or dgram\n\ + -t socktype\t\tRun test only for socket type: stream or dgram\n\ -z\t\t\tDo not send real control data if possible\n\n"); fprintf(stderr, " Available tests for stream sockets:\n"); - for (test_func = test_stream_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_STREAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_stream_tbl[i].desc); fprintf(stderr, "\n Available tests for datagram sockets:\n"); - for (test_func = test_dgram_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_DGRAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_dgram_tbl[i].desc); } /* @@ -195,7 +229,7 @@ output(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "output: vsnprintf failed"); + err(EXIT_FAILURE, "output: vsnprintf failed"); write(STDOUT_FILENO, buf, strlen(buf)); va_end(ap); } @@ -210,18 +244,16 @@ logmsg(const char *format, ...) va_list ap; int errno_save; - errno_save = errno; /* Save errno. */ - + errno_save = errno; va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsg: vsnprintf failed"); + err(EXIT_FAILURE, "logmsg: vsnprintf failed"); if (errno_save == 0) output("%s: %s\n", myname, buf); else output("%s: %s: %s\n", myname, buf, strerror(errno_save)); va_end(ap); - - errno = errno_save; /* Restore errno. */ + errno = errno_save; } /* @@ -235,33 +267,47 @@ logmsgx(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsgx: vsnprintf failed"); + err(EXIT_FAILURE, "logmsgx: vsnprintf failed"); output("%s: %s\n", myname, buf); va_end(ap); } /* - * Run tests from testno1 to testno2. + * Run tests for the given socket type. */ static int -run_tests(u_int testno1, u_int testno2) +run_tests(int type, u_int testno1) { - const struct test_func *test_func; - u_int i, nfailed1; + const struct test_func *tf; + u_int i, nfailed1, testno2; - output("Running tests for %s sockets:\n", sock_type_str); - test_func = (sock_type == SOCK_STREAM ? - test_stream_tbl : test_dgram_tbl) + testno1; + sock_type = type; + if (type == SOCK_STREAM) { + sock_type_str = "SOCK_STREAM"; + tf = test_stream_tbl; + i = TEST_STREAM_TBL_SIZE - 1; + } else { + sock_type_str = "SOCK_DGRAM"; + tf = test_dgram_tbl; + i = TEST_DGRAM_TBL_SIZE - 1; + } + if (testno1 == 0) { + testno1 = 1; + testno2 = i; + } else + testno2 = testno1; + output("Running tests for %s sockets:\n", sock_type_str); nfailed1 = 0; - for (i = testno1; i <= testno2; ++test_func, ++i) { - output(" %s\n", test_func->desc); - switch (test_func->func()) { + for (i = testno1, tf += testno1; i <= testno2; ++tf, ++i) { + output(" %u: %s\n", i, tf->desc); + switch (tf->func()) { case -1: ++nfailed1; break; case -2: - logmsgx("some system error occurred, exiting"); + logmsgx("some system error or timeout occurred, " + "exiting"); return (-1); } } @@ -284,181 +330,222 @@ run_tests(u_int testno1, u_int testno2) return (0); } -/* ARGSUSED */ +/* + * Initialize signals handlers. + */ static void -sig_alrm(int signo __unused) +sig_init(void) { - siglongjmp(env_alrm, 1); + struct sigaction sigact; + + sigact.sa_handler = SIG_IGN; + sigact.sa_flags = 0; + sigemptyset(&sigact.sa_mask); + if (sigaction(SIGPIPE, &sigact, (struct sigaction *)NULL) < 0) + err(EXIT_FAILURE, "sigaction(SIGPIPE)"); } /* - * Initialize signals handlers. + * Output this process UID, GID, groups from getgroups(), EUID and EGID. */ static void -sig_init(void) +show_my_id(void) { - struct sigaction sa; + int i; - sa.sa_handler = SIG_IGN; - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - if (sigaction(SIGPIPE, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGPIPE)"); - - sa.sa_handler = sig_alrm; - if (sigaction(SIGALRM, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGALRM)"); + if (!debug) + return; + logmsgx("UID %lu, GID %lu, groups from getgroups():", + (u_long)my_uid, (u_long)my_gid); + for (i = 0; i < my_ngids; ++i) + logmsgx(" GID %lu", (u_long)my_gids[i]); + logmsgx("EUID %lu, EGID %lu", (u_long)my_euid, (u_long)my_egid); +} + +static int +fork_client(void) +{ + client_pid = fork(); + if (client_pid == 0) + myname = "CLIENT"; + else if (client_pid == (pid_t)-1) { + logmsg("fork"); + return (-1); + } + return (0); } int main(int argc, char *argv[]) { const char *errstr; - int opt, dgramflag, streamflag; - u_int testno1, testno2; + u_int testno; + int opt, rv; + bool dgramflag, streamflag; - dgramflag = streamflag = 0; + dgramflag = streamflag = false; while ((opt = getopt(argc, argv, "dht:z")) != -1) switch (opt) { case 'd': - debug = 1; + debug = true; break; case 'h': - usage(0); - return (EX_OK); + usage(true); + return (EXIT_SUCCESS); case 't': if (strcmp(optarg, "stream") == 0) - streamflag = 1; + streamflag = true; else if (strcmp(optarg, "dgram") == 0) - dgramflag = 1; + dgramflag = true; else - errx(EX_USAGE, "wrong socket type in -t option"); + errx(EXIT_FAILURE, "option -t: " + "wrong socket type"); break; case 'z': - no_control_data = 1; + no_control_data = true; break; case '?': default: - usage(1); - return (EX_USAGE); + usage(false); + return (EXIT_FAILURE); } if (optind < argc) { if (optind + 1 != argc) - errx(EX_USAGE, "too many arguments"); - testno1 = strtonum(argv[optind], 0, UINT_MAX, &errstr); + errx(EXIT_FAILURE, "too many arguments"); + testno = strtonum(argv[optind], 0, UINT_MAX, &errstr); if (errstr != NULL) - errx(EX_USAGE, "wrong test number: %s", errstr); + errx(EXIT_FAILURE, "wrong test number: %s", errstr); } else - testno1 = 0; + testno = 0; - if (dgramflag == 0 && streamflag == 0) - dgramflag = streamflag = 1; + if (!dgramflag && !streamflag) + dgramflag = streamflag = true; - if (dgramflag && streamflag && testno1 != 0) - errx(EX_USAGE, "you can use particular test, only with datagram or stream sockets"); + if (dgramflag && streamflag && testno != 0) + errx(EXIT_FAILURE, "you can use particular test, only " + "with datagram or stream sockets"); if (streamflag) { - if (testno1 > TEST_STREAM_NO_MAX) - errx(EX_USAGE, "given test %u for stream sockets does not exist", - testno1); + if (testno >= TEST_STREAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for stream " + "sockets does not exist", testno); } else { - if (testno1 > TEST_DGRAM_NO_MAX) - errx(EX_USAGE, "given test %u for datagram sockets does not exist", - testno1); + if (testno >= TEST_DGRAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for datagram " + "sockets does not exist", testno); } my_uid = getuid(); my_euid = geteuid(); my_gid = getgid(); my_egid = getegid(); - switch (my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids)) { + my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids); + switch (my_ngids) { case -1: - err(EX_SOFTWARE, "getgroups"); + err(EXIT_FAILURE, "getgroups"); /* NOTREACHED */ case 0: - errx(EX_OSERR, "getgroups returned 0 groups"); + errx(EXIT_FAILURE, "getgroups returned no groups"); } sig_init(); if (mkdtemp(tempdir) == NULL) - err(EX_OSERR, "mkdtemp"); + err(EXIT_FAILURE, "mkdtemp"); - if (streamflag) { - sock_type = SOCK_STREAM; - sock_type_str = "SOCK_STREAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_STREAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - testno1 = 0; - } - - if (dgramflag) { - sock_type = SOCK_DGRAM; - sock_type_str = "SOCK_DGRAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_DGRAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - } + myname = "SERVER"; + rv = EXIT_SUCCESS; + show_my_id(); + if (streamflag) + if (run_tests(SOCK_STREAM, testno) < 0) + rv = EXIT_FAILURE; + if (dgramflag && rv == EXIT_SUCCESS) + if (run_tests(SOCK_DGRAM, testno) < 0) + rv = EXIT_FAILURE; if (rmdir(tempdir) < 0) { logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); + rv = EXIT_FAILURE; } - return (nfailed ? EX_OSERR : EX_OK); + return (nfailed > 0 ? EXIT_FAILURE : rv); +} -failed: - if (rmdir(tempdir) < 0) - logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); +/* + * Close socket descriptor, if sock_path is not equal to NULL, + * then unlink the given path. + */ +static int +close_socket(const char *sock_path, int fd) +{ + int rv; + + if (close(fd) < 0) { + logmsg("close_socket: close"); + rv = -1; + } else + rv = 0; + if (sock_path != NULL) + if (unlink(sock_path) < 0) { + logmsg("close_socket: unlink(%s)", sock_path); + rv = -1; + } + return (rv); } /* * Create PF_LOCAL socket, if sock_path is not equal to NULL, then - * bind() it. Return socket address in addr. Return file descriptor + * bind() it. Return socket address in *un. Return file descriptor * or -1 if some error occurred. */ static int -create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *addr) +create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *un) { - int rv, fd; + struct timeval tv; + int fd; - if ((fd = socket(PF_LOCAL, sock_type, 0)) < 0) { - logmsg("create_socket: socket(PF_LOCAL, %s, 0)", sock_type_str); + fd = socket(PF_LOCAL, sock_type, 0); + if (fd < 0) { + logmsg("create_socket: socket(PF_LOCAL, %s, 0)", + sock_type_str); return (-1); } + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) < 0 || + setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv)) < 0) { + logmsg("create_socket: setsockopt(SO_RCVTIMEO/SO_SNDTIMEO)"); + goto failed; + } + if (sock_path != NULL) { - if ((rv = snprintf(sock_path, sock_path_len, "%s/%s", - tempdir, myname)) < 0) { + int rv; + + rv = snprintf(sock_path, sock_path_len, "%s/%s", tempdir, + myname); + if (rv < 0) { logmsg("create_socket: snprintf failed"); goto failed; } if ((size_t)rv >= sock_path_len) { - logmsgx("create_socket: too long path name for given buffer"); + logmsgx("create_socket: too long path name for " + "given buffer"); goto failed; } - - memset(addr, 0, sizeof(addr)); - addr->sun_family = AF_LOCAL; - if (strlen(sock_path) >= sizeof(addr->sun_path)) { - logmsgx("create_socket: too long path name (>= %lu) for local domain socket", - (u_long)sizeof(addr->sun_path)); + if (strlen(sock_path) >= sizeof(un->sun_path)) { + logmsgx("create_socket: too long path name (>= %zu) " + "for local domain socket", sizeof(un->sun_path)); goto failed; } - strcpy(addr->sun_path, sock_path); - if (bind(fd, (struct sockaddr *)addr, SUN_LEN(addr)) < 0) { + memset(un, 0, sizeof(un)); + un->sun_family = PF_LOCAL; + strcpy(un->sun_path, sock_path); + un->sun_len = SUN_LEN(un); + + if (bind(fd, (struct sockaddr *)un, un->sun_len) < 0) { logmsg("create_socket: bind(%s)", sock_path); goto failed; } @@ -473,43 +560,49 @@ failed: } /* - * Call create_socket() for server listening socket. - * Return socket descriptor or -1 if some error occurred. + * Create server socket. */ static int create_server_socket(void) { - return (create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr)); -} + int fd; -/* - * Create unbound socket. - */ -static int -create_unbound_socket(void) -{ - return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); + fd = create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr); + if (fd < 0) + return (-1); + + if (sock_type == SOCK_STREAM) { + int val; + + if (listen(fd, LISTENQ) < 0) { + logmsg("create_server_socket: listen"); + goto failed; + } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("create_server_socket: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val | O_NONBLOCK) < 0) { + logmsg("create_server_socket: fcntl(F_SETFL)"); + goto failed; + } + } + + return (fd); + +failed: + (void)close_socket(serv_sock_path, fd); + return (-1); } /* - * Close socket descriptor, if sock_path is not equal to NULL, - * then unlink the given path. + * Create client socket. */ static int -close_socket(const char *sock_path, int fd) +create_client_socket(void) { - int error = 0; - - if (close(fd) < 0) { - logmsg("close_socket: close"); - error = -1; - } - if (sock_path != NULL) - if (unlink(sock_path) < 0) { - logmsg("close_socket: unlink(%s)", sock_path); - error = -1; - } - return (error); + return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); } /* @@ -524,7 +617,7 @@ connect_server(int fd) * If PF_LOCAL listening socket's queue is full, then connect() * returns ECONNREFUSED immediately, do not need timeout. */ - if (connect(fd, (struct sockaddr *)&servaddr, sizeof(servaddr)) < 0) { + if (connect(fd, (struct sockaddr *)&servaddr, servaddr.sun_len) < 0) { logmsg("connect_server: connect(%s)", serv_sock_path); return (-1); } @@ -533,34 +626,23 @@ connect_server(int fd) } /* - * sendmsg() with timeout. + * sendmsg() wrapper. */ static int -sendmsg_timeout(int fd, struct msghdr *msg, size_t n) +send_message(int fd, const struct msghdr *msg, size_t n) { ssize_t nsent; - dbgmsg(("sending %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sendmsg_timeout: cannot send message to %s (timeout)", serv_sock_path); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("sending %zu bytes", n)); nsent = sendmsg(fd, msg, 0); - - (void)alarm(0); - if (nsent < 0) { - logmsg("sendmsg_timeout: sendmsg"); + logmsg("send_message: sendmsg"); return (-1); } - if ((size_t)nsent != n) { - logmsgx("sendmsg_timeout: sendmsg: short send: %ld of %lu bytes", - (long)nsent, (u_long)n); + logmsgx("send_message: sendmsg: short send: " + "%zd of %zu bytes", nsent, n); return (-1); } @@ -568,63 +650,73 @@ sendmsg_timeout(int fd, struct msghdr *m } /* - * accept() with timeout. + * accept() wrapper. */ static int -accept_timeout(int listenfd) +accept_connection(int listenfd) { - int fd; + fd_set rset; + struct timeval tv; + int fd, rv, val; dbgmsg(("accepting connection")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("accept_timeout: cannot accept connection (timeout)"); + FD_ZERO(&rset); + FD_SET(listenfd, &rset); + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + rv = select(listenfd + 1, &rset, (fd_set *)NULL, (fd_set *)NULL, &tv); + if (rv < 0) { + logmsg("accept_connection: select"); + return (-1); + } + if (rv == 0) { + logmsgx("accept_connection: select timeout"); return (-1); } - - (void)alarm(TIMEOUT); fd = accept(listenfd, (struct sockaddr *)NULL, (socklen_t *)NULL); - - (void)alarm(0); - if (fd < 0) { - logmsg("accept_timeout: accept"); + logmsg("accept_connection: accept"); return (-1); } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("accept_connection: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val & ~O_NONBLOCK) < 0) { + logmsg("accept_connection: fcntl(F_SETFL)"); + goto failed; + } + return (fd); + +failed: + if (close(fd) < 0) + logmsg("accept_connection: close"); + return (-1); } /* - * recvmsg() with timeout. + * recvmsg() wrapper. */ static int -recvmsg_timeout(int fd, struct msghdr *msg, size_t n) +recv_message(int fd, struct msghdr *msg, size_t n) { ssize_t nread; - dbgmsg(("receiving %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("recvmsg_timeout: cannot receive message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("receiving %zu bytes", n)); nread = recvmsg(fd, msg, MSG_WAITALL); - - (void)alarm(0); - if (nread < 0) { - logmsg("recvmsg_timeout: recvmsg"); + logmsg("recv_message: recvmsg"); return (-1); } - if ((size_t)nread != n) { - logmsgx("recvmsg_timeout: recvmsg: short read: %ld of %lu bytes", - (long)nread, (u_long)n); + logmsgx("recv_message: recvmsg: short read: " + "%zd of %zu bytes", nread, n); return (-1); } @@ -632,7 +724,7 @@ recvmsg_timeout(int fd, struct msghdr *m } /* - * Wait for synchronization message (1 byte) with timeout. + * Wait for synchronization message (1 byte). */ static int sync_recv(int fd) @@ -642,25 +734,13 @@ sync_recv(int fd) dbgmsg(("waiting for sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_recv: cannot receive sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nread = read(fd, &buf, 1); - - (void)alarm(0); - if (nread < 0) { logmsg("sync_recv: read"); return (-1); } - if (nread != 1) { - logmsgx("sync_recv: read: short read: %ld of 1 byte", - (long)nread); + logmsgx("sync_recv: read: short read: %zd of 1 byte", nread); return (-1); } @@ -668,7 +748,7 @@ sync_recv(int fd) } /* - * Send synchronization message (1 byte) with timeout. + * Send synchronization message (1 byte). */ static int sync_send(int fd) @@ -677,25 +757,13 @@ sync_send(int fd) dbgmsg(("sending sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_send: cannot send sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nsent = write(fd, "", 1); - - (void)alarm(0); - if (nsent < 0) { logmsg("sync_send: write"); return (-1); } - if (nsent != 1) { - logmsgx("sync_send: write: short write: %ld of 1 byte", - (long)nsent); + logmsgx("sync_send: write: short write: %zd of 1 byte", nsent); return (-1); } @@ -711,36 +779,29 @@ wait_client(void) int status; pid_t pid; - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("wait_client: cannot get exit status of client PID %ld (timeout)", - (long)client_pid); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("waiting for a client")); pid = waitpid(client_pid, &status, 0); - - (void)alarm(0); - if (pid == (pid_t)-1) { logmsg("wait_client: waitpid"); return (-1); } if (WIFEXITED(status)) { - if (WEXITSTATUS(status) != 0) { - logmsgx("wait_client: exit status of client PID %ld is %d", - (long)client_pid, WEXITSTATUS(status)); + if (WEXITSTATUS(status) != EXIT_SUCCESS) { + logmsgx("wait_client: exit status of client PID %ld " + "is %d", (long)client_pid, WEXITSTATUS(status)); return (-1); } } else { if (WIFSIGNALED(status)) - logmsgx("wait_client: abnormal termination of client PID %ld, signal %d%s", - (long)client_pid, WTERMSIG(status), WCOREDUMP(status) ? " (core file generated)" : ""); + logmsgx("wait_client: abnormal termination of client " + "PID %ld, signal %d%s", (long)client_pid, + WTERMSIG(status), WCOREDUMP(status) ? + " (core file generated)" : ""); else - logmsgx("wait_client: termination of client PID %ld, unknown status", - (long)client_pid); + logmsgx("wait_client: termination of client PID %ld, " + "unknown status", (long)client_pid); return (-1); } @@ -748,28 +809,27 @@ wait_client(void) } /* - * Check if n supplementary GIDs in gids are correct. (my_gids + 1) - * has (my_ngids - 1) supplementary GIDs of current process. + * Check whether n GIDs in gids are correct. */ static int check_groups(const gid_t *gids, int n) { + int i, j, rv; char match[NGROUPS_MAX] = { 0 }; - int error, i, j; - if (n != my_ngids - 1) { - logmsgx("wrong number of groups %d != %d (returned from getgroups() - 1)", - n, my_ngids - 1); - error = -1; + if (n != my_ngids) { + logmsgx("wrong number of groups %d != %d (returned from " + "getgroups())", n, my_ngids); + rv = -1; } else - error = 0; + rv = 0; for (i = 0; i < n; ++i) { - for (j = 1; j < my_ngids; ++j) { + for (j = 0; j < my_ngids; ++j) { if (gids[i] == my_gids[j]) { if (match[j]) { logmsgx("duplicated GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } else match[j] = 1; break; @@ -777,15 +837,15 @@ check_groups(const gid_t *gids, int n) } if (j == my_ngids) { logmsgx("unexpected GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } } - for (j = 1; j < my_ngids; ++j) + for (j = 0; j < my_ngids; ++j) if (match[j] == 0) { - logmsgx("did not receive supplementary GID %u", my_gids[j]); - error = -1; + logmsgx("did not receive GID %lu", (u_long)my_gids[j]); + rv = -1; } - return (error); + return (rv); } /* @@ -802,16 +862,17 @@ t_cmsgcred_client(u_int n) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; u_int i; + int fd, rv; - assert(n == 1 || n == 2); + rv = EXIT_FAILURE; - if ((fd = create_unbound_socket()) < 0) + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -834,20 +895,16 @@ t_cmsgcred_client(u_int n) for (i = 0; i < n; ++i) { dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; } - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); - + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd)) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -858,28 +915,27 @@ failed: static int t_cmsgcred_server(int fd1) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct cmsgcred)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct cmsgcred)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - const struct cmsgcred *cmcredptr; - socklen_t controllen; - int error, error2, fd2; + const struct cmsgcred *cmcred; u_int i; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; - error = 0; - - controllen = sizeof(control_un.control); + rv = 0; for (i = 0; i < 2; ++i) { iov[0].iov_base = buf; @@ -890,29 +946,31 @@ t_cmsgcred_server(int fd1) msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = controllen; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - controllen = CMSG_SPACE(sizeof(struct cmsgcred)); - - if (recvmsg_timeout(fd2, &msg, sizeof(buf)) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("#%u control data was truncated, MSG_CTRUNC flag is on", - i); - goto next_error; + logmsgx("#%u control data was truncated, MSG_CTRUNC " + "flag is on", i); + goto next; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, @@ -921,142 +979,120 @@ t_cmsgcred_server(int fd1) if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct cmsgcred))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(sizeof(struct cmsgcred))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct cmsgcred))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(sizeof(struct cmsgcred))", i, + (u_int)cmptr->cmsg_len, + CMSG_LEN(sizeof(struct cmsgcred))); + goto next; } - cmcredptr = (const struct cmsgcred *)CMSG_DATA(cmptr); + cmcred = (struct cmsgcred *)CMSG_DATA(cmptr); - error2 = 0; - if (cmcredptr->cmcred_pid != client_pid) { + if (cmcred->cmcred_pid != client_pid) { logmsgx("#%u cmcred_pid %ld != %ld (PID of client)", - i, (long)cmcredptr->cmcred_pid, (long)client_pid); - error2 = 1; + i, (long)cmcred->cmcred_pid, (long)client_pid); + goto next; } - if (cmcredptr->cmcred_uid != my_uid) { - logmsgx("#%u cmcred_uid %lu != %lu (UID of current process)", - i, (u_long)cmcredptr->cmcred_uid, (u_long)my_uid); - error2 = 1; - } - if (cmcredptr->cmcred_euid != my_euid) { - logmsgx("#%u cmcred_euid %lu != %lu (EUID of current process)", - i, (u_long)cmcredptr->cmcred_euid, (u_long)my_euid); - error2 = 1; - } - if (cmcredptr->cmcred_gid != my_gid) { - logmsgx("#%u cmcred_gid %lu != %lu (GID of current process)", - i, (u_long)cmcredptr->cmcred_gid, (u_long)my_gid); - error2 = 1; + if (cmcred->cmcred_uid != my_uid) { + logmsgx("#%u cmcred_uid %lu != %lu (UID of current " + "process)", i, (u_long)cmcred->cmcred_uid, + (u_long)my_uid); + goto next; + } + if (cmcred->cmcred_euid != my_euid) { + logmsgx("#%u cmcred_euid %lu != %lu (EUID of current " + "process)", i, (u_long)cmcred->cmcred_euid, + (u_long)my_euid); + goto next; + } + if (cmcred->cmcred_gid != my_gid) { + logmsgx("#%u cmcred_gid %lu != %lu (GID of current " + "process)", i, (u_long)cmcred->cmcred_gid, + (u_long)my_gid); + goto next; } - if (cmcredptr->cmcred_ngroups == 0) { + if (cmcred->cmcred_ngroups == 0) { logmsgx("#%u cmcred_ngroups = 0, this is wrong", i); - error2 = 1; - } else { - if (cmcredptr->cmcred_ngroups > NGROUPS_MAX) { - logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", - i, cmcredptr->cmcred_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (cmcredptr->cmcred_ngroups < 0) { - logmsgx("#%u cmcred_ngroups %d < 0", - i, cmcredptr->cmcred_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u cmcred_ngroups = %d", i, - cmcredptr->cmcred_ngroups)); - if (cmcredptr->cmcred_groups[0] != my_egid) { - logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of current process)", - i, (u_long)cmcredptr->cmcred_groups[0], (u_long)my_egid); - error2 = 1; - } - if (check_groups(cmcredptr->cmcred_groups + 1, cmcredptr->cmcred_ngroups - 1) < 0) { - logmsgx("#%u cmcred_groups has wrong GIDs", i); - error2 = 1; - } - } + goto next; } - - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header", i); - goto next_error; + if (cmcred->cmcred_ngroups < 0) { + logmsgx("#%u cmcred_ngroups %d < 0", + i, cmcred->cmcred_ngroups); + goto next; + } + if (cmcred->cmcred_ngroups > NGROUPS_MAX) { + logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", + i, cmcred->cmcred_ngroups, NGROUPS_MAX); + goto next; + } + + dbgmsg(("#%u cmcred_ngroups = %d", i, cmcred->cmcred_ngroups)); + if (cmcred->cmcred_groups[0] != my_egid) { + logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of " + "current process)", i, + (u_long)cmcred->cmcred_groups[0], (u_long)my_egid); + goto next; + } + if (check_groups(cmcred->cmcred_groups, + cmcred->cmcred_ngroups) < 0) { + logmsgx("#%u cmcred_groups has wrong GIDs", i); + goto next; + } + + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, " + "this is wrong", i); + goto next; } - continue; -next_error: - error = -1; +next: + rv = -1; } if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_cmsgcred(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_cmsgcred_client(2); } - if ((error = t_cmsgcred_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_cmsgcred_server(fd); if (wait_client() < 0) - goto failed; - - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1067,20 +1103,21 @@ t_sockcred_client(int type) { struct msghdr msg; struct iovec iov[1]; - int fd; u_int i; + int fd, rv; - assert(type == 0 || type == 1); + rv = EXIT_FAILURE; - if ((fd = create_unbound_socket()) < 0) + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; if (type == 1) if (sync_recv(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1094,19 +1131,15 @@ t_sockcred_client(int type) msg.msg_flags = 0; for (i = 0; i < 2; ++i) - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1119,232 +1152,217 @@ failed: static int t_sockcred_server(int type, int fd1, u_int n) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct sockcred *sockcred; - int error, error2, fd2, optval; u_int i; + int fd2, rv, optval; + char buf[IPC_MESSAGE_SIZE]; - assert(n == 1 || n == 2); - assert(type == 0 || type == 1); + rv = -2; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); if (type == 1) { optval = 1; - if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for accepted socket"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for accepted " + "socket"); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } if (sync_send(fd2) < 0) - goto failed; + goto done; } } else fd2 = fd1; - error = 0; + rv = 0; for (i = 0; i < n; ++i) { iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("control data was truncated, MSG_CTRUNC flag is on"); - goto next_error; + logmsgx("control data was truncated, MSG_CTRUNC flag " + "is on"); + goto next; } + dbgmsg(("#%u msg_controllen = %u", i, + (u_int)msg.msg_controllen)); + if (i != 0 && sock_type == SOCK_STREAM) { if (msg.msg_controllen != 0) { - logmsgx("second message has control data, this is wrong for stream sockets"); - goto next_error; + logmsgx("second message has control data, " + "this is wrong for stream sockets"); + goto next; } - dbgmsg(("#%u msg_controllen = %u", i, - (u_int)msg.msg_controllen)); continue; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } - dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, - (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); + dbgmsg(("#%u cmsg_len = %u", i, (u_int)cmptr->cmsg_len)); if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len < CMSG_LEN(SOCKCREDSIZE(1))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(SOCKCREDSIZE(1)))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(SOCKCREDSIZE(1))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(SOCKCREDSIZE(1)))", i, + (u_int)cmptr->cmsg_len, CMSG_LEN(SOCKCREDSIZE(1))); + goto next; } - sockcred = (const struct sockcred *)CMSG_DATA(cmptr); + sockcred = (struct sockcred *)CMSG_DATA(cmptr); - error2 = 0; if (sockcred->sc_uid != my_uid) { - logmsgx("#%u sc_uid %lu != %lu (UID of current process)", - i, (u_long)sockcred->sc_uid, (u_long)my_uid); - error2 = 1; + logmsgx("#%u sc_uid %lu != %lu (UID of current " + "process)", i, (u_long)sockcred->sc_uid, + (u_long)my_uid); + goto next; } if (sockcred->sc_euid != my_euid) { - logmsgx("#%u sc_euid %lu != %lu (EUID of current process)", - i, (u_long)sockcred->sc_euid, (u_long)my_euid); - error2 = 1; + logmsgx("#%u sc_euid %lu != %lu (EUID of current " + "process)", i, (u_long)sockcred->sc_euid, + (u_long)my_euid); + goto next; } if (sockcred->sc_gid != my_gid) { - logmsgx("#%u sc_gid %lu != %lu (GID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_gid); - error2 = 1; + logmsgx("#%u sc_gid %lu != %lu (GID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_gid); + goto next; } if (sockcred->sc_egid != my_egid) { - logmsgx("#%u sc_egid %lu != %lu (EGID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_egid); - error2 = 1; + logmsgx("#%u sc_egid %lu != %lu (EGID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_egid); + goto next; + } + if (sockcred->sc_ngroups == 0) { + logmsgx("#%u sc_ngroups %d = 0, this is wrong", + i, sockcred->sc_ngroups); + goto next; + } + if (sockcred->sc_ngroups < 0) { + logmsgx("#%u sc_ngroups %d < 0", + i, sockcred->sc_ngroups); + goto next; } if (sockcred->sc_ngroups > NGROUPS_MAX) { logmsgx("#%u sc_ngroups %d > %u (NGROUPS_MAX)", i, sockcred->sc_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (sockcred->sc_ngroups < 0) { - logmsgx("#%u sc_ngroups %d < 0", - i, sockcred->sc_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); - if (check_groups(sockcred->sc_groups, sockcred->sc_ngroups) < 0) { - logmsgx("#%u sc_groups has wrong GIDs", i); - error2 = 1; - } + goto next; } - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header, this is wrong", - i); - goto next_error; + dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); + if (check_groups(sockcred->sc_groups, + sockcred->sc_ngroups) < 0) { + logmsgx("#%u sc_groups has wrong GIDs", i); + goto next; } + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, " + "this is wrong", i); + goto next; + } continue; -next_error: - error = -1; +next: + rv = -1; } - -done_close: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: +done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_sockcred(int type) { - int error, fd, optval; + int fd, rv, optval; - assert(type == 0 || type == 1); - - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; if (type == 0) { optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_sockcred_client(type); } - if ((error = t_sockcred_server(type, fd, 2)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(type, fd, 2); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } static int @@ -1368,59 +1386,39 @@ t_sockcred_dgram(void) static int t_cmsgcred_sockcred(void) { - int error, fd, optval; + int fd, rv, optval; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for %s socket", sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_cmsgcred_client(1); } - if ((error = t_sockcred_server(0, fd, 1)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(0, fd, 1); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1437,13 +1435,16 @@ t_timestamp_client(void) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; + int fd, rv; + + rv = EXIT_FAILURE; - if ((fd = create_unbound_socket()) < 0) + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1454,7 +1455,7 @@ t_timestamp_client(void) msg.msg_iovlen = 1; msg.msg_control = control_un.control; msg.msg_controllen = no_control_data ? - sizeof(struct cmsghdr) :sizeof control_un.control; + sizeof(struct cmsghdr) : sizeof(control_un.control); msg.msg_flags = 0; cmptr = CMSG_FIRSTHDR(&msg); @@ -1466,19 +1467,15 @@ t_timestamp_client(void) dbgmsg(("msg_controllen = %u, cmsg_len = %u", (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1490,36 +1487,40 @@ t_timestamp_server(int fd1) { union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct timeval)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct timeval)) + + EXTRA_CMSG_SPACE]; } control_un; - char buf[IPC_MESSAGE_SIZE]; - int error, fd2; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct timeval *timeval; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control;; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + goto done; + } - error = -1; + rv = -1; if (msg.msg_flags & MSG_CTRUNC) { logmsgx("control data was truncated, MSG_CTRUNC flag is on"); @@ -1527,12 +1528,13 @@ t_timestamp_server(int fd1) } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("msg_controllen %u < %lu (sizeof(struct cmsghdr))", - (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); + logmsgx("msg_controllen %u < %zu (sizeof(struct cmsghdr))", + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); goto done; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); goto done; } @@ -1551,80 +1553,202 @@ t_timestamp_server(int fd1) } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct timeval))) { - logmsgx("cmsg_len %u != %lu (CMSG_LEN(sizeof(struct timeval))", - (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct timeval))); + logmsgx("cmsg_len %u != %zu (CMSG_LEN(sizeof(struct timeval))", + (u_int)cmptr->cmsg_len, CMSG_LEN(sizeof(struct timeval))); goto done; } - timeval = (const struct timeval *)CMSG_DATA(cmptr); + timeval = (struct timeval *)CMSG_DATA(cmptr); - dbgmsg(("timeval tv_sec %jd, tv_usec %jd", + dbgmsg(("timeval tv_sec %"PRIdMAX", tv_usec %"PRIdMAX, (intmax_t)timeval->tv_sec, (intmax_t)timeval->tv_usec)); - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("control data has extra header"); + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("control data has extra header, this is wrong"); goto done; } - error = 0; - + rv = 0; done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_timestamp(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_timestamp_client(); } - if ((error = t_timestamp_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_timestamp_server(fd); if (wait_client() < 0) + rv = -2; +done: + if (close_socket(serv_sock_path, fd) < 0) + rv = -2; + return (rv); +} + +/* + * Verify that xucred structure has correct credentials. + */ +static int +check_xucred(const struct xucred *xucred, socklen_t len) +{ + if (len != sizeof(*xucred)) { + logmsgx("option value size %zu != %zu (sizeof(struct xucred))", + (size_t)len, sizeof(*xucred)); + return (-1); + } + if (xucred->cr_version != XUCRED_VERSION) { + logmsgx("cr_version %u != %d (XUCRED_VERSION)", + xucred->cr_version, XUCRED_VERSION); + return (-1); + } + if (xucred->cr_uid != my_euid) { + logmsgx("cr_uid %lu != %lu (EUID of current process)", + (u_long)xucred->cr_uid, (u_long)my_euid); + return (-1); + } + if (xucred->cr_ngroups == 0) { + logmsgx("cr_ngroups = 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups < 0) { + logmsgx("cr_ngroups < 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups > NGROUPS_MAX) { + logmsgx("cr_ngroups %hu > %u (NGROUPS_MAX)", + xucred->cr_ngroups, NGROUPS_MAX); + return (-1); + } + if (xucred->cr_groups[0] != my_egid) { + logmsgx("cr_groups[0] %lu != %lu (EGID of current process)", + (u_long)xucred->cr_groups[0], (u_long)my_egid); + return (-1); + } + if (check_groups(xucred->cr_groups, xucred->cr_ngroups) < 0) { + logmsgx("cr_groups has wrong GIDs"); + return (-1); + } + return (0); +} + +/* + * Connect to server and set LOCAL_PEERCRED socket option for connected + * socket. Verify that credentials of the peer are correct. + */ +static void +t_peercred_client(void) +{ + struct xucred xucred; + socklen_t len; + int fd, rv; + + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); + if (connect_server(fd) < 0) + goto done; + + len = sizeof(xucred); + if (getsockopt(fd, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + goto done; } - return (error); + if (check_xucred(&xucred, len) < 0) + goto done; + + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: + _exit(rv); +} + +/* + * Accept connection from client and set LOCAL_PEERCRED socket option for + * connected socket. Verify that credentials of the peer are correct. + */ +static int +t_peercred_server(int fd1) +{ + struct xucred xucred; + socklen_t len; + int fd2, rv; + + fd2 = accept_connection(fd1); + if (fd2 < 0) + return (-2); + + len = sizeof(xucred); + if (getsockopt(fd2, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + rv = -2; + goto done; + } + + if (check_xucred(&xucred, len) < 0) { + rv = -1; + goto done; + } + + rv = 0; +done: + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); +} + +static int +t_peercred(void) +{ + int fd, rv; + + fd = create_server_socket(); + if (fd < 0) + return (-2); + + rv = -2; + + if (fork_client() < 0) + goto done; + + if (client_pid == 0) { + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); + t_peercred_client(); + } + + rv = t_peercred_server(fd); + + if (wait_client() < 0) + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } diff -ruNp unix_cmsg.orig/unix_cmsg.t unix_cmsg/unix_cmsg.t --- unix_cmsg.orig/unix_cmsg.t 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/unix_cmsg.t 2012-10-01 13:47:17.000000000 +0300 @@ -23,14 +23,15 @@ run() done } -echo "1..15" +echo "1..16" for desc in \ "Sending, receiving cmsgcred" \ - "Receiving sockcred (listening socket has LOCAL_CREDS) # TODO" \ - "Receiving sockcred (accepted socket has LOCAL_CREDS) # TODO" \ - "Sending cmsgcred, receiving sockcred # TODO" \ - "Sending, receiving timestamp" + "Receiving sockcred (listening socket has LOCAL_CREDS)" \ + "Receiving sockcred (accepted socket has LOCAL_CREDS)" \ + "Sending cmsgcred, receiving sockcred" \ + "Sending, receiving timestamp" \ + "Check LOCAL_PEERCRED socket option" do n=`expr ${n} + 1` run ${n} stream "" ${n} "STREAM ${desc}" @@ -48,10 +49,10 @@ do run ${n} dgram "" ${i} "DGRAM ${desc}" done -run 10 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" -run 11 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 12 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" +run 11 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" +run 12 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 13 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" -run 13 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" -run 14 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 15 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" +run 14 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" +run 15 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 16 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 16:24:25 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C25E6106566B; Mon, 1 Oct 2012 16:24:25 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4878A8FC12; Mon, 1 Oct 2012 16:24:24 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 01 Oct 2012 12:24:24 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BSE24778; Mon, 1 Oct 2012 12:24:23 -0400 X-Auth-ID: anat Received: from pool-173-63-112-200.nwrknj.fios.verizon.net (HELO [192.168.1.8]) ([173.63.112.200]) by smtp04.lnh.mail.rcn.net with ESMTP; 01 Oct 2012 12:24:23 -0400 Message-ID: <5069C3B3.9050500@aldan.algebra.com> Date: Mon, 01 Oct 2012 12:24:19 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120820 Thunderbird/14.0 MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: anders@freebsd.org, apache@FreeBSD.org Subject: Is it worth the effort to make proxy and server communicate via Unix socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:24:25 -0000 In a fairly common setup today, a proxy (say, Varnish) runs on the same system as the actual "backend" server (such as Apache). Would it be worthwhile to alter them both to allow them to talk via a socket instead of via TCP (on the lo0 interface)? Or is the win just too negligible? Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 19:22: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 D9E3E106564A; Mon, 1 Oct 2012 19:22:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id ABFE08FC1B; Mon, 1 Oct 2012 19:22:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 062D1B918; Mon, 1 Oct 2012 15:22:07 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 1 Oct 2012 15:21:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201209280835.56684.jhb@freebsd.org> In-Reply-To: <201209280835.56684.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201210011521.53397.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Oct 2012 15:22:07 -0400 (EDT) Cc: Alexander Motin , Marcin Cieslak Subject: Re: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 19:22:08 -0000 On Friday, September 28, 2012 8:35:56 am John Baldwin wrote: > On Thursday, September 27, 2012 9:02:59 am Marcin Cieslak wrote: > > >> John Baldwin wrote: > > > On Wednesday, September 26, 2012 6:42:19 pm Garrett Cooper wrote: > > >> On Wed, Sep 26, 2012 at 3:33 PM, Olivier Cochard-Labb=C3=A9 > > >> wrote: > > >> > On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak wrote: > > >> >> I have just updated by 9.0-something laptop to 10.0-CURRENT r2409= 48 > > >> >> and it very quickly panics after enabling network with IPsec > > >> >> (I am using IPsec w/racoon for IPv4 over 802.11, also using > > >> >> tunelled IPv6). > > >> > > > >> > I don't know if it's related, but one of the first dmesg message > > >> > displayd on my -current (rev 240921) is: > > >> > > > >> > module_register: module enc already exists! > > >> > Module enc failed to register: 17 > > > > > > I suspect this is the root cause and that the "wrong" global variable= is being=20 > > > used in ipsec_output.c due to duplicate symbols. > >=20 > > As the original poster: I don't have this "module enc already exists!" = message. > > I have had "device enc" in the kernel config file and I didn't try > > to load if_enc as module. I have IPSEC permanently enabled > > in the kernel and it is initialized at boot with setkey and later > > with racoon.=20 > >=20 > > > OTOH, have you created an enc0 device? I can't find anything that=20 > > > automatically creates it. > >=20 > > No. Previously, in 9.x times, it was always present in the ifconfig out= put. >=20 > Ok, I think that is the root cause. >=20 > HEAD should still be creating an enc0. The enc.c file creates an enc_clo= ner: >=20 > IFC_SIMPLE_DECLARE(enc, 1); >=20 > static int > enc_modevent(module_t mod, int type, void *data) > { > switch (type) { > case MOD_LOAD: > mtx_init(&enc_mtx, "enc mtx", NULL, MTX_DEF); > if_clone_attach(&enc_cloner); > break; >=20 > That '1' is the minimum number of interfaces to create on attach in > ifc_simple_attach(). I've no idea why enc0 isn't being created on boot, = but > it should be. I tracked this down. At some point a new CAM 'enc' module was added, and it used the same module name as 'device enc'. As a result, when both were compiled into the kernel, only one of the modules was included (and had its event handler run). Since CAM is earlier in the link order, it always won and enc(4) was never initialized. The patch below fixes this by renaming t= he module to "if_enc" instead of "enc" (this is more typical for network interfaces anyway). Index: if_enc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- if_enc.c (revision 241096) +++ if_enc.c (working copy) @@ -179,12 +179,12 @@ enc_modevent(module_t mod, int type, void *data) } =20 static moduledata_t enc_mod =3D { =2D "enc", + "if_enc", enc_modevent, 0 }; =20 =2DDECLARE_MODULE(enc, enc_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); +DECLARE_MODULE(if_enc, enc_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); =20 static int enc_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 21:10:43 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 212BB106566C; Mon, 1 Oct 2012 21:10:43 +0000 (UTC) (envelope-from anders@FreeBSD.org) Received: from fupp.net (totem.fix.no [80.91.36.20]) by mx1.freebsd.org (Postfix) with ESMTP id CD37A8FC16; Mon, 1 Oct 2012 21:10:41 +0000 (UTC) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by fupp.net (Postfix) with ESMTP id C32F35925A; Mon, 1 Oct 2012 23:04:07 +0200 (CEST) Received: from fupp.net ([80.91.36.20]) by totem.fix.no (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP id iDYnmzlfvWDX; Mon, 1 Oct 2012 23:04:07 +0200 (CEST) Received: by fupp.net (Postfix, from userid 1000) id 86BEA59259; Mon, 1 Oct 2012 23:04:07 +0200 (CEST) Date: Mon, 1 Oct 2012 23:04:07 +0200 From: Anders Nordby To: "Mikhail T." Message-ID: <20121001210407.GA10881@fupp.net> References: <5069C3B3.9050500@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5069C3B3.9050500@aldan.algebra.com> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: apache@FreeBSD.org, net@FreeBSD.org Subject: Re: Is it worth the effort to make proxy and server communicate via Unix socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:10:43 -0000 Hi, On man, okt 01, 2012 at 12:24:19pm -0400, Mikhail T. wrote: > In a fairly common setup today, a proxy (say, Varnish) runs on the same > system as the actual "backend" server (such as Apache). > > Would it be worthwhile to alter them both to allow them to talk via a > socket instead of via TCP (on the lo0 interface)? > > Or is the win just too negligible? Thanks! I don't see the point. Varnish usually runs on separate servers. On a small scale setup, the likely improvements would be negligible. The Varnish developers also do not want Varnish to become a web server, it's just not it's job. Your time is better spent improving your cache hit ratio (% of requests cached) as well as integrating purging with your content management systems when caching dynamic pages. If you are serving flat files only you may want to consider just using lighttpd or nginx, which are known to be fast. Regards, -- Anders. From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 03:06:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57C34106566B for ; Tue, 2 Oct 2012 03:06:39 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4908FC0A for ; Tue, 2 Oct 2012 03:06:38 +0000 (UTC) Received: from invalid-dns.RFC1918.monkeybrains.net (199-116-74-151-v301.PUBLIC.monkeybrains.net [199.116.74.151]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q9236WLr062918 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 1 Oct 2012 20:06:32 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <506A5A35.9030104@monkeybrains.net> Date: Mon, 01 Oct 2012 20:06:29 -0700 From: "Rudy (bulk)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> <50616D5C.705@gmail.com> <50649457.4050701@monkeybrains.net> <50649633.2090307@monkeybrains.net> <50668EEF.1070902@gmail.com> In-Reply-To: <50668EEF.1070902@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 03:06:39 -0000 On 9/28/12 11:02 PM, Hooman Fazaeli wrote: > > > On 9/27/2012 9:38 PM, Rudy wrote: >> On 09/27/2012 11:00 AM, Rudy wrote: >>> Rebooting and/or the settings change seems to have stopped the errors. >>> Here is a pretty little graph showing error rate on em1 for the past 3 >>> days. >>> >>> http://www.monkeybrains.net/images/ErrorRate-em1.png >>> >> >> Interesting... if I zoom in on the graph, I see the errors were >> 'every other sample period' until I rebooted the box. >> >> http://www.monkeybrains.net/images/ErrorRate-em1-zoom.png >> >> >> > How much traffic (bytes/s and packets/s) and of what type is passing > through this box? It is a router passing ISP traffic (lots of stuff, mostly port 80 and torrents....). dev in/out igb0 300Mbps/200Mbps igb1 400Mbps/100Mbps em0 40Mbps/4Mbps em1 100Mbps/400Mbps em2 150Mbps/50Mbps Rebooting 5 days ago with these tunings in loader.conf fixed the issue... Thanks for all the help, FreeBSD community! kern.ipc.nmbclusters=524288 hw.igb.rxd=4096 hw.igb.txd=4096 hw.em.rxd=4096 hw.em.txd=4096 Oh, and I ordered a motherboard with two ix and two igb devices on the motherboard. That will replace this slightly older router. http://www.supermicro.com/products/system/1U/1026/SYS-1026T-6RF_.cfm It is 1U and has room for 3 PCIe cards, whee! Rudy From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 13:41:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A99371065672; Thu, 4 Oct 2012 13:41:33 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC0E8FC0A; Thu, 4 Oct 2012 13:41:33 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id 7D705509A8; Thu, 4 Oct 2012 09:41:26 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id 276655093D; Thu, 4 Oct 2012 09:41:26 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Thu, 4 Oct 2012 09:41:26 -0400 From: Dominic Blais To: "Alexander V. Chernikov" Date: Thu, 4 Oct 2012 09:41:13 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2fT6Mhkj+dd0OLRv6WtiL19bA74AC40+rA Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E28127@WIN2008.Domnt.abi.ca> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> In-Reply-To: <5068B48E.2070303@FreeBSD.org> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 13:41:33 -0000 Hi, The server that actually has the problem is: - FreeBSD 9.0-RELEASE-p3 - Uses IPFW & dummynet for traffic shaping - Uses PF for firewalling and NAT - Uses MPD 5.6 for PPPoE server - Uses freeradius and PostgreSQL for authentication. I wrote a script some weeks ago that does the following: =3D=3D=3D=3D=3D #!/bin/sh RIGHT_GATEWAY=3D'1.1.1.1' NOC_EMAIL=3D'blah@test.com' i=3D5 while [ $i -gt 0 ] do if [ `/usr/bin/netstat -rn |grep default |grep $RIGHT_GATEWAY |wc -l` -= ne 1 ] then /sbin/route del -net default /sbin/route add -net default $RIGHT_GATEWAY tail -n 100 /tmp/route_monitor.log | mail -s "Default route bug hap= pened" $NOC_EMAIL fi i=3D`expr $i - 1` sleep 10 done =3D=3D=3D=3D=3D I've changed the variables for privacy purposes. This script is executed ea= ch minutes in crontab. So if the gateway changes, it is fixed within 10 sec= onds (a mean of 5 seconds). I have seen multiple days where it doesn't happen at all... Today was a rec= ord!! 43 times between 22:43 and 23:56. It means, 43 times the script detec= ted the gateway wasn't the good one and had to change it. It looks like it = happens when network usage is higher than usual.. there's obviously a link = with usage...The server isn't using all its resources. I usually see 25% CP= U usage at higher loads... All loads value are almost always under 0.4 and= are mostly around 0.35 for past 15 minutes. I'm running a route monitor in a screen and I'm sending the output to a tex= tfile. As you see in the script, I'm sending me the last 100 lines of it an= d I only see my script changing the gateway... nothing before is changing i= t. The other people experiencing that bug seems to have the same behaviour. -----Message d'origine----- De=A0: Alexander V. Chernikov [mailto:melifaro@FreeBSD.org]=20 Envoy=E9=A0: 30 septembre 2012 17:07 =C0=A0: Dominic Blais Cc=A0: freebsd-net@freebsd.org Objet=A0: Re: Default route destination changing without warning follow-up On 01.10.2012 00:59, Dominic Blais wrote: > It's all about IPv4 in my case. It will be great to supply some more details (e.g. like FreeBSD version, in= terfaces configuration, netstat -rn output). How often does this happen ? (e.g. while true; do echo -n `date` ; route -n get default | grep gate; sle= ep 1; done can help) If this is reproducible, what actions precedes this change? Maybe some ARP traffic on that interface, or interface creation/deletion, o= r.. ? Is route monitor completely silent when the change happens? > > > -- > > > > -----Message d'origine----- > De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] Envoy=E9 : 30=20 > septembre 2012 16:39 =C0 : Dominic Blais Cc : freebsd-net@freebsd.org=20 > Objet : Re: Default route destination changing without warning=20 > follow-up > > On 01.10.2012 00:33, Dominic Blais wrote: >> Yes, I'm very sure of it! A "route monitor" show no changes when it happ= ens. I've heard of another person with the same bug that has no traces in "= route monitor" either... We have in common that we're using IPFW and PF. > So, are we talking about IPv4 or IPv6? >> >> >> >> -- >> >> >> >> -----Message d'origine----- >> De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] Envoy=E9 : 30= =20 >> septembre 2012 16:31 =C0 : Dominic Blais Cc : freebsd-net@freebsd.org=20 >> Objet : Re: Default route destination changing without warning=20 >> follow-up >> >> On 01.10.2012 00:00, Dominic Blais wrote: >>> Hi, >> Hello! >>> >>> I was just wondering if there was anything new about the bug of default= route changing without warning... Is there any test I can do to help fixi= ng it? >> Can you be a bit more precise and specify FreeBSD version and address fa= mily? >> >> Are you sure that it is not changed by some other userland process (e.g. >> did you do some `route monitor` checks) ? >>> >>> -- >>> [cid:image001.gif@01CD9F24.B366CBF0] >>> >>> >>> >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list=20 >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 14:07: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 07414106566B for ; Thu, 4 Oct 2012 14:07:24 +0000 (UTC) (envelope-from krzysiek@airnet.opole.pl) Received: from base.airnet.opole.pl (ns2.airmax.pl [176.111.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id AA3258FC16 for ; Thu, 4 Oct 2012 14:07:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by base.airnet.opole.pl (Postfix) with ESMTP id 239337FF02B for ; Thu, 4 Oct 2012 15:58:57 +0200 (CEST) Received: from base.airnet.opole.pl ([127.0.0.1]) by localhost (mail.airnet.opole.pl [127.0.0.1]) (maiad, port 10024) with ESMTP id 84769-03 for ; Thu, 4 Oct 2012 15:58:56 +0200 (CEST) Received: from [10.10.11.223] (unknown [176.111.138.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: krzysiek@airnet.opole.pl) by base.airnet.opole.pl (Postfix) with ESMTPSA id E8DB37FF020 for ; Thu, 4 Oct 2012 15:58:56 +0200 (CEST) Message-ID: <506D961D.2030604@airnet.opole.pl> Date: Thu, 04 Oct 2012 15:58:53 +0200 From: Krzysztof Barcikowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E28127@WIN2008.Domnt.abi.ca> In-Reply-To: <2DE61B0869B7484997BCA012845482C7EBE8E28127@WIN2008.Domnt.abi.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 14:07:24 -0000 W dniu 2012-10-04 15:41, Dominic Blais pisze: > Hi, > > The server that actually has the problem is: > > - FreeBSD 9.0-RELEASE-p3 > - Uses IPFW & dummynet for traffic shaping > - Uses PF for firewalling and NAT > - Uses MPD 5.6 for PPPoE server > - Uses freeradius and PostgreSQL for authentication. > > I have similar issues, it can happen many times a day, or there are few days without a problem. There is no "route monitor" output when it happens. "fstat | grep route" periodically gives just ntpd and bsnmpd. I turned it off, no change. I tried to turn TSO on all em interfaces - no change. Three routers with similar setup and problem of changing default gateway or static routes: - 9.0-RELEASE-p1 FreeBSD (amd64) - IPFW & dumynet for shaping - PF for NAT and filtering I do not use MPD. However I do use PPPoE in my network, terminated at Mikrotik Routerboard and then routed to FBSD. Sorry for my poor english. Best regards! Krzysiek From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 14:15:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32E861065670; Thu, 4 Oct 2012 14:15:57 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id B8C618FC08; Thu, 4 Oct 2012 14:15:56 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id 202D4509A8; Thu, 4 Oct 2012 10:15:56 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id B9E7D50881; Thu, 4 Oct 2012 10:15:55 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Thu, 4 Oct 2012 10:15:55 -0400 From: Dominic Blais To: Dominic Blais , "Alexander V. Chernikov" Date: Thu, 4 Oct 2012 10:15:43 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2fT6Mhkj+dd0OLRv6WtiL19bA74AC40+rAAAHYr4A= Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E28129@WIN2008.Domnt.abi.ca> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 14:15:57 -0000 About hardware, the my server is a HP Proliant ML115. It has a Broadcom BCM= 5722 as network controller. In my network configuration, I'm using a single= NIC (bge0). This interface has an IP address in the default gateway subnet= . I also have a vlan interface on the same NIC for pppoe traffic. -- -----Message d'origine----- De=A0: Dominic Blais=20 Envoy=E9=A0: 4 octobre 2012 09:41 =C0=A0: 'Alexander V. Chernikov' Cc=A0: freebsd-net@freebsd.org Objet=A0: RE: Default route destination changing without warning follow-up Hi, The server that actually has the problem is: - FreeBSD 9.0-RELEASE-p3 - Uses IPFW & dummynet for traffic shaping - Uses PF for firewalling and NAT - Uses MPD 5.6 for PPPoE server - Uses freeradius and PostgreSQL for authentication. I wrote a script some weeks ago that does the following: =3D=3D=3D=3D=3D #!/bin/sh RIGHT_GATEWAY=3D'1.1.1.1' NOC_EMAIL=3D'blah@test.com' i=3D5 while [ $i -gt 0 ] do if [ `/usr/bin/netstat -rn |grep default |grep $RIGHT_GATEWAY |wc -l` -= ne 1 ] then /sbin/route del -net default /sbin/route add -net default $RIGHT_GATEWAY tail -n 100 /tmp/route_monitor.log | mail -s "Default route bug hap= pened" $NOC_EMAIL fi i=3D`expr $i - 1` sleep 10 done =3D=3D=3D=3D=3D I've changed the variables for privacy purposes. This script is executed ea= ch minutes in crontab. So if the gateway changes, it is fixed within 10 sec= onds (a mean of 5 seconds). I have seen multiple days where it doesn't happen at all... Today was a rec= ord!! 43 times between 22:43 and 23:56. It means, 43 times the script detec= ted the gateway wasn't the good one and had to change it. It looks like it = happens when network usage is higher than usual.. there's obviously a link = with usage...The server isn't using all its resources. I usually see 25% CP= U usage at higher loads... All loads value are almost always under 0.4 and= are mostly around 0.35 for past 15 minutes. I'm running a route monitor in a screen and I'm sending the output to a tex= tfile. As you see in the script, I'm sending me the last 100 lines of it an= d I only see my script changing the gateway... nothing before is changing i= t. The other people experiencing that bug seems to have the same behaviour. -----Message d'origine----- De=A0: Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] Envoy=E9=A0: 30= septembre 2012 17:07 =C0=A0: Dominic Blais Cc=A0: freebsd-net@freebsd.org = Objet=A0: Re: Default route destination changing without warning follow-up On 01.10.2012 00:59, Dominic Blais wrote: > It's all about IPv4 in my case. It will be great to supply some more details (e.g. like FreeBSD version, in= terfaces configuration, netstat -rn output). How often does this happen ? (e.g. while true; do echo -n `date` ; route -n get default | grep gate; sle= ep 1; done can help) If this is reproducible, what actions precedes this change? Maybe some ARP traffic on that interface, or interface creation/deletion, o= r.. ? Is route monitor completely silent when the change happens? > > > -- > > > > -----Message d'origine----- > De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] Envoy=E9 : 30=20 > septembre 2012 16:39 =C0 : Dominic Blais Cc : freebsd-net@freebsd.org=20 > Objet : Re: Default route destination changing without warning=20 > follow-up > > On 01.10.2012 00:33, Dominic Blais wrote: >> Yes, I'm very sure of it! A "route monitor" show no changes when it happ= ens. I've heard of another person with the same bug that has no traces in "= route monitor" either... We have in common that we're using IPFW and PF. > So, are we talking about IPv4 or IPv6? >> >> >> >> -- >> >> >> >> -----Message d'origine----- >> De : Alexander V. Chernikov [mailto:melifaro@FreeBSD.org] Envoy=E9 : 30= =20 >> septembre 2012 16:31 =C0 : Dominic Blais Cc : freebsd-net@freebsd.org=20 >> Objet : Re: Default route destination changing without warning=20 >> follow-up >> >> On 01.10.2012 00:00, Dominic Blais wrote: >>> Hi, >> Hello! >>> >>> I was just wondering if there was anything new about the bug of default= route changing without warning... Is there any test I can do to help fixi= ng it? >> Can you be a bit more precise and specify FreeBSD version and address fa= mily? >> >> Are you sure that it is not changed by some other userland process (e.g. >> did you do some `route monitor` checks) ? >>> >>> -- >>> [cid:image001.gif@01CD9F24.B366CBF0] >>> >>> >>> >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list=20 >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 16:02: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 D2E881065670; Thu, 4 Oct 2012 16:02:47 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 813D18FC0A; Thu, 4 Oct 2012 16:02:47 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id q94G2ev2010232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 09:02:40 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id q94G2eCI010231; Thu, 4 Oct 2012 09:02:40 -0700 (PDT) (envelope-from jmg) Date: Thu, 4 Oct 2012 09:02:40 -0700 From: John-Mark Gurney To: "Alexander V. Chernikov" Message-ID: <20121004160240.GA1967@funkthat.com> Mail-Followup-To: "Alexander V. Chernikov" , Dominic Blais , "freebsd-net@freebsd.org" References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5068B48E.2070303@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 04 Oct 2012 09:02:40 -0700 (PDT) Cc: "freebsd-net@freebsd.org" , Dominic Blais Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:02:47 -0000 Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07 +0400: > On 01.10.2012 00:59, Dominic Blais wrote: > >It's all about IPv4 in my case. > > It will be great to supply some more details (e.g. like FreeBSD version, > interfaces configuration, netstat -rn output). > > How often does this happen ? > (e.g. while true; do echo -n `date` ; route -n get default | grep gate; > sleep 1; done can help) > > If this is reproducible, what actions precedes this change? > Maybe some ARP traffic on that interface, or interface > creation/deletion, or.. ? > > Is route monitor completely silent when the change happens? Just for refernece, Dominic brought this up in an earlier thread: http://www.freebsd.org/cgi/mid.cgi?2DE61B0869B7484997BCA012845482C7EBE62DDD88@WIN2008.Domnt.abi.ca and at least on other person seems to have the same issue... quick question for you Dominic, do you see the correct number of routes, but a new wrong one appear? or does the route just simply disapear? or does a new one seem to replace the old one? The reason I ask is that if a new wrong one appears, it could be memory corruption, but if a new one replaces the old one, for some reason when allocating a new route, it could accidentatlly be replacing the default route... Just some thoughts... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 16:12:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7133106566C; Thu, 4 Oct 2012 16:12:44 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id 906368FC17; Thu, 4 Oct 2012 16:12:44 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id 90FD1509A8; Thu, 4 Oct 2012 12:12:43 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id 3AFAC50881; Thu, 4 Oct 2012 12:12:43 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Thu, 4 Oct 2012 12:12:42 -0400 From: Dominic Blais To: John-Mark Gurney , "Alexander V. Chernikov" Date: Thu, 4 Oct 2012 12:12:30 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2iSbSTomJeQYlwQbq8uLTyjwbNYQAAC2fA Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E28133@WIN2008.Domnt.abi.ca> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> In-Reply-To: <20121004160240.GA1967@funkthat.com> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:12:45 -0000 There's never 2 default route... it's always a single default route. Since = route monitor shows nothing, I guess it's the same route that gets its gate= way changed for some reason... I guess the effective and appearing change c= ould be due to a pointer changing somewhere or the memory space where is lo= cated the default gateway is replaced with new stuff... I don't know how it= 's coded but it looks like that kind of stuff since nothing is triggered on= the route monitor radar... The default route always exists and there's no trace of it deleted prior to= what my script does so we may be quite sure it's the same route that's bru= talized ;) Since mpd creates new interfaces for each new connection I see some route b= eing added/replaced from time to time. I first thought it was mpd's fault b= ecause it was the only thing playing with routes but Krzysztof Barcikowski = doesn't use MPD and shares the use of IPFW and PF like me and has the same = default route gateway changing behaviour... -- -----Message d'origine----- De=A0: John-Mark Gurney [mailto:jmg@funkthat.com]=20 Envoy=E9=A0: 4 octobre 2012 12:03 =C0=A0: Alexander V. Chernikov Cc=A0: Dominic Blais; freebsd-net@freebsd.org Objet=A0: Re: Default route destination changing without warning follow-up Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07 +04= 00: > On 01.10.2012 00:59, Dominic Blais wrote: > >It's all about IPv4 in my case. >=20 > It will be great to supply some more details (e.g. like FreeBSD=20 > version, interfaces configuration, netstat -rn output). >=20 > How often does this happen ? > (e.g. while true; do echo -n `date` ; route -n get default | grep=20 > gate; sleep 1; done can help) >=20 > If this is reproducible, what actions precedes this change? > Maybe some ARP traffic on that interface, or interface=20 > creation/deletion, or.. ? >=20 > Is route monitor completely silent when the change happens? Just for refernece, Dominic brought this up in an earlier thread: http://www.freebsd.org/cgi/mid.cgi?2DE61B0869B7484997BCA012845482C7EBE62DDD= 88@WIN2008.Domnt.abi.ca and at least on other person seems to have the same issue... quick question for you Dominic, do you see the correct number of routes, bu= t a new wrong one appear? or does the route just simply disapear? or does = a new one seem to replace the old one? The reason I ask is that if a new wrong one appears, it could be memory cor= ruption, but if a new one replaces the old one, for some reason when alloca= ting a new route, it could accidentatlly be replacing the default route... Just some thoughts... --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 17:36: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 1B33C106564A; Thu, 4 Oct 2012 17:36:55 +0000 (UTC) (envelope-from krzysiek@airnet.opole.pl) Received: from base.airnet.opole.pl (ns2.airmax.pl [176.111.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id 830D68FC14; Thu, 4 Oct 2012 17:36:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by base.airnet.opole.pl (Postfix) with ESMTP id 0C6EB7FF02E; Thu, 4 Oct 2012 19:36:55 +0200 (CEST) Received: from base.airnet.opole.pl ([127.0.0.1]) by localhost (mail.airnet.opole.pl [127.0.0.1]) (maiad, port 10024) with ESMTP id 35670-08; Thu, 4 Oct 2012 19:36:54 +0200 (CEST) Received: from [10.10.11.223] (unknown [176.111.138.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: krzysiek@airnet.opole.pl) by base.airnet.opole.pl (Postfix) with ESMTPSA id CACE47FF02B; Thu, 4 Oct 2012 19:36:54 +0200 (CEST) Message-ID: <506DC933.7080307@airnet.opole.pl> Date: Thu, 04 Oct 2012 19:36:51 +0200 From: Krzysztof Barcikowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" , Dominic Blais , "freebsd-net@freebsd.org" References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> In-Reply-To: <20121004160240.GA1967@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 17:36:55 -0000 W dniu 2012-10-04 18:02, John-Mark Gurney pisze: > Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07 +0400: >> On 01.10.2012 00:59, Dominic Blais wrote: >>> It's all about IPv4 in my case. >> It will be great to supply some more details (e.g. like FreeBSD version, >> interfaces configuration, netstat -rn output). >> >> How often does this happen ? >> (e.g. while true; do echo -n `date` ; route -n get default | grep gate; >> sleep 1; done can help) >> >> If this is reproducible, what actions precedes this change? >> Maybe some ARP traffic on that interface, or interface >> creation/deletion, or.. ? >> >> Is route monitor completely silent when the change happens? > Just for refernece, Dominic brought this up in an earlier thread: > http://www.freebsd.org/cgi/mid.cgi?2DE61B0869B7484997BCA012845482C7EBE62DDD88@WIN2008.Domnt.abi.ca > > and at least on other person seems to have the same issue... > > quick question for you Dominic, do you see the correct number of routes, > but a new wrong one appear? or does the route just simply disapear? or > does a new one seem to replace the old one? > > The reason I ask is that if a new wrong one appears, it could be memory > corruption, but if a new one replaces the old one, for some reason when > allocating a new route, it could accidentatlly be replacing the default > route... > > Just some thoughts... > Hi, I don't see a second new route appearing in my case, just the default or static route is replaced. I'm not conviced of memory corruption, as it happens on 3 different physical machines. Best regards! Krzysiek Barcikowski From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 17:58:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9274B106564A; Thu, 4 Oct 2012 17:58:17 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5E95C8FC08; Thu, 4 Oct 2012 17:58:17 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id q94HwGbi012251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 10:58:16 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id q94HwGmR012250; Thu, 4 Oct 2012 10:58:16 -0700 (PDT) (envelope-from jmg) Date: Thu, 4 Oct 2012 10:58:16 -0700 From: John-Mark Gurney To: Dominic Blais Message-ID: <20121004175816.GB1967@funkthat.com> Mail-Followup-To: Dominic Blais , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <2DE61B0869B7484997BCA012845482C7EBE8E28133@WIN2008.Domnt.abi.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2DE61B0869B7484997BCA012845482C7EBE8E28133@WIN2008.Domnt.abi.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 04 Oct 2012 10:58:16 -0700 (PDT) Cc: "freebsd-net@freebsd.org" , "Alexander V. Chernikov" Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 17:58:17 -0000 Dominic Blais wrote this message on Thu, Oct 04, 2012 at 12:12 -0400: > There's never 2 default route... it's always a single default route. Since route monitor shows nothing, I guess it's the same route that gets its gateway changed for some reason... I guess the effective and appearing change could be due to a pointer changing somewhere or the memory space where is located the default gateway is replaced with new stuff... I don't know how it's coded but it looks like that kind of stuff since nothing is triggered on the route monitor radar... > > The default route always exists and there's no trace of it deleted prior to what my script does so we may be quite sure it's the same route that's brutalized ;) It looks like ddb does support breaking on a hardware address, so we might be able to track it down this way... If you can use ddb or gdb to track down the memory address of the ip of the default route, you can set an hwatch (see ddb(4)) on that address and hopefully catch the code that is corrupting the default route... I'm not familar w/ the routing system to help you figure out the address to watch on, etc... Maybe someone else can... Or you can try to read the code... Hope this helps... > Since mpd creates new interfaces for each new connection I see some route being added/replaced from time to time. I first thought it was mpd's fault because it was the only thing playing with routes but Krzysztof Barcikowski doesn't use MPD and shares the use of IPFW and PF like me and has the same default route gateway changing behaviour... > > > -- > > > > -----Message d'origine----- > De : John-Mark Gurney [mailto:jmg@funkthat.com] > Envoyé : 4 octobre 2012 12:03 > À : Alexander V. Chernikov > Cc : Dominic Blais; freebsd-net@freebsd.org > Objet : Re: Default route destination changing without warning follow-up > > Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07 +0400: > > On 01.10.2012 00:59, Dominic Blais wrote: > > >It's all about IPv4 in my case. > > > > It will be great to supply some more details (e.g. like FreeBSD > > version, interfaces configuration, netstat -rn output). > > > > How often does this happen ? > > (e.g. while true; do echo -n `date` ; route -n get default | grep > > gate; sleep 1; done can help) > > > > If this is reproducible, what actions precedes this change? > > Maybe some ARP traffic on that interface, or interface > > creation/deletion, or.. ? > > > > Is route monitor completely silent when the change happens? > > Just for refernece, Dominic brought this up in an earlier thread: > http://www.freebsd.org/cgi/mid.cgi?2DE61B0869B7484997BCA012845482C7EBE62DDD88@WIN2008.Domnt.abi.ca > > and at least on other person seems to have the same issue... > > quick question for you Dominic, do you see the correct number of routes, but a new wrong one appear? or does the route just simply disapear? or does a new one seem to replace the old one? > > The reason I ask is that if a new wrong one appears, it could be memory corruption, but if a new one replaces the old one, for some reason when allocating a new route, it could accidentatlly be replacing the default route... > > Just some thoughts... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 22:23:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57800106566C; Thu, 4 Oct 2012 22:23:39 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBB88FC20; Thu, 4 Oct 2012 22:23:39 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TJtpH-000JAc-FG; Thu, 04 Oct 2012 18:23:27 -0400 Date: Thu, 4 Oct 2012 18:23:27 -0400 From: Gary Palmer To: Krzysztof Barcikowski Message-ID: <20121004222327.GA40357@in-addr.com> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <506DC933.7080307@airnet.opole.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <506DC933.7080307@airnet.opole.pl> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: "freebsd-net@freebsd.org" , "Alexander V. Chernikov" , Dominic Blais Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:23:39 -0000 On Thu, Oct 04, 2012 at 07:36:51PM +0200, Krzysztof Barcikowski wrote: > W dniu 2012-10-04 18:02, John-Mark Gurney pisze: > > Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07 +0400: > >> On 01.10.2012 00:59, Dominic Blais wrote: > >>> It's all about IPv4 in my case. > >> It will be great to supply some more details (e.g. like FreeBSD version, > >> interfaces configuration, netstat -rn output). > >> > >> How often does this happen ? > >> (e.g. while true; do echo -n `date` ; route -n get default | grep gate; > >> sleep 1; done can help) > >> > >> If this is reproducible, what actions precedes this change? > >> Maybe some ARP traffic on that interface, or interface > >> creation/deletion, or.. ? > >> > >> Is route monitor completely silent when the change happens? > > Just for refernece, Dominic brought this up in an earlier thread: > > http://www.freebsd.org/cgi/mid.cgi?2DE61B0869B7484997BCA012845482C7EBE62DDD88@WIN2008.Domnt.abi.ca > > > > and at least on other person seems to have the same issue... > > > > quick question for you Dominic, do you see the correct number of routes, > > but a new wrong one appear? or does the route just simply disapear? or > > does a new one seem to replace the old one? > > > > The reason I ask is that if a new wrong one appears, it could be memory > > corruption, but if a new one replaces the old one, for some reason when > > allocating a new route, it could accidentatlly be replacing the default > > route... > > > > Just some thoughts... > > > > Hi, > > I don't see a second new route appearing in my case, just the default or > static route is replaced. > I'm not conviced of memory corruption, as it happens on 3 different > physical machines. Sorry for jumping into the middle of the thread (and apologies if this was asked/answered previously), however what are the settings for the following sysctls? net.inet.icmp.log_redirect net.inet.icmp.drop_redirect and potentially net.inet6.ip6.redirect net.inet6.icmp6.rediraccept Gary From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 23:22:01 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 3B943106566C for ; Thu, 4 Oct 2012 23:22:01 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B9AF38FC08 for ; Thu, 4 Oct 2012 23:22:00 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c50so962649eek.13 for ; Thu, 04 Oct 2012 16:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vKyVyFYZCMiNmoqZ8di6UVgxWBTD2xSieM/lqW86+1c=; b=diWjUHI6cPBDWMK64+98jGhtV4pAtmcQORNzkaTZcBlsc3T0ZS9va5J9XmW17GC2sp e/vsW080zJu1X8fyPQAxxzGICnSTThJS7vO1os0LHjFawEWd5I+QNLwboi4/6naCGwwv Tfj7z9mqLNUVABAMrxD82wVyivALFnMXFmIXXqtBVC1pceUu74RamUMFK7I3x6Wmzi/0 ta226nFtQpoCz3F1P0GwQ6vzCQtk7zzsa3MhHjPzNQfNHepsEnBrv3XqyL4KuhvxidYs 14EkDzc86WRgFUr0GzjdwZ+JAUzPDquRTIPDrXnENUO+ji6b00AsL3KWM5iagxNzHQPI QYtA== MIME-Version: 1.0 Received: by 10.14.205.9 with SMTP id i9mr10730766eeo.21.1349392919343; Thu, 04 Oct 2012 16:21:59 -0700 (PDT) Received: by 10.14.199.73 with HTTP; Thu, 4 Oct 2012 16:21:59 -0700 (PDT) Date: Thu, 4 Oct 2012 16:21:59 -0700 Message-ID: From: Vijay Singh To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: A small cleanup patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 23:22:01 -0000 Folks, I came up with this while going through the lltable code. kong@[/u/vijay/bsd/CODE/cur/sys]# svn diff net/if.c Index: net/if.c =================================================================== --- net/if.c (revision 241169) +++ net/if.c (working copy) @@ -691,12 +691,9 @@ if_attachdomain(void *dummy) { struct ifnet *ifp; - int s; - s = splnet(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) if_attachdomain1(ifp); - splx(s); } SYSINIT(domainifattach, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_SECOND, if_attachdomain, NULL); @@ -705,22 +702,17 @@ if_attachdomain1(struct ifnet *ifp) { struct domain *dp; - int s; - s = splnet(); - /* * Since dp->dom_ifattach calls malloc() with M_WAITOK, we * cannot lock ifp->if_afdata initialization, entirely. */ if (IF_AFDATA_TRYLOCK(ifp) == 0) { - splx(s); return; } if (ifp->if_afdata_initialized >= domain_init_status) { IF_AFDATA_UNLOCK(ifp); - splx(s); - printf("if_attachdomain called more than once on %s\n", + log(LOG_WARNING, "if_attachdomain called more than once on %s\n", ifp->if_xname); return; } @@ -734,8 +726,6 @@ ifp->if_afdata[dp->dom_family] = (*dp->dom_ifattach)(ifp); } - - splx(s); } /* From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 00:28: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 9C1F71065672; Fri, 5 Oct 2012 00:28:13 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4904B8FC0A; Fri, 5 Oct 2012 00:28:12 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id E4143509AB; Thu, 4 Oct 2012 20:28:11 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id 6990C50881; Thu, 4 Oct 2012 20:28:11 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Thu, 4 Oct 2012 20:28:11 -0400 From: Dominic Blais To: Gary Palmer , Krzysztof Barcikowski Date: Thu, 4 Oct 2012 20:27:58 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2ifuhL7I/vMxudQc+Z57zSk3GI9QAETEFA Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E2814B@WIN2008.Domnt.abi.ca> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <506DC933.7080307@airnet.opole.pl> <20121004222327.GA40357@in-addr.com> In-Reply-To: <20121004222327.GA40357@in-addr.com> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "Alexander V. Chernikov" Subject: RE: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 00:28:13 -0000 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet6.ip6.redirect: 1 net.inet6.icmp6.rediraccept: 1 -- -----Message d'origine----- De=A0: Gary Palmer [mailto:gpalmer@freebsd.org]=20 Envoy=E9=A0: 4 octobre 2012 18:23 =C0=A0: Krzysztof Barcikowski Cc=A0: Alexander V. Chernikov; Dominic Blais; freebsd-net@freebsd.org Objet=A0: Re: Default route destination changing without warning follow-up On Thu, Oct 04, 2012 at 07:36:51PM +0200, Krzysztof Barcikowski wrote: > W dniu 2012-10-04 18:02, John-Mark Gurney pisze: > > Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07= +0400: > >> On 01.10.2012 00:59, Dominic Blais wrote: > >>> It's all about IPv4 in my case. > >> It will be great to supply some more details (e.g. like FreeBSD=20 > >> version, interfaces configuration, netstat -rn output). > >> > >> How often does this happen ? > >> (e.g. while true; do echo -n `date` ; route -n get default | grep=20 > >> gate; sleep 1; done can help) > >> > >> If this is reproducible, what actions precedes this change? > >> Maybe some ARP traffic on that interface, or interface=20 > >> creation/deletion, or.. ? > >> > >> Is route monitor completely silent when the change happens? > > Just for refernece, Dominic brought this up in an earlier thread: > > http://www.freebsd.org/cgi/mid.cgi?2DE61B0869B7484997BCA012845482C7E > > BE62DDD88@WIN2008.Domnt.abi.ca > > > > and at least on other person seems to have the same issue... > > > > quick question for you Dominic, do you see the correct number of=20 > > routes, but a new wrong one appear? or does the route just simply=20 > > disapear? or does a new one seem to replace the old one? > > > > The reason I ask is that if a new wrong one appears, it could be=20 > > memory corruption, but if a new one replaces the old one, for some=20 > > reason when allocating a new route, it could accidentatlly be=20 > > replacing the default route... > > > > Just some thoughts... > > >=20 > Hi, >=20 > I don't see a second new route appearing in my case, just the default=20 > or static route is replaced. > I'm not conviced of memory corruption, as it happens on 3 different=20 > physical machines. Sorry for jumping into the middle of the thread (and apologies if this was = asked/answered previously), however what are the settings for the following= sysctls? net.inet.icmp.log_redirect net.inet.icmp.drop_redirect and potentially net.inet6.ip6.redirect net.inet6.icmp6.rediraccept Gary From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 03:28:29 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 518F8106564A; Fri, 5 Oct 2012 03:28:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21F4C8FC12; Fri, 5 Oct 2012 03:28:29 +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 q953STNK068350; Fri, 5 Oct 2012 03:28:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q953SSuK068344; Fri, 5 Oct 2012 03:28:28 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 03:28:28 GMT Message-Id: <201210050328.q953SSuK068344@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:28:29 -0000 Old Synopsis: [panic] [igb] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type New Synopsis: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 03:27:58 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=172113 From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 03:44:03 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7BD91065672; Fri, 5 Oct 2012 03:44:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9AFA68FC0A; Fri, 5 Oct 2012 03:44:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q953i34f071635; Fri, 5 Oct 2012 03:44:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q953i2gj071631; Fri, 5 Oct 2012 03:44:02 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 03:44:02 GMT Message-Id: <201210050344.q953i2gj071631@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171825: [ale] [patch] ale driver msix setup typo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:44:03 -0000 Old Synopsis: ale driver msix setup typo New Synopsis: [ale] [patch] ale driver msix setup typo Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 03:43:27 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171825 From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 03:49:10 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F244D1065672; Fri, 5 Oct 2012 03:49:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C66988FC14; Fri, 5 Oct 2012 03:49:09 +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 q953n9Mg072439; Fri, 5 Oct 2012 03:49:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q953n9Yg072435; Fri, 5 Oct 2012 03:49:09 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 03:49:09 GMT Message-Id: <201210050349.q953n9Yg072435@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171739: [bce] [panic] bce related kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:49:10 -0000 Old Synopsis: bce related kernel panic New Synopsis: [bce] [panic] bce related kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 03:48:51 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171739 From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 03:50:53 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDDDB106566B; Fri, 5 Oct 2012 03:50:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A28E48FC25; Fri, 5 Oct 2012 03:50:53 +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 q953orfd072805; Fri, 5 Oct 2012 03:50:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q953orxQ072789; Fri, 5 Oct 2012 03:50:53 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 03:50:53 GMT Message-Id: <201210050350.q953orxQ072789@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171711: [dummynet] [panic] Kernel panic in dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 03:50:53 -0000 Synopsis: [dummynet] [panic] Kernel panic in dummynet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 03:50:42 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171711 From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 06:19:25 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 DA11A106566B; Fri, 5 Oct 2012 06:19:24 +0000 (UTC) (envelope-from krzysiek@airnet.opole.pl) Received: from base.airnet.opole.pl (ns2.airmax.pl [176.111.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFA58FC08; Fri, 5 Oct 2012 06:19:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by base.airnet.opole.pl (Postfix) with ESMTP id C6D947FF02B; Fri, 5 Oct 2012 08:19:22 +0200 (CEST) Received: from base.airnet.opole.pl ([127.0.0.1]) by localhost (mail.airnet.opole.pl [127.0.0.1]) (maiad, port 10024) with ESMTP id 59996-03; Fri, 5 Oct 2012 08:19:22 +0200 (CEST) Received: from [10.10.11.223] (unknown [176.111.138.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: krzysiek@airnet.opole.pl) by base.airnet.opole.pl (Postfix) with ESMTPSA id 94A857FF020; Fri, 5 Oct 2012 08:19:22 +0200 (CEST) Message-ID: <506E7BE7.2080104@airnet.opole.pl> Date: Fri, 05 Oct 2012 08:19:19 +0200 From: Krzysztof Barcikowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Gary Palmer References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <506DC933.7080307@airnet.opole.pl> <20121004222327.GA40357@in-addr.com> In-Reply-To: <20121004222327.GA40357@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "Alexander V. Chernikov" , Dominic Blais Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 06:19:25 -0000 W dniu 2012-10-05 00:23, Gary Palmer pisze: > On Thu, Oct 04, 2012 at 07:36:51PM +0200, Krzysztof Barcikowski wrote: >> W dniu 2012-10-04 18:02, John-Mark Gurney pisze: >>> Alexander V. Chernikov wrote this message on Mon, Oct 01, 2012 at 01:07 +0400: >>>> On 01.10.2012 00:59, Dominic Blais wrote: >>>>> It's all about IPv4 in my case. >>>> It will be great to supply some more details (e.g. like FreeBSD version, >>>> interfaces configuration, netstat -rn output). >>>> >>>> How often does this happen ? >>>> (e.g. while true; do echo -n `date` ; route -n get default | grep gate; >>>> sleep 1; done can help) >>>> >>>> If this is reproducible, what actions precedes this change? >>>> Maybe some ARP traffic on that interface, or interface >>>> creation/deletion, or.. ? >>>> >>>> Is route monitor completely silent when the change happens? >>> Just for refernece, Dominic brought this up in an earlier thread: >>> http://www.freebsd.org/cgi/mid.cgi?2DE61B0869B7484997BCA012845482C7EBE62DDD88@WIN2008.Domnt.abi.ca >>> >>> and at least on other person seems to have the same issue... >>> >>> quick question for you Dominic, do you see the correct number of routes, >>> but a new wrong one appear? or does the route just simply disapear? or >>> does a new one seem to replace the old one? >>> >>> The reason I ask is that if a new wrong one appears, it could be memory >>> corruption, but if a new one replaces the old one, for some reason when >>> allocating a new route, it could accidentatlly be replacing the default >>> route... >>> >>> Just some thoughts... >>> >> Hi, >> >> I don't see a second new route appearing in my case, just the default or >> static route is replaced. >> I'm not conviced of memory corruption, as it happens on 3 different >> physical machines. > Sorry for jumping into the middle of the thread (and apologies if this was > asked/answered previously), however what are the settings for the following > sysctls? > > net.inet.icmp.log_redirect > net.inet.icmp.drop_redirect > > and potentially > > net.inet6.ip6.redirect > net.inet6.icmp6.rediraccept > > Gary > _______________________________________________ > 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" > Hi, net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 1 net.inet6.ip6.redirect: 1 net.inet6.icmp6.rediraccept: 1 Best regards! Krzysiek Barcikowski Krzysiek Barcikowski From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 11:47:23 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 C94701065670 for ; Fri, 5 Oct 2012 11:47:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id E3A468FC0A for ; Fri, 5 Oct 2012 11:47:22 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q95BlGsY051551 for ; Fri, 5 Oct 2012 15:47:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q95BlGRP051550 for net@FreeBSD.org; Fri, 5 Oct 2012 15:47:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 5 Oct 2012 15:47:16 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20121005114716.GP34622@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 11:47:23 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hello, once the pfil(9) API was introduced in FreeBSD, our main packet filter, the ipfw(4) worked in host byte order, that's why the pfil(9) API was violated: the AF_INET hooks were entered with packet in host byte order. If you look into pfil(9) manpage you'll see that it still declares opposite :) Today, pf(4) and ipfw(4) both are working with net byte order. But pfil(9) still supplies packet to them in host byte order, contrary to what API manual says. Right now, we have tons of places where byte order is swapped there and back to resolve this mess: - when entering pf - when entering ipfw - when calling pfil hooks from enc(4) - when calling pfil hooks from if_bridge(4) - in ip_fastfwd.c Also, we've got ip_fragment() that accepts packet in host byte order and emits new ones in net byte order. Moreover, when we put packets into the NETISR_IP queue, we put them in different byte order: those that have M_FASTFWD_OURS flag are in host byte order, while all others are in net. Attached patch does the following: - all packets in NETISR_IP queue are in net byte order - ip_input() is entered in net byte order and converts packet to host byte order right _after_ processing pfil(9) hooks - ip_output() is entered in host byte order and converts packet to net byte order right _before_ processing pfil(9) hooks - ip_fragment() accepts and emits packet in net byte order - ip_forward(), ip_mloopback() use host byte order (untouched actually) - ip_fastforward() no longer modifies packet at all (except ip_ttl) - swapping of byte order there and back removed from the following modules: pf(4), ipfw(4), enc(4), if_bridge(4) - swapping of byte order added to ipfilter(4), based on __FreeBSD_version - __FreeBSD_version bumped - manual page updated -- Totus tuus, Glebius. --r5Pyd7+fXNt84Ff3 Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="net_byte_order.diff" Index: netinet/ip_output.c =================================================================== --- netinet/ip_output.c (revision 241220) +++ netinet/ip_output.c (working copy) @@ -125,7 +125,8 @@ int error = 0; struct sockaddr_in *dst; struct in_ifaddr *ia; - int isbroadcast, sw_csum; + int isbroadcast; + uint16_t ip_len, ip_off, sw_csum; struct route iproute; struct rtentry *rte; /* cache for ro->ro_rt */ struct in_addr odst; @@ -501,6 +502,12 @@ hlen = ip->ip_hl << 2; #endif /* IPSEC */ + /* + * To network byte order. pfil(9) hooks and ip_fragment() expect this. + */ + ip->ip_len = htons(ip->ip_len); + ip->ip_off = htons(ip->ip_off); + /* Jump over all PFIL processing if hooks are not active. */ if (!PFIL_HOOKED(&V_inet_pfil_hook)) goto passout; @@ -537,6 +544,8 @@ } else { if (ia != NULL) ifa_free(&ia->ia_ifa); + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); goto again; /* Redo the routing table lookup. */ } } @@ -570,11 +579,16 @@ m_tag_delete(m, fwd_tag); if (ia != NULL) ifa_free(&ia->ia_ifa); + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); goto again; } #endif /* IPFIREWALL_FORWARD */ passout: + ip_len = ntohs(ip->ip_len); + ip_off = ntohs(ip->ip_off); + /* 127/8 must not appear on wire - RFC1122. */ if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { @@ -603,11 +617,9 @@ * If small enough for interface, or the interface will take * care of the fragmentation for us, we can just send directly. */ - if (ip->ip_len <= mtu || + if (ip_len <= mtu || (m->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 || - ((ip->ip_off & IP_DF) == 0 && (ifp->if_hwassist & CSUM_FRAGMENT))) { - ip->ip_len = htons(ip->ip_len); - ip->ip_off = htons(ip->ip_off); + ((ip_off & IP_DF) == 0 && (ifp->if_hwassist & CSUM_FRAGMENT))) { ip->ip_sum = 0; if (sw_csum & CSUM_DELAY_IP) ip->ip_sum = in_cksum(m, hlen); @@ -641,7 +653,7 @@ } /* Balk when DF bit is set or the interface didn't support TSO. */ - if ((ip->ip_off & IP_DF) || (m->m_pkthdr.csum_flags & CSUM_TSO)) { + if ((ip_off & IP_DF) || (m->m_pkthdr.csum_flags & CSUM_TSO)) { error = EMSGSIZE; IPSTAT_INC(ips_cantfrag); goto bad; @@ -710,8 +722,12 @@ int firstlen; struct mbuf **mnext; int nfrags; + uint16_t ip_len, ip_off; - if (ip->ip_off & IP_DF) { /* Fragmentation not allowed */ + ip_len = ntohs(ip->ip_len); + ip_off = ntohs(ip->ip_off); + + if (ip_off & IP_DF) { /* Fragmentation not allowed */ IPSTAT_INC(ips_cantfrag); return EMSGSIZE; } @@ -785,7 +801,7 @@ * The fragments are linked off the m_nextpkt of the original * packet, which after processing serves as the first fragment. */ - for (nfrags = 1; off < ip->ip_len; off += len, nfrags++) { + for (nfrags = 1; off < ip_len; off += len, nfrags++) { struct ip *mhip; /* ip header on the fragment */ struct mbuf *m; int mhlen = sizeof (struct ip); @@ -811,10 +827,10 @@ mhip->ip_hl = mhlen >> 2; } m->m_len = mhlen; - /* XXX do we need to add ip->ip_off below ? */ - mhip->ip_off = ((off - hlen) >> 3) + ip->ip_off; - if (off + len >= ip->ip_len) { /* last fragment */ - len = ip->ip_len - off; + /* XXX do we need to add ip_off below ? */ + mhip->ip_off = ((off - hlen) >> 3) + ip_off; + if (off + len >= ip_len) { /* last fragment */ + len = ip_len - off; m->m_flags |= M_LASTFRAG; } else mhip->ip_off |= IP_MF; @@ -849,11 +865,10 @@ * Update first fragment by trimming what's been copied out * and updating header. */ - m_adj(m0, hlen + firstlen - ip->ip_len); + m_adj(m0, hlen + firstlen - ip_len); m0->m_pkthdr.len = hlen + firstlen; ip->ip_len = htons((u_short)m0->m_pkthdr.len); - ip->ip_off |= IP_MF; - ip->ip_off = htons(ip->ip_off); + ip->ip_off = htons(ip_off | IP_MF); ip->ip_sum = 0; if (sw_csum & CSUM_DELAY_IP) ip->ip_sum = in_cksum(m0, hlen); @@ -1279,6 +1294,8 @@ * calls the output routine of the loopback "driver", but with an interface * pointer that might NOT be a loopback interface -- evil, but easier than * replicating that code here. + * + * IP header in host byte order. */ static void ip_mloopback(struct ifnet *ifp, struct mbuf *m, struct sockaddr_in *dst, Index: netinet/ip_input.c =================================================================== --- netinet/ip_input.c (revision 241220) +++ netinet/ip_input.c (working copy) @@ -380,20 +380,18 @@ struct ifaddr *ifa; struct ifnet *ifp; int checkif, hlen = 0; - u_short sum; + uint16_t sum, ip_len; int dchg = 0; /* dest changed after fw */ struct in_addr odst; /* original dst address */ M_ASSERTPKTHDR(m); if (m->m_flags & M_FASTFWD_OURS) { - /* - * Firewall or NAT changed destination to local. - * We expect ip_len and ip_off to be in host byte order. - */ m->m_flags &= ~M_FASTFWD_OURS; /* Set up some basics that will be used later. */ ip = mtod(m, struct ip *); + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); hlen = ip->ip_hl << 2; goto ours; } @@ -458,15 +456,11 @@ return; #endif - /* - * Convert fields to host representation. - */ - ip->ip_len = ntohs(ip->ip_len); - if (ip->ip_len < hlen) { + ip_len = ntohs(ip->ip_len); + if (ip_len < hlen) { IPSTAT_INC(ips_badlen); goto bad; } - ip->ip_off = ntohs(ip->ip_off); /* * Check that the amount of data in the buffers @@ -474,17 +468,17 @@ * Trim mbufs if longer than we expect. * Drop packet if shorter than we expect. */ - if (m->m_pkthdr.len < ip->ip_len) { + if (m->m_pkthdr.len < ip_len) { tooshort: IPSTAT_INC(ips_tooshort); goto bad; } - if (m->m_pkthdr.len > ip->ip_len) { + if (m->m_pkthdr.len > ip_len) { if (m->m_len == m->m_pkthdr.len) { - m->m_len = ip->ip_len; - m->m_pkthdr.len = ip->ip_len; + m->m_len = ip_len; + m->m_pkthdr.len = ip_len; } else - m_adj(m, ip->ip_len - m->m_pkthdr.len); + m_adj(m, ip_len - m->m_pkthdr.len); } #ifdef IPSEC /* @@ -519,6 +513,8 @@ #ifdef IPFIREWALL_FORWARD if (m->m_flags & M_FASTFWD_OURS) { m->m_flags &= ~M_FASTFWD_OURS; + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); goto ours; } if ((dchg = (m_tag_find(m, PACKET_TAG_IPFORWARD, NULL) != NULL)) != 0) { @@ -527,6 +523,8 @@ * packets originally destined to us to some other directly * connected host. */ + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); ip_forward(m, dchg); return; } @@ -534,6 +532,13 @@ passin: /* + * From now and up to output pfil(9) processing in ip_output() + * the header is in host byte order. + */ + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); + + /* * Process options and, if not destined for us, * ship it on. ip_dooptions returns 1 when an * error was detected (causing an icmp message @@ -1360,6 +1365,8 @@ * * The srcrt parameter indicates whether the packet is being forwarded * via a source route. + * + * IP header in host byte order. */ void ip_forward(struct mbuf *m, int srcrt) Index: netinet/ip_fastfwd.c =================================================================== --- netinet/ip_fastfwd.c (revision 241220) +++ netinet/ip_fastfwd.c (working copy) @@ -164,7 +164,7 @@ struct sockaddr_in *dst = NULL; struct ifnet *ifp; struct in_addr odest, dest; - u_short sum, ip_len; + uint16_t sum, ip_len, ip_off; int error = 0; int hlen, mtu; #ifdef IPFIREWALL_FORWARD @@ -340,12 +340,6 @@ * Step 3: incoming packet firewall processing */ - /* - * Convert to host representation - */ - ip->ip_len = ntohs(ip->ip_len); - ip->ip_off = ntohs(ip->ip_off); - odest.s_addr = dest.s_addr = ip->ip_dst.s_addr; /* @@ -472,8 +466,6 @@ forwardlocal: /* * Return packet for processing by ip_input(). - * Keep host byte order as expected at ip_input's - * "ours"-label. */ m->m_flags |= M_FASTFWD_OURS; if (ro.ro_rt) @@ -500,6 +492,8 @@ /* * Step 6: send off the packet */ + ip_len = ntohs(ip->ip_len); + ip_off = ntohs(ip->ip_off); /* * Check if route is dampned (when ARP is unable to resolve) @@ -515,7 +509,7 @@ /* * Check if there is enough space in the interface queue */ - if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >= + if ((ifp->if_snd.ifq_len + ip_len / ifp->if_mtu + 1) >= ifp->if_snd.ifq_maxlen) { IPSTAT_INC(ips_odropped); /* would send source quench here but that is depreciated */ @@ -539,14 +533,9 @@ else mtu = ifp->if_mtu; - if (ip->ip_len <= mtu || - (ifp->if_hwassist & CSUM_FRAGMENT && (ip->ip_off & IP_DF) == 0)) { + if (ip_len <= mtu || + (ifp->if_hwassist & CSUM_FRAGMENT && (ip_off & IP_DF) == 0)) { /* - * Restore packet header fields to original values - */ - ip->ip_len = htons(ip->ip_len); - ip->ip_off = htons(ip->ip_off); - /* * Send off the packet via outgoing interface */ error = (*ifp->if_output)(ifp, m, @@ -555,7 +544,7 @@ /* * Handle EMSGSIZE with icmp reply needfrag for TCP MTU discovery */ - if (ip->ip_off & IP_DF) { + if (ip_off & IP_DF) { IPSTAT_INC(ips_cantfrag); icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_NEEDFRAG, 0, mtu); @@ -565,10 +554,6 @@ * We have to fragment the packet */ m->m_pkthdr.csum_flags |= CSUM_IP; - /* - * ip_fragment expects ip_len and ip_off in host byte - * order but returns all packets in network byte order - */ if (ip_fragment(ip, &m, mtu, ifp->if_hwassist, (~ifp->if_hwassist & CSUM_DELAY_IP))) { goto drop; Index: contrib/ipfilter/netinet/fil.c =================================================================== --- contrib/ipfilter/netinet/fil.c (revision 241220) +++ contrib/ipfilter/netinet/fil.c (working copy) @@ -2513,7 +2513,7 @@ } else #endif { -#if (defined(OpenBSD) && (OpenBSD >= 200311)) && defined(_KERNEL) +#if ((defined(OpenBSD) && (OpenBSD >= 200311)) || (defined(FreeBSD) && (__FreeBSD_version >= 1000019))) && defined(_KERNEL) ip->ip_len = ntohs(ip->ip_len); ip->ip_off = ntohs(ip->ip_off); #endif @@ -2777,7 +2777,7 @@ RWLOCK_EXIT(&ipf_global); #ifdef _KERNEL -# if (defined(OpenBSD) && (OpenBSD >= 200311)) +# if (defined(OpenBSD) && (OpenBSD >= 200311)) || (defined(FreeBSD) && (__FreeBSD_version >= 1000019)) if (FR_ISPASS(pass) && (v == 4)) { ip = fin->fin_ip; ip->ip_len = ntohs(ip->ip_len); Index: netpfil/pf/pf_ioctl.c =================================================================== --- netpfil/pf/pf_ioctl.c (revision 241220) +++ netpfil/pf/pf_ioctl.c (working copy) @@ -3473,52 +3473,22 @@ pf_check_in(void *arg, struct mbuf **m, struct ifnet *ifp, int dir, struct inpcb *inp) { - /* - * XXX Wed Jul 9 22:03:16 2003 UTC - * OpenBSD has changed its byte ordering convention on ip_len/ip_off - * in network stack. OpenBSD's network stack have converted - * ip_len/ip_off to host byte order frist as FreeBSD. - * Now this is not true anymore , so we should convert back to network - * byte order. - */ - struct ip *h = NULL; int chk; - if ((*m)->m_pkthdr.len >= (int)sizeof(struct ip)) { - /* if m_pkthdr.len is less than ip header, pf will handle. */ - h = mtod(*m, struct ip *); - HTONS(h->ip_len); - HTONS(h->ip_off); - } - CURVNET_SET(ifp->if_vnet); chk = pf_test(PF_IN, ifp, m, inp); - CURVNET_RESTORE(); + if (chk && *m) { m_freem(*m); *m = NULL; } - if (*m != NULL) { - /* pf_test can change ip header location */ - h = mtod(*m, struct ip *); - NTOHS(h->ip_len); - NTOHS(h->ip_off); - } - return chk; + + return (chk); } static int pf_check_out(void *arg, struct mbuf **m, struct ifnet *ifp, int dir, struct inpcb *inp) { - /* - * XXX Wed Jul 9 22:03:16 2003 UTC - * OpenBSD has changed its byte ordering convention on ip_len/ip_off - * in network stack. OpenBSD's network stack have converted - * ip_len/ip_off to host byte order frist as FreeBSD. - * Now this is not true anymore , so we should convert back to network - * byte order. - */ - struct ip *h = NULL; int chk; /* We need a proper CSUM befor we start (s. OpenBSD ip_output) */ @@ -3526,26 +3496,14 @@ in_delayed_cksum(*m); (*m)->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; } - if ((*m)->m_pkthdr.len >= (int)sizeof(*h)) { - /* if m_pkthdr.len is less than ip header, pf will handle. */ - h = mtod(*m, struct ip *); - HTONS(h->ip_len); - HTONS(h->ip_off); - } - CURVNET_SET(ifp->if_vnet); + chk = pf_test(PF_OUT, ifp, m, inp); - CURVNET_RESTORE(); if (chk && *m) { m_freem(*m); *m = NULL; } - if (*m != NULL) { - /* pf_test can change ip header location */ - h = mtod(*m, struct ip *); - NTOHS(h->ip_len); - NTOHS(h->ip_off); - } - return chk; + + return (chk); } #endif @@ -3554,10 +3512,6 @@ pf_check6_in(void *arg, struct mbuf **m, struct ifnet *ifp, int dir, struct inpcb *inp) { - - /* - * IPv6 is not affected by ip_len/ip_off byte order changes. - */ int chk; /* @@ -3579,9 +3533,6 @@ pf_check6_out(void *arg, struct mbuf **m, struct ifnet *ifp, int dir, struct inpcb *inp) { - /* - * IPv6 does not affected ip_len/ip_off byte order changes. - */ int chk; /* We need a proper CSUM before we start (s. OpenBSD ip_output) */ Index: netpfil/ipfw/ip_fw_pfil.c =================================================================== --- netpfil/ipfw/ip_fw_pfil.c (revision 241220) +++ netpfil/ipfw/ip_fw_pfil.c (working copy) @@ -125,10 +125,6 @@ int ipfw; int ret; - /* all the processing now uses ip_len in net format */ - if (mtod(*m0, struct ip *)->ip_v == 4) - SET_NET_IPLEN(mtod(*m0, struct ip *)); - /* convert dir to IPFW values */ dir = (dir == PFIL_IN) ? DIR_IN : DIR_OUT; bzero(&args, sizeof(args)); @@ -288,8 +284,7 @@ FREE_PKT(*m0); *m0 = NULL; } - if (*m0 && mtod(*m0, struct ip *)->ip_v == 4) - SET_HOST_IPLEN(mtod(*m0, struct ip *)); + return ret; } Index: sys/param.h =================================================================== --- sys/param.h (revision 241220) +++ sys/param.h (working copy) @@ -58,7 +58,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 1000018 /* Master, propagated to newvers */ +#define __FreeBSD_version 1000019 /* Master, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, Index: net/if_bridge.c =================================================================== --- net/if_bridge.c (revision 241220) +++ net/if_bridge.c (working copy) @@ -3093,15 +3093,6 @@ switch (ether_type) { case ETHERTYPE_IP: /* - * before calling the firewall, swap fields the same as - * IP does. here we assume the header is contiguous - */ - ip = mtod(*mp, struct ip *); - - ip->ip_len = ntohs(ip->ip_len); - ip->ip_off = ntohs(ip->ip_off); - - /* * Run pfil on the member interface and the bridge, both can * be skipped by clearing pfil_member or pfil_bridge. * @@ -3139,7 +3130,7 @@ } } - /* Recalculate the ip checksum and restore byte ordering */ + /* Recalculate the ip checksum. */ ip = mtod(*mp, struct ip *); hlen = ip->ip_hl << 2; if (hlen < sizeof(struct ip)) @@ -3151,8 +3142,6 @@ if (ip == NULL) goto bad; } - ip->ip_len = htons(ip->ip_len); - ip->ip_off = htons(ip->ip_off); ip->ip_sum = 0; if (hlen == sizeof(struct ip)) ip->ip_sum = in_cksum_hdr(ip); Index: net/if_enc.c =================================================================== --- net/if_enc.c (revision 241220) +++ net/if_enc.c (working copy) @@ -270,23 +270,8 @@ switch (ip->ip_v) { #ifdef INET case 4: - /* - * before calling the firewall, swap fields the same as - * IP does. here we assume the header is contiguous - */ - ip->ip_len = ntohs(ip->ip_len); - ip->ip_off = ntohs(ip->ip_off); - error = pfil_run_hooks(&V_inet_pfil_hook, mp, encif, dir, NULL); - - if (*mp == NULL || error != 0) - break; - - /* restore byte ordering */ - ip = mtod(*mp, struct ip *); - ip->ip_len = htons(ip->ip_len); - ip->ip_off = htons(ip->ip_off); break; #endif #ifdef INET6 --r5Pyd7+fXNt84Ff3-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 12:23: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 ED435106566C for ; Fri, 5 Oct 2012 12:23:46 +0000 (UTC) (envelope-from tretuliy2@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id B9E8B8FC0C for ; Fri, 5 Oct 2012 12:23:46 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so1915384pad.13 for ; Fri, 05 Oct 2012 05:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YUTR9bUwP+z00UyRuYUZQVHhaT/+9Joq2/TkkzrFZY8=; b=pJPwbKWsyc4a69IHP9bYGRe6kqMr9hmPrQOpCsfW98jvzU9onU+2cxdWWqvRKsBn6F 0dytJaUUYwU6iuedcT/Ri9wHddPTCuBr9fNLbbMjkMJ/S/m3ukYajixmNQYcqOBVATsc 0/aGHnBb1GU9lA5BUTOTiI2101+c6zhzBffpkJ8MvVDx5Rpw0jN0wjfZS0Mpq9ohk73g qhxQOPERBUeBQRFQ/awNZuGQoZa5rYQ56aPTqkb4Yl3K/0v43UbwEaQNUe5DFU2NX1kY F2j3Cklh67f4OieVioc4/v2R43CEly1T2f0EqbMkmi8BWpcFjN1wX1Rd3GoAFCizje73 jVVw== MIME-Version: 1.0 Received: by 10.66.75.168 with SMTP id d8mr21130397paw.63.1349439826164; Fri, 05 Oct 2012 05:23:46 -0700 (PDT) Received: by 10.66.156.170 with HTTP; Fri, 5 Oct 2012 05:23:46 -0700 (PDT) In-Reply-To: <506E7BE7.2080104@airnet.opole.pl> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <506DC933.7080307@airnet.opole.pl> <20121004222327.GA40357@in-addr.com> <506E7BE7.2080104@airnet.opole.pl> Date: Fri, 5 Oct 2012 15:23:46 +0300 Message-ID: From: Vadim Urazaev To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:23:47 -0000 I don`t know if it`s important, anyway I have only one routing table on server where this issue happens. Maybe we should check our kernel configuration to find something similar in it. For example I have options ZERO_COPY_SOCKETS From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 12:29: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 8F7FA1065673 for ; Fri, 5 Oct 2012 12:29:38 +0000 (UTC) (envelope-from krzysiek@airnet.opole.pl) Received: from base.airnet.opole.pl (ns2.airmax.pl [176.111.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5FB8FC0C for ; Fri, 5 Oct 2012 12:29:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by base.airnet.opole.pl (Postfix) with ESMTP id 210D37FF02E for ; Fri, 5 Oct 2012 14:29:38 +0200 (CEST) Received: from base.airnet.opole.pl ([127.0.0.1]) by localhost (mail.airnet.opole.pl [127.0.0.1]) (maiad, port 10024) with ESMTP id 38128-07 for ; Fri, 5 Oct 2012 14:29:37 +0200 (CEST) Received: from [10.10.11.223] (unknown [176.111.138.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: krzysiek@airnet.opole.pl) by base.airnet.opole.pl (Postfix) with ESMTPSA id DDC2C7FF020 for ; Fri, 5 Oct 2012 14:29:37 +0200 (CEST) Message-ID: <506ED2AD.8000408@airnet.opole.pl> Date: Fri, 05 Oct 2012 14:29:33 +0200 From: Krzysztof Barcikowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <506DC933.7080307@airnet.opole.pl> <20121004222327.GA40357@in-addr.com> <506E7BE7.2080104@airnet.opole.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:29:38 -0000 W dniu 2012-10-05 14:23, Vadim Urazaev pisze: > I don`t know if it`s important, anyway I have only one routing table on > server where this issue happens. > Maybe we should check our kernel configuration to find something similar in > it. > For example I have > options ZERO_COPY_SOCKETS > _______________________________________________ > 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" > Hi, I have GENERIC kernel + the following options/devices: device pf device pflog options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options HZ=1000 options PANIC_REBOOT_WAIT_TIME=3 options ALTQ options ALTQ_RIO options ALTQ_RED options ALTQ_PRIQ options ALTQ_CBQ options ALTQ_HFSC options ALTQ_NOPCC Best regards! Krzysiek Barcikowski From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 13:01:41 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 3C71A1065672; Fri, 5 Oct 2012 13:01:41 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6B08FC08; Fri, 5 Oct 2012 13:01:39 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so924945bkc.13 for ; Fri, 05 Oct 2012 06:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gRsTi2fZ1kK/d7FTfsTjQfWH6mE9nINVPoIKDiSfGJI=; b=WiK/rY/hwxYuTsEkvjmpAKWPYUstcbYj7sBP+7yTqreluiaeAGX9v6LxuTnH/UaNEL //eqCrLdxz7jUjEG6vmwKklWmag9QZamsMEdsRcHsOUIsRJCTk3T2eRhgVxZWMHwJhRf oooVPZJT/T2EDOFd81F5YA/7JO/y+iz2hB/xWpf41BJCOqf40iiZ+UsJUiZXOkZynX2x MtCy1HjRb83MirzZbtZS7DXeP5+5RfzEkK/MF2HRvDoSdzbB8S3trYqgjgqppR+vkNpQ JQAsSNLkEu5vcPtIpEsia0Gzsld014UoijEJ5i+fW/SYF3YSCFbv6zVD3xXC2Vs6IkwD bQ4g== MIME-Version: 1.0 Received: by 10.205.127.146 with SMTP id ha18mr2819402bkc.130.1349442099017; Fri, 05 Oct 2012 06:01:39 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.204.143.148 with HTTP; Fri, 5 Oct 2012 06:01:38 -0700 (PDT) In-Reply-To: <20121005114716.GP34622@FreeBSD.org> References: <20121005114716.GP34622@FreeBSD.org> Date: Fri, 5 Oct 2012 15:01:38 +0200 X-Google-Sender-Auth: kNi2zcKFCTM54C3qfmtp5ynnzfc Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:01:41 -0000 Hello Gleb, it would be better to switch to net byte order allover rather than trade one for the other. This makes it even more tricky to understand the code than it is. If you do the work its better to do the full thing in one shot and switch to netbyte order. speaking of pf(4) side of things please do not loose the VIMAGE calls! On Fri, Oct 5, 2012 at 1:47 PM, Gleb Smirnoff wrote: > Hello, > > once the pfil(9) API was introduced in FreeBSD, our main packet filter, > the ipfw(4) worked in host byte order, that's why the pfil(9) API was > violated: the AF_INET hooks were entered with packet in host byte order. > > If you look into pfil(9) manpage you'll see that it still declares > opposite :) > > Today, pf(4) and ipfw(4) both are working with net byte order. But > pfil(9) still supplies packet to them in host byte order, contrary > to what API manual says. > > Right now, we have tons of places where byte order is swapped there > and back to resolve this mess: > > - when entering pf > - when entering ipfw > - when calling pfil hooks from enc(4) > - when calling pfil hooks from if_bridge(4) > - in ip_fastfwd.c > > Also, we've got ip_fragment() that accepts packet in host byte > order and emits new ones in net byte order. > > Moreover, when we put packets into the NETISR_IP queue, we put them > in different byte order: those that have M_FASTFWD_OURS flag are in > host byte order, while all others are in net. > > Attached patch does the following: > > - all packets in NETISR_IP queue are in net byte order > - ip_input() is entered in net byte order and converts packet > to host byte order right _after_ processing pfil(9) hooks > - ip_output() is entered in host byte order and converts packet > to net byte order right _before_ processing pfil(9) hooks > - ip_fragment() accepts and emits packet in net byte order > - ip_forward(), ip_mloopback() use host byte order (untouched actually) > - ip_fastforward() no longer modifies packet at all (except ip_ttl) > - swapping of byte order there and back removed from the following modules: > pf(4), ipfw(4), enc(4), if_bridge(4) > - swapping of byte order added to ipfilter(4), based on __FreeBSD_version > - __FreeBSD_version bumped > - manual page updated > > -- > Totus tuus, Glebius. > > _______________________________________________ > 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" -- Ermal From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 13:12:30 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 DB783106566C; Fri, 5 Oct 2012 13:12:30 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 54D628FC0A; Fri, 5 Oct 2012 13:12:30 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q95DCSld051955; Fri, 5 Oct 2012 17:12:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q95DCSKX051954; Fri, 5 Oct 2012 17:12:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 5 Oct 2012 17:12:28 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20121005131228.GQ34622@glebius.int.ru> References: <20121005114716.GP34622@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:12:31 -0000 Ermal, On Fri, Oct 05, 2012 at 03:01:38PM +0200, Ermal Lu?i wrote: E> it would be better to switch to net byte order allover rather than E> trade one for the other. E> This makes it even more tricky to understand the code than it is. E> If you do the work its better to do the full thing in one shot and E> switch to netbyte order. Please read carefully my description and patch. It creates a definite points in stack where byte order is swapped. One point where it is swapped into host, and one point where it is swapped back into net. Patch already narrows down the scope of host byte order in the stack, host byte order is now between to definite points. If anyone ever wants to switch entire stack to net byte order, let it be. Current patch is just step in this direction. The fast forwarding path is already entirely in net byte order. Even if run with ipfw and/or pf. E> speaking of pf(4) side of things please do not loose the VIMAGE calls! Yeah, can you explain please why do we need them here? The pfil hooks are always run already in some defined VNET context, don't they? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 13:39:22 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 84A9C106566C; Fri, 5 Oct 2012 13:39:22 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id BBCA68FC17; Fri, 5 Oct 2012 13:39:21 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c50so1479399eek.13 for ; Fri, 05 Oct 2012 06:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=s/0btmeNVjieDXGglPHzL7TasNwXzAKiU7KaemUcQwM=; b=qMq0G9Ub0wWe7FGXV/LOqJhetblg/S19BNZfInH1lZC4kLiuoMGqoW1cNntB3shlHI kEDCrsxDWNvpQV/8uOvJRa6FnT+86I5zaazhGkf2EeOUfaXeBNajZeRLPdY5OgEBvVR2 hjHoCDKSHWygxTGviiJAtv//r4UeKPUPq5Hkv/nnW+Us8l8GiuvnfNYjFaJEWg2W5MU1 R8LUzR+gCyrVXr0Fh8cwY55Uu/sEHPlaSO+26wjw3voKOnaCOxvkr9Upene7Fo7Vkvot ydnV6gGD9B6WlYiecuQUKuHC/ho580FcV3Ubj/GyY+41hkyOEL+U4Eu1lreeMQW8js53 LkNQ== MIME-Version: 1.0 Received: by 10.14.184.134 with SMTP id s6mr12989242eem.46.1349444360599; Fri, 05 Oct 2012 06:39:20 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.14.193.193 with HTTP; Fri, 5 Oct 2012 06:39:20 -0700 (PDT) In-Reply-To: <20121005131228.GQ34622@glebius.int.ru> References: <20121005114716.GP34622@FreeBSD.org> <20121005131228.GQ34622@glebius.int.ru> Date: Fri, 5 Oct 2012 06:39:20 -0700 X-Google-Sender-Auth: ilA88dGxjoofZEWUIvf_dvcl3rA Message-ID: From: Luigi Rizzo To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ermal Lu?i , net@freebsd.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:39:22 -0000 On Fri, Oct 5, 2012 at 6:12 AM, Gleb Smirnoff wrote: > Ermal, > > On Fri, Oct 05, 2012 at 03:01:38PM +0200, Ermal Lu?i wrote: > E> it would be better to switch to net byte order allover rather than > E> trade one for the other. > E> This makes it even more tricky to understand the code than it is. > E> If you do the work its better to do the full thing in one shot and > E> switch to netbyte order. > > Please read carefully my description and patch. It creates a definite > points in stack where byte order is swapped. One point where it is > swapped into host, and one point where it is swapped back into net. > > Patch already narrows down the scope of host byte order in the stack, > host byte order is now between to definite points. If anyone ever wants > to switch entire stack to net byte order, let it be. Current patch is > just step in this direction. > Good. I too wanted to be sure that the change is a step towards "everything in NET order" even though nobody expects you to do it all at once. (having everything in the same byte order is obviously useful because one does not need to deal with the differences, but having everything in wire format is even more interesting because it eventually makes buffers readonly). cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 13:50:30 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id CDEC110656C3; Fri, 5 Oct 2012 13:50:30 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 488E514FBDE; Fri, 5 Oct 2012 13:50:28 +0000 (UTC) Message-ID: <506EE57A.7040005@FreeBSD.org> Date: Fri, 05 Oct 2012 17:49:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Gleb Smirnoff References: <20121005114716.GP34622@FreeBSD.org> In-Reply-To: <20121005114716.GP34622@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 13:50:30 -0000 On 05.10.2012 15:47, Gleb Smirnoff wrote: > Hello, > > once the pfil(9) API was introduced in FreeBSD, our main packet filter, > the ipfw(4) worked in host byte order, that's why the pfil(9) API was > violated: the AF_INET hooks were entered with packet in host byte order. > > Moreover, when we put packets into the NETISR_IP queue, we put them > in different byte order: those that have M_FASTFWD_OURS flag are in > host byte order, while all others are in net. divert and ng_ipfw are another places where we play these games, too. > > Attached patch does the following: > > - all packets in NETISR_IP queue are in net byte order > - ip_input() is entered in net byte order and converts packet > to host byte order right _after_ processing pfil(9) hooks > - ip_output() is entered in host byte order and converts packet > to net byte order right _before_ processing pfil(9) hooks > - ip_fragment() accepts and emits packet in net byte order > - ip_forward(), ip_mloopback() use host byte order (untouched actually) > - ip_fastforward() no longer modifies packet at all (except ip_ttl) > - swapping of byte order there and back removed from the following modules: > pf(4), ipfw(4), enc(4), if_bridge(4) > - swapping of byte order added to ipfilter(4), based on __FreeBSD_version > - __FreeBSD_version bumped > - manual page updated That's great! Unified approach for host/network fields in entire kernel will help greatly in making/debugging complex (netgraph, pfil or divert) paths. Additionally, this is a good step to make mbuf entirely r/o (which can help in some cases like transparent firewalling, for example). > > > > _______________________________________________ > 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" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 14:22:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43E98106566B for ; Fri, 5 Oct 2012 14:22:27 +0000 (UTC) (envelope-from dblais@interplex.ca) Received: from smtp1.interplex.ca (smtp1.interplex.ca [207.134.105.5]) by mx1.freebsd.org (Postfix) with ESMTP id DA4C88FC17 for ; Fri, 5 Oct 2012 14:22:26 +0000 (UTC) Received: by smtp1.interplex.ca (Postfix, from userid 106) id 3E5FF509AD; Fri, 5 Oct 2012 10:22:20 -0400 (EDT) Received: from smtp.interplex.ca (office.abi.ca [207.134.166.34]) by smtp1.interplex.ca (Postfix) with ESMTP id E250750967 for ; Fri, 5 Oct 2012 10:22:19 -0400 (EDT) Received: from WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295]) by WIN2008.Domnt.abi.ca ([fe80::e06e:fea4:8702:2295%12]) with mapi; Fri, 5 Oct 2012 10:22:19 -0400 From: Dominic Blais To: "freebsd-net@freebsd.org" Date: Fri, 5 Oct 2012 10:22:06 -0400 Thread-Topic: Default route destination changing without warning follow-up Thread-Index: Ac2i9Rx/IBupsp9DTGyOP2+KWMZPgQAD4VQQ Message-ID: <2DE61B0869B7484997BCA012845482C7EBE8E28162@WIN2008.Domnt.abi.ca> References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <506DC933.7080307@airnet.opole.pl> <20121004222327.GA40357@in-addr.com> <506E7BE7.2080104@airnet.opole.pl> <506ED2AD.8000408@airnet.opole.pl> In-Reply-To: <506ED2AD.8000408@airnet.opole.pl> Accept-Language: fr-FR, fr-CA Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, fr-CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:22:27 -0000 Hi, I'm using GENERIC. Everything else is added as loaded module. Here's my kldstat: Id Refs Address Size Name 1 34 0xffffffff80200000 11cdab0 kernel 2 1 0xffffffff81412000 2a134 pf.ko 3 2 0xffffffff8143d000 c16e ipfw.ko 4 1 0xffffffff8144a000 a079 dummynet.ko 5 1 0xffffffff81455000 1ba9 ng_socket.ko 6 9 0xffffffff81457000 8e12 netgraph.ko 7 1 0xffffffff81460000 1861 ng_mppc.ko 8 1 0xffffffff81462000 284 rc4.ko 9 1 0xffffffff81463000 1579 ng_ether.ko 10 1 0xffffffff81465000 3165 ng_pppoe.ko 11 1 0xffffffff81469000 aa5 ng_tee.ko 12 1 0xffffffff8146a000 138d ng_iface.ko 13 1 0xffffffff8146c000 4605 ng_ppp.ko 14 1 0xffffffff81471000 a29 ng_tcpmss.ko 15 1 0xffffffff81472000 1f12 ng_vjc.ko -- -----Message d'origine----- De=A0: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org]= De la part de Krzysztof Barcikowski Envoy=E9=A0: 5 octobre 2012 08:30 =C0=A0: freebsd-net@freebsd.org Objet=A0: Re: Default route destination changing without warning follow-up W dniu 2012-10-05 14:23, Vadim Urazaev pisze: > I don`t know if it`s important, anyway I have only one routing table=20 > on server where this issue happens. > Maybe we should check our kernel configuration to find something=20 > similar in it. > For example I have > options ZERO_COPY_SOCKETS > _______________________________________________ > 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" > Hi, I have GENERIC kernel + the following options/devices: device pf device pflog options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options HZ=3D1000 options PANIC_REBOOT_WAIT_TIME=3D3 options ALTQ options ALTQ_RIO options ALTQ_RED options ALTQ_PRIQ options ALTQ_CBQ options ALTQ_HFSC options ALTQ_NOPCC Best regards! Krzysiek Barcikowski _______________________________________________ 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 Oct 5 14:27:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDE1B1065670 for ; Fri, 5 Oct 2012 14:27:28 +0000 (UTC) (envelope-from krzysiek@airnet.opole.pl) Received: from base.airnet.opole.pl (ns2.airmax.pl [176.111.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4628FC19 for ; Fri, 5 Oct 2012 14:27:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by base.airnet.opole.pl (Postfix) with ESMTP id 4CEA27FF02E for ; Fri, 5 Oct 2012 16:27:23 +0200 (CEST) Received: from base.airnet.opole.pl ([127.0.0.1]) by localhost (mail.airnet.opole.pl [127.0.0.1]) (maiad, port 10024) with ESMTP id 90585-02 for ; Fri, 5 Oct 2012 16:27:23 +0200 (CEST) Received: from [10.10.11.223] (unknown [176.111.138.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: krzysiek@airnet.opole.pl) by base.airnet.opole.pl (Postfix) with ESMTPSA id 17A787FF020 for ; Fri, 5 Oct 2012 16:27:23 +0200 (CEST) Message-ID: <506EEE46.1000604@airnet.opole.pl> Date: Fri, 05 Oct 2012 16:27:18 +0200 From: Krzysztof Barcikowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <2DE61B0869B7484997BCA012845482C7EBE8E280DB@WIN2008.Domnt.abi.ca> <5068AC17.8020704@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DC@WIN2008.Domnt.abi.ca> <5068ADCC.5030105@FreeBSD.org> <2DE61B0869B7484997BCA012845482C7EBE8E280DD@WIN2008.Domnt.abi.ca> <5068B48E.2070303@FreeBSD.org> <20121004160240.GA1967@funkthat.com> <506DC933.7080307@airnet.opole.pl> <20121004222327.GA40357@in-addr.com> <506E7BE7.2080104@airnet.opole.pl> <506ED2AD.8000408@airnet.opole.pl> <2DE61B0869B7484997BCA012845482C7EBE8E28162@WIN2008.Domnt.abi.ca> In-Reply-To: <2DE61B0869B7484997BCA012845482C7EBE8E28162@WIN2008.Domnt.abi.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Default route destination changing without warning follow-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 14:27:29 -0000 W dniu 2012-10-05 16:22, Dominic Blais pisze: > Hi, > > I'm using GENERIC. Everything else is added as loaded module. > > Here's my kldstat: > > I forgot about modules, here they are: Id Refs Address Size Name 1 13 0xffffffff80200000 12200c8 kernel 2 1 0xffffffff81421000 215f8 geom_mirror.ko 3 1 0xffffffff81443000 29e8 coretemp.ko 4 1 0xffffffff81446000 17450 dummynet.ko From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 15:05:24 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 58C2F1065670; Fri, 5 Oct 2012 15:05:24 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A1BC68FC16; Fri, 5 Oct 2012 15:05:22 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so1001264bkc.13 for ; Fri, 05 Oct 2012 08:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QOmg5vPTVu4T01P1ZB9v7gI7QB2J2dZe+Byaf8XO9Co=; b=UstDc5IuGeULzlGsmFRYLb8VN2MDEidZBf/lJG+e6v5W8ajhn2FONXHupGVgLrUaDL qj6LpEO1yDCG7TQoBEz/J5vfbYgEhTIYXTJQfVpYIOWqdDiEBKNh186k06fUA/GtGCpN B2dBaVEH0+/LD6Y6Ku0OMijxjXuBXT6liVfNgs2ezH6gon+xK5cKhJIvAKQFmHY6cWyU Q+Zesp0g1gFMe+8ABv+JUhTFdLg/Uz5g7AyphHT4Y9I1DFTa/2MoDUcWOd7/m5ZyAgpp ayw8tM/Uge6n9uLhzmAVKyAf6Aim5KB6jWwOuaKBAxveCCaztvPYRXYePSJZyP7Hv+hV 7WqA== MIME-Version: 1.0 Received: by 10.205.127.146 with SMTP id ha18mr2974028bkc.130.1349449516054; Fri, 05 Oct 2012 08:05:16 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.204.143.148 with HTTP; Fri, 5 Oct 2012 08:05:16 -0700 (PDT) In-Reply-To: <20121005131228.GQ34622@glebius.int.ru> References: <20121005114716.GP34622@FreeBSD.org> <20121005131228.GQ34622@glebius.int.ru> Date: Fri, 5 Oct 2012 17:05:16 +0200 X-Google-Sender-Auth: ZSs9BbnZ8PLtjvM0IgUvyTUEdEg Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:05:24 -0000 On Fri, Oct 5, 2012 at 3:12 PM, Gleb Smirnoff wrote: > Ermal, > > On Fri, Oct 05, 2012 at 03:01:38PM +0200, Ermal Lu?i wrote: > E> it would be better to switch to net byte order allover rather than > E> trade one for the other. > E> This makes it even more tricky to understand the code than it is. > E> If you do the work its better to do the full thing in one shot and > E> switch to netbyte order. > > Please read carefully my description and patch. It creates a definite > points in stack where byte order is swapped. One point where it is > swapped into host, and one point where it is swapped back into net. > > Patch already narrows down the scope of host byte order in the stack, > host byte order is now between to definite points. If anyone ever wants > to switch entire stack to net byte order, let it be. Current patch is > just step in this direction. > > The fast forwarding path is already entirely in net byte order. Even > if run with ipfw and/or pf. > > E> speaking of pf(4) side of things please do not loose the VIMAGE calls! > > Yeah, can you explain please why do we need them here? The pfil hooks > are always run already in some defined VNET context, don't they? > from my testing at the time these were needed otherwise you will get issues. I do not remember the details but i put those there because were required. There is no overhead as well from leaving those there. > -- > Totus tuus, Glebius. -- Ermal From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 15:18:04 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 344931065670; Fri, 5 Oct 2012 15:18:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 826B38FC22; Fri, 5 Oct 2012 15:18:00 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q95FHx5u052560; Fri, 5 Oct 2012 19:17:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q95FHxOW052559; Fri, 5 Oct 2012 19:17:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 5 Oct 2012 19:17:59 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20121005151759.GT34622@glebius.int.ru> References: <20121005114716.GP34622@FreeBSD.org> <20121005131228.GQ34622@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org, zec@FreeBSD.org, bjoern@FreeBSD.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:18:04 -0000 On Fri, Oct 05, 2012 at 05:05:16PM +0200, Ermal Lu?i wrote: E> > E> speaking of pf(4) side of things please do not loose the VIMAGE calls! E> > E> > Yeah, can you explain please why do we need them here? The pfil hooks E> > are always run already in some defined VNET context, don't they? E> > E> E> from my testing at the time these were needed otherwise you will get issues. E> I do not remember the details but i put those there because were required. E> There is no overhead as well from leaving those there. Well, we need to understand things we are doing, and not put code blindly. AFAIU, any packet filter is called in already defined VNET context. Let me put Marko and Bjoern to Cc and ask their help. Marko, Bjoern, we are speaking about CURVNET_SET()/CURVNET_RESTORE() in pf_check* functions in pf_ioctl.c. Do we need them? IMO, any pfil(9) hook should be called in defined context. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 16:17:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E87B91065670; Fri, 5 Oct 2012 16:17:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BF81A8FC0C; Fri, 5 Oct 2012 16:17:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1658FB9BF; Fri, 5 Oct 2012 12:17:39 -0400 (EDT) From: John Baldwin To: yongari@freebsd.org Date: Fri, 5 Oct 2012 12:05:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201210050344.q953i2gj071631@freefall.freebsd.org> In-Reply-To: <201210050344.q953i2gj071631@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201210051205.30084.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 05 Oct 2012 12:17:39 -0400 (EDT) Cc: freebsd-net@freebsd.org Subject: Re: kern/171825: [ale] [patch] ale driver msix setup typo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:17:40 -0000 On Thursday, October 04, 2012 11:44:02 pm linimon@freebsd.org wrote: > Old Synopsis: ale driver msix setup typo > New Synopsis: [ale] [patch] ale driver msix setup typo > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Fri Oct 5 03:43:27 UTC 2012 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=171825 This patch looks correct to me. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 16:44:37 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A2431065674; Fri, 5 Oct 2012 16:44:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0928FC19; Fri, 5 Oct 2012 16:44:37 +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 q95GiaMr078740; Fri, 5 Oct 2012 16:44:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q95Giave078736; Fri, 5 Oct 2012 16:44:36 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 16:44:36 GMT Message-Id: <201210051644.q95Giave078736@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/172364: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:44:37 -0000 Old Synopsis: cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode New Synopsis: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 16:44:19 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=172364 From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 17:23:29 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B80C1065676; Fri, 5 Oct 2012 17:23:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2F38FC12; Fri, 5 Oct 2012 17:23:29 +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 q95HNSkU084183; Fri, 5 Oct 2012 17:23:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q95HNSKA084179; Fri, 5 Oct 2012 17:23:28 GMT (envelope-from linimon) Date: Fri, 5 Oct 2012 17:23:28 GMT Message-Id: <201210051723.q95HNSKA084179@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, np@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/170713: [cxgb] Driver must be loaded after boot due to timing issues checking for kern.ipc.nmb* values set via /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:23:29 -0000 Synopsis: [cxgb] Driver must be loaded after boot due to timing issues checking for kern.ipc.nmb* values set via /boot/loader.conf Responsible-Changed-From-To: freebsd-net->np Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 5 17:23:14 UTC 2012 Responsible-Changed-Why: by request. http://www.freebsd.org/cgi/query-pr.cgi?pr=170713 From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 17:50:15 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90ED2106566C for ; Fri, 5 Oct 2012 17:50:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C2A58FC0A for ; Fri, 5 Oct 2012 17:50:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q95HoF3G087288 for ; Fri, 5 Oct 2012 17:50:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q95HoEuo087272; Fri, 5 Oct 2012 17:50:14 GMT (envelope-from gnats) Date: Fri, 5 Oct 2012 17:50:14 GMT Message-Id: <201210051750.q95HoEuo087272@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Navdeep Parhar Cc: Subject: Re: kern/172364: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Navdeep Parhar List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:50:15 -0000 The following reply was made to PR kern/172364; it has been noted by GNATS. From: Navdeep Parhar To: bug-followup@FreeBSD.org, atkin901@gmail.com Cc: Subject: Re: kern/172364: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode Date: Fri, 05 Oct 2012 10:41:56 -0700 Here's an untested patch that you could try: diff -r 62ccc35abd89 sys/dev/cxgbe/t4_main.c --- a/sys/dev/cxgbe/t4_main.c Wed Oct 03 15:57:10 2012 -0700 +++ b/sys/dev/cxgbe/t4_main.c Fri Oct 05 10:32:11 2012 -0700 @@ -2995,7 +2995,7 @@ { struct ifnet *vlan; - if (arg != ifp) + if (arg != ifp || ifp->if_type != IFT_ETHER) return; vlan = VLAN_DEVAT(ifp, vid); By the way, I noticed your kernel name is CXGBETOE. Keep in mind that hw TCP offload over an if_lagg is unimplemented as of now. TCP offload over an if_vlan directly over cxgbe will work just fine. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 18:40:09 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05BF61065673 for ; Fri, 5 Oct 2012 18:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DEAA98FC17 for ; Fri, 5 Oct 2012 18:40:08 +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 q95Ie8tI092870 for ; Fri, 5 Oct 2012 18:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q95Ie8Rv092865; Fri, 5 Oct 2012 18:40:08 GMT (envelope-from gnats) Date: Fri, 5 Oct 2012 18:40:08 GMT Message-Id: <201210051840.q95Ie8Rv092865@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mark Atkinson Cc: Subject: Re: kern/172364: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Atkinson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:40:09 -0000 The following reply was made to PR kern/172364; it has been noted by GNATS. From: Mark Atkinson To: Navdeep Parhar Cc: bug-followup@FreeBSD.org Subject: Re: kern/172364: [cxbge] cxbge_vlan_config() Fatal trap 12: page fault while in kernel mode Date: Fri, 05 Oct 2012 11:32:01 -0700 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/2012 10:41, Navdeep Parhar wrote: > Here's an untested patch that you could try: OK, thank you. That gets past the crash. I have to bounce the ports an extra time (ifconfig cxgbe0-1 down/up) in order for the trunk to form, but traffic is now passing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBvJ6EACgkQrDN5kXnx8yYc0wCfaOdFEPRW5KdGa5fNgLyn/rfE 7QwAn0fhAW55QVMy5i/bPoeh0l+FBv0H =p/5/ -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sat Oct 6 03:29:37 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BC471065670; Sat, 6 Oct 2012 03:29:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4738FC0A; Sat, 6 Oct 2012 03:29:37 +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 q963Tb88059635; Sat, 6 Oct 2012 03:29:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q963TaDt059629; Sat, 6 Oct 2012 03:29:36 GMT (envelope-from linimon) Date: Sat, 6 Oct 2012 03:29:36 GMT Message-Id: <201210060329.q963TaDt059629@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171840: [ip6] IPv6 packets transmitting only on queue 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 03:29:37 -0000 Old Synopsis: IPv6 packets transmitting only on queue 0 New Synopsis: [ip6] IPv6 packets transmitting only on queue 0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 6 03:29:13 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171840 From owner-freebsd-net@FreeBSD.ORG Sat Oct 6 06:59:47 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 3A62F106566C; Sat, 6 Oct 2012 06:59:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id A616E8FC08; Sat, 6 Oct 2012 06:59:46 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q966xiOc056076; Sat, 6 Oct 2012 10:59:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q966xiJd056075; Sat, 6 Oct 2012 10:59:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 6 Oct 2012 10:59:44 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20121006065944.GW34622@glebius.int.ru> References: <20121005114716.GP34622@FreeBSD.org> <20121005131228.GQ34622@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 06:59:47 -0000 On Fri, Oct 05, 2012 at 05:05:16PM +0200, Ermal Lu?i wrote: E> > E> speaking of pf(4) side of things please do not loose the VIMAGE calls! E> > E> > Yeah, can you explain please why do we need them here? The pfil hooks E> > are always run already in some defined VNET context, don't they? E> E> from my testing at the time these were needed otherwise you will get issues. E> I do not remember the details but i put those there because were required. E> There is no overhead as well from leaving those there. Well, Bjoern and Marko are silent. Let's look ourselves. The most generic case is Ethernet interfaces, and yes, ether_input_internal() sets VNET context. Then packet is demuxed to IP level, ip_input() calls pfil(9) hooks and that all is in defined context. If you remember some issues w/o CURVNET in pf_check_*(), then probably you were using some kind of interface (may be some tunneling) that didn't set VNET context. In this case this is bug in the code of this interface, and not in pf. I will remove CURVNET_SET/RESTORE in a separate commit, not related to byte ordering. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Oct 6 19:08:11 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31173106566B; Sat, 6 Oct 2012 19:08:11 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 050EF8FC0A; Sat, 6 Oct 2012 19:08:11 +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 q96J8A9t093770; Sat, 6 Oct 2012 19:08:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q96J8A2n093766; Sat, 6 Oct 2012 19:08:10 GMT (envelope-from linimon) Date: Sat, 6 Oct 2012 19:08:10 GMT Message-Id: <201210061908.q96J8A2n093766@freefall.freebsd.org> To: linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171728: [arp] arp issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 19:08:11 -0000 Old Synopsis: ARP ISSUE New Synopsis: [arp] arp issue Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 6 19:06:04 UTC 2012 Responsible-Changed-Why: atttempt to reclassify and add misfiled followups. To submitter: was this in reply to another PR? http://www.freebsd.org/cgi/query-pr.cgi?pr=171728