From owner-freebsd-net@FreeBSD.ORG Sun May 10 02:15:03 2009 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 2930A1065675 for ; Sun, 10 May 2009 02:15:03 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (ns1.ip6.com.au [125.255.112.202]) by mx1.freebsd.org (Postfix) with ESMTP id DFEE48FC23 for ; Sun, 10 May 2009 02:15:02 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id B0C22287FD for ; Sun, 10 May 2009 12:14:49 +1000 (EST) Received: from secure.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id 7090D2880B for ; Sun, 10 May 2009 12:14:49 +1000 (EST) Received: from 220.233.42.226 (SquirrelMail authenticated user sam) by secure.ip6.com.au with HTTP; Sun, 10 May 2009 12:14:49 +1000 (EST) Message-ID: <26744.220.233.42.226.1241921689.squirrel@secure.ip6.com.au> Date: Sun, 10 May 2009 12:14:49 +1000 (EST) From: "Sam Wan" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP Subject: IPSEC_ESP and IPSEC_FILTERGIF in 7.2 kernel config file 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, 10 May 2009 02:15:03 -0000 I tried to build a kernel include the following options, but it failed with something like "unknown option IPSEC_ESP and IPSEC_FILTERGIF..." options IPSEC #IP security options IPSEC_ESP #IP security options IPSEC_FILTERGIF #filter ipsec packets from a tunnel #options IPSEC_NAT_T How do I enable ipsec in 7.2? do I have to rebuild the kernel with the IPSEC options built-in? and which options are supported at the moment? Thanks From owner-freebsd-net@FreeBSD.ORG Sun May 10 02:59:46 2009 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 9D9FB106566C for ; Sun, 10 May 2009 02:59:46 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4EA8FC0C for ; Sun, 10 May 2009 02:59:46 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n4A2Y3RT009883; Sat, 9 May 2009 22:34:03 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200905100234.n4A2Y3RT009883@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 09 May 2009 22:35:27 -0400 To: "Sam Wan" , freebsd-net@freebsd.org From: Mike Tancsa In-Reply-To: <26744.220.233.42.226.1241921689.squirrel@secure.ip6.com.au > References: <26744.220.233.42.226.1241921689.squirrel@secure.ip6.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: IPSEC_ESP and IPSEC_FILTERGIF in 7.2 kernel config file 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, 10 May 2009 02:59:48 -0000 At 10:14 PM 5/9/2009, Sam Wan wrote: >How do I enable ipsec in 7.2? do I have to rebuild the kernel with the >IPSEC options built-in? and which options are supported at the moment? On 7.x, you need to rebuild your kernel with options IPSEC device crypto and optionally options IPSEC_FILTERTUNNEL If you add IPSEC_FILTERTUNNEL, you might as well add device enc ---Mike ---Mike From owner-freebsd-net@FreeBSD.ORG Sun May 10 04:52:37 2009 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 C49D01065674 for ; Sun, 10 May 2009 04:52:37 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (ns1.ip6.com.au [125.255.112.202]) by mx1.freebsd.org (Postfix) with ESMTP id 87C0B8FC18 for ; Sun, 10 May 2009 04:52:32 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id 70A942880C for ; Sun, 10 May 2009 14:52:19 +1000 (EST) Received: from secure.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id 2AEFF28804 for ; Sun, 10 May 2009 14:52:19 +1000 (EST) Received: from 220.233.42.226 (SquirrelMail authenticated user sam) by secure.ip6.com.au with HTTP; Sun, 10 May 2009 14:52:19 +1000 (EST) Message-ID: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> Date: Sun, 10 May 2009 14:52:19 +1000 (EST) From: "Sam Wan" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP Subject: kernel hang when reboot with loaded ip_vs_rr.ko 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, 10 May 2009 04:52:38 -0000 I built ip_vs_rr.ko in 7.2 Release. There is no problem when loaded ipvs.ko. After I loaded ip_vs_rr.ko, and reboot the system, the entire system is hang. Here is a list of the ip_vs moudles have built: modules # ls -l total 118 drwxr-xr-x 2 root wheel 512 May 8 15:20 ./ drwxr-xr-x 8 root wheel 512 May 9 21:22 ../ -r-xr-xr-x 1 root wheel 5366 May 8 15:20 ip_vs_dh.ko* -r-xr-xr-x 1 root wheel 8249 May 8 15:20 ip_vs_lblc.ko* -r-xr-xr-x 1 root wheel 9783 May 8 15:20 ip_vs_lblcr.ko* -r-xr-xr-x 1 root wheel 4560 May 8 15:20 ip_vs_lc.ko* -r-xr-xr-x 1 root wheel 4592 May 8 15:20 ip_vs_nq.ko* -r-xr-xr-x 1 root wheel 4838 May 8 15:20 ip_vs_rr.ko* -r-xr-xr-x 1 root wheel 4574 May 8 15:20 ip_vs_sed.ko* -r-xr-xr-x 1 root wheel 5366 May 8 15:20 ip_vs_sh.ko* -r-xr-xr-x 1 root wheel 4574 May 8 15:20 ip_vs_wlc.ko* -r-xr-xr-x 1 root wheel 5634 May 8 15:20 ip_vs_wrr.ko* -r-xr-xr-x 1 root wheel 43081 May 8 15:20 ipvs.ko* -rw-r--r-- 1 root wheel 360 May 8 15:20 linker.hints What is the problem? Important is how to get more information about this kernel module is hang? Your suggestion is highly appreciated. Thanks From owner-freebsd-net@FreeBSD.ORG Sun May 10 06:58:34 2009 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 83520106564A for ; Sun, 10 May 2009 06:58:34 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 587A28FC18 for ; Sun, 10 May 2009 06:58:34 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so1902164rvb.43 for ; Sat, 09 May 2009 23:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=o7AMEYJQieDzJbJhFsSmbItajQvh4ArU2X9gjJcA0VA=; b=LGV34l7NmVm9FjEyVdszDSGwlH5/Xr94XSkm9NYCKgYx3i3UaAzUn9gc+l3pOxpsHF OdCaGXEFQaM8VaiJneIjVXRsuuQ2ZX4gtKb3v8piR8RlBmglT2/SIQzFNKtzGb378hXz NWjsUbRBdWGCFuvyoYEJ8U80874+D4h/BBvSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=AvmaSbRQARVXjMz0pNsoTvps/3VxZhMCkevV8cJcUP45ltj+WbBK/VgQUHRZEdClCF PvDs7rJ6TwSBT6+sJUUlgs8UPRU86Vne9KcO1hpQNgswAXQ1VxeEOzgbcuwkFhqZ5tyL oU2fchqPqqY3BOv1Y4mQrMOmOYOcqNNMU8x5c= MIME-Version: 1.0 Received: by 10.142.139.14 with SMTP id m14mr2274413wfd.157.1241938714094; Sat, 09 May 2009 23:58:34 -0700 (PDT) In-Reply-To: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> Date: Sun, 10 May 2009 16:58:34 +1000 Message-ID: <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> From: Sam Wun To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: kernel hang when reboot with loaded ip_vs_rr.ko 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, 10 May 2009 06:58:34 -0000 It is IPVS patch, for FreeBSD. I am in Melbourne Australia. Can you send me email regarding about how to fix this issue? BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will execute the reboot / shutdown normally. When I executed reboot/shutdown with the ip_vs_rr still loaded in the kernel, the system hangs after the console printed the message "...vnode...." Here are the modules loaded: # kldstat Id Refs Address Size Name 1 5 0xc0400000 a434d8 kernel 2 1 0xc0e44000 6a45c acpi.ko 3 1 0xc469d000 2000 ip_vs_rr.ko 4 1 0xc469f000 b000 ipvs.ko # shutdown -h now ..... Syncing disks, vnodes remaining... 1 1 0 0 done All buffers synced. IPVS: ipvs unloaded then it hangs forever. Another problem is I can't put ipvs_vs_rr_load=3D"yes" in the /boot/loader.conf file. The system will hang when it tried to boot the kernel with this ko loaded. Thanks On Sun, May 10, 2009 at 2:52 PM, Sam Wan wrote: > I built ip_vs_rr.ko in 7.2 Release. > There is no problem when loaded ipvs.ko. > After I loaded ip_vs_rr.ko, and reboot the system, the entire system is h= ang. > Here is a list of the ip_vs moudles have built: > > modules # ls -l > total 118 > drwxr-xr-x =A02 root =A0wheel =A0 =A0512 May =A08 15:20 ./ > drwxr-xr-x =A08 root =A0wheel =A0 =A0512 May =A09 21:22 ../ > -r-xr-xr-x =A01 root =A0wheel =A0 5366 May =A08 15:20 ip_vs_dh.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 8249 May =A08 15:20 ip_vs_lblc.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 9783 May =A08 15:20 ip_vs_lblcr.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 4560 May =A08 15:20 ip_vs_lc.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 4592 May =A08 15:20 ip_vs_nq.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 4838 May =A08 15:20 ip_vs_rr.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 4574 May =A08 15:20 ip_vs_sed.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 5366 May =A08 15:20 ip_vs_sh.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 4574 May =A08 15:20 ip_vs_wlc.ko* > -r-xr-xr-x =A01 root =A0wheel =A0 5634 May =A08 15:20 ip_vs_wrr.ko* > -r-xr-xr-x =A01 root =A0wheel =A043081 May =A08 15:20 ipvs.ko* > -rw-r--r-- =A01 root =A0wheel =A0 =A0360 May =A08 15:20 linker.hints > > What is the problem? > Important is how to get more information about this kernel module is =A0h= ang? > > Your suggestion is highly appreciated. > > Thanks > > > _______________________________________________ > 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 May 10 07:25:58 2009 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 03782106566B for ; Sun, 10 May 2009 07:25:58 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id CACE08FC18 for ; Sun, 10 May 2009 07:25:57 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1891727wfg.7 for ; Sun, 10 May 2009 00:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=41QslKYaOnD3+eehGPsp8gszheZa5mkMeMI/ja0wx6Y=; b=ZXwGT6HPnxujzIMTrpVSUCtbyobuq7bhTO5KxP+hE57TvD5IwfOVQfgoTqtY8LxxxW DVKBQPNsWgj4saZhV7Ft0eGl6XGjPxDOgjvT/QEYcgDrJsYS+4djmiH0jioKjA6slhzF fUu7Fy7Gu40+C717WDicNMXgoSaNl8i0RTRYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Tje3m8snaylMMXvTZ1nJpliqTAXHKHJcF5H0b4XxYH42BRovmweqOdnQGGfDRZr3Hq uVitxLWIYYVZvgUjvmIaYRcctfNCvRV8P0a+w0XqKWlbQgDJ0ucCFQnKRa53Gmce2cYF mxlByIC25Wv7WNcxmE80GMCOKgfu0XqwKDedM= MIME-Version: 1.0 Received: by 10.142.217.3 with SMTP id p3mr1732733wfg.228.1241940357378; Sun, 10 May 2009 00:25:57 -0700 (PDT) In-Reply-To: References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> Date: Sun, 10 May 2009 17:25:57 +1000 Message-ID: <736c47cb0905100025i8bf54fev3466e49d28809197@mail.gmail.com> From: Sam Wun To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: kernel hang when reboot with loaded ip_vs_rr.ko 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, 10 May 2009 07:25:58 -0000 That patch is for 7.0-current. But I applied to 7.2 Release, and built successfully. Manually kldload and kldunload has no problem. On Sun, May 10, 2009 at 5:16 PM, Adrian Chadd wrote: > What version of FreeBSD is the IPVS patch for? > > And hi from Perth. :) What are you guys doing with FreeBSD in > particular out there? > > > > Adrian > > 2009/5/10 Sam Wun : >> It is IPVS patch, for FreeBSD. >> I am in Melbourne Australia. >> Can you send me email regarding about how to fix this issue? >> BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will >> execute the reboot / shutdown normally. >> When I executed reboot/shutdown with the ip_vs_rr still loaded in the >> kernel, the system hangs after the console printed the message >> "...vnode...." >> >> Here are the modules loaded: >> # kldstat >> Id Refs Address =A0 =A0Size =A0 =A0 Name >> =A01 =A0 =A05 0xc0400000 a434d8 =A0 kernel >> =A02 =A0 =A01 0xc0e44000 6a45c =A0 =A0acpi.ko >> =A03 =A0 =A01 0xc469d000 2000 =A0 =A0 ip_vs_rr.ko >> =A04 =A0 =A01 0xc469f000 b000 =A0 =A0 ipvs.ko >> >> =A0# shutdown -h now >> ..... >> Syncing disks, vnodes remaining... 1 1 0 0 done >> All buffers synced. >> IPVS: ipvs unloaded >> >> then it hangs forever. >> >> Another problem is I can't put ipvs_vs_rr_load=3D"yes" in the >> /boot/loader.conf file. The system will hang when it tried to boot the >> kernel with this ko loaded. >> >> Thanks >> >> >> On Sun, May 10, 2009 at 2:52 PM, Sam Wan wrote: >>> I built ip_vs_rr.ko in 7.2 Release. >>> There is no problem when loaded ipvs.ko. >>> After I loaded ip_vs_rr.ko, and reboot the system, the entire system is= hang. >>> Here is a list of the ip_vs moudles have built: >>> >>> modules # ls -l >>> total 118 >>> drwxr-xr-x =A02 root =A0wheel =A0 =A0512 May =A08 15:20 ./ >>> drwxr-xr-x =A08 root =A0wheel =A0 =A0512 May =A09 21:22 ../ >>> -r-xr-xr-x =A01 root =A0wheel =A0 5366 May =A08 15:20 ip_vs_dh.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 8249 May =A08 15:20 ip_vs_lblc.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 9783 May =A08 15:20 ip_vs_lblcr.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 4560 May =A08 15:20 ip_vs_lc.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 4592 May =A08 15:20 ip_vs_nq.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 4838 May =A08 15:20 ip_vs_rr.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 4574 May =A08 15:20 ip_vs_sed.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 5366 May =A08 15:20 ip_vs_sh.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 4574 May =A08 15:20 ip_vs_wlc.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A0 5634 May =A08 15:20 ip_vs_wrr.ko* >>> -r-xr-xr-x =A01 root =A0wheel =A043081 May =A08 15:20 ipvs.ko* >>> -rw-r--r-- =A01 root =A0wheel =A0 =A0360 May =A08 15:20 linker.hints >>> >>> What is the problem? >>> Important is how to get more information about this kernel module is = =A0hang? >>> >>> Your suggestion is highly appreciated. >>> >>> Thanks >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Sun May 10 08:14:10 2009 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 7078E1065670 for ; Sun, 10 May 2009 08:14:10 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by mx1.freebsd.org (Postfix) with SMTP id D1FF38FC18 for ; Sun, 10 May 2009 08:14:09 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: (qmail 26923 invoked by uid 503); 10 May 2009 07:47:38 -0000 Received: from b7.ovh.net (HELO mail437.ha.ovh.net) (213.186.33.57) by 30.mail-out.ovh.net with SMTP; 10 May 2009 07:47:37 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 10 May 2009 07:47:27 -0000 Received: from unknown (HELO localhost) (maciej@suszko.eu@62.61.57.118) by ns0.ovh.net with SMTP; 10 May 2009 07:47:26 -0000 Date: Sun, 10 May 2009 09:47:21 +0200 From: Maciej Suszko To: Sam Wun Message-ID: <20090510094721.32a7f4bf@suszko.eu> In-Reply-To: <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/UTdDjm60RronMiFAnmEQ=TE"; protocol="application/pgp-signature" X-Ovh-Tracer-Id: 9695405573999714504 X-Ovh-Remote: 62.61.57.118 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N Cc: freebsd-net@freebsd.org Subject: Re: kernel hang when reboot with loaded ip_vs_rr.ko 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, 10 May 2009 08:14:10 -0000 --Sig_/UTdDjm60RronMiFAnmEQ=TE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sam Wun wrote: > It is IPVS patch, for FreeBSD. > I am in Melbourne Australia. > Can you send me email regarding about how to fix this issue? > BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will > execute the reboot / shutdown normally. > When I executed reboot/shutdown with the ip_vs_rr still loaded in the > kernel, the system hangs after the console printed the message > "...vnode...." >=20 > Here are the modules loaded: > # kldstat > Id Refs Address Size Name > 1 5 0xc0400000 a434d8 kernel > 2 1 0xc0e44000 6a45c acpi.ko > 3 1 0xc469d000 2000 ip_vs_rr.ko > 4 1 0xc469f000 b000 ipvs.ko >=20 > # shutdown -h now > ..... > Syncing disks, vnodes remaining... 1 1 0 0 done > All buffers synced. > IPVS: ipvs unloaded >=20 > then it hangs forever. >=20 > Another problem is I can't put ipvs_vs_rr_load=3D"yes" in the > /boot/loader.conf file. The system will hang when it tried to boot the > kernel with this ko loaded. Hi, Check the freebsd-clister archive - AFAIR I've tested ipvs+keepalived a time ago and the panic problem was already known. Someone even sent some rc scripts to mailing list. It was a year ago or so... --=20 regards, Maciej Suszko. --Sig_/UTdDjm60RronMiFAnmEQ=TE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoGho0ACgkQCikUk0l7iGoY/gCffvx6hCexiDPr7nJTMrdvR987 UdYAnjGQaXTIs4USZanxqls+Z2whna2f =6i3f -----END PGP SIGNATURE----- --Sig_/UTdDjm60RronMiFAnmEQ=TE-- From owner-freebsd-net@FreeBSD.ORG Sun May 10 10:51:38 2009 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 B46881065672 for ; Sun, 10 May 2009 10:51:38 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (ns1.ip6.com.au [125.255.112.202]) by mx1.freebsd.org (Postfix) with ESMTP id 73F5B8FC13 for ; Sun, 10 May 2009 10:51:37 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id EBC162880B for ; Sun, 10 May 2009 20:51:24 +1000 (EST) Received: from secure.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id A973D28805 for ; Sun, 10 May 2009 20:51:24 +1000 (EST) Received: from 220.233.42.226 (SquirrelMail authenticated user sam) by secure.ip6.com.au with HTTP; Sun, 10 May 2009 20:51:24 +1000 (EST) Message-ID: <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> In-Reply-To: <20090510094721.32a7f4bf@suszko.eu> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> <20090510094721.32a7f4bf@suszko.eu> Date: Sun, 10 May 2009 20:51:24 +1000 (EST) From: "Sam Wan" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: kernel hang when reboot with loaded ip_vs_rr.ko 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, 10 May 2009 10:51:38 -0000 Unfortunately, after started ip_vs_rr with this script, reboot still failed, but interestingly, system shutdown is running fine with these moduels loaded. Thanks Sam > Sam Wun wrote: >> It is IPVS patch, for FreeBSD. >> I am in Melbourne Australia. >> Can you send me email regarding about how to fix this issue? >> BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will >> execute the reboot / shutdown normally. >> When I executed reboot/shutdown with the ip_vs_rr still loaded in the >> kernel, the system hangs after the console printed the message >> "...vnode...." >> >> Here are the modules loaded: >> # kldstat >> Id Refs Address Size Name >> 1 5 0xc0400000 a434d8 kernel >> 2 1 0xc0e44000 6a45c acpi.ko >> 3 1 0xc469d000 2000 ip_vs_rr.ko >> 4 1 0xc469f000 b000 ipvs.ko >> >> # shutdown -h now >> ..... >> Syncing disks, vnodes remaining... 1 1 0 0 done >> All buffers synced. >> IPVS: ipvs unloaded >> >> then it hangs forever. >> >> Another problem is I can't put ipvs_vs_rr_load="yes" in the >> /boot/loader.conf file. The system will hang when it tried to boot the >> kernel with this ko loaded. > > Hi, > > Check the freebsd-clister archive - AFAIR I've tested ipvs+keepalived a > time ago and the panic problem was already known. Someone even sent > some rc scripts to mailing list. It was a year ago or so... > -- > regards, Maciej Suszko. > From owner-freebsd-net@FreeBSD.ORG Sun May 10 12:16:21 2009 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 9B2771065670 for ; Sun, 10 May 2009 12:16:21 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by mx1.freebsd.org (Postfix) with SMTP id 095DA8FC1B for ; Sun, 10 May 2009 12:16:20 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: (qmail 31044 invoked by uid 503); 10 May 2009 13:01:40 -0000 Received: from b9.ovh.net (HELO mail95.ha.ovh.net) (213.186.33.59) by 27.mail-out.ovh.net with SMTP; 10 May 2009 13:01:40 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 10 May 2009 12:16:15 -0000 Received: from unknown (HELO localhost) (maciej@suszko.eu@62.61.57.118) by ns0.ovh.net with SMTP; 10 May 2009 12:16:13 -0000 Date: Sun, 10 May 2009 14:16:09 +0200 From: Maciej Suszko To: "Sam Wan" Message-ID: <20090510141609.3a11b5eb@suszko.eu> In-Reply-To: <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> <20090510094721.32a7f4bf@suszko.eu> <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/VetFMm9.MkeGB_B_IYs0x=W"; protocol="application/pgp-signature" X-Ovh-Tracer-Id: 14234752523319730178 X-Ovh-Remote: 62.61.57.118 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N Cc: freebsd-net@freebsd.org Subject: Re: kernel hang when reboot with loaded ip_vs_rr.ko 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, 10 May 2009 12:16:21 -0000 --Sig_/VetFMm9.MkeGB_B_IYs0x=W Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Sam Wan" wrote: > Unfortunately, after started ip_vs_rr with this script, reboot still > failed, but interestingly, system shutdown is running fine with these > moduels loaded. >=20 > Thanks > Sam >=20 > > Sam Wun wrote: > >> It is IPVS patch, for FreeBSD. > >> I am in Melbourne Australia. > >> Can you send me email regarding about how to fix this issue? > >> BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system > >> will execute the reboot / shutdown normally. > >> When I executed reboot/shutdown with the ip_vs_rr still loaded in > >> the kernel, the system hangs after the console printed the message > >> "...vnode...." > >> > >> Here are the modules loaded: > >> # kldstat > >> Id Refs Address Size Name > >> 1 5 0xc0400000 a434d8 kernel > >> 2 1 0xc0e44000 6a45c acpi.ko > >> 3 1 0xc469d000 2000 ip_vs_rr.ko > >> 4 1 0xc469f000 b000 ipvs.ko > >> > >> # shutdown -h now > >> ..... > >> Syncing disks, vnodes remaining... 1 1 0 0 done > >> All buffers synced. > >> IPVS: ipvs unloaded > >> > >> then it hangs forever. > >> > >> Another problem is I can't put ipvs_vs_rr_load=3D"yes" in the > >> /boot/loader.conf file. The system will hang when it tried to boot > >> the kernel with this ko loaded. > > > > Hi, > > > > Check the freebsd-clister archive - AFAIR I've tested > > ipvs+keepalived a time ago and the panic problem was already known. > > Someone even sent some rc scripts to mailing list. It was a year > > ago or so... 1) Answer below the text. 2) The 'reboot' command should be used only when you're in single mode. Use shutdown -r to clean reboot as written in reboot(8) and shutdown(8). I haven't looked at the script, but I think everything should be fine if modules are loaded on boot and unloaded before reboot (within some start/stop action). --=20 regards, Maciej Suszko. --Sig_/VetFMm9.MkeGB_B_IYs0x=W Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoGxYwACgkQCikUk0l7iGoxOgCdE8D41QXF+g0plvOHmRY/IWD7 mZMAnimEkXx4v30Xyb+hwLorSdZytu2B =bDv0 -----END PGP SIGNATURE----- --Sig_/VetFMm9.MkeGB_B_IYs0x=W-- From owner-freebsd-net@FreeBSD.ORG Sun May 10 12:21:06 2009 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 9F1141065674 for ; Sun, 10 May 2009 12:21:06 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (ns1.ip6.com.au [125.255.112.202]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0348FC12 for ; Sun, 10 May 2009 12:21:06 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id AFDDE2880B for ; Sun, 10 May 2009 22:20:53 +1000 (EST) Received: from secure.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id 6C336287FD for ; Sun, 10 May 2009 22:20:53 +1000 (EST) Received: from 220.233.42.226 (SquirrelMail authenticated user sam) by secure.ip6.com.au with HTTP; Sun, 10 May 2009 22:20:53 +1000 (EST) Message-ID: <20813.220.233.42.226.1241958053.squirrel@secure.ip6.com.au> In-Reply-To: <20090510141609.3a11b5eb@suszko.eu> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> <20090510094721.32a7f4bf@suszko.eu> <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> <20090510141609.3a11b5eb@suszko.eu> Date: Sun, 10 May 2009 22:20:53 +1000 (EST) From: "Sam Wan" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: kernel hang when reboot with loaded ip_vs_rr.ko 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, 10 May 2009 12:21:07 -0000 > > 1) Answer below the text. > 2) The 'reboot' command should be used only when you're in single mode. > Use shutdown -r to clean reboot as written in reboot(8) and > shutdown(8). Ok, confirmed shutdown -r works with ip_* loaded. > I haven't looked at the script, but I think everything should be fine > if modules are loaded on boot and unloaded before reboot (within some > start/stop action). > -- Now, I will give it a shot and see how it handle keeplive for two web servers. Will keep you posted. Thanks Sam > regards, Maciej Suszko. > From owner-freebsd-net@FreeBSD.ORG Sun May 10 15:50:26 2009 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 2C878106564A for ; Sun, 10 May 2009 15:50:26 +0000 (UTC) (envelope-from info@lottery.co.uk) Received: from hm995.locaweb.com.br (hm995.locaweb.com.br [200.234.200.100]) by mx1.freebsd.org (Postfix) with ESMTP id C83668FC1C for ; Sun, 10 May 2009 15:50:25 +0000 (UTC) (envelope-from info@lottery.co.uk) Received: from hm1207.locaweb.com.br (hm1207.locaweb.com.br [200.234.200.152]) by hm995.locaweb.com.br (Postfix) with ESMTP id DB486A2E19848 for ; Sun, 10 May 2009 12:33:32 -0300 (BRT) Received: by hm1207.locaweb.com.br (Postfix, from userid 50714) id D68973C070; Sun, 10 May 2009 12:31:38 -0300 (BRT) X-Locaweb-ID: 63325679646D56794F69426F625445794D4463734948567A5A584A755957316C4F694232595735705957526C5932467A64484A76 To: freebsd-net@freebsd.org X-PHP-Script: www.vaniadecastro.com.br/zero.php for 196.3.182.250 From: UK NATIONAL LOTTERY MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20090510153332.D68973C070@hm1207.locaweb.com.br> Date: Sun, 10 May 2009 12:31:38 -0300 (BRT) Subject: National Lottery: Your Email Won X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zonal.anderson-spencer@msn.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 15:50:26 -0000 United Kingdom National Lottery 101 Bovill Road, London SE23 1EL United Kingdom File #: EGS/2251256003/02 Congratulations, we are pleased to inform you of the result of the United Kingdom National Lottery Award Winners. Your email address have been randomly selected as a winner in the ongoing United Kingdom National Lottery Online program, the draw was held on 30th April, 2009 using a computerized balloting system of selection. The United Kingdom National Lottery is aimed and focused at global development and improvement of living standard across the world. Free £77 Million Pounds won including *four* Ten Million Pounds Winners and *fourteen* Millionaires plus thousands of other cash prizes. Winner from all over the world, India, France, Singapore, USA, United Kingdom, Spain, South America, Malaysia, Indonesia, South Africa, Belgium, Denmark, Ireland and many more. We wish to express our sincere apologies for the late notification, this free award online program is been conducted bi-quarterly. United Kingdom National Lottery Free Award draw was conducted at the Europe Issuing Centre, you were selected from an exclusive list of 1,000,000,000 e-mail addresses of internet users from the following categories; consumers, professionals and corporate bodies picked by an advanced automated random computer ballot search from the internet 'NO TICKETS OR DRAFTS WERE SOLD'. Your email address attached to Security File #: EGS/2251256003/02 with Serial number No: 002839 emerged as a winner of Six Hundred Thousand Pounds (£600.000.00 GBP), therefore you are eligible to file claim for your prize as one of our lucky winners for the payout of your total sum after a thorough verification that will be conducted by our various credible financial institutions. This online program is precisely aimed at enabling all internet users across the world benefit from the United Kingdom National Lottery, your email address falls within the First Category Winner as such your file has been designated to our European Centre, where the complete verification and payout will be conducted only if there are no exceptions during the claims process, to file your claim immediately please contact our International Programs Director Anderson Spencer with the following information: 1. Name in full----------------------------------------- 2. Phone/Fax------------------------------------------- 3. Occupation------------------------------------------ TO: Contact Person: Anderson Spencer European Payment Issuing Office Tel: +447024065192 (8am - 5pm GMT) Fax: +447092894160 Email: zonal.anderson-spencer@msn.com NOTE: In order to benefit from this program, you are advised in your own best interest to file your claim not later than 7days days from the date of this notification to avoid disqualification; anybody under the age of 18 is automatically disqualified. Please include this File #: EGS/2251256003/02 in every of your correspondence with our Foreign Service Director Anderson Spencer. IMPORTANT: Solemn confidentiality should be ensured until successful remittance of your prize to you to avoid undue taking of advantage, unwarranted claim and abuse of program, any breach of confidentiality on the part of the winner will result to automatic disqualification. Sincerely Yours, Mrs. Julie Van Hans, Executive Director. United Kingdom National Lottery. From owner-freebsd-net@FreeBSD.ORG Sun May 10 16:40:02 2009 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 56190106566C; Sun, 10 May 2009 16:40:02 +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 29E0D8FC16; Sun, 10 May 2009 16:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4AGe2Dt034411; Sun, 10 May 2009 16:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4AGe2qM034402; Sun, 10 May 2009 16:40:02 GMT (envelope-from gnats) Date: Sun, 10 May 2009 16:40:02 GMT Message-Id: <200905101640.n4AGe2qM034402@freefall.freebsd.org> To: Cezary Morga , net@FreeBSD.org From: FreeBSD-gnats-submit@FreeBSD.org In-Reply-To: Your message of Sun, 10 May 2009 16:36:16 GMT <200905101636.n4AGaGTf015369@www.freebsd.org> Cc: Subject: Re: ports/134429: Update databases/tora from 1.3.22 to 2.0.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 16:40:02 -0000 Thank you very much for your problem report. It has the internal identification `ports/134429'. The individual assigned to look at your report is: freebsd-ports-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=134429 >Category: ports >Responsible: freebsd-ports-bugs >Synopsis: Update databases/tora from 1.3.22 to 2.0.0 >Arrival-Date: Sun May 10 16:40:01 UTC 2009 From owner-freebsd-net@FreeBSD.ORG Mon May 11 07:43:16 2009 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 0E7EB106567A for ; Mon, 11 May 2009 07:43:16 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8FF308FC17 for ; Mon, 11 May 2009 07:43:15 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from hamilton.upcnetadm.upcnet.es (hamilton.upcnetadm.upcnet.es [147.83.2.240]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id n4B7h2sE031302 for ; Mon, 11 May 2009 09:43:04 +0200 Received: from [147.83.40.234] ([147.83.40.234]) by hamilton.upcnetadm.upcnet.es (Lotus Domino Release 5.0.12) with ESMTP id 2009051109431288:44793 ; Mon, 11 May 2009 09:43:12 +0200 Message-ID: <4A07D68D.9090006@entel.upc.edu> Date: Mon, 11 May 2009 09:41:01 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.95.7 X-MIMETrack: Itemize by SMTP Server on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 11/05/2009 09:43:13, Serialize by Router on hamilton/UPC(Release 5.0.12 |February 13, 2003) at 11/05/2009 09:43:13, Serialize complete at 11/05/2009 09:43:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 11 May 2009 09:43:04 +0200 (CEST) Subject: Problem/freezes with if_bwi and firmware 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, 11 May 2009 07:43:16 -0000 Hi, I'm using a Broadcom BCM4312 with i386 FreeBSD-8.0 updated May 08 2009. Ports up to date. Using net/bwi-firmware-kmod. Loading first bwi_v3_ucode and then if_bwi. When starting the supplicant, it associates fine and it works for a period of time. From time to time I start to lose signal, I'm my log I can see the following message : May 11 08:42:51 gusiport kernel: bwi0: firmware rev 0x0127, patch level 0x000e May 11 08:42:51 gusiport kernel: bwi0: bwi_intr: intr PHY TX error Many of those messages per second. This is the first problem with if_bwi. It forces me to restart by hand the wlan1 device associated to bwi0. And here comes the freeze (the second problem I encountered). If I try restarting like this : /etc/rc.d/netif stop wlan1 && /etc/rc.d/netif start wlan1 it works (until the PHY TX error appears againg). If I try like : /etc/rc.d/netif restart or if I try : /etc/rc.d/netif stop bwi0 the machine freezes. If i try to kldunload the module while in use (if there's a wlan device created) the machine freezes too. It can be unloaded only if there is not any wlan associated to the bwi device. From owner-freebsd-net@FreeBSD.ORG Mon May 11 11:07:01 2009 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 55E1A1065677 for ; Mon, 11 May 2009 11:07:01 +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 41DF38FC26 for ; Mon, 11 May 2009 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4BB71Lr086041 for ; Mon, 11 May 2009 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4BB70MV086037 for freebsd-net@FreeBSD.org; Mon, 11 May 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 May 2009 11:07:00 GMT Message-Id: <200905111107.n4BB70MV086037@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, 11 May 2009 11:07:01 -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/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) 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/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte 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/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country 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/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us 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 bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw 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 o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation 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/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting 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) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by 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/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card 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/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in 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/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans 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 bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN 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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce 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 o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to 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] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel 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/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS 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 kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste 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 a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface 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/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset 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/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads 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/105348 net [ath] ath device stopps TX 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/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac 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 f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in 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 s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate 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 f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress 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 o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 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 f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern 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/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". 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 o conf/23063 net [arp] [patch] for static ARP tables in rc.network 299 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 11 11:50:05 2009 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 29C39106564A for ; Mon, 11 May 2009 11:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F20018FC14 for ; Mon, 11 May 2009 11:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4BBo4wF046871 for ; Mon, 11 May 2009 11:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4BBo47C046870; Mon, 11 May 2009 11:50:04 GMT (envelope-from gnats) Date: Mon, 11 May 2009 11:50:04 GMT Message-Id: <200905111150.n4BBo47C046870@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Adam K Kirchhoff Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adam K Kirchhoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 11:50:05 -0000 The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org, adamk@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Mon, 11 May 2009 07:36:05 -0400 Upgrading to the latest firmware from Intel (following these directions: http://forums.freebsd.org/showthread.php?t=3849 ) did not change anything. It did not, however, negatively impact anything, either. Adam From owner-freebsd-net@FreeBSD.ORG Mon May 11 16:42:48 2009 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 DCDCB106566C; Mon, 11 May 2009 16:42:48 +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 B21948FC12; Mon, 11 May 2009 16:42:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4BGgmrJ054868; Mon, 11 May 2009 16:42:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4BGgmv7054864; Mon, 11 May 2009 16:42:48 GMT (envelope-from linimon) Date: Mon, 11 May 2009 16:42:48 GMT Message-Id: <200905111642.n4BGgmv7054864@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/134220: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() 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, 11 May 2009 16:42:49 -0000 Old Synopsis: ng_netflow(4): incorrect comparison in ng_netflow_rcvmsg() New Synopsis: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 11 16:42:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134220 From owner-freebsd-net@FreeBSD.ORG Tue May 12 04:27:30 2009 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 D9E1F1065676; Tue, 12 May 2009 04:27:30 +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 AF4038FC0A; Tue, 12 May 2009 04:27:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4C4RUd3096724; Tue, 12 May 2009 04:27:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4C4RUV9096720; Tue, 12 May 2009 04:27:30 GMT (envelope-from linimon) Date: Tue, 12 May 2009 04:27:30 GMT Message-Id: <200905120427.n4C4RUV9096720@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/134401: [msk] [panic] Kernel Fatal trap 12: page fault while in kernel mode at boot time; if_msk eth device module 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, 12 May 2009 04:27:31 -0000 Old Synopsis: Kernel Fatal trap 12: page fault while in kernel mode at boot time; if_msk eth device module New Synopsis: [msk] [panic] Kernel Fatal trap 12: page fault while in kernel mode at boot time; if_msk eth device module Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 12 04:27:05 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134401 From owner-freebsd-net@FreeBSD.ORG Tue May 12 06:18:27 2009 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 BBC521065673 for ; Tue, 12 May 2009 06:18:27 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from mail.jumbuck.com (p82.jumbuck.com [206.112.99.82]) by mx1.freebsd.org (Postfix) with ESMTP id A02EC8FC16 for ; Tue, 12 May 2009 06:18:27 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from mail.jumbuck.com (mail.jumbuck.com [206.112.99.82]) by mail.jumbuck.com (Postfix) with ESMTP id 02A60DDABEDD; Tue, 12 May 2009 05:58:45 +0000 (UTC) Received: from beaste5.jumbuck.com (ppp191-232.static.internode.on.net [59.167.191.232]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.jumbuck.com (Postfix) with ESMTPS id 7B7F9DDABEDB; Tue, 12 May 2009 05:58:44 +0000 (UTC) Received: from beaste5.jumbuck.com (beast5 [192.168.46.105]) by beaste5.jumbuck.com (Postfix) with ESMTP id D602B209D007; Tue, 12 May 2009 15:58:42 +1000 (EST) Received: from [127.0.0.1] (unknown [192.168.46.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by beaste5.jumbuck.com (Postfix) with ESMTPSA id A32DE209D000; Tue, 12 May 2009 15:58:42 +1000 (EST) Message-ID: <4A090FFF.3070105@thebeastie.org> Date: Tue, 12 May 2009 15:58:23 +1000 From: Michael Vince User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Oleg Baranov References: <49FF706F.1050209@csa.ru> In-Reply-To: <49FF706F.1050209@csa.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Awful forwarding rate [7.2-Release, igb] 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, 12 May 2009 06:18:28 -0000 Also make sure that the route for this specific test isn't going out on the Internet and coming back in at your outside link speed of around117kbits/sec? I had a similar problem once where I had 3 boxes hooked up and the speeds were blistering fast for 2 tests but the third test was horrid slow. Turns out I simply forgot to add the route so the packets jumped across the local network, instead the packets were taking a route of a pointless jump out to my first upstream provider and back again :) Mike Oleg Baranov wrote: > Hello! > > I have extremely low forwarding speed on 7.2-Release box with dual > Intel 82575. > > Box "B" with dual 82575 nic is connected between A and C using gigabit > swithes > A <---> B <----> C > > > iperf run from A to C shows: > > $ iperf -w 128k -c 192.168.111.3 > ------------------------------------------------------------ > Client connecting to 192.168.111.3, TCP port 5001 > TCP window size: 129 KByte (WARNING: requested 128 KByte) > ------------------------------------------------------------ > [ 3] local 192.168.1.15 port 51077 connected with 192.168.111.3 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-11.2 sec 160 KBytes 117 Kbits/sec > > > > the same run from A to B shows: > > ]$ iperf -w 128k -c 192.168.1.153 > ------------------------------------------------------------ > Client connecting to 192.168.1.153, TCP port 5001 > TCP window size: 129 KByte (WARNING: requested 128 KByte) > ------------------------------------------------------------ > [ 3] local 192.168.1.15 port 60907 connected with 192.168.1.153 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 1.09 GBytes 933 Mbits/sec > > > and from B to C shows: > > $ iperf -w 128k -c 192.168.111.3 > ------------------------------------------------------------ > Client connecting to 192.168.111.3, TCP port 5001 > TCP window size: 129 KByte (WARNING: requested 128 KByte) > ------------------------------------------------------------ > [ 3] local 192.168.111.254 port 64290 connected with 192.168.111.3 > port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 1.08 GBytes 930 Mbits/sec > > > Boxes B and C are both dual quad-core e5420 CPUs on Supermicro X7DWN+ > motherboard. > As A I tried several machines including dual quad-core Phenom system > as well as some portable PCs and workstations residing in the same LAN. > > Here is ifconfig from B > > $ ifconfig > igb0: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:30:48:c8:19:66 > inet 192.168.1.153 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > igb1: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:30:48:c8:19:67 > media: Ethernet autoselect (1000baseTX ) > status: active > lagg: laggdev lagg0 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > lagg0: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:30:48:c8:19:67 > inet 192.168.111.254 netmask 0xffffff00 broadcast 192.168.111.255 > media: Ethernet autoselect > status: active > laggproto lacp > laggport: igb1 flags=1c > gif0: flags=8051 metric 0 mtu 1280 > tunnel inet 192.168.1.153 --> 192.168.1.156 > inet 192.168.111.254 --> 192.168.112.254 netmask 0xffffffff > > > I tried to remove lagg & gif interfaces, boot GENERIC kernel and even > set up same net config from LiveFS cd - nothing helps. Forwarding > speed sometimes goes up to 1-2 Mbit/sec while local speeds are always > above 900Mbit. > System load is less 1%, logs contain nothing interesting... > > Any clues and ideas would be appreciated!!!! > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue May 12 14:12:06 2009 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 A0FBC106568F; Tue, 12 May 2009 14:12:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 743AC8FC21; Tue, 12 May 2009 14:12:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (jhb@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4CEC62S036483; Tue, 12 May 2009 14:12:06 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4CEC6jB036479; Tue, 12 May 2009 14:12:06 GMT (envelope-from jhb) Date: Tue, 12 May 2009 14:12:06 GMT Message-Id: <200905121412.n4CEC6jB036479@freefall.freebsd.org> To: jhb@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: kern/134486: Wrong MSS in outgoing packets for non-default (1460) MSS 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, 12 May 2009 14:12:07 -0000 Synopsis: Wrong MSS in outgoing packets for non-default (1460) MSS Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: jhb Responsible-Changed-When: Tue May 12 14:11:35 UTC 2009 Responsible-Changed-Why: This is a network stack issue, not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=134486 From owner-freebsd-net@FreeBSD.ORG Tue May 12 22:43:21 2009 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 14546106564A; Tue, 12 May 2009 22:43:21 +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 DDC5D8FC19; Tue, 12 May 2009 22:43:20 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4CMhKxG027666; Tue, 12 May 2009 22:43:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4CMhKSD027662; Tue, 12 May 2009 22:43:20 GMT (envelope-from linimon) Date: Tue, 12 May 2009 22:43:20 GMT Message-Id: <200905122243.n4CMhKSD027662@freefall.freebsd.org> To: linimon@FreeBSD.org, benno@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/118238: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) 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, 12 May 2009 22:43:21 -0000 Old Synopsis: [bce] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) New Synopsis: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) Responsible-Changed-From-To: benno->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 12 22:42:45 UTC 2009 Responsible-Changed-Why: Reassign this to freebsd-net, to try to get it some attention before 8.0. http://www.freebsd.org/cgi/query-pr.cgi?pr=118238 From owner-freebsd-net@FreeBSD.ORG Wed May 13 02:28:24 2009 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 E5575106566C; Wed, 13 May 2009 02:28:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BBF388FC0A; Wed, 13 May 2009 02:28:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (mav@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4D2SOuY022649; Wed, 13 May 2009 02:28:24 GMT (envelope-from mav@freefall.freebsd.org) Received: (from mav@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4D2SO4a022645; Wed, 13 May 2009 02:28:24 GMT (envelope-from mav) Date: Wed, 13 May 2009 02:28:24 GMT Message-Id: <200905130228.n4D2SO4a022645@freefall.freebsd.org> To: myc@barev.net, mav@FreeBSD.org, freebsd-net@FreeBSD.org From: mav@FreeBSD.org Cc: Subject: Re: kern/134220: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 02:28:25 -0000 Synopsis: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() State-Changed-From-To: open->patched State-Changed-By: mav State-Changed-When: Wed May 13 02:27:03 UTC 2009 State-Changed-Why: Patch committed to 8-CURRENT. http://www.freebsd.org/cgi/query-pr.cgi?pr=134220 From owner-freebsd-net@FreeBSD.ORG Wed May 13 02:30:03 2009 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 EEFB610656AD for ; Wed, 13 May 2009 02:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21FFE8FC13 for ; Wed, 13 May 2009 02:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4D2U3UO022916 for ; Wed, 13 May 2009 02:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4D2U24R022911; Wed, 13 May 2009 02:30:03 GMT (envelope-from gnats) Date: Wed, 13 May 2009 02:30:03 GMT Message-Id: <200905130230.n4D2U24R022911@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/134220: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 02:30:04 -0000 The following reply was made to PR kern/134220; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134220: commit references a PR Date: Wed, 13 May 2009 02:26:48 +0000 (UTC) Author: mav Date: Wed May 13 02:26:34 2009 New Revision: 192032 URL: http://svn.freebsd.org/changeset/base/192032 Log: Fix copy-paste bug in NGM_NETFLOW_SETCONFIG argument size verification. PR: kern/134220 Submitted by: Eugene Mychlo MFC after: 1 week Modified: head/sys/netgraph/netflow/ng_netflow.c Modified: head/sys/netgraph/netflow/ng_netflow.c ============================================================================== --- head/sys/netgraph/netflow/ng_netflow.c Wed May 13 00:04:08 2009 (r192031) +++ head/sys/netgraph/netflow/ng_netflow.c Wed May 13 02:26:34 2009 (r192032) @@ -422,7 +422,7 @@ ng_netflow_rcvmsg (node_p node, item_p i { struct ng_netflow_setconfig *set; - if (msg->header.arglen != sizeof(struct ng_netflow_settimeouts)) + if (msg->header.arglen != sizeof(struct ng_netflow_setconfig)) ERROUT(EINVAL); set = (struct ng_netflow_setconfig *)msg->data; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed May 13 04:51:50 2009 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 350FE1065676; Wed, 13 May 2009 04:51:50 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 23EFB8FC24; Wed, 13 May 2009 04:51:50 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (delphij@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4D4povt024555; Wed, 13 May 2009 04:51:50 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4D4pnOX024551; Wed, 13 May 2009 04:51:49 GMT (envelope-from delphij) Date: Wed, 13 May 2009 04:51:49 GMT Message-Id: <200905130451.n4D4pnOX024551@freefall.freebsd.org> To: av@holymail.biz, delphij@FreeBSD.org, freebsd-net@FreeBSD.org, delphij@FreeBSD.org From: delphij@FreeBSD.org Cc: Subject: Re: kern/134486: [tcp] Wrong MSS in outgoing packets for non-default (1460) MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 04:51:50 -0000 Synopsis: [tcp] Wrong MSS in outgoing packets for non-default (1460) MSS State-Changed-From-To: open->closed State-Changed-By: delphij State-Changed-When: Wed May 13 04:49:34 UTC 2009 State-Changed-Why: This is known issue, a possible workaround would be to disable TSO on fxp(4). A true fix is to apply this patch: # cd /tmp # fetch -o fxp.tso.patch "http://svn.freebsd.org/viewvc/base/head/sys/dev/fxp/if_fxp.c?r1=190982&r2=188176&view=patch" # cd /usr/src/sys/dev/fxp # patch -p4 < /tmp/fxp.tso.patch Rebuild, install kernel and reboot. Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Wed May 13 04:49:34 UTC 2009 Responsible-Changed-Why: Take so I can receive further information if this was wrongly closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=134486 From owner-freebsd-net@FreeBSD.ORG Wed May 13 17:18:15 2009 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 41D981065770 for ; Wed, 13 May 2009 17:18:15 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id AE3AD8FC19 for ; Wed, 13 May 2009 17:18:14 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id KAA15455 for ; Wed, 13 May 2009 10:48:13 -0600 (MDT) Message-Id: <200905131648.KAA15455@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 May 2009 10:48:02 -0600 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 17:18:15 -0000 I need to find a way to do "MAC address locking" in FreeBSD -- that is, to ensure that only a machine with a particular MAC address can use a particular IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 information in a packet can't look at Layer 3, and vice versa. Is there a way to work around this to do MAC address locking and/or other functions that involve looking at Layer 2 and Layer 3 simultaneously? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed May 13 18:57:09 2009 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 21AEF1065689 for ; Wed, 13 May 2009 18:57:09 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 631608FC2B for ; Wed, 13 May 2009 18:57:08 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id DB3161B133E2; Wed, 13 May 2009 20:46:29 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.5 Received: from postal.dev.moneybookers.net (postal.dev.moneybookers.net [192.168.3.200]) by blah.sun-fish.com (Postfix) with ESMTP id 1D81D1B12BFD; Wed, 13 May 2009 20:46:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by postal.dev.moneybookers.net (Postfix) with ESMTP id 340CD936A2A; Wed, 13 May 2009 20:45:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at moneybookers.com Received: from postal.dev.moneybookers.net ([127.0.0.1]) by localhost (postal.dev.moneybookers.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bJXYEtghKJNo; Wed, 13 May 2009 20:45:11 +0200 (CEST) Received: from [10.1.1.3] (unknown [192.168.25.10]) by postal.dev.moneybookers.net (Postfix) with ESMTP id 9A1DC936A3E; Wed, 13 May 2009 20:45:11 +0200 (CEST) Message-Id: <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> From: Stefan Lambrev To: Brett Glass In-Reply-To: <200905131648.KAA15455@lariat.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 13 May 2009 21:46:24 +0300 References: <200905131648.KAA15455@lariat.net> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94/9356/Wed May 13 01:38:29 2009 on blah.cmotd.com X-Virus-Status: Clean Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 18:57:09 -0000 Hi, apr -S (or -s) is not helping? Have in mind that this is not a real security as it's very easy to change your MAC. On May 13, 2009, at 7:48 PM, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that > is, to ensure that only a machine with a particular MAC address can > use a particular IP address. Unfortunately, it appears that rules in > FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 > information in a packet can't look at Layer 3, and vice versa. Is > there a way to work around this to do MAC address locking and/or > other functions that involve looking at Layer 2 and Layer 3 > simultaneously? > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Wed May 13 19:03:40 2009 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 CAC301065672 for ; Wed, 13 May 2009 19:03:40 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCD98FC08 for ; Wed, 13 May 2009 19:03:40 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA17981; Wed, 13 May 2009 13:03:32 -0600 (MDT) Message-Id: <200905131903.NAA17981@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 May 2009 13:03:20 -0600 To: Stefan Lambrev From: Brett Glass In-Reply-To: <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 19:03:41 -0000 Stefan: You are correct: This is not real security. In fact, I would argue that it's not security at all. But many businesses that have to maintain hotspots -- especially some hotel chains -- are "allergic" to any sort of serious security. This is because a small but vocal subset of their customers just want to get on the Net and complain about any sort of security. Even having to enter a password or a WEP key irks them. (I personally think that these people are ignorant fools and are setting themselves up for identity theft and worse, but that's just me. And the businesses seem more willing to allow piracy of their Wi-Fi than to irritate these boneheads.) Also, these systems have to be usable by some fairly lame devices -- e.g. an XBox -- that aren't really computers and don't have the capability to run secure protocols or even a particularly good Web browser built in. So, painful as it is, I have to help these guys implement systems which "bless" MAC addresses. The "arp -s" command can sort of lock an IP to a MAC address, but awkwardly and only for outbound packets. What I'd like is to get this into the firewall, so I can not only block spoofing but trigger a log entry when it happens. --Brett At 12:46 PM 5/13/2009, Stefan Lambrev wrote: >Hi, > >apr -S (or -s) is not helping? >Have in mind that this is not a real security as it's very easy to change your MAC. > >On May 13, 2009, at 7:48 PM, Brett Glass wrote: > >>I need to find a way to do "MAC address locking" in FreeBSD -- that is, to ensure that only a machine with a particular MAC address can use a particular IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 information in a packet can't look at Layer 3, and vice versa. Is there a way to work around this to do MAC address locking and/or other functions that involve looking at Layer 2 and Layer 3 simultaneously? >> >>--Brett Glass >> >>_______________________________________________ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >-- >Best Wishes, >Stefan Lambrev >ICQ# 24134177 > > > > From owner-freebsd-net@FreeBSD.ORG Wed May 13 19:14:56 2009 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 46FCB106566C for ; Wed, 13 May 2009 19:14:56 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 661578FC16 for ; Wed, 13 May 2009 19:14:54 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id E445A1B135C5; Wed, 13 May 2009 21:14:53 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.5 Received: from postal.dev.moneybookers.net (postal.dev.moneybookers.net [192.168.3.200]) by blah.sun-fish.com (Postfix) with ESMTP id 427DA1B135C8; Wed, 13 May 2009 21:14:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by postal.dev.moneybookers.net (Postfix) with ESMTP id 50272936A39; Wed, 13 May 2009 21:13:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at moneybookers.com Received: from postal.dev.moneybookers.net ([127.0.0.1]) by localhost (postal.dev.moneybookers.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9Df7uvaka3JM; Wed, 13 May 2009 21:13:35 +0200 (CEST) Received: from [10.1.1.3] (unknown [192.168.25.10]) by postal.dev.moneybookers.net (Postfix) with ESMTP id D0647935B7B; Wed, 13 May 2009 21:13:35 +0200 (CEST) Message-Id: From: Stefan Lambrev To: Brett Glass In-Reply-To: <200905131903.NAA17981@lariat.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 13 May 2009 22:14:48 +0300 References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94/9356/Wed May 13 01:38:29 2009 on blah.cmotd.com X-Virus-Status: Clean Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 19:14:56 -0000 Hi, On May 13, 2009, at 10:03 PM, Brett Glass wrote: > Stefan: > > You are correct: This is not real security. In fact, I would argue > that it's not security at all. > > But many businesses that have to maintain hotspots -- especially > some hotel chains -- are "allergic" to any sort of serious security. > This is because a small but vocal subset of their customers just > want to get on the Net and complain about any sort of security. Even > having to enter a password or a WEP key irks them. (I personally > think that these people are ignorant fools and are setting > themselves up for identity theft and worse, but that's just me. And > the businesses seem more willing to allow piracy of their Wi-Fi than > to irritate these boneheads.) Also, these systems have to be usable > by some fairly lame devices -- e.g. an XBox -- that aren't really > computers and don't have the capability to run secure protocols or > even a particularly good Web browser built in. > > So, painful as it is, I have to help these guys implement systems > which "bless" MAC addresses. The "arp -s" command can sort of lock > an IP to a MAC address, but awkwardly and only for outbound packets. > What I'd like is to get this into the firewall, so I can not only > block spoofing but trigger a log entry when it happens. I think /usr/ports/net-mgmt/arpwatch will be helpful then, though I never used in on wireless. Not that I understand how "knowing" mac address is easier for customers then wpa2 password ;) > > --Brett > > At 12:46 PM 5/13/2009, Stefan Lambrev wrote: > >> Hi, >> >> apr -S (or -s) is not helping? >> Have in mind that this is not a real security as it's very easy to >> change your MAC. >> >> On May 13, 2009, at 7:48 PM, Brett Glass wrote: >> >>> I need to find a way to do "MAC address locking" in FreeBSD -- >>> that is, to ensure that only a machine with a particular MAC >>> address can use a particular IP address. Unfortunately, it appears >>> that rules in FreeBSD's IPFW are "stuck" on one layer: rules that >>> look at Layer 2 information in a packet can't look at Layer 3, and >>> vice versa. Is there a way to work around this to do MAC address >>> locking and/or other functions that involve looking at Layer 2 and >>> Layer 3 simultaneously? >>> >>> --Brett Glass >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org >>> " >> >> -- >> Best Wishes, >> Stefan Lambrev >> ICQ# 24134177 >> >> >> >> -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Wed May 13 19:25:59 2009 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 90C06106564A for ; Wed, 13 May 2009 19:25:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 51B158FC13 for ; Wed, 13 May 2009 19:25:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id AF479FF47; Thu, 14 May 2009 07:07:14 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe4W4I3aegfP; Thu, 14 May 2009 07:07:10 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Thu, 14 May 2009 07:07:10 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 04D3411434; Thu, 14 May 2009 07:07:09 +1200 (NZST) Date: Wed, 13 May 2009 12:07:09 -0700 From: Andrew Thompson To: Brett Glass Message-ID: <20090513190709.GA2871@citylink.fud.org.nz> References: <200905131648.KAA15455@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905131648.KAA15455@lariat.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 19:25:59 -0000 On Wed, May 13, 2009 at 10:48:02AM -0600, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that is, to > ensure that only a machine with a particular MAC address can use a > particular IP address. Unfortunately, it appears that rules in FreeBSD's > IPFW are "stuck" on one layer: rules that look at Layer 2 information in a > packet can't look at Layer 3, and vice versa. Is there a way to work around > this to do MAC address locking and/or other functions that involve looking > at Layer 2 and Layer 3 simultaneously? This has been implemented as part of Gleb Kurtsov's 2008 SoC project. http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering It has not been committed yet but I beleieve is ready to go in, you can find the code on the svn branch http://svn.freebsd.org/viewvc/base/projects/l2filter/ Andrew From owner-freebsd-net@FreeBSD.ORG Wed May 13 19:29:47 2009 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 DB892106567C for ; Wed, 13 May 2009 19:29:47 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 410D48FC14 for ; Wed, 13 May 2009 19:29:47 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA18422; Wed, 13 May 2009 13:29:43 -0600 (MDT) Message-Id: <200905131929.NAA18422@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 May 2009 13:29:34 -0600 To: Andrew Thompson From: Brett Glass In-Reply-To: <20090513190709.GA2871@citylink.fud.org.nz> References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@FreeBSD.org Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 19:29:48 -0000 At 01:07 PM 5/13/2009, Andrew Thompson wrote: >This has been implemented as part of Gleb Kurtsov's 2008 SoC project. >http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering > >It has not been committed yet but I beleieve is ready to go in, you can >find the code on the svn branch >http://svn.freebsd.org/viewvc/base/projects/l2filter/ How does one generate a diff between this code and, say, 7.1-RELEASE or 7.2-RELEASE so that I can try it as a patch? The GUI doesn't seem to be capable of doing this (or it may be that I just don't see how). --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed May 13 19:52:19 2009 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 3E35D106564A for ; Wed, 13 May 2009 19:52:19 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id C94778FC18 for ; Wed, 13 May 2009 19:52:18 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA18748; Wed, 13 May 2009 13:52:12 -0600 (MDT) Message-Id: <200905131952.NAA18748@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 May 2009 13:52:03 -0600 To: Stefan Lambrev From: Brett Glass In-Reply-To: References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 19:52:19 -0000 At 01:14 PM 5/13/2009, Stefan Lambrev wrote: >Not that I understand how "knowing" mac address is easier for >customers then wpa2 password ;) Most customers would not recognize a WPA2 password if it bit them. ;-) Also, many older operating systems and Wi-Fi cards do not support WPA at all. (For example, Windows 2000 doesn't have a WPA supplicant.) Many game machines, network appliances, and network accessories (including Wi-Fi to Ethernet bridges) don't either. If there's any authentication at all, users want it to be through their Web browsers, because very often they don't know how to interact with the network through any other program. (In fact, many refer to their browsers as "The Internet" and don't know what a browser is.) I know, I know; a lot of folks would say that anyone with this little knowledge should be kept off of the Internet for the sake of his or her safety. But if they're a paying customer at a hotel or coffeehouse there are some venues that just want to accommodate them. In fact, several hotel chains actually INSIST that there be no security on the Wi-Fi. They literally distribute documents mandating this for all of their franchisees. Shortsighted, I know, but that's the awful state of network security today. --Brett P.S. -- I have looked over that Summer of Code work, and it looks like it's applicable. The English in the docs should be cleaned up, but the code looks solid. The tough part would be linking it to dhcpd so that a rule is added when a lease is issued and removed when the lease is not renewed. From owner-freebsd-net@FreeBSD.ORG Wed May 13 20:10:08 2009 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 0391D106566B for ; Wed, 13 May 2009 20:10: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 DB8728FC12 for ; Wed, 13 May 2009 20:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4DKA7AF095810 for ; Wed, 13 May 2009 20:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4DKA7gT095806; Wed, 13 May 2009 20:10:07 GMT (envelope-from gnats) Date: Wed, 13 May 2009 20:10:07 GMT Message-Id: <200905132010.n4DKA7gT095806@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Boris Kochergin Cc: Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Boris Kochergin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 20:10:08 -0000 The following reply was made to PR kern/129508; it has been noted by GNATS. From: Boris Kochergin To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Date: Wed, 13 May 2009 15:38:47 -0400 As a workaround, lowering the MTU of the 802.11 interfaces on all of the access points made the panic go away, until one of the machines that was panicking was upgraded to 7.2-RELEASE. Afterward, a panic with a different backtrace started occuring: Unread portion of the kernel message buffer: in_cksum_skip: out of data by 21295 delayed m_pullup, m->len: 22 off: 28410 p: 97 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x44032cbf fault code = supervisor read, page not present instruction pointer = 0x20:0xc05a9b54 stack pointer = 0x28:0xc1f274cc frame pointer = 0x28:0xc1f274d4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 19 (irq5: xl0) trap number = 12 panic: page fault Uptime: 7d15h55m48s Physical memory: 246 MB Dumping 58 MB: 43 27 11 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:244 244 dumptid = curthread->td_tid; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:244 #1 0xc0542599 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0542955 in panic (fmt=Could not find the frame base for "panic".) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0754ee1 in trap_fatal (frame=0xc1f2748c, eva=1141058751) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0754ad0 in trap_pfault (frame=0xc1f2748c, usermode=0, eva=1141058751) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc075439a in trap (frame=0xc1f2748c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc073c3fb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc05a9b54 in m_tag_locate (m=0xc3004300, cookie=0, type=21, t=0x0) at /usr/src/sys/kern/uipc_mbuf2.c:391 #8 0xc043ef81 in m_tag_find (m=0xc3004300, type=21, start=0x0) at mbuf.h:957 #9 0xc043eee1 in pf_get_mtag (m=0xc3004300) at pf_mtag.h:70 #10 0xc044c44e in pf_test (dir=2, ifp=0xc20b6c00, m0=0xc1f276f0, eh=0x0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:6776 #11 0xc0459f3f in pf_check_out (arg=0x0, m=0xc1f276f0, ifp=0xc20b6c00, dir=2, inp=0x0) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3687 #12 0xc061da71 in pfil_run_hooks (ph=0xc07dee60, mp=0xc1f277b4, ifp=0xc20b6c00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #13 0xc064557e in ip_output (m=0xc3004300, opt=0x0, ro=0xc21b1aa4, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:443 #14 0xc06359d3 in in_gif_output (ifp=0xc2103400, family=18, m=0xc3004300) at /usr/src/sys/netinet/in_gif.c:244 #15 0xc061b3cd in gif_output (ifp=0xc2103400, m=0xc238c100, dst=0xc219c560, rt=0x0) at /usr/src/sys/net/if_gif.c:455 #16 0xc061b009 in gif_start (ifp=0xc2103400) at /usr/src/sys/net/if_gif.c:351 #17 0xc0612c39 in bridge_enqueue (sc=0xc222c800, dst_ifp=0xc2103400, m=0x0) at /usr/src/sys/net/if_bridge.c:1742 #18 0xc0614d9c in bridge_broadcast (sc=0xc222c800, src_if=0xc2196000, m=0xc238c100, runfilt=1) at /usr/src/sys/net/if_bridge.c:2386 #19 0xc0613951 in bridge_forward (sc=0xc222c800, sbif=0xc22c8400, m=0xc238c100) at /usr/src/sys/net/if_bridge.c:2046 #20 0xc0613ed5 in bridge_input (ifp=0xc2196000, m=0xc3068600) at /usr/src/sys/net/if_bridge.c:2168 #21 0xc061b6da in gif_input (m=0xc3068600, af=18, ifp=0xc2196000) at /usr/src/sys/net/if_gif.c:563 #22 0xc0635d34 in in_gif_input (m=0xc3068600, off=20) at /usr/src/sys/netinet/in_gif.c:342 #23 0xc063d905 in encap4_input (m=0xc3068600, off=20) at /usr/src/sys/netinet/ip_encap.c:191 #24 0xc064190f in ip_input (m=0xc3068600) at /usr/src/sys/netinet/ip_input.c:664 #25 0xc061d61a in netisr_dispatch (num=2, m=0xc3068600) at /usr/src/sys/net/netisr.c:185 #26 0xc0619d16 in ether_demux (ifp=0xc20b6c00, m=0xc3068600) at /usr/src/sys/net/if_ethersubr.c:834 #27 0xc0619af2 in ether_input (ifp=0xc20b6c00, m=0xc3068600) at /usr/src/sys/net/if_ethersubr.c:692 #28 0xc06a1924 in xl_rxeof (sc=0xc20d7000) at /usr/src/sys/pci/if_xl.c:2022 #29 0xc06a23ce in xl_intr (arg=0xc20d7000) at /usr/src/sys/pci/if_xl.c:2257 #30 0xc0518ca0 in ithread_execute_handlers (p=0xc20aa000, ie=0xc2009900) at /usr/src/sys/kern/kern_intr.c:1088 #31 0xc0518e67 in ithread_loop (arg=0xc20d3c80) at /usr/src/sys/kern/kern_intr.c:1175 #32 0xc0516d23 in fork_exit (callout=0xc0518de0 , arg=0xc20d3c80, frame=0xc1f27d38) at /usr/src/sys/kern/kern_fork.c:810 #33 0xc073c470 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 From owner-freebsd-net@FreeBSD.ORG Wed May 13 20:20:04 2009 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 E9DD4106564A for ; Wed, 13 May 2009 20:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D79AD8FC1D for ; Wed, 13 May 2009 20:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4DKK4jF009870 for ; Wed, 13 May 2009 20:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4DKK4h1009869; Wed, 13 May 2009 20:20:04 GMT (envelope-from gnats) Date: Wed, 13 May 2009 20:20:04 GMT Message-Id: <200905132020.n4DKK4h1009869@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Seth Mos" Cc: Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Seth Mos List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 20:20:05 -0000 The following reply was made to PR kern/127528; it has been noted by GNATS. From: "Seth Mos" To: bug-followup@FreeBSD.org, seth.mos@xs4all.nl Cc: Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Wed, 13 May 2009 21:58:40 +0200 (CEST) Hi there again, it's been a while. We are currently on a pfSense 1.2.3-RC1 release and we are now getting a host of people on the forum and in the mailing lists that are complaining about the load balancer flapping. Some debugging turned out some very weird behaviour. Every now and then, depending on the concurrenty of icmp traffic originating from the FreeBSD host, ping will miss icmp replies. Here are the steps performed to debug this issue. For example the output tcpdump -ni vlan0 -t icmp Where vlan0 is the external interface. The IP address being pinged is a local gateway connected by ethernet so there is nothing but the switch in between. http://pastebin.com/f6608c875 The ping command issued is /sbin/ping -t 4 -oqc 5 -i 0.7 213.23.199.249 This command line will ping the target and exit with a return status of 0 when it receives a reply which can be any of the 5 attempts within the maximum of 4 seconds. The output clearly shows that all attempts have unique process IDs, which is good. It also shows that all attempt have a sequence number of 0 which is the 1st attempt to ping. There is however one attempt where this is different, on attempt with pid 46060 you will see that it attempted 4 times to ping the target, it got valid responses to all 5 requests!. However, ping exited with a return status of 1 which would imply a timeout. So now it is worse then the originally reported issue we had on 7.0. We can now make the FreeBSD distributed ping fail. Specifically, it fails to see the valid replies. For your reference I also pasted the tcpdump below. I can also reproduce this exact same behaviour by using fping. So I would not consider this a bug in the ping binary itself. Since the original PR had this issue with apinger, which is different from both ping and fping I am quite confident there is a serious regression in here. # uname -a FreeBSD noord.coltex.nl 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #0: Tue Mar 24 01:18:19 EDT 2009 sullrich@RELENG_1_2-snapshots.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.7 i386 Kind regards, Seth Mos pfSense Developer -------------- 1. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 25068, seq 0, length 64 2. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 25068, seq 0, length 64 3. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 27372, seq 0, length 64 4. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 27372, seq 0, length 64 5. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 29676, seq 0, length 64 6. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 29676, seq 0, length 64 7. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 31468, seq 0, length 64 8. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 31468, seq 0, length 64 9. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 33772, seq 0, length 64 10. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 33772, seq 0, length 64 11. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 36076, seq 0, length 64 12. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 36076, seq 0, length 64 13. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 0, length 64 14. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 0, length 64 15. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 1, length 64 16. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 1, length 64 17. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 12525, seq 0, length 64 18. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 12525, seq 0, length 64 19. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 14829, seq 0, length 64 20. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 14829, seq 0, length 64 21. IP 213.23.199.249 > 213.23.199.250: ICMP host 192.168.120.254 unreachable - admin prohibited filter, length 60 22. IP 213.23.199.249 > 213.23.199.250: ICMP host 192.168.148.1 unreachable - admin prohibited filter, length 60 23. IP 213.23.199.249 > 213.23.199.250: ICMP host 192.168.112.1 unreachable - admin prohibited filter, length 60 24. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 2, length 64 25. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 2, length 64 26. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 17645, seq 0, length 64 27. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 17645, seq 0, length 64 28. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 3, length 64 29. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 3, length 64 30. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 4, length 64 31. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 4, length 64 From owner-freebsd-net@FreeBSD.ORG Wed May 13 21:34:44 2009 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 BBE68106564A; Wed, 13 May 2009 21:34:44 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id A83C38FC13; Wed, 13 May 2009 21:34:44 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJL00AKZNT85L70@asmtp019.mac.com>; Wed, 13 May 2009 13:34:23 -0700 (PDT) Message-id: <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> From: Chuck Swiger To: Brett Glass In-reply-to: <200905131929.NAA18422@lariat.net> Date: Wed, 13 May 2009 13:34:20 -0700 References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> X-Mailer: Apple Mail (2.930.3) Cc: Andrew Thompson , net@FreeBSD.org Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 21:34:45 -0000 On May 13, 2009, at 12:29 PM, Brett Glass wrote: >> It has not been committed yet but I beleieve is ready to go in, you >> can >> find the code on the svn branch >> http://svn.freebsd.org/viewvc/base/projects/l2filter/ > > How does one generate a diff between this code and, say, 7.1-RELEASE > or 7.2-RELEASE so that I can try it as a patch? The GUI doesn't seem > to be capable of doing this (or it may be that I just don't see how). Something like: svn diff http://svn.freebsd.org/base/releng/7.1 http://svn.freebsd.org/base/projects/l2filter However, while this answers your question, it's not as useful as you might hope; probably you are actually interested in the diff between when/where the branch was cut and what it currently has, as that is the patch that you'd want to try against whatever OS source code version you actually want to run. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed May 13 22:08:33 2009 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 4C89A1065678 for ; Wed, 13 May 2009 22:08:33 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id ED5578FC30 for ; Wed, 13 May 2009 22:08:32 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KJL00LSLQS6B760@mta-1.ms.rz.RWTH-Aachen.de> for net@freebsd.org; Wed, 13 May 2009 23:38:30 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.41,190,1241388000"; d="scan'208";a="11809311" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 13 May 2009 23:38:28 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n4DLcULI000961; Wed, 13 May 2009 23:38:30 +0200 (CEST) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1M4M9m-00017b-7y; Wed, 13 May 2009 23:38:30 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id DBD2E3F41B; Wed, 13 May 2009 23:38:29 +0200 (CEST) Date: Wed, 13 May 2009 23:38:29 +0200 From: Christian Brueffer To: Brett Glass Message-id: <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=3MwIy2ne0vdjdPXF Content-disposition: inline In-reply-to: <200905131903.NAA17981@lariat.net> X-Operating-System: FreeBSD 6.4-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.11 Cc: net@freebsd.org, Stefan Lambrev Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 22:08:33 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 13, 2009 at 01:03:20PM -0600, Brett Glass wrote: > Stefan: >=20 > You are correct: This is not real security. In fact, I would argue that i= t's not security at all.=20 >=20 > But many businesses that have to maintain hotspots -- especially some hot= el chains -- are "allergic" to any sort of serious security. This is becaus= e a small but vocal subset of their customers just want to get on the Net a= nd complain about any sort of security. Even having to enter a password or = a WEP key irks them. (I personally think that these people are ignorant foo= ls and are setting themselves up for identity theft and worse, but that's j= ust me. And the businesses seem more willing to allow piracy of their Wi-Fi= than to irritate these boneheads.) Also, these systems have to be usable b= y some fairly lame devices -- e.g. an XBox -- that aren't really computers = and don't have the capability to run secure protocols or even a particularl= y good Web browser built in. >=20 > So, painful as it is, I have to help these guys implement systems which "= bless" MAC addresses. The "arp -s" command can sort of lock an IP to a MAC = address, but awkwardly and only for outbound packets. What I'd like is to g= et this into the firewall, so I can not only block spoofing but trigger a l= og entry when it happens. >=20 Sounds like wlan_acl(4) may be of interest to you. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFKCz3VbHYXjKDtmC0RApELAKCgQVZjuEzXrcxJ/eNgOGYyVjGTCgCg9uHI 5CHvSngxLAoXZMH8JTzFN4k= =ma8f -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Wed May 13 22:30:11 2009 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 4BA91106564A for ; Wed, 13 May 2009 22:30:11 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id BCEAD8FC16 for ; Wed, 13 May 2009 22:30:10 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA20732; Wed, 13 May 2009 16:30:04 -0600 (MDT) Message-Id: <200905132230.QAA20732@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 May 2009 16:29:53 -0600 To: Christian Brueffer From: Brett Glass In-Reply-To: <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@FreeBSD.org, Stefan Lambrev Subject: Re: MAC locking and filtering in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 22:30:11 -0000 At 03:38 PM 5/13/2009, Christian Brueffer wrote: >Sounds like wlan_acl(4) may be of interest to you. Unfortunately, wlan_acl(4) is only useful if one wants to ban users from the network, which these venues will rarely want to do except to block an abuser. Rather, they'll want the equipment to recognize MAC addresses and grant different degrees of access to them. For example, a user might be trapped in a "walled garden" until agreeing to an acceptable use policy, and then redirected -- but only once -- to a specific Web page, such as the hotel chain's reservation page. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu May 14 00:44:28 2009 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 6A185106564A; Thu, 14 May 2009 00:44:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id F052C8FC19; Thu, 14 May 2009 00:44:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so1900950qyk.3 for ; Wed, 13 May 2009 17:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=EhvnB3jra7R6vfrogcppn2dcmC7cTgncx7wOz2p6Twc=; b=WYFfQnkkdHS8vUPZRoOdoRSgYlluQyYlEjRk0uUUA87UHx35qAgkdgCP4n9ECK+kgb en9ED2LxtJQWCj04qA/6u/7kOBAzVBFSVqRhtz8kzEw2dbDIO2f0nyY6gi0Eosix3gd+ KOEwXC6hhjuN/CIaT8uIi/8bke6+FE+bHVF90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MuRo0sC8k4YjtqaP1P/udhS6Q/MQqhW7xPf5sSydlj+2t5FunWS+ml6IUnYDsuo4vG DD1l2IaukN3x+fbZFFi2erraDl8gyyT5Ipvr+AOqfqMHliKFH7EbGQEYCSsyMzLuVTaS Q08zk5VPhvLmvqh46JX1netNoI4586NQ42oqE= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.99.208 with SMTP id v16mr1337991qcn.75.1242260452202; Wed, 13 May 2009 17:20:52 -0700 (PDT) In-Reply-To: <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> Date: Thu, 14 May 2009 08:20:52 +0800 X-Google-Sender-Auth: e9d8efb77b8245e0 Message-ID: From: Adrian Chadd To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brett Glass , Andrew Thompson , net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 00:44:28 -0000 There's one big SVN commit - r186069. There's a couple of "merge from head" commits and an arpv2/routetable tidyup commit. This is all against -current though. I'm going to see how cleanly the patch applies to 7.2-release and if it works at all. Adrian From owner-freebsd-net@FreeBSD.ORG Thu May 14 03:17:27 2009 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 3B9751065670; Thu, 14 May 2009 03:17:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id D127A8FC19; Thu, 14 May 2009 03:17:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so2019507qyk.3 for ; Wed, 13 May 2009 20:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=EpBcYDNAClxf3RjVHHPCn+9zNTgDTUbiAt8gww0PwEA=; b=Di6D/6uAs2IenbqmOWMOUKtDLA0taJbWG3cah+qbCqTzccsEQAp40mfLDXI22VbNw5 PK3na8FGxBz94zb+PxEK+wEy7oo4/IDgTaR/sXR2hitgbmgjP/pzuSSmiApeg5g/gQ/q RbNl9t6Atfdx+8lGubIO1jGD2fM6aXfKcTBW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MrDtQmU8TqdRhaCnfGCy0PzgxV5HXAS1Izqc1lcNOez9jdec8zpes6pPIJ7Z7hl0tI Hedd4ibZpUTGbl3mB2p0/pwMsgOB81NzGYFsg2iMkou587sST7AFNJNT6dmI2jW9vXA6 Pm666yL3aABLbM5/yZ3XEa0PV9Uo+iPDw9QfE= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.84.6 with SMTP id h6mr1473266qcl.19.1242271046251; Wed, 13 May 2009 20:17:26 -0700 (PDT) In-Reply-To: References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> Date: Thu, 14 May 2009 11:17:26 +0800 X-Google-Sender-Auth: 3466c052257ccc0b Message-ID: From: Adrian Chadd To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brett Glass , Andrew Thompson , net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 03:17:27 -0000 Brett, you can grab the specific "bulk" change to an earlier -current from here: svn diff -r 186068:186069 http://svn.freebsd.org/base/projects/l2filter > /tmp/l2filter-186069.diff There aren't any bugfix commits in that branch after that; they're all merge-from-head and arpv2/routetable work merging. Andrew, I'm taking a look at this as I have a similar interest to Brett at the moment. It may make it easier to review and commit if we broke it up into separate chunks: * separate out the changes to the ethernet/bridging layer and the new pfil hooks into a separate initial commit (and MFC); * then generate separate patches for pf/ipfw and let people test it against -current and 7.2-release (which is where I'd like the support to appear..) Thanks, Adrian 2009/5/14 Adrian Chadd : > There's one big SVN commit - r186069. > > There's a couple of "merge from head" commits and an arpv2/routetable > tidyup commit. > > This is all against -current though. I'm going to see how cleanly the > patch applies to 7.2-release and if it works at all. > > > > Adrian > From owner-freebsd-net@FreeBSD.ORG Thu May 14 03:25:14 2009 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 CE50A106564A for ; Thu, 14 May 2009 03:25:14 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 3867F8FC0A for ; Thu, 14 May 2009 03:25:13 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n4E2xv7V045706; Thu, 14 May 2009 10:59:57 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id n4E2xvqE045705; Thu, 14 May 2009 10:59:57 +0800 (KRAST) (envelope-from eugen) Date: Thu, 14 May 2009 10:59:57 +0800 From: Eugene Grosbein To: Brett Glass Message-ID: <20090514025957.GA45372@svzserv.kemerovo.su> References: <200905131648.KAA15455@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905131648.KAA15455@lariat.net> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 03:25:15 -0000 On Wed, May 13, 2009 at 10:48:02AM -0600, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that > is, to ensure that only a machine with a particular MAC address can > use a particular IP address. Unfortunately, it appears that rules > in FreeBSD's IPFW are "stuck" on one layer: rules that look at > Layer 2 information in a packet can't look at Layer 3, and vice > versa. Is there a way to work around this to do MAC address locking > and/or other functions that involve looking at Layer 2 and Layer 3 > simultaneously? There is no need in advanced filtering rules for that. Just use 'arp -f /path/to/IP-MAC-pairs' with 'ifconfig $iface staticarp'. We use that for years since FreeBSD 2.2.x (before 4.x that required patches). Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu May 14 03:40:03 2009 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 5DB1B106568A for ; Thu, 14 May 2009 03:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2DE8FC14 for ; Thu, 14 May 2009 03:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4E3e3Tm002797 for ; Thu, 14 May 2009 03:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4E3e3Qm002796; Thu, 14 May 2009 03:40:03 GMT (envelope-from gnats) Date: Thu, 14 May 2009 03:40:03 GMT Message-Id: <200905140340.n4E3e3Qm002796@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Chris Buechler Cc: Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris Buechler List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 03:40:03 -0000 The following reply was made to PR kern/127528; it has been noted by GNATS. From: Chris Buechler To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Wed, 13 May 2009 23:08:05 -0400 A brief addition to Seth's update on this issue, which should provide adequate detail. We switched from fping to the stock FreeBSD ping, and it made the issue better, but we're still seeing problems with FreeBSD's ping. In many circumstances it never appears, in others it's very easy to replicate. There isn't any commonality between environments that can replicate it, it happens across many types of NICs, using VLANs and not, etc. We should be able to arrange access to one of the systems that can routinely replicate the problem for an interested FreeBSD developer. We're in a bit over our heads here and not sure how to troubleshoot further. thanks, Chris From owner-freebsd-net@FreeBSD.ORG Thu May 14 05:13:32 2009 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 2F2181065676 for ; Thu, 14 May 2009 05:13:32 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3598FC15 for ; Thu, 14 May 2009 05:13:31 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Thu, 14 May 2009 06:59:09 +0200 id 0002E023.4A0BA51D.00016EC2 From: Milan Obuch To: freebsd-net@freebsd.org Date: Thu, 14 May 2009 07:03:09 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905140703.10473.freebsd-net@dino.sk> Subject: Weird dhclient behavior after today's rebuild 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, 14 May 2009 05:13:32 -0000 Hi, I did full system rebuild from freshly csup'ped sources. Everything went smooth as usual, but after reboot network card did not get configured via DHCP. There were four lines logged on console/in syslog: dhclient[822]: re0: not found dhclient[822]: exiting dhclient[823]: connection closed dhclient[823]: exiting I did some tests, disabled automatic dhclient invocation in rc.conf. Then, after connecting cable, ifconfig re0 show status active, netstat -rnf inet shows only loopback route (128.0.0.1 on lo0). Manually starting dhclient re0: ifconfig: ioctl (SIOCAIFADDR): File exists re0: not found exiting At this point, netstat -rnf inet shows additional 0.0.0.0/8 route on re0,yet there is no addres in ifconfig re0 output. Assigning IP statically works (tested only via ifconfig re0 , but setting this in rc.conf should have exastly the same effect). I found a bit strange workaround for this - first assign any IP to interface, I used 0.0.0.1/8, then launching dhclient re0 yields desired result... This problem is observed with sources 24 hours old, verified with sources 12 hours old, did not occured last time I did rebuild from sources 3 or 4 days old (not remembered exactly). Regards, Milan From owner-freebsd-net@FreeBSD.ORG Thu May 14 05:47:18 2009 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 6FDB4106566C for ; Thu, 14 May 2009 05:47:18 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id F26468FC12 for ; Thu, 14 May 2009 05:47:17 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n4E5aOud010434; Wed, 13 May 2009 22:36:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 22:32:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Weird dhclient behavior after today's rebuild Thread-Index: AcnUUs8upHXwtU3JQaiPRAOU3tLUmQAAoxMB References: <200905140703.10473.freebsd-net@dino.sk> From: "Li, Qing" To: "Milan Obuch" , Cc: Subject: RE: Weird dhclient behavior after today's rebuild 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, 14 May 2009 05:47:18 -0000 I have committed the patch, please update your source and give it a try. Thanks, -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Milan Obuch Sent: Wed 5/13/2009 10:03 PM To: freebsd-net@freebsd.org Subject: Weird dhclient behavior after today's rebuild =20 Hi, I did full system rebuild from freshly csup'ped sources. Everything went = smooth as usual, but after reboot network card did not get configured = via=20 DHCP. There were four lines logged on console/in syslog: dhclient[822]: re0: not found dhclient[822]: exiting dhclient[823]: connection closed dhclient[823]: exiting I did some tests, disabled automatic dhclient invocation in rc.conf. Then, after connecting cable, ifconfig re0 show status active, netstat = -rnf=20 inet shows only loopback route (128.0.0.1 on lo0). Manually starting dhclient re0: ifconfig: ioctl (SIOCAIFADDR): File exists re0: not found exiting At this point, netstat -rnf inet shows additional 0.0.0.0/8 route on = re0,yet=20 there is no addres in ifconfig re0 output. Assigning IP statically works (tested only via ifconfig re0 , but = setting=20 this in rc.conf should have exastly the same effect). I found a bit strange workaround for this - first assign any IP to = interface,=20 I used 0.0.0.1/8, then launching dhclient re0 yields desired result... This problem is observed with sources 24 hours old, verified with = sources 12=20 hours old, did not occured last time I did rebuild from sources 3 or 4 = days=20 old (not remembered exactly). Regards, Milan _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu May 14 06:41:17 2009 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 31B4B106566C for ; Thu, 14 May 2009 06:41:17 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id C0E488FC08 for ; Thu, 14 May 2009 06:41:16 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id AAA25118; Thu, 14 May 2009 00:40:59 -0600 (MDT) Message-Id: <200905140640.AAA25118@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 May 2009 00:40:39 -0600 To: Ian Smith From: Brett Glass In-Reply-To: <20090514155226.Y46325@sola.nimnet.asn.au> References: <200905131648.KAA15455@lariat.net> <20090514155226.Y46325@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 06:41:17 -0000 At 12:17 AM 5/14/2009, Ian Smith wrote: >You can use fixed leases with MAC specified in dhcp for that, This lets you assign specific addresses to machines with specific MAC addresses. But it doesn't inhibit MAC address "cloning," and the DHCP server cannot force a machine to use a specific IP or stop it from using one that was not assigned to it. >Re ipfw(8), I'm not clear on what your problem is: the section PACKET >FLOW shows clearly how to distinguish layer 2 from layer 3 traffic. The problem is that you cannot test both the MAC address and the IP address in the same rule -- at least in the current implementation. >Your 'vice versa' here isn't correct; you can select by layer 3 criteria >on packets from ether_demux, The docs say that you can't. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu May 14 06:53:30 2009 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 C1BBE1065673 for ; Thu, 14 May 2009 06:53:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF828FC1A for ; Thu, 14 May 2009 06:53:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n4E6HsRS044674; Thu, 14 May 2009 16:17:55 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 14 May 2009 16:17:54 +1000 (EST) From: Ian Smith To: Brett Glass In-Reply-To: <200905131648.KAA15455@lariat.net> Message-ID: <20090514155226.Y46325@sola.nimnet.asn.au> References: <200905131648.KAA15455@lariat.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 06:53:31 -0000 On Wed, 13 May 2009, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that is, to > ensure that only a machine with a particular MAC address can use a particular > IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are > "stuck" on one layer: rules that look at Layer 2 information in a packet > can't look at Layer 3, and vice versa. Is there a way to work around this to > do MAC address locking and/or other functions that involve looking at Layer 2 > and Layer 3 simultaneously? You can use fixed leases with MAC specified in dhcp for that, with or without specifying a range of addresses available to boxes with unknown MACs. An org I'm working for uses just that method to good effect. You can also specify a different (eg) router address for non-fixed leases, towards your 'captive portal' requirement for new boxes. Re ipfw(8), I'm not clear on what your problem is: the section PACKET FLOW shows clearly how to distinguish layer 2 from layer 3 traffic. Your 'vice versa' here isn't correct; you can select by layer 3 criteria on packets from ether_demux, though of course once (or if) they get to re-enter the firewall at layer 3 (from ip_input) you can't see/test MAC addresses anymore. 'simultaneously' isn't really the case then; clearly the layer 2 pass occurs first on input, and last on output. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu May 14 07:39:19 2009 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 E7333106564A for ; Thu, 14 May 2009 07:39:19 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 724D38FC17 for ; Thu, 14 May 2009 07:39:19 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: by fg-out-1718.google.com with SMTP id e12so1089078fga.12 for ; Thu, 14 May 2009 00:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=quh0CyWzBIcu+f9kG/aDmCYYE1vi6Ba8gbm708UDT44=; b=YS/YcCQQhJNzZ6FNUYMHbas6f+riG7hDmd1HeuhnSUuUVySSqDg+B6KueEvtR0G8hO 7z1bipRu06X9R5OMNe7Ja3tMIF2Wl1M6XbCDaL4JdYGknihXwpvGX+bk6h4QCC0za1oN AhFB42pnquP8z7vgZcV27r/bD/XF160oMhgSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=l9w1XNTmM//VFhLyarlBOy2O9DtaUnMYo3VODV3JSNMTJo6IABSk/fDmV8YZ7Smzgc lomAgagpr3OhhuXXvuFtjY7Dlxo0RdXY2s30i2gCy+x7uSMXO0NtnvkQiZTmn2AHrtpB ytWguKpYYyv/ktNhHQYKO5YTvnTMwOlxcWKY8= Received: by 10.86.59.18 with SMTP id h18mr2163626fga.71.1242285230575; Thu, 14 May 2009 00:13:50 -0700 (PDT) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id d4sm1554753fga.4.2009.05.14.00.13.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 May 2009 00:13:50 -0700 (PDT) Date: Thu, 14 May 2009 10:14:43 +0300 From: Gleb Kurtsou To: Brett Glass Message-ID: <20090514071442.GA6702@tops.skynet.lt> References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <200905131929.NAA18422@lariat.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Andrew Thompson , net@FreeBSD.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 07:39:20 -0000 On (13/05/2009 13:29), Brett Glass wrote: > At 01:07 PM 5/13/2009, Andrew Thompson wrote: > > >This has been implemented as part of Gleb Kurtsov's 2008 SoC project. > >http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering > > > >It has not been committed yet but I beleieve is ready to go in, you can > >find the code on the svn branch > >http://svn.freebsd.org/viewvc/base/projects/l2filter/ > > How does one generate a diff between this code and, say, > 7.1-RELEASE or 7.2-RELEASE so that I can try it as a patch? The GUI > doesn't seem to be capable of doing this (or it may be that I just > don't see how). I'd suggest you using latest patchs from http://blogs.freebsdish.org/gleb/2009/03/24/layer2-dummynet/ projects svn repository is quiet outdated, and I was going to make patch against 7.2 on this weekend (will blog about it) > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu May 14 07:40:08 2009 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 CE2181065674 for ; Thu, 14 May 2009 07:40:08 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3258FC12 for ; Thu, 14 May 2009 07:40:08 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id D925B1B12BFD; Thu, 14 May 2009 09:40:06 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham version=3.2.5 Received: from postal.dev.moneybookers.net (postal.dev.moneybookers.net [192.168.3.200]) by blah.sun-fish.com (Postfix) with ESMTP id 20ECF1B12BD9; Thu, 14 May 2009 09:40:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by postal.dev.moneybookers.net (Postfix) with ESMTP id 9AE43936A35; Thu, 14 May 2009 09:38:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at moneybookers.com Received: from postal.dev.moneybookers.net ([127.0.0.1]) by localhost (postal.dev.moneybookers.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tJf12mEr8OuL; Thu, 14 May 2009 09:38:46 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by postal.dev.moneybookers.net (Postfix) with ESMTP id 0D60A936A33; Thu, 14 May 2009 09:38:46 +0200 (CEST) Message-Id: <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> From: Stefan Lambrev To: Brett Glass In-Reply-To: <200905132230.QAA20732@lariat.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 10:39:59 +0300 References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV 0.94/9357/Wed May 13 23:05:21 2009 on blah.cmotd.com X-Virus-Status: Clean Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Christian Brueffer , net@FreeBSD.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 07:40:09 -0000 Hi Brett, I think what you are looking for is called captive portal. You can look at pfsense - http://doc.pfsense.org/index.php/Category:Captive_Portal which comes with such solution into it. On May 14, 2009, at 1:29 AM, Brett Glass wrote: > At 03:38 PM 5/13/2009, Christian Brueffer wrote: > >> Sounds like wlan_acl(4) may be of interest to you. > > Unfortunately, wlan_acl(4) is only useful if one wants to ban users > from the network, which these venues will rarely want to do except > to block an abuser. > > Rather, they'll want the equipment to recognize MAC addresses and > grant different degrees of access to them. For example, a user might > be trapped in a "walled garden" until agreeing to an acceptable use > policy, and then redirected -- but only once -- to a specific Web > page, such as the hotel chain's reservation page. > > --Brett Glass > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Thu May 14 07:51:41 2009 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 AC458106566B for ; Thu, 14 May 2009 07:51:41 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 256B48FC08 for ; Thu, 14 May 2009 07:51:40 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n4E7pdeS047474; Thu, 14 May 2009 17:51:39 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 14 May 2009 17:51:39 +1000 (EST) From: Ian Smith To: Brett Glass In-Reply-To: <200905140640.AAA25118@lariat.net> Message-ID: <20090514170535.Y46325@sola.nimnet.asn.au> References: <200905131648.KAA15455@lariat.net> <20090514155226.Y46325@sola.nimnet.asn.au> <200905140640.AAA25118@lariat.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: net@freebsd.org Subject: Re: MAC locking and filtering in FreeBSD 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, 14 May 2009 07:51:41 -0000 On Thu, 14 May 2009, Brett Glass wrote: > At 12:17 AM 5/14/2009, Ian Smith wrote: > > >You can use fixed leases with MAC specified in dhcp for that, > > This lets you assign specific addresses to machines with specific MAC > addresses. But it doesn't inhibit MAC address "cloning," and the DHCP > server cannot force a machine to use a specific IP or stop it from > using one that was not assigned to it. You can have it only issue a lease for a given IP to a machine with the correct MAC, and issue no leases to any other machines; at least, that works for us. Of course that can't prevent someone who a) knows the IP address to MAC mapping, and b) can spoof the MAC address. I don't know what could prevent that, but it's hardly the common scenario. Then have ipfw refuse traffic from addresses other than those allowed. > >Re ipfw(8), I'm not clear on what your problem is: the section PACKET > >FLOW shows clearly how to distinguish layer 2 from layer 3 traffic. > > The problem is that you cannot test both the MAC address and the IP > address in the same rule -- at least in the current implementation. Assuming you have net.link.ether.ipfw=1 to get layer 2 packets, and are separating your layer 2 packets for testing as shown under PACKET FLOW, can you show us the rule to do just that, that isn't working right? > >Your 'vice versa' here isn't correct; you can select by layer 3 criteria > >on packets from ether_demux, > > The docs say that you can't. Please point out where ipfw(8) says that? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu May 14 10:29:55 2009 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 CDA221065670 for ; Thu, 14 May 2009 10:29:55 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 44E598FC08 for ; Thu, 14 May 2009 10:29:54 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Thu, 14 May 2009 12:25:34 +0200 id 0002E033.4A0BF19E.00017C4A From: Milan Obuch To: freebsd-net@freebsd.org Date: Thu, 14 May 2009 12:29:33 +0200 User-Agent: KMail/1.9.10 References: <200905140703.10473.freebsd-net@dino.sk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905141229.34731.freebsd-net@dino.sk> Cc: "Li, Qing" Subject: Re: Weird dhclient behavior after today's rebuild 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, 14 May 2009 10:29:56 -0000 On Thursday 14 May 2009 07:32:22 Li, Qing wrote: > I have committed the patch, please update your source and > give it a try. > > Thanks, > > -- Qing > After fresh csup and rebuild it works again. I suppose your fix wents into sys/netinet/in.c, as I did not see anything else network related in csup's output... Thanks for quick fix. Milan > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Milan Obuch > Sent: Wed 5/13/2009 10:03 PM > To: freebsd-net@freebsd.org > Subject: Weird dhclient behavior after today's rebuild > > Hi, > > I did full system rebuild from freshly csup'ped sources. Everything went > smooth as usual, but after reboot network card did not get configured via > DHCP. There were four lines logged on console/in syslog: > > dhclient[822]: re0: not found > dhclient[822]: exiting > dhclient[823]: connection closed > dhclient[823]: exiting > > I did some tests, disabled automatic dhclient invocation in rc.conf. > > Then, after connecting cable, ifconfig re0 show status active, netstat -rnf > inet shows only loopback route (128.0.0.1 on lo0). Manually starting > dhclient re0: > > ifconfig: ioctl (SIOCAIFADDR): File exists > re0: not found > exiting > [ snip ] From owner-freebsd-net@FreeBSD.ORG Thu May 14 15:20:05 2009 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 2D7CF1065675 for ; Thu, 14 May 2009 15:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ED04F8FC18 for ; Thu, 14 May 2009 15:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4EFK4LN088998 for ; Thu, 14 May 2009 15:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4EFK4Rb088995; Thu, 14 May 2009 15:20:04 GMT (envelope-from gnats) Date: Thu, 14 May 2009 15:20:04 GMT Message-Id: <200905141520.n4EFK4Rb088995@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sergey Pronin Cc: Subject: Re: kern/132984: [netgraph] swi1: net 100% cpu usage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Pronin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 15:20:05 -0000 The following reply was made to PR kern/132984; it has been noted by GNATS. From: Sergey Pronin To: bug-followup@FreeBSD.org, vlad@prokk.net Cc: Subject: Re: kern/132984: [netgraph] swi1: net 100% cpu usage Date: Thu, 14 May 2009 18:39:35 +0400 --000e0cd311a2045e870469e04ca6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This bug is still urgent for me. Was it solved? --000e0cd311a2045e870469e04ca6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This bug is still urgent for me. Was it solved?
--000e0cd311a2045e870469e04ca6-- From owner-freebsd-net@FreeBSD.ORG Thu May 14 18:40:03 2009 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 9EF1F1065676 for ; Thu, 14 May 2009 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3608FC14 for ; Thu, 14 May 2009 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4EIe3FU060813 for ; Thu, 14 May 2009 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4EIe3E3060812; Thu, 14 May 2009 18:40:03 GMT (envelope-from gnats) Date: Thu, 14 May 2009 18:40:03 GMT Message-Id: <200905141840.n4EIe3E3060812@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Stacey Son Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stacey Son List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 18:40:04 -0000 The following reply was made to PR kern/134079; it has been noted by GNATS. From: Stacey Son To: bug-followup@freebsd.org, g.zhengming@gmail.com Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) Date: Thu, 14 May 2009 13:18:35 -0500 I have the same, exact problem with FreeBSD-Current running on VMWare Fusion (64-bit, 2 virtual procs, 4096MB Memory allocation, Mac Pro host). Running 7.2 on this same configuration there is no problem with the e1000 (if_em) driver. Upgrading to -current I get the following error (in dmesg): em0: Invalid MAC address device_attach:em0 attach returned 5 My work around is to edit the "vmx" config file on the host for the virtual image and change: ethernet0.virtualDev="e1000" to: ethernet0.virtualDev="vlance" so the virtual machine emulates an AMD Lance instead. -stacey. From owner-freebsd-net@FreeBSD.ORG Thu May 14 21:42:38 2009 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 25DE01065674 for ; Thu, 14 May 2009 21:42:38 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id D31BD8FC1F for ; Thu, 14 May 2009 21:42:37 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n4ELgZxG009386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 May 2009 14:42:36 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B09701CC12 for ; Thu, 14 May 2009 14:42:35 -0700 (PDT) To: freebsd-net@freebsd.org Date: Thu, 14 May 2009 14:42:35 -0700 From: "Kevin Oberman" Message-Id: <20090514214235.B09701CC12@ptavv.es.net> Subject: IPv6 fragmentation weirdness 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, 14 May 2009 21:42:38 -0000 I have recently noticed problems with data transfers via IPv6. Attempt to fetch files from dome sites was hanging as soon as the data started to flow. Felt like an MTU issue, so I tried sending various sizes of ICMP echo (ping) packets and discovered that I could not send a packet of over 1280 bytes. (ping6 -s 1232) If I disabled kernel fragmentation (-m), I could use packets up to the MTU of my interface (1500 bytes). The path is entirely native IPv6. No tunnels. All should allow full 1500 byte packets. I then captured the ICMP and discovered that the kernel was fragmenting all of them! Worse, the fragment was sent out before the ICMP! What the heck is going on! Thread synchronization? When I captured the packets (via tcpdump -s0 -w file host ftp.funet.fi), the first things captured is an IPv6 fragment of 72 bytes. 3 microseconds later, I get the ICMP6 packet of 1294 bytes. This pattern is consistent over repeated packets. This was with -s 1234 for a total ICMPv6 size of 1282. First, why is the kernel fragmenting this at all as it fits in the interface MTU? Second, why the heck is the fragment going out first? This should be OK, but I suspect many firewalls (which are often not happy with fragments) are not likely to pass a fragment which precedes the initial frame. Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is something in the path that is blocking my traffic, so others may not see this, but I think the root issues is the kernel fragmenting packets way below MTU size. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-net@FreeBSD.ORG Thu May 14 22:09:04 2009 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 C5507106564A for ; Thu, 14 May 2009 22:09:04 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 110368FC1C for ; Thu, 14 May 2009 22:09:03 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 43899 invoked from network); 14 May 2009 22:09:02 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 14 May 2009 22:09:02 -0000 Date: Fri, 15 May 2009 00:09:02 +0200 (CEST) Message-Id: <20090515.000902.74658525.sthaug@nethelp.no> To: oberman@es.net From: sthaug@nethelp.no In-Reply-To: <20090514214235.B09701CC12@ptavv.es.net> References: <20090514214235.B09701CC12@ptavv.es.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPv6 fragmentation weirdness 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, 14 May 2009 22:09:05 -0000 > First, why is the kernel fragmenting this at all as it fits in the > interface MTU? Good question, I definitely disagree with this behavior and would say that it breaks POLA. But it's documented (see the ping6 -m option). > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > something in the path that is blocking my traffic, so others may not see > this, but I think the root issues is the kernel fragmenting packets way > below MTU size. I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow but usable. My path (from Oslo, Norway) is: sthaug@lab1% traceroute6 ftp.funet.fi traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms 8 csc0-x0000-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around 17 ms). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu May 14 22:29:33 2009 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 280C9106564A for ; Thu, 14 May 2009 22:29:33 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id D138C8FC1C for ; Thu, 14 May 2009 22:29:32 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n4EMTVB4011495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 15:29:31 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D71611CC0B; Thu, 14 May 2009 15:29:30 -0700 (PDT) To: sthaug@nethelp.no In-reply-to: Your message of "Fri, 15 May 2009 00:09:02 +0200." <20090515.000902.74658525.sthaug@nethelp.no> Date: Thu, 14 May 2009 15:29:30 -0700 From: "Kevin Oberman" Message-Id: <20090514222930.D71611CC0B@ptavv.es.net> Cc: freebsd-net@freebsd.org Subject: Re: IPv6 fragmentation weirdness 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, 14 May 2009 22:29:33 -0000 > Date: Fri, 15 May 2009 00:09:02 +0200 (CEST) > From: sthaug@nethelp.no > > > First, why is the kernel fragmenting this at all as it fits in the > > interface MTU? > > Good question, I definitely disagree with this behavior and would say > that it breaks POLA. But it's documented (see the ping6 -m option). > > > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > > something in the path that is blocking my traffic, so others may not see > > this, but I think the root issues is the kernel fragmenting packets way > > below MTU size. > > I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow > but usable. My path (from Oslo, Norway) is: > > sthaug@lab1% traceroute6 ftp.funet.fi > traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets > 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms > 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms > 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms > 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms > 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms > 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms > 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms > 8 csc0-x0000-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms > 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms > > Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful > compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around > 17 ms). > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > Thanks, Steinar. I just re-read the man page and I had misunderstood what it was saying. That still leave me baffled as to what is happening. My path is, as would be expected, very different. traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:400:0:40::200:101, 64 hops max, 12 byte packets 1 esnet.rt1.ams.nl.geant2.net (2001:798:29:10aa::9) 83.998 ms 115.099 ms 85.969 ms 2 so-7-0-0.rt2.cop.dk.geant2.net (2001:798:cc:1501:2201::1) 101.692 ms 96.955 ms 96.868 ms 3 nordunet-gw.rt2.cop.dk.geant2.net (2001:798:15:10aa::2) 179.931 ms 205.407 ms 195.268 ms 4 dk-uni.nordu.net (2001:948:0:f055::2) 210.468 ms se-fre.nordu.net (2001:948:0:f03f::1) 187.479 ms dk-uni.nordu.net (2001:948:0:f055::2) 190.578 ms 5 se-tug.nordu.net (2001:948:0:f049::2) 188.170 ms 213.538 ms se-tug.nordu.net (2001:948:0:f056::1) 183.273 ms 6 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 188.114 ms 189.214 ms 192.192 ms 7 csc0-x0000-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 186.166 ms 190.181 ms 186.669 ms 8 ftp.funet.fi (2001:708:10:9::20:1) 186.251 ms 198.591 ms 205.987 ms This is exactly the same as my IPv4 path. Something along this path is silently refusing to pass a packet at the start of the transfer and that screams MTU. If I ping from a Juniper router, I can get 1482 byte packets through, so I suspect that there is a tunnel somewhere. But FreeBSD boxes die at the lower limit. Does the kernel fragmentation only affect ICMP or are TCP packet also fragmented at 1280 bytes? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-net@FreeBSD.ORG Thu May 14 22:35:08 2009 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 84A7A1065733 for ; Thu, 14 May 2009 22:35:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 105FE8FC1C for ; Thu, 14 May 2009 22:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BF64B41C7A5; Fri, 15 May 2009 00:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Og+W5YB2jQea; Fri, 15 May 2009 00:35:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id F1C4B41C7AD; Fri, 15 May 2009 00:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D62FF4448E6; Thu, 14 May 2009 22:34:44 +0000 (UTC) Date: Thu, 14 May 2009 22:34:44 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Kevin Oberman In-Reply-To: <20090514222930.D71611CC0B@ptavv.es.net> Message-ID: <20090514223413.F72053@maildrop.int.zabbadoz.net> References: <20090514222930.D71611CC0B@ptavv.es.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, sthaug@nethelp.no Subject: Re: IPv6 fragmentation weirdness 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, 14 May 2009 22:35:10 -0000 On Thu, 14 May 2009, Kevin Oberman wrote: Hi, >> Date: Fri, 15 May 2009 00:09:02 +0200 (CEST) >> From: sthaug@nethelp.no >> >>> First, why is the kernel fragmenting this at all as it fits in the >>> interface MTU? >> >> Good question, I definitely disagree with this behavior and would say >> that it breaks POLA. But it's documented (see the ping6 -m option). >> >>> Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is >>> something in the path that is blocking my traffic, so others may not see >>> this, but I think the root issues is the kernel fragmenting packets way >>> below MTU size. >> >> I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow >> but usable. My path (from Oslo, Norway) is: >> >> sthaug@lab1% traceroute6 ftp.funet.fi >> traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets >> 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms >> 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms >> 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms >> 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms >> 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms >> 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms >> 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms >> 8 csc0-x0000-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms >> 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms >> >> Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful >> compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around >> 17 ms). >> >> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >> > > Thanks, Steinar. > > I just re-read the man page and I had misunderstood what it was > saying. That still leave me baffled as to what is happening. > > My path is, as would be expected, very different. > traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:400:0:40::200:101, 64 hops max, 12 byte packets > 1 esnet.rt1.ams.nl.geant2.net (2001:798:29:10aa::9) 83.998 ms 115.099 ms 85.969 ms > 2 so-7-0-0.rt2.cop.dk.geant2.net (2001:798:cc:1501:2201::1) 101.692 ms 96.955 ms 96.868 ms > 3 nordunet-gw.rt2.cop.dk.geant2.net (2001:798:15:10aa::2) 179.931 ms 205.407 ms 195.268 ms > 4 dk-uni.nordu.net (2001:948:0:f055::2) 210.468 ms se-fre.nordu.net (2001:948:0:f03f::1) 187.479 ms dk-uni.nordu.net (2001:948:0:f055::2) 190.578 ms > 5 se-tug.nordu.net (2001:948:0:f049::2) 188.170 ms 213.538 ms se-tug.nordu.net (2001:948:0:f056::1) 183.273 ms > 6 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 188.114 ms 189.214 ms 192.192 ms > 7 csc0-x0000-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 186.166 ms 190.181 ms 186.669 ms > 8 ftp.funet.fi (2001:708:10:9::20:1) 186.251 ms 198.591 ms 205.987 ms > > This is exactly the same as my IPv4 path. Something along this path is > silently refusing to pass a packet at the start of the transfer and that > screams MTU. > > If I ping from a Juniper router, I can get 1482 byte packets through, so > I suspect that there is a tunnel somewhere. But FreeBSD boxes die at the > lower limit. > > Does the kernel fragmentation only affect ICMP or are TCP packet also > fragmented at 1280 bytes? WRT to TCP you may also want to check the hostcache: sysctl net.inet.tcp.hostcache.list -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Thu May 14 23:05:51 2009 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 5571B1065678; Thu, 14 May 2009 23:05:51 +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 2A3708FC17; Thu, 14 May 2009 23:05:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4EN5pIx023400; Thu, 14 May 2009 23:05:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4EN5pAE023396; Thu, 14 May 2009 23:05:51 GMT (envelope-from linimon) Date: Thu, 14 May 2009 23:05:51 GMT Message-Id: <200905142305.n4EN5pAE023396@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/134531: [route] [panic] kernel crash related to routes/zebra 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, 14 May 2009 23:05:52 -0000 Old Synopsis: kernel crash related to routes/zebra New Synopsis: [route] [panic] kernel crash related to routes/zebra Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 14 23:05:22 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134531 From owner-freebsd-net@FreeBSD.ORG Fri May 15 12:38:50 2009 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 2377F106568A for ; Fri, 15 May 2009 12:38:50 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 78FEF8FC21 for ; Fri, 15 May 2009 12:38:49 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 58152 invoked by uid 89); 15 May 2009 12:41:17 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 15 May 2009 12:41:17 -0000 Message-ID: <4A0D6253.7080509@ibctech.ca> Date: Fri, 15 May 2009 08:38:43 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Kevin Oberman References: <20090514214235.B09701CC12@ptavv.es.net> In-Reply-To: <20090514214235.B09701CC12@ptavv.es.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040601000108020904000801" Cc: freebsd-net@freebsd.org Subject: Re: IPv6 fragmentation weirdness 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, 15 May 2009 12:38:50 -0000 This is a cryptographically signed message in MIME format. --------------ms040601000108020904000801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kevin Oberman wrote: > Second, why the heck is the fragment going out first? This should be OK, > but I suspect many firewalls (which are often not happy with fragments) > are not likely to pass a fragment which precedes the initial frame. I'll try to find some time today to see if I can replicate this issue. I've never noticed it, mind you, I haven't been looking. > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > something in the path that is blocking my traffic, so others may not see > this, but I think the root issues is the kernel fragmenting packets way > below MTU size. 7.2-RELEASE .iso @ ~14 Mbps from Ontario, Canada: %traceroute6 ftp.funet.fi traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:4978:1:600::2, 64 hops max, 12 byte packets 1 unassigned.v6.your.org 18.742 ms 18.863 ms 18.967 ms 2 ge2-47-107.ar1.ord1.us.nlayer.net 19.951 ms 19.985 ms 19.966 ms 3 xe-1-3-0.cr1.ord1.us.nlayer.net 51.970 ms 70.543 ms 51.435 ms 4 xe-4-1-0.cr1.nyc2.us.nlayer.net 87.404 ms 65.532 ms 63.924 ms 5 xe-1-0-0.cr1.lhr1.uk.nlayer.net 135.912 ms 134.998 ms 134.890 ms 6 2001:2000:3081:9::1 149.455 ms 150.032 ms 149.364 ms 7 s-ipv6-b1-link.ipv6.telia.net 149.408 ms 149.922 ms 148.395 ms 8 ldn-ipv6-b1-link.ipv6.telia.net 150.385 ms 148.909 ms 152.906 ms 9 2001:2000:3080:d::2 225.358 ms 220.996 ms 217.359 ms 10 helsinki0-rtr.funet.fi 225.881 ms 234.301 ms 248.352 ms 11 csc0-x0000-helsinki0.ipv6.funet.fi 226.369 ms 226.393 ms 228.843 ms 12 ftp.funet.fi 225.370 ms 226.904 ms 229.846 ms Steve --------------ms040601000108020904000801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII/zCC AtowggJDoAMCAQICEEs5xg/J3t77QWJ4SatV1HcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUwNzIzMTYxMFoX DTEwMDUwNzIzMTYxMFowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0G CSqGSIb3DQEJARYQc3RldmVAaWJjdGVjaC5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAJSTRAjP1RVa87/mnZn+PBTbENgyhhBJ4rWApmaNcthzRdk2DB/49KrXx3EQP60w Lj4KU0DFkiGNVj9BnVxRAx/WDXKxGC3uGGEG6gjyWv8KFMWMsH9mL7y7uNow1HueT6pZUf9o yY8Ewd+01QpGi7FfXOae7lGHhbEwnEJGwz08ytRfLmH0KtEzlZanZZhwDGX5s1kIHnyxdACh 3byXY6Z2bOrx0rcrQHCnHJppxddR60F7igjaMuBFstE51h9XTgXDNKJbglqTug5ghGihNuP6 VsBN7ue62y96UGIE22TvKEcAQ665vQGjHqZeSzZYy+hWNOa27pWFmhlqFjx0x8MCAwEAAaMt MCswGwYDVR0RBBQwEoEQc3RldmVAaWJjdGVjaC5jYTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4GBAMOmjxjp2Xzk6ZHLwTgFDzVhm98RjRT3UXotKjNIR7SgwfWF5wkJrx4I+dXu ui5ztMEq4bTTRgJ344MqE6uZiZlg+tBIFHZGCJfKdzsX4QuV2jmw0sR5dMaYxG6tlDB0YUMv gTqzV7ZDpiusTMOZe9pP1PdxFhOcIJXtMQDj5LhuMIIC2jCCAkOgAwIBAgIQSznGD8ne3vtB YnhJq1XUdzANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDkwNTA3MjMxNjEwWhcNMTAwNTA3MjMxNjEwWjBCMR8wHQYD VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBzdGV2ZUBpYmN0 ZWNoLmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlJNECM/VFVrzv+admf48 FNsQ2DKGEEnitYCmZo1y2HNF2TYMH/j0qtfHcRA/rTAuPgpTQMWSIY1WP0GdXFEDH9YNcrEY Le4YYQbqCPJa/woUxYywf2YvvLu42jDUe55PqllR/2jJjwTB37TVCkaLsV9c5p7uUYeFsTCc QkbDPTzK1F8uYfQq0TOVlqdlmHAMZfmzWQgefLF0AKHdvJdjpnZs6vHStytAcKccmmnF11Hr QXuKCNoy4EWy0TnWH1dOBcM0oluCWpO6DmCEaKE24/pWwE3u57rbL3pQYgTbZO8oRwBDrrm9 AaMepl5LNljL6FY05rbulYWaGWoWPHTHwwIDAQABoy0wKzAbBgNVHREEFDASgRBzdGV2ZUBp YmN0ZWNoLmNhMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAw6aPGOnZfOTpkcvB OAUPNWGb3xGNFPdRei0qM0hHtKDB9YXnCQmvHgj51e66LnO0wSrhtNNGAnfjgyoTq5mJmWD6 0EgUdkYIl8p3OxfhC5XaObDSxHl0xpjEbq2UMHRhQy+BOrNXtkOmK6xMw5l72k/U93EWE5wg le0xAOPkuG4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f 6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRw Oi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8E BAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEs5xg/J3t77QWJ4SatV 1HcwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDkwNTE1MTIzODQzWjAjBgkqhkiG9w0BCQQxFgQUnIl1y+uskhaSOQiqCkEP9GoM +MUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0Fi eEmrVdR3MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0FieEmrVdR3MA0GCSqGSIb3DQEBAQUABIIB AA3oYiI94mW/Hob9CeXezdmqkpRjgFLB5iWBjR1yQjCWIdFIW3I+rO8m/LT3U9HLRUCMjYv5 VQC/JWeZZwViy/ASV93lF5uj+v36f845jHtRuMoGUecV//pGaTlEP3oAgazV7xbZucm8bUEO WMcPChpawE6iZMz6MBxPLq6kAwRlvvGhr6yntRUblrj2vST0Xrmp9cpL/o6KKEvIVUCU83C9 JyjWdQbdEM8AxD+Mdi8LcbBgwnI0x4p+aKYa+ZrtUil00fCAxBhYTU7b69a+PG4gT+J6Ftiy JMMxKE8T5FB6PAJYGCgmzdXk2HdGiLxPxMUG+1wWkG7a0WIvKI8V0YIAAAAAAAA= --------------ms040601000108020904000801-- From owner-freebsd-net@FreeBSD.ORG Fri May 15 14:00:08 2009 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 6EC6D106564A for ; Fri, 15 May 2009 14:00: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 5CBDD8FC13 for ; Fri, 15 May 2009 14:00:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4FE089X042003 for ; Fri, 15 May 2009 14:00:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4FE08VE042002; Fri, 15 May 2009 14:00:08 GMT (envelope-from gnats) Date: Fri, 15 May 2009 14:00:08 GMT Message-Id: <200905151400.n4FE08VE042002@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/130628: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 14:00:08 -0000 The following reply was made to PR kern/130628; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/130628: commit references a PR Date: Fri, 15 May 2009 13:59:01 +0000 (UTC) Author: dfr Date: Fri May 15 13:58:45 2009 New Revision: 192142 URL: http://svn.freebsd.org/changeset/base/192142 Log: Back port a change to the locking model used to manage active transports from FreeBSD-current to avoid a deadlock. PR: 130628 Modified: stable/7/sys/rpc/svc.c stable/7/sys/rpc/svc.h stable/7/sys/rpc/svc_dg.c stable/7/sys/rpc/svc_vc.c Modified: stable/7/sys/rpc/svc.c ============================================================================== --- stable/7/sys/rpc/svc.c Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc.c Fri May 15 13:58:45 2009 (r192142) @@ -178,18 +178,23 @@ xprt_active(SVCXPRT *xprt) } void -xprt_inactive(SVCXPRT *xprt) +xprt_inactive_locked(SVCXPRT *xprt) { SVCPOOL *pool = xprt->xp_pool; - mtx_lock(&pool->sp_lock); - if (xprt->xp_active) { TAILQ_REMOVE(&pool->sp_active, xprt, xp_alink); xprt->xp_active = FALSE; } - wakeup(&pool->sp_active); +} +void +xprt_inactive(SVCXPRT *xprt) +{ + SVCPOOL *pool = xprt->xp_pool; + + mtx_lock(&pool->sp_lock); + xprt_inactive_locked(xprt); mtx_unlock(&pool->sp_lock); } Modified: stable/7/sys/rpc/svc.h ============================================================================== --- stable/7/sys/rpc/svc.h Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc.h Fri May 15 13:58:45 2009 (r192142) @@ -47,6 +47,7 @@ #include #include #include +#include #endif /* @@ -128,7 +129,7 @@ struct __rpc_svcpool; */ typedef struct __rpc_svcxprt { #ifdef _KERNEL - struct mtx xp_lock; + struct sx xp_lock; struct __rpc_svcpool *xp_pool; /* owning pool (see below) */ TAILQ_ENTRY(__rpc_svcxprt) xp_link; TAILQ_ENTRY(__rpc_svcxprt) xp_alink; @@ -332,6 +333,7 @@ __END_DECLS __BEGIN_DECLS extern void xprt_active(SVCXPRT *); extern void xprt_inactive(SVCXPRT *); +extern void xprt_inactive_locked(SVCXPRT *); __END_DECLS #endif Modified: stable/7/sys/rpc/svc_dg.c ============================================================================== --- stable/7/sys/rpc/svc_dg.c Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc_dg.c Fri May 15 13:58:45 2009 (r192142) @@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -118,7 +119,7 @@ svc_dg_create(SVCPOOL *pool, struct sock xprt = mem_alloc(sizeof (SVCXPRT)); memset(xprt, 0, sizeof (SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = NULL; @@ -161,6 +162,9 @@ static enum xprt_stat svc_dg_stat(SVCXPRT *xprt) { + if (soreadable(xprt->xp_socket)) + return (XPRT_MOREREQS); + return (XPRT_IDLE); } @@ -173,22 +177,17 @@ svc_dg_recv(SVCXPRT *xprt, struct rpc_ms int error, rcvflag; /* + * Serialise access to the socket. + */ + sx_xlock(&xprt->xp_lock); + + /* * The socket upcall calls xprt_active() which will eventually * cause the server to call us here. We attempt to read a * packet from the socket and process it. If the read fails, * we have drained all pending requests so we call * xprt_inactive(). - * - * The lock protects us in the case where a new packet arrives - * on the socket after our call to soreceive fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); - uio.uio_resid = 1000000000; uio.uio_td = curthread; mreq = NULL; @@ -196,8 +195,19 @@ svc_dg_recv(SVCXPRT *xprt, struct rpc_ms error = soreceive(xprt->xp_socket, &raddr, &uio, &mreq, NULL, &rcvflag); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for readability after taking the + * lock to protect us in the case where a new packet + * arrives on the socket after our call to soreceive + * fails with EWOULDBLOCK. The pool lock protects us + * from racing the upcall after our soreadable() call + * returns false. + */ + mtx_lock(&xprt->xp_pool->sp_lock); + if (!soreadable(xprt->xp_socket)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -208,11 +218,11 @@ svc_dg_recv(SVCXPRT *xprt, struct rpc_ms xprt->xp_socket->so_rcv.sb_flags &= ~SB_UPCALL; SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); KASSERT(raddr->sa_len < xprt->xp_rtaddr.maxlen, ("Unexpected remote address length")); @@ -301,7 +311,7 @@ svc_dg_destroy(SVCXPRT *xprt) xprt_unregister(xprt); - mtx_destroy(&xprt->xp_lock); + sx_destroy(&xprt->xp_lock); if (xprt->xp_socket) (void)soclose(xprt->xp_socket); @@ -328,7 +338,5 @@ svc_dg_soupcall(struct socket *so, void { SVCXPRT *xprt = (SVCXPRT *) arg; - mtx_lock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); } Modified: stable/7/sys/rpc/svc_vc.c ============================================================================== --- stable/7/sys/rpc/svc_vc.c Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc_vc.c Fri May 15 13:58:45 2009 (r192142) @@ -54,6 +54,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -142,7 +143,7 @@ svc_vc_create(SVCPOOL *pool, struct sock } xprt = mem_alloc(sizeof(SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = NULL; @@ -219,7 +220,7 @@ svc_vc_create_conn(SVCPOOL *pool, struct cd->strm_stat = XPRT_IDLE; xprt = mem_alloc(sizeof(SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = cd; @@ -255,9 +256,9 @@ svc_vc_create_conn(SVCPOOL *pool, struct * Throw the transport into the active list in case it already * has some data buffered. */ - mtx_lock(&xprt->xp_lock); + sx_xlock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (xprt); cleanup_svc_vc_create: @@ -347,22 +348,27 @@ svc_vc_rendezvous_recv(SVCXPRT *xprt, st * connection from the socket and turn it into a new * transport. If the accept fails, we have drained all pending * connections so we call xprt_inactive(). - * - * The lock protects us in the case where a new connection arrives - * on the socket after our call to accept fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); + sx_xlock(&xprt->xp_lock); error = svc_vc_accept(xprt->xp_socket, &so); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for new connections after taking + * the lock to protect us in the case where a new + * connection arrives after our call to accept fails + * with EWOULDBLOCK. The pool lock protects us from + * racing the upcall after our TAILQ_EMPTY() call + * returns false. + */ + ACCEPT_LOCK(); + mtx_lock(&xprt->xp_pool->sp_lock); + if (TAILQ_EMPTY(&xprt->xp_socket->so_comp)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + ACCEPT_UNLOCK(); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -373,11 +379,11 @@ svc_vc_rendezvous_recv(SVCXPRT *xprt, st xprt->xp_socket->so_rcv.sb_flags &= ~SB_UPCALL; SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); sa = 0; error = soaccept(so, &sa); @@ -422,7 +428,7 @@ svc_vc_destroy_common(SVCXPRT *xprt) xprt_unregister(xprt); - mtx_destroy(&xprt->xp_lock); + sx_destroy(&xprt->xp_lock); if (xprt->xp_socket) (void)soclose(xprt->xp_socket); @@ -483,21 +489,29 @@ svc_vc_stat(SVCXPRT *xprt) /* * Return XPRT_MOREREQS if we have buffered data and we are - * mid-record or if we have enough data for a record marker. + * mid-record or if we have enough data for a record + * marker. Since this is only a hint, we read mpending and + * resid outside the lock. We do need to take the lock if we + * have to traverse the mbuf chain. */ if (cd->mpending) { if (cd->resid) return (XPRT_MOREREQS); n = 0; + sx_xlock(&xprt->xp_lock); m = cd->mpending; while (m && n < sizeof(uint32_t)) { n += m->m_len; m = m->m_next; } + sx_xunlock(&xprt->xp_lock); if (n >= sizeof(uint32_t)) return (XPRT_MOREREQS); } + if (soreadable(xprt->xp_socket)) + return (XPRT_MOREREQS); + return (XPRT_IDLE); } @@ -509,6 +523,12 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms struct mbuf *m; int error, rcvflag; + /* + * Serialise access to the socket and our own record parsing + * state. + */ + sx_xlock(&xprt->xp_lock); + for (;;) { /* * If we have an mbuf chain in cd->mpending, try to parse a @@ -584,6 +604,7 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms */ xdrmbuf_create(&xprt->xp_xdrreq, cd->mreq, XDR_DECODE); cd->mreq = NULL; + sx_xunlock(&xprt->xp_lock); if (! xdr_callmsg(&xprt->xp_xdrreq, msg)) { XDR_DESTROY(&xprt->xp_xdrreq); return (FALSE); @@ -602,17 +623,7 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms * the result in cd->mpending. If the read fails, * we have drained both cd->mpending and the socket so * we can call xprt_inactive(). - * - * The lock protects us in the case where a new packet arrives - * on the socket after our call to soreceive fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); - uio.uio_resid = 1000000000; uio.uio_td = curthread; m = NULL; @@ -621,8 +632,20 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms &rcvflag); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for readability after + * taking the lock to protect us in the case + * where a new packet arrives on the socket + * after our call to soreceive fails with + * EWOULDBLOCK. The pool lock protects us from + * racing the upcall after our soreadable() + * call returns false. + */ + mtx_lock(&xprt->xp_pool->sp_lock); + if (!soreadable(xprt->xp_socket)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -634,7 +657,7 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); cd->strm_stat = XPRT_DIED; - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -642,8 +665,9 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms /* * EOF - the other end has closed the socket. */ + xprt_inactive(xprt); cd->strm_stat = XPRT_DIED; - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -651,8 +675,6 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms m_last(cd->mpending)->m_next = m; else cd->mpending = m; - - mtx_unlock(&xprt->xp_lock); } } @@ -739,9 +761,7 @@ svc_vc_soupcall(struct socket *so, void { SVCXPRT *xprt = (SVCXPRT *) arg; - mtx_lock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); } #if 0 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri May 15 16:57:33 2009 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 D42D51065680 for ; Fri, 15 May 2009 16:57:33 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 4F7298FC28 for ; Fri, 15 May 2009 16:57:33 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 68780 invoked by uid 89); 15 May 2009 17:00:02 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 15 May 2009 17:00:01 -0000 Message-ID: <4A0D9EF7.3030101@ibctech.ca> Date: Fri, 15 May 2009 12:57:27 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Kevin Oberman References: <20090514214235.B09701CC12@ptavv.es.net> <4A0D6253.7080509@ibctech.ca> In-Reply-To: <4A0D6253.7080509@ibctech.ca> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060606050006070800090706" Cc: freebsd-net@freebsd.org Subject: Re: IPv6 fragmentation weirdness 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, 15 May 2009 16:57:34 -0000 This is a cryptographically signed message in MIME format. --------------ms060606050006070800090706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Steve Bertrand wrote: > Kevin Oberman wrote: > >> Second, why the heck is the fragment going out first? This should be OK, >> but I suspect many firewalls (which are often not happy with fragments) >> are not likely to pass a fragment which precedes the initial frame. > > I'll try to find some time today to see if I can replicate this issue. > I've never noticed it, mind you, I haven't been looking. > >> Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is >> something in the path that is blocking my traffic, so others may not see >> this, but I think the root issues is the kernel fragmenting packets way >> below MTU size. > > 7.2-RELEASE .iso @ ~14 Mbps from Ontario, Canada: ...doh! Given that fetch does v4, that 14Mb translates into ~500Kb when using v6 ;) Steve --------------ms060606050006070800090706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII/zCC AtowggJDoAMCAQICEEs5xg/J3t77QWJ4SatV1HcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUwNzIzMTYxMFoX DTEwMDUwNzIzMTYxMFowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0G CSqGSIb3DQEJARYQc3RldmVAaWJjdGVjaC5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAJSTRAjP1RVa87/mnZn+PBTbENgyhhBJ4rWApmaNcthzRdk2DB/49KrXx3EQP60w Lj4KU0DFkiGNVj9BnVxRAx/WDXKxGC3uGGEG6gjyWv8KFMWMsH9mL7y7uNow1HueT6pZUf9o yY8Ewd+01QpGi7FfXOae7lGHhbEwnEJGwz08ytRfLmH0KtEzlZanZZhwDGX5s1kIHnyxdACh 3byXY6Z2bOrx0rcrQHCnHJppxddR60F7igjaMuBFstE51h9XTgXDNKJbglqTug5ghGihNuP6 VsBN7ue62y96UGIE22TvKEcAQ665vQGjHqZeSzZYy+hWNOa27pWFmhlqFjx0x8MCAwEAAaMt MCswGwYDVR0RBBQwEoEQc3RldmVAaWJjdGVjaC5jYTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4GBAMOmjxjp2Xzk6ZHLwTgFDzVhm98RjRT3UXotKjNIR7SgwfWF5wkJrx4I+dXu ui5ztMEq4bTTRgJ344MqE6uZiZlg+tBIFHZGCJfKdzsX4QuV2jmw0sR5dMaYxG6tlDB0YUMv gTqzV7ZDpiusTMOZe9pP1PdxFhOcIJXtMQDj5LhuMIIC2jCCAkOgAwIBAgIQSznGD8ne3vtB YnhJq1XUdzANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDkwNTA3MjMxNjEwWhcNMTAwNTA3MjMxNjEwWjBCMR8wHQYD VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBzdGV2ZUBpYmN0 ZWNoLmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlJNECM/VFVrzv+admf48 FNsQ2DKGEEnitYCmZo1y2HNF2TYMH/j0qtfHcRA/rTAuPgpTQMWSIY1WP0GdXFEDH9YNcrEY Le4YYQbqCPJa/woUxYywf2YvvLu42jDUe55PqllR/2jJjwTB37TVCkaLsV9c5p7uUYeFsTCc QkbDPTzK1F8uYfQq0TOVlqdlmHAMZfmzWQgefLF0AKHdvJdjpnZs6vHStytAcKccmmnF11Hr QXuKCNoy4EWy0TnWH1dOBcM0oluCWpO6DmCEaKE24/pWwE3u57rbL3pQYgTbZO8oRwBDrrm9 AaMepl5LNljL6FY05rbulYWaGWoWPHTHwwIDAQABoy0wKzAbBgNVHREEFDASgRBzdGV2ZUBp YmN0ZWNoLmNhMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAw6aPGOnZfOTpkcvB OAUPNWGb3xGNFPdRei0qM0hHtKDB9YXnCQmvHgj51e66LnO0wSrhtNNGAnfjgyoTq5mJmWD6 0EgUdkYIl8p3OxfhC5XaObDSxHl0xpjEbq2UMHRhQy+BOrNXtkOmK6xMw5l72k/U93EWE5wg le0xAOPkuG4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f 6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRw Oi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8E BAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEs5xg/J3t77QWJ4SatV 1HcwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDkwNTE1MTY1NzI3WjAjBgkqhkiG9w0BCQQxFgQUZcBTaL/kzXhttbxgM2CvVOHP eXswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0Fi eEmrVdR3MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0FieEmrVdR3MA0GCSqGSIb3DQEBAQUABIIB AD4pfvb1yx0Je+vyv8tDH+t6GGFju3W18/6ZMfB71vx5xt1nHqxDzYK85mUX7w7IRFsUEnTo boYF1wfJKl3mKcN4mLGx6o5cA0w9Aijae9xb2Z3+1aX8p1cXmoI96KVIFjZlEFZAtPT/AC/H 5jzQHz1Vy3jAWMgDwFpp/tqTP6jFXKwgbYt+xSNqj+5wnzau75nkOhImTu5O9SCofpPWm2Tx 5xvkhCFIv9+hEjvtULiJCVC9U0VsEoCCQUq9rmcHqX7T5ywfihMR+JfWrS8KkLp8YgOtCzwu TtbSPP2UQ23e50+Bif34EWKwosu/af/1rriVf5AUU3BjhcdpcEP0pYQAAAAAAAA= --------------ms060606050006070800090706-- From owner-freebsd-net@FreeBSD.ORG Fri May 15 17:21:17 2009 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 A5A58106566B; Fri, 15 May 2009 17:21:17 +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 7B44C8FC18; Fri, 15 May 2009 17:21:17 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4FHLH1U018143; Fri, 15 May 2009 17:21:17 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4FHLH9R018132; Fri, 15 May 2009 17:21:17 GMT (envelope-from linimon) Date: Fri, 15 May 2009 17:21:17 GMT Message-Id: <200905151721.n4FHLH9R018132@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem 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, 15 May 2009 17:21:18 -0000 Old Synopsis: 7.2 with mpd5.3 hanging up - ng_pptp problem New Synopsis: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 15 17:20:25 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134557 From owner-freebsd-net@FreeBSD.ORG Sat May 16 03:34:29 2009 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 6EA80106566C; Sat, 16 May 2009 03:34:29 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id D880C8FC13; Sat, 16 May 2009 03:34:28 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id VAA04831; Fri, 15 May 2009 21:34:21 -0600 (MDT) Message-Id: <200905160334.VAA04831@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 15 May 2009 21:11:07 -0600 To: Stefan Lambrev From: Brett Glass In-Reply-To: <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Christian Brueffer , net@FreeBSD.org Subject: Re: MAC locking and filtering in FreeBSD 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, 16 May 2009 03:34:29 -0000 Unfortunately, the pfsense captive portal lacks many of the features that we need and has also had problems in some of our tests. We need the ability to "roll our own" rather than a canned solution, which is why we'd like to make sure that we can implement this via IPFW. --Brett At 01:39 AM 5/14/2009, Stefan Lambrev wrote: >Hi Brett, > >I think what you are looking for is called captive portal. >You can look at pfsense - >http://doc.pfsense.org/index.php/Category:Captive_Portal >which comes with such solution into it. From owner-freebsd-net@FreeBSD.ORG Sat May 16 07:58:56 2009 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 9E7D21065672; Sat, 16 May 2009 07:58:56 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9718FC22; Sat, 16 May 2009 07:58:56 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1359332ywe.13 for ; Sat, 16 May 2009 00:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=1rOWMy0qQG1MgNcSdz/UPoAhPOhHRXzyqnCmBCtwNsA=; b=g8OGeBH071AlVjiFHNroX9OiriZcSlLMheFk+7TrcuzydIQc8gbWT4bR8wYsNd4VCA 5D9QUkqfBGK3kmzQAO9dQB7FpQFO+dZNhcNWlvxthTw39RuCXocwAYvJZzpfh3RJfES5 OBQjrpKALhnMmqJ6EUfC6yHhCngBoCs/IHtvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=eaiLy0GREcw2Xvpdyy2aK1Lhw9vlIvYbD424EXzjryaEFSI27OxSkPY7w9y8N1cIfE RF29yRWxkE/g+Vr/7iCIyv7Yx0czd7AlyUuMXWczR/uAO9xVWBO+uS8yFoCuJSRJaQ8n D3fCCBEJp5j+vyIp9oZq+gT7IecMQNmGIfbSA= MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.151.142.5 with SMTP id u5mr7572605ybn.349.1242458798097; Sat, 16 May 2009 00:26:38 -0700 (PDT) In-Reply-To: <200905160334.VAA04831@lariat.net> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> <200905160334.VAA04831@lariat.net> From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Date: Sat, 16 May 2009 09:26:18 +0200 X-Google-Sender-Auth: 65c3e9cd8d3d8a0c Message-ID: <9a542da30905160026n780b03f4xc34ef0e39cc8b529@mail.gmail.com> To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org, Christian Brueffer , Stefan Lambrev Subject: Re: MAC locking and filtering in FreeBSD 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, 16 May 2009 07:58:56 -0000 What kind of features? Just out of curiosity, cause i made some fixes to it and am curious what can be added more!? On Sat, May 16, 2009 at 5:11 AM, Brett Glass wrote: > Unfortunately, the pfsense captive portal lacks many of the features that we > need and has also had problems in some of our tests. We need the ability to > "roll our own" rather than a canned solution, which is why we'd like to make > sure that we can implement this via IPFW. > > --Brett > > At 01:39 AM 5/14/2009, Stefan Lambrev wrote: > >> Hi Brett, >> >> I think what you are looking for is called captive portal. >> You can look at pfsense - >> http://doc.pfsense.org/index.php/Category:Captive_Portal >> which comes with such solution into it. > > _______________________________________________ > 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 Sat May 16 19:00:56 2009 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 2B6B01065674; Sat, 16 May 2009 19:00:56 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8188FC12; Sat, 16 May 2009 19:00:54 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA16685; Sat, 16 May 2009 13:00:49 -0600 (MDT) Message-Id: <200905161900.NAA16685@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 16 May 2009 13:00:43 -0600 To: Ermal Luçi From: Brett Glass In-Reply-To: <9a542da30905160026n780b03f4xc34ef0e39cc8b529@mail.gmail.co m> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> <200905160334.VAA04831@lariat.net> <9a542da30905160026n780b03f4xc34ef0e39cc8b529@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: net@freebsd.org, Christian Brueffer , Stefan Lambrev Subject: Re: MAC locking and filtering in FreeBSD 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, 16 May 2009 19:00:56 -0000 Among other things, more control -- including an easy way to cut off bandwidth hogs and abusers -- and a walled garden that is better able to hijack browsers (the one in pfsense often fails). We actually have quite a few things we'd like to implement. More offlist if you'd like. --Brett Glass At 01:26 AM 5/16/2009, Ermal Luçi wrote: >What kind of features? >Just out of curiosity, cause i made some fixes to it and am curious >what can be added more!?