From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 04:51:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11C17106566C for ; Sun, 3 Jun 2012 04:51:35 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id CF7FD8FC08 for ; Sun, 3 Jun 2012 04:51:34 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 66EAF20783; Sun, 3 Jun 2012 00:51:34 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 03 Jun 2012 00:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=2EspuW6WYSdvf4HLHRQL3n 9Ou/A=; b=VpfCXQ2YT5ImamzU0Lc1QbUt3G4ydw6K9bW+3HERskcjxWBFNkXHfs WxQomyfSBp7rkTfyyQLCdSXaw9N/Aqwz7KLHW4OZQhhpbTnUryCuXdmTlNyJ9Hq4 Un2HwUxuDAmRWIDTjrKUyRr6Uc83CYyoMu5m/Doa4fg5BCmXEE9B4= X-Sasl-enc: v9CqkGSHqtuwiRQ8UFrwDxaf47xEyv98pbTgAv5hESjk 1338699093 Received: from [192.168.1.124] (unknown [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPA id 68BB148352D; Sun, 3 Jun 2012 00:51:33 -0400 (EDT) Message-ID: <4FCAEDBC.7080602@freebsd.org> Date: Sun, 03 Jun 2012 14:53:16 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4FCA36F6.8040308@freebsd.org> <57EDF758-FF3F-4BA5-B44E-398846B92925@lists.zabbadoz.net> In-Reply-To: <57EDF758-FF3F-4BA5-B44E-398846B92925@lists.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bin/102701 - ifconfig xx0 inet6 delete always fails X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@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, 03 Jun 2012 04:51:35 -0000 On 3/06/2012 5:11 AM, Bjoern A. Zeeb wrote: > > On 2. Jun 2012, at 15:53 , Darren Reed wrote: > >> Is there any reason that this patch hasn't been applied >> to -current? I've just run into this and I can't believe >> that it still exists, given that it falls into the "low >> hanging fruit" category. I'll note that if it wasn't for >> subversion, I'd be doing a commit rather than an email. > > ifconfig [-L] [-k] [-m] [-n] interface [create] address_family [address > [dest_address]] [parameters] > ... > > > The following parameters may be set with ifconfig: > ... > -alias Remove the network address specified. This would be used if you > incorrectly specified an alias, or it was no longer needed. If > you have incorrectly set an NS address having the side effect of > specifying the host portion, removing all NS addresses will allow > you to respecify the host portion. > ... > delete Another name for the -alias parameter. > > > Parameters go last as clearly stated in the beginning of the man page and > that works well: > > root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:ffff::ffff/128 alias > root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:ffff::ffff/128 delete > root@lion3:/home/test # > > > The fact that for inet you could give it in the beginning and other minor > things leniently allowed have caused a lot of trouble the last years. This also works: ifconfig lo0 inet6 alias 2001:db8:ffff::ffff/128 ... so it seems strange for delete to not also work like that. Anyway, if the current behaviour isn't a bug and that PR won't be fixed (or the patch won't be applied) then someone should close it out. Darren From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 05:18:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C37106566C; Sun, 3 Jun 2012 05:18:20 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1D88FC08; Sun, 3 Jun 2012 05:18:20 +0000 (UTC) Received: by dadv36 with SMTP id v36so4702225dad.13 for ; Sat, 02 Jun 2012 22:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/04r3UWOzFi93uuR6/wPrkopWT8lfpAQ/8/RI+uzMzk=; b=iXrs9iBRTPZadbnTmfBWD6ZZmgdh4qdwZ4k3/ino9TlsZH3gBh8LTkZ8DB/C07nW+p wqJrkaFnBBRCFbbrG2zQuY4GjG6m/FXKTiUtFEc3XuX/RpdMHO/bmz4J0e38pRw/ReDU aeuQmeJAO/p6y5rV6zzYdRdPIqUyxfwwllpkvjN+7TCrwdDnG8xuFWxoqx6S7OPFXP9I d3kGCCV7OWOgGIOTAR67SMhEhf7SBcCZfKvTHYQOSEg6g9uD2OJz4pslnUYPQ5FVl7aa lcT9TiN5F75eYxGb8nSkRIHzlGcFeDycX59FSM7ubfzR/0ogomDRNeDlf22p0agU52MS DlFQ== MIME-Version: 1.0 Received: by 10.68.227.69 with SMTP id ry5mr26592953pbc.16.1338700694110; Sat, 02 Jun 2012 22:18:14 -0700 (PDT) Received: by 10.68.71.232 with HTTP; Sat, 2 Jun 2012 22:18:14 -0700 (PDT) In-Reply-To: <4FC82D6C.4050309@freebsd.org> References: <4FBF88CE.20209@cs.duke.edu> <4FC82D6C.4050309@freebsd.org> Date: Sun, 3 Jun 2012 05:18:14 +0000 Message-ID: From: Kevin Oberman To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Andrew Gallatin , Andrew Gallatin Subject: Re: Major performance hit with ToS setting 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, 03 Jun 2012 05:18:20 -0000 On Fri, Jun 1, 2012 at 2:48 AM, Lawrence Stewart wrote: > On 05/31/12 13:33, Kevin Oberman wrote: > [snip] >> >> I used SIFTR at the suggestion of Lawrence Stewart who headed the >> >> project to bring plugable congestion algorithms to FreeBSD and found >> really odd congestion behavior. First, I do see a triple ACK, but the >> congestion window suddenly drops from 73K to 8K. If I understand >> CUBIC, it should half the congestion window, not what is happening.. >> It then increases slowly (in slow start) to 82K. while the slow-start >> bytes are INCREASING, the congestion window again goes to 8K while the >> SS size moves from 36K up to 52K. It just continues to bound wildly >> between 8K (always the low point) and between 64k and 82K. The swings >> start at 83K and, over the first few seconds the peaks drop to about >> 64K. > > > Oh, and a comment about this behaviour. Dropping back to 8k (1MSS) is only > nasty if the TF_{CONG|FAST}RECOVERY flags are *not* set i.e. if you see cwnd > grow, drop to 8k with those flags set, and then when the flags are unset, > cwnd starts at the value of ssthresh, then that is perfectly normal recovery > behaviour. What *is* nasty is if an RTO fires, which will reset cwnd to 8k, > ssthresh to 2*MSS and make the connection effectively start from scratch > again. > > There is evidence of RTOs in your siftr output, which is bad news e.g here's > one example of 2 side-by-side log lines from your trace: > > # Direction,time,ssthresh,cwnd,flags > i,1338319593.574706,27044,27044,1630544864 > o,1338319593.831482,16384,8192,1092625377 > > Note the 300ms gap, and how cwnd resets to 1MSS and flags go from 1630544864 > (TF_WASCRECOVERY|TF_CONGRECOVERY|TF_WASFRECOVERY|TF_FASTRECOVERY) to > 1092625377 (TF_WASCRECOVERY|TF_WASFRECOVERY). What can I say but that you are right. When I looked at the interface stats I found that the link overflow drops were through the roof! This confuses me a bit since the traffic is outbound and I woudl assume from the description on hte Myricom web page that these are input drops. A problem a problem with that card? On systems that are working "normally", I still see a sharp drop with the ToS bits set, but nothing nearly as drastic. Now it is a drop from 4.5G to 728M on a cross-country (US) circuit. I am now looking for issues on the route that might explain the performance, but the question of why the drop-of only shows up in FreeBSD 8 means something odd is still going on. It is even possible that the problem is with 7 and the losses are due to the policy for ToS 32 on the path. ToS 32 is less than best effort in our network. Maybe the marking was getting lost on 7. Not likely, but possible. I'll post further details after some very careful reviews of router statistics. Thanks, Lawrence! -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 12:15:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 179041065670; Sun, 3 Jun 2012 12:15:41 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 917C48FC17; Sun, 3 Jun 2012 12:15:40 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3AF4125D3A9E; Sun, 3 Jun 2012 12:15:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 3A02DBE7518; Sun, 3 Jun 2012 12:15:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id pqQ8oH8aeNOY; Sun, 3 Jun 2012 12:15:36 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D20B7BE7517; Sun, 3 Jun 2012 12:15:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FCAEDBC.7080602@freebsd.org> Date: Sun, 3 Jun 2012 12:15:35 +0000 Content-Transfer-Encoding: 7bit Message-Id: <9D90684A-84DA-436F-BF38-F07EC4394863@lists.zabbadoz.net> References: <4FCA36F6.8040308@freebsd.org> <57EDF758-FF3F-4BA5-B44E-398846B92925@lists.zabbadoz.net> <4FCAEDBC.7080602@freebsd.org> To: darrenr@freebsd.org X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: bin/102701 - ifconfig xx0 inet6 delete always fails 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, 03 Jun 2012 12:15:41 -0000 On 3. Jun 2012, at 04:53 , Darren Reed wrote: > On 3/06/2012 5:11 AM, Bjoern A. Zeeb wrote: >> >> On 2. Jun 2012, at 15:53 , Darren Reed wrote: >> ... >> Parameters go last as clearly stated in the beginning of the man page and >> that works well: >> >> root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:ffff::ffff/128 alias >> root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:ffff::ffff/128 delete >> root@lion3:/home/test # >> >> >> The fact that for inet you could give it in the beginning and other minor >> things leniently allowed have caused a lot of trouble the last years. > > This also works: > > ifconfig lo0 inet6 alias 2001:db8:ffff::ffff/128 > > ... so it seems strange for delete to not also work like that. Hmm, that wasn't supposed to work either for v6. *grml* > Anyway, if the current behaviour isn't a bug and that PR won't be > fixed (or the patch won't be applied) then someone should close it > out. It is. It says State: closed when I look it up. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 12:33:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16087106564A for ; Sun, 3 Jun 2012 12:33:56 +0000 (UTC) (envelope-from gallatin@myri.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B851D8FC0C for ; Sun, 3 Jun 2012 12:33:55 +0000 (UTC) Received: by ghbz22 with SMTP id z22so3361758ghb.13 for ; Sun, 03 Jun 2012 05:33:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ejU0cfAhprEjCC/hLeIbq2an4lww+cbunswwBaJG/Xc=; b=CAKX73xgJPTWlRd1BOtIoPWeVxQdTssrojhEJRxutZED0O41iyEhxikjZcgY2aoS2Y fINj/oYVm7kuV+k1NAFDkmVIyVUyhjVxy3ZTNJJpTWLqEbrgVg44MIbEimqveBEnJsyo mkTGeFQMSZLCq2ZwBztByAgIQ/Wt7s8ZbIP6R34RfmJj5/+pdHZOB9nNfKpKiUy8Y+uH tK/Vs3b8tqPOLOQ4qwkz1dPtDA+BrWoFxOKV3NrOKtbyRRrH5VlvGFaWsWnd6Zg2otAm dmIWBmVaAEFL4bL54OpDqQhNH0NWAdo8bMhkrBqMoYhml+5cHHMw9HsMkI66o9CIT5J2 IXzw== Received: by 10.236.145.168 with SMTP id p28mr4095895yhj.4.1338726835213; Sun, 03 Jun 2012 05:33:55 -0700 (PDT) Received: from [192.168.200.2] (c-24-125-204-77.hsd1.va.comcast.net. [24.125.204.77]) by mx.google.com with ESMTPS id c8sm19580382yhm.18.2012.06.03.05.33.54 (version=SSLv3 cipher=OTHER); Sun, 03 Jun 2012 05:33:54 -0700 (PDT) Message-ID: <4FCB59B1.2050908@myri.com> Date: Sun, 03 Jun 2012 08:33:53 -0400 From: Andrew Gallatin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kevin Oberman References: <4FBF88CE.20209@cs.duke.edu> <4FC82D6C.4050309@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlzxI1K6xyPzh6v89nRIBbeB6sg3iUscn5kIlbgG9W+FGgofraY01dCuvFRnzU+q+EvElVQ Cc: Lawrence Stewart , Andrew Gallatin , freebsd-net@freebsd.org Subject: Re: Major performance hit with ToS setting 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, 03 Jun 2012 12:33:56 -0000 On 06/03/12 01:18, Kevin Oberman wrote: > What can I say but that you are right. When I looked at the interface > stats I found that the link overflow drops were through the roof! This > confuses me a bit since the traffic is outbound and I woudl assume Indeed, link overflow is incoming traffic that was dropped due to lack of rx resources. If you have flow control disabled, it is drops simply due to lack of space in the rx fifo. If you have flow control enabled, link overflow can include drops due to lack of host rx buffers as well. For primarily WAN traffic, we suggest that flow control be disabled (it is enabled by default). With f/c disabled, drops due to lack of rx buffers are counted as dropped_no_[big|small]_buffer At any rate, it is surprising to see link overflow increase on an outgoing unidirectional test. Is there other incoming traffic that you might not have been aware of? The only really unlikely thing I can think of is if something is buffering tens of thousands of acks and dumping them all at once. Drew From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 16:51:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3D5F1065672 for ; Sun, 3 Jun 2012 16:51:19 +0000 (UTC) (envelope-from bounces+73574-866e-freebsd-net=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 6B5628FC16 for ; Sun, 3 Jun 2012 16:51:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=smtpapi; bh=Mi9/DbovhHiry6yybyyzN4P f6pM=; b=wyv0B/FvMStarTwgBKIIqLyFk7tmuJnyljejr1P0gEPu4oY090Gk0Zq oOrovMl/y7IzUf8qozm457goCr/OSIeapuhb/cmuaQvWcm7zPXgQdkO62d8WEhsC IgH//xYq3g2Flpf0CHMBd1+c2FwGhonD1hZk5kqYjRURV1hbu148= Received: by 10.41.149.156 with SMTP id f04-21.20172.4FCB960111 Sun, 03 Jun 2012 16:51:13 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.8.49.124]) by mi4 (SG) with ESMTP id 4fcb9601.461d.3bec0c2 for ; Sun, 03 Jun 2012 11:51:13 -0500 (CST) Received: (qmail 32518 invoked from network); 3 Jun 2012 16:43:31 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by mail.tarsnap.com with ESMTP; 3 Jun 2012 16:43:31 -0000 Received: (qmail 32186 invoked from network); 3 Jun 2012 16:51:02 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 3 Jun 2012 16:51:02 -0000 Message-ID: <4FCB95F6.30204@freebsd.org> Date: Sun, 03 Jun 2012 09:51:02 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120509 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Gallatin References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> In-Reply-To: <4FC63D27.70807@cs.duke.edu> X-Enigmail-Version: 1.5pre Content-Type: multipart/mixed; boundary="------------010705070900080106050908" X-Sendgrid-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxHlg7RAud3TTYZr9QVSeo9IJ9+l/mitYMw78g4lVdZtunuW9cVVCosro439GFVLCwSHePeBYXzH9/Yvm2gDY0ThL8NkaxEdOMCcoklYGaoXQcD3wzUI9n5XW8h2+C0RrxQ= Cc: freebsd-net@freebsd.org Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 16:51:19 -0000 This is a multi-part message in MIME format. --------------010705070900080106050908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/30/12 08:30, Andrew Gallatin wrote: > On 05/30/12 10:59, Colin Percival wrote: >> The Xen virtual network interface has an issue (ok, really the issue is with >> the linux back-end, but that's what most people are using) where it can't >> handle scatter-gather writes with lots of pieces, aka. long mbuf chains. >> This currently bites us hard with TSO enabled, since it produces said long >> mbuf chains. > > I think a better approach would be to have a limit on the size of the > pre-segmented TCP payload size sent to the driver. I tend to think > that this would be more generically useful, and it is a better match > for the NDIS APIs, where a driver must specify the max TSO size. I > think the changes to the TCP stack might be simpler (eg, they > would seem to jive better with the existing "maxmtu" approach). > > I think this could work for you as well. You could set the Xen max > tso size to be 32K (derived from 18 pages/skb, multiplied by a typical > 2KB mbuf size, with some slack built in). If the chain was too large, > you could m_defrag it down to size. I've attached a new patch which: 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet, 2. sets these in netfront when the IFCAP_TSO4 flag is set, 3. extends tcp_maxmtu to read this value, 4. adds a tx_tso_mss field to struct tcpcb, 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and 6. limits TSO lengths to tx_tso_mss in tcp_output. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid --------------010705070900080106050908 Content-Type: text/plain; charset=us-ascii; name="tx_tso_mss.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tx_tso_mss.patch" Index: netinet/tcp_input.c =================================================================== --- netinet/tcp_input.c (revision 235780) +++ netinet/tcp_input.c (working copy) @@ -3298,6 +3298,7 @@ { int mss = 0; u_long maxmtu = 0; + int tx_tso_mss = 0; struct inpcb *inp = tp->t_inpcb; struct hc_metrics_lite metrics; int origoffer; @@ -3321,8 +3322,10 @@ /* Initialize. */ #ifdef INET6 if (isipv6) { - maxmtu = tcp_maxmtu6(&inp->inp_inc, mtuflags); + maxmtu = tcp_maxmtu6_ext(&inp->inp_inc, mtuflags, + &tx_tso_mss); tp->t_maxopd = tp->t_maxseg = V_tcp_v6mssdflt; + tp->t_tx_tso_mss = tx_tso_mss; } #endif #if defined(INET) && defined(INET6) @@ -3330,8 +3333,10 @@ #endif #ifdef INET { - maxmtu = tcp_maxmtu(&inp->inp_inc, mtuflags); + maxmtu = tcp_maxmtu_ext(&inp->inp_inc, mtuflags, + &tx_tso_mss); tp->t_maxopd = tp->t_maxseg = V_tcp_mssdflt; + tp->t_tx_tso_mss = tx_tso_mss; } #endif Index: netinet/tcp_subr.c =================================================================== --- netinet/tcp_subr.c (revision 235780) +++ netinet/tcp_subr.c (working copy) @@ -1708,7 +1708,7 @@ * tcp_mss_update to get the peer/interface MTU. */ u_long -tcp_maxmtu(struct in_conninfo *inc, int *flags) +tcp_maxmtu_ext(struct in_conninfo *inc, int *flags, int * tx_tso_mss) { struct route sro; struct sockaddr_in *dst; @@ -1738,15 +1738,26 @@ ifp->if_hwassist & CSUM_TSO) *flags |= CSUM_TSO; } + if (tx_tso_mss != NULL) { + if (ifp->if_capabilities & IFCAP_TSO_MSS) + *tx_tso_mss = ifp->if_tx_tso_mss; + } RTFREE(sro.ro_rt); } return (maxmtu); } + +u_long +tcp_maxmtu(struct in_conninfo *inc, int *flags) +{ + + return (tcp_maxmtu_ext(inc, flags, NULL)); +} #endif /* INET */ #ifdef INET6 u_long -tcp_maxmtu6(struct in_conninfo *inc, int *flags) +tcp_maxmtu6_ext(struct in_conninfo *inc, int *flags, int * tx_tso_mss) { struct route_in6 sro6; struct ifnet *ifp; @@ -1775,11 +1786,22 @@ ifp->if_hwassist & CSUM_TSO) *flags |= CSUM_TSO; } + if (tx_tso_mss != NULL) { + if (ifp->if_capabilities & IFCAP_TSO_MSS) + *tx_tso_mss = ifp->if_tx_tso_mss; + } RTFREE(sro6.ro_rt); } return (maxmtu); } + +u_long +tcp_maxmtu6(struct in_conninfo *inc, int *flags) +{ + + return (tcp_maxmtu6_ext(inc, flags, NULL)); +} #endif /* INET6 */ #ifdef IPSEC Index: netinet/tcp_var.h =================================================================== --- netinet/tcp_var.h (revision 235780) +++ netinet/tcp_var.h (working copy) @@ -208,7 +208,8 @@ u_int t_keepintvl; /* interval between keepalives */ u_int t_keepcnt; /* number of keepalives before close */ - uint32_t t_ispare[8]; /* 5 UTO, 3 TBD */ + uint32_t t_tx_tso_mss; /* max segment size for TSO offload */ + uint32_t t_ispare[7]; /* 5 UTO, 3 TBD */ void *t_pspare2[4]; /* 4 TBD */ uint64_t _pad[6]; /* 6 TBD (1-2 CC/RTT?) */ }; @@ -674,7 +675,9 @@ #endif void tcp_input(struct mbuf *, int); u_long tcp_maxmtu(struct in_conninfo *, int *); +u_long tcp_maxmtu_ext(struct in_conninfo *, int *, int *); u_long tcp_maxmtu6(struct in_conninfo *, int *); +u_long tcp_maxmtu6_ext(struct in_conninfo *, int *, int *); void tcp_mss_update(struct tcpcb *, int, int, struct hc_metrics_lite *, int *); void tcp_mss(struct tcpcb *, int); Index: netinet/tcp_output.c =================================================================== --- netinet/tcp_output.c (revision 235780) +++ netinet/tcp_output.c (working copy) @@ -748,6 +748,15 @@ } /* + * Some drivers want an even shorter limit to the + * length sent via TSO; respect their wishes. + */ + if (tp->t_tx_tso_mss != 0 && len > tp->t_tx_tso_mss) { + len = tp->t_tx_tso_mss; + sendalot = 1; + } + + /* * Prevent the last segment from being * fractional unless the send sockbuf can * be emptied. Index: dev/xen/netfront/netfront.c =================================================================== --- dev/xen/netfront/netfront.c (revision 235780) +++ dev/xen/netfront/netfront.c (working copy) @@ -135,6 +135,7 @@ * to mirror the Linux MAX_SKB_FRAGS constant. */ #define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2) +#define TX_TSO_MSS (MAX_TX_REQ_FRAGS - 2) * MCLBYTES #define RX_COPY_THRESHOLD 256 @@ -2040,6 +2041,9 @@ if (val) { np->xn_ifp->if_capabilities |= IFCAP_TSO4|IFCAP_LRO; printf(" feature-gso-tcp4"); + + np->xn_ifp->if_capabilities |= IFCAP_TSO_MSS; + np->xn_ifp->if_tx_tso_mss = TX_TSO_MSS; } printf("\n"); Index: net/if.h =================================================================== --- net/if.h (revision 235780) +++ net/if.h (working copy) @@ -230,6 +230,7 @@ #define IFCAP_VLAN_HWTSO 0x40000 /* can do IFCAP_TSO on VLANs */ #define IFCAP_LINKSTATE 0x80000 /* the runtime link state is dynamic */ #define IFCAP_NETMAP 0x100000 /* netmap mode supported/enabled */ +#define IFCAP_TSO_MSS 0x200000 /* TSO size is limited */ #define IFCAP_HWCSUM (IFCAP_RXCSUM | IFCAP_TXCSUM) #define IFCAP_TSO (IFCAP_TSO4 | IFCAP_TSO6) Index: net/if_var.h =================================================================== --- net/if_var.h (revision 235780) +++ net/if_var.h (working copy) @@ -205,7 +205,8 @@ * be used with care where binary compatibility is required. */ char if_cspare[3]; - int if_ispare[4]; + int if_tx_tso_mss; /* if IFCAP_TSO_MSS */ + int if_ispare[3]; void *if_pspare[8]; /* 1 netmap, 7 TDB */ }; --------------010705070900080106050908-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 17:06:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B60B106564A; Sun, 3 Jun 2012 17:06:01 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 09FEF8FC14; Sun, 3 Jun 2012 17:06:00 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7B4A125D3A90; Sun, 3 Jun 2012 17:05:59 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 779F4BE751D; Sun, 3 Jun 2012 17:05:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id NKWaG1YibvRz; Sun, 3 Jun 2012 17:05:57 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B8790BE751C; Sun, 3 Jun 2012 17:05:56 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Jun 2012 17:05:54 +0000 Message-Id: <90B0A065-634A-47F5-A8B9-3D093865F48A@lists.zabbadoz.net> To: Jack F Vogel Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Networking Mailing List Subject: ixgbe(4) intr and pps problems in at least HEAD 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, 03 Jun 2012 17:06:01 -0000 Hey Jack or anyone on net@, having updated my sources of HEAD from Dec/Mar to something of last week I get a lot of: interrupt storm detected on "irq262:"; throttling interrupt source Given Intel's driver REDAME I found online says to update the sysctl to = this: hw.intr_storm_threshold=3D9000 I did that. I then quickly ended up at 25k which still wasn't enough so I added 2 more zeros to get my console unspammed. Any idea what the cause for this could be? The few input pps also seem = to keep it quite busy, even if only distributed to a single queue and what = netstat reports is far from ideal. The pps number it should be able to take should be way higher I feel and = I am sending it a load more pps anyway. # netstat -I ix1 -w 1 input (ix1) output packets errs idrops bytes packets errs bytes colls 114467 200089 0 23275412 113885 0 8458948 0 147135 206724 0 26074654 147010 0 10820024 0 176973 334783 0 37914940 176904 0 13117378 0 106443 274685 0 28386046 106781 0 8002984 0 35404 0 0 2492980 35236 0 2538270 0 172295 214024 0 28396162 171991 0 12616392 0 52870 201826 0 19069376 53563 0 4068360 0 182143 366926 0 40728536 181543 0 13530772 0 128465 231976 0 26673492 128992 0 9513468 0 26161 0 0 1841770 26204 0 1880830 0 115360 220160 0 24864314 115523 0 8562074 0 ^C 12 root -92 - 0K 432K CPU1 1 474:32 100.00% = intr{irq262: ix1:que } 0 root -92 0 0K 384K CPU0 0 226:12 100.00% = kernel{ix1 que} 12 root -92 - 0K 432K CPU3 3 214:36 99.66% = intr{irq264: ix1:que } 0 root -92 0 0K 384K - 2 464:29 98.29% kernel{ix1 = que} 11 root 155 ki31 0K 64K RUN 2 82.9H 1.56% idle{idle: = cpu2} 12 root -92 - 0K 432K WAIT 2 26:15 1.17% = intr{irq263: ix1:que } 11 root 155 ki31 0K 64K RUN 0 84.0H 0.00% idle{idle: = cpu0} 11 root 155 ki31 0K 64K RUN 3 82.4H 0.00% idle{idle: = cpu3} 11 root 155 ki31 0K 64K RUN 1 79.5H 0.00% idle{idle: = cpu1} 12 root -92 - 0K 432K RUN 0 26:34 0.00% = intr{irq261: ix1:que } 17 root 16 - 0K 16K syncer 2 26:25 0.00% syncer 0 root -92 0 0K 384K - 3 17:30 0.00% kernel{ix1 = que} 0 root -92 0 0K 384K RUN 2 16:09 0.00% kernel{em0 = que} 0 root -92 0 0K 384K - 0 15:54 0.00% kernel{ix1 = que} 12 root -60 - 0K 432K WAIT 1 10:38 0.00% intr{swi4: = clock} Is anyone seeing this as well or can reproduce it? It's a ix1@pci0:3:0:1: class=3D0x020000 card=3D0xa15f8086 chip=3D0x10c68086 = rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82598EB 10-Gigabit AF Dual Port Network Connection' class =3D network subclass =3D ethernet with only 1 port used currently. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 17:58:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D04106564A for ; Sun, 3 Jun 2012 17:58:41 +0000 (UTC) (envelope-from camzal@trash-mail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3FB8FC19 for ; Sun, 3 Jun 2012 17:58:41 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SbF4a-0007DU-Aq for freebsd-net@freebsd.org; Sun, 03 Jun 2012 10:58:40 -0700 Date: Sun, 3 Jun 2012 10:58:40 -0700 (PDT) From: camzal To: freebsd-net@freebsd.org Message-ID: <1338746320312-5714572.post@n5.nabble.com> In-Reply-To: <1338381030717-5713365.post@n5.nabble.com> References: <20120425210856.GB8498@michelle.cdnetworks.com> <1338243177761-5713012.post@n5.nabble.com> <1338381030717-5713365.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Realtek 8111F 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, 03 Jun 2012 17:58:41 -0000 Thank you for your tutorial. I compiled the three files (64bit) http://shareplace.com/?02715E1729 http://shareplace.com/?02715E1729 and my RTL8111F was detected :) -- View this message in context: http://freebsd.1045724.n5.nabble.com/Realtek-8111F-tp5661828p5714572.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 18:12:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33D2B106564A; Sun, 3 Jun 2012 18:12:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 010A28FC14; Sun, 3 Jun 2012 18:12:07 +0000 (UTC) Received: by dadv36 with SMTP id v36so5136072dad.13 for ; Sun, 03 Jun 2012 11:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M5wmgYMUZJs1Wa0LxF6crCLtLebV5NA1ci5B9dv1vD0=; b=uJVFel6O3QU2zs9meBuP9z1LbMmPh7F+8FK91bI62uL0ihsv3Fk3hLw3oOexEvS3VD 32cSWMUW/9MmO7VDWGw7u0wXtJafyDWF3J3DBAWTgQfwuPs5Rv3RzmsvR48qSFWRe0gk NSraNJ6+TUXLWp2hS63Hba+5QrztudH5z2556KbygFjQ12Tf1D56nipUrvVEBxV06FZS 9K2n8ZNvfuPTimvYvEpTq2jo+gSvI9MhpQZL3FmLACATp+fTgQE8hiNdpzn87JewlzFM 4Y1ueE8ElQRayTEN9gOxg/UmXy2gJk0nB3cfFWgfN4GyVNFK/CJjtvs/PtxjqJfe2mju z8Cw== MIME-Version: 1.0 Received: by 10.68.211.170 with SMTP id nd10mr31265798pbc.68.1338747127608; Sun, 03 Jun 2012 11:12:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Sun, 3 Jun 2012 11:12:07 -0700 (PDT) In-Reply-To: <90B0A065-634A-47F5-A8B9-3D093865F48A@lists.zabbadoz.net> References: <90B0A065-634A-47F5-A8B9-3D093865F48A@lists.zabbadoz.net> Date: Sun, 3 Jun 2012 11:12:07 -0700 X-Google-Sender-Auth: zfeo265NEeVsnPhd9x46OiJ2KZo Message-ID: From: Adrian Chadd To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , FreeBSD Networking Mailing List Subject: Re: ixgbe(4) intr and pps problems in at least HEAD 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, 03 Jun 2012 18:12:08 -0000 On 3 June 2012 10:05, Bjoern A. Zeeb wrote: > Hey Jack or anyone on net@, > > having updated my sources of HEAD from Dec/Mar to something of last week > I get a lot of: > > interrupt storm detected on "irq262:"; throttling interrupt source That to me almost sounds like no interrupt mitigation or just an unserviced isr bit. Can you go grovelling through the interrupt handler and see what bits are/aren't being handled? Adrian From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 19:05:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBD1F106566C; Sun, 3 Jun 2012 19:05:25 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2138FC0A; Sun, 3 Jun 2012 19:05:25 +0000 (UTC) Received: from [192.168.200.2] (c-24-125-204-77.hsd1.va.comcast.net [24.125.204.77]) (authenticated bits=0) by duke.cs.duke.edu (8.14.5/8.14.5) with ESMTP id q53J5Ikn029786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jun 2012 15:05:18 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu q53J5Ikn029786 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1338750318; bh=WcFbGonLnz+xEQDcGOgn9aEtCjLkaoVlZxC3Wk6EhNY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=f/k5PVv/0svHa7vhlXBElHK6rmiGc8aM/VU0UPx1cEfmp1P8UuBobw4yCG8zdCsxc LdJRR7cB93n4JL65+jUy2ulyF5kQviB06Nphyy2pVMSqdSmC3FxxJsbO1Jq+OvpjIw woW77JQ98kFywJQFKOjVqKj19mzjNdd9iIowsL15pXWm70EkN/zGfa7spcP4fBbSGd s2ZFD8CDaO0DkqsqWE8TLa4nQX6/QCxNXursXQBHzkntL/YdnmSONe9cdQ3mGjNEq0 2OLCGSl5Eb7Vc8TK4mLFu0H2F9RWDviM2qPvlkRz3VBiHX5GpZrnWIeHUgXwSxfxbs MH0a1XwkE5lGw== Message-ID: <4FCBB56D.2080800@cs.duke.edu> Date: Sun, 03 Jun 2012 15:05:17 -0400 From: Andrew Gallatin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Colin Percival References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> <4FCB95F6.30204@freebsd.org> In-Reply-To: <4FCB95F6.30204@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 19:05:25 -0000 On 06/03/12 12:51, Colin Percival wrote: > On 05/30/12 08:30, Andrew Gallatin wrote: >> On 05/30/12 10:59, Colin Percival wrote: >>> The Xen virtual network interface has an issue (ok, really the issue is with >>> the linux back-end, but that's what most people are using) where it can't >>> handle scatter-gather writes with lots of pieces, aka. long mbuf chains. >>> This currently bites us hard with TSO enabled, since it produces said long >>> mbuf chains. >> >> I think a better approach would be to have a limit on the size of the >> pre-segmented TCP payload size sent to the driver. I tend to think >> that this would be more generically useful, and it is a better match >> for the NDIS APIs, where a driver must specify the max TSO size. I >> think the changes to the TCP stack might be simpler (eg, they >> would seem to jive better with the existing "maxmtu" approach). >> >> I think this could work for you as well. You could set the Xen max >> tso size to be 32K (derived from 18 pages/skb, multiplied by a typical >> 2KB mbuf size, with some slack built in). If the chain was too large, >> you could m_defrag it down to size. > > I've attached a new patch which: > 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet, > 2. sets these in netfront when the IFCAP_TSO4 flag is set, > 3. extends tcp_maxmtu to read this value, > 4. adds a tx_tso_mss field to struct tcpcb, > 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and > 6. limits TSO lengths to tx_tso_mss in tcp_output. > Looks good to me. I don't pretend to understand the bowels of the TCP stack, so I can't comment on the "sendalot" stuff to force segmentation. I assume it works as well as your previous patch to solve the problems you were seeing with Xen? One minor nit is that I envision this limit to always be 64K or less, so you could probably get away with stealing 16 bits from ifcspare. The other trivial nit is that I would have made these new if_tx_tso_mss and t_tx_tso_mss fields unsigned. Thanks so much for doing this! Drew From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 20:08:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9483A106566C for ; Sun, 3 Jun 2012 20:08:23 +0000 (UTC) (envelope-from philipp_subx@redfish-solutions.com) Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [66.232.79.143]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1758FC1B for ; Sun, 3 Jun 2012 20:08:23 +0000 (UTC) Received: from macbook.redfish-solutions.com ([192.168.1.17]) (authenticated bits=0) by mail.redfish-solutions.com (8.14.5/8.14.5) with ESMTP id q53JveLE013137 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 3 Jun 2012 13:57:40 -0600 Message-ID: <4FCBC1B4.2090904@redfish-solutions.com> Date: Sun, 03 Jun 2012 13:57:40 -0600 From: Philip Prindeville User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.1.3 Subject: BSD and Darwin routing API questions 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, 03 Jun 2012 20:08:23 -0000 Hi. I'm working on a portable (multiplatform) C library for manipulating routing tables. It will eventually be wrapperized for the C++ Poco toolkit, but the raw C API should be usable directly too. I'm trying to support BSD/MacOSX, Linux, and Win32. My experience with BSD routing tables was current as of NetBSD circa 1999, so I have a little catching up to do. Anyway, if someone can collaborate with me and answer some questions about some of the corner cases (like IPsec and 6to4 tunnelling, etc.) I'd appreciate it: please contact me offline. Pointers to useful examples are also appreciated. I looked at netutils (route and netstat), Quagga, KAME, and a couple of other places but the latter all seemed to be oriented toward special cases. Thanks, -Philip From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 20:56:35 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65FAC10656DC; Sun, 3 Jun 2012 20:56:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 02DC88FC08; Sun, 3 Jun 2012 20:56:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA01667; Sun, 03 Jun 2012 23:56:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SbHqi-000MuE-3h; Sun, 03 Jun 2012 23:56:32 +0300 Message-ID: <4FCBCF7E.9020603@FreeBSD.org> Date: Sun, 03 Jun 2012 23:56:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-Current , freebsd-net@FreeBSD.org X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org, Jung-uk Kim Subject: null pointer panic in bpf_peers_present 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, 03 Jun 2012 20:56:35 -0000 I wonder if anybody else is seeing this and if there is a fix... This is very recent (today's) FreeBSD head with pretty dull network configuration. During boot I run into the following panic: <118>Setting hostname: xxxxx <118>Starting dhclient. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805a12a8 stack pointer = 0x28:0xffffff8249905a10 frame pointer = 0x28:0xffffff8249905a50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq20: rl0) trap number = 12 panic: page fault cpuid = 0 curthread: 0xfffffe00115e14b0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff802cc50a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff8051ce2a = kdb_backtrace+0x3a panic() at 0xffffffff804e9e36 = panic+0x266 trap_fatal() at 0xffffffff80692f9d = trap_fatal+0x3ad trap_pfault() at 0xffffffff806930d5 = trap_pfault+0x115 trap() at 0xffffffff8069383b = trap+0x49b calltrap() at 0xffffffff8067ec63 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff805a12a8, rsp = 0xffffff8249905a10, rbp = 0xffffff8249905a50 --- ether_nh_input() at 0xffffffff805a12a8 = ether_nh_input+0x118 netisr_dispatch_src() at 0xffffffff805a9a31 = netisr_dispatch_src+0xb1 netisr_dispatch() at 0xffffffff805a9c41 = netisr_dispatch+0x11 ether_input() at 0xffffffff805a0c0e = ether_input+0xe rl_rxeof() at 0xffffffff805f97c8 = rl_rxeof+0x228 rl_intr() at 0xffffffff805faaa6 = rl_intr+0xf6 intr_event_execute_handlers() at 0xffffffff804c17e9 = intr_event_execute_handlers+0xd9 ithread_loop() at 0xffffffff804c247f = ithread_loop+0x9f fork_exit() at 0xffffffff804bef25 = fork_exit+0x125 fork_trampoline() at 0xffffffff8067f18e = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8249905cf0, rbp = 0 --- Uptime: 31s ether_nh_input+0x118 corresponds to: (kgdb) list *ether_nh_input+0x118 0xffffffff805a12a8 is in ether_nh_input (bpf.h:1248). 1243 1244 static __inline int 1245 bpf_peers_present(struct bpf_if *bpf) 1246 { 1247 1248 if (!LIST_EMPTY(&bpf->bif_dlist)) 1249 return (1); 1250 return (0); 1251 } 1252 bpf argument seems to be NULL. Because of inlining the backtrace does not show a call to ether_input_internal where ETHER_BPF_MTAP() invokes bpf_peers_present(). The system has two network interfaces: rl and re. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 20:59:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8DA51065674 for ; Sun, 3 Jun 2012 20:59:38 +0000 (UTC) (envelope-from bounces+73574-866e-freebsd-net=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 923BB8FC14 for ; Sun, 3 Jun 2012 20:59:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=smtpapi; bh=gVzXeyUzNIzMszoS01iUAHe hjN8=; b=BQOYBRoRtikd4zTpT9EC7GxyL6ZL6CB5eSWC+d1oFFrjPDpq7vQp0VV +YGRzD1svZBCcDpFRM15qOkRiQkF+ihb1/NLer8Cq2RyELKkYmm9vzLJaVqAwwNK TAU9RQMzt4MvsL6wQKK6pyoYdEwbNtPhi7wSyzJxTgvKhN6vhFdQ= Received: by 10.41.149.111 with SMTP id f04-08.10408.4FCBD039B Sun, 03 Jun 2012 20:59:37 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.9.180.5]) by mi4 (SG) with ESMTP id 4fcbd039.462b.29a473f for ; Sun, 03 Jun 2012 15:59:37 -0500 (CST) Received: (qmail 34513 invoked from network); 3 Jun 2012 20:51:55 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by mail.tarsnap.com with ESMTP; 3 Jun 2012 20:51:55 -0000 Received: (qmail 35456 invoked from network); 3 Jun 2012 20:59:26 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 3 Jun 2012 20:59:26 -0000 Message-ID: <4FCBD02D.2020500@freebsd.org> Date: Sun, 03 Jun 2012 13:59:25 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120509 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Gallatin References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> <4FCB95F6.30204@freebsd.org> <4FCBB56D.2080800@cs.duke.edu> In-Reply-To: <4FCBB56D.2080800@cs.duke.edu> X-Enigmail-Version: 1.5pre Content-Type: multipart/mixed; boundary="------------030204000100060308060202" X-Sendgrid-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxEJ7pQio6/S9Skj7KnmnF2556962czSUSXk201SDMJj4EwI/+Dz4EewBDE/zOOkSHhasKA03wSZdlURjWTCtD6k6+CPVzfqKufn63SJ1CARs3zr+vKUe+sMxIYWCZAC6ys= X-SendGrid-Contentd-ID: {"test_id":1338757177} Cc: freebsd-net@freebsd.org Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 20:59:38 -0000 This is a multi-part message in MIME format. --------------030204000100060308060202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/03/12 12:05, Andrew Gallatin wrote: > On 06/03/12 12:51, Colin Percival wrote: >> I've attached a new patch which: >> 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet, >> 2. sets these in netfront when the IFCAP_TSO4 flag is set, >> 3. extends tcp_maxmtu to read this value, >> 4. adds a tx_tso_mss field to struct tcpcb, >> 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and >> 6. limits TSO lengths to tx_tso_mss in tcp_output. > > Looks good to me. I don't pretend to understand the bowels of > the TCP stack, so I can't comment on the "sendalot" stuff to > force segmentation. The "sendalot" bit is rather confusing, and I'm not at all certain that it's doing what it's supposed to be doing, but my reading of the code is that it really means "there's more data buffered than what we're sending right now so after we issue this write we need to go back to the top and do another". > I assume it works as well as your > previous patch to solve the problems you were seeing with Xen? Yes. > One minor nit is that I envision this limit to always be > 64K or less, so you could probably get away with stealing > 16 bits from ifcspare. With IPv6 I could imagine larger limits happening, so I figured it was better to take one of the ints. > The other trivial nit is that I would have made these new > if_tx_tso_mss and t_tx_tso_mss fields unsigned. Oops, quite right. I was trying to make sure I didn't break ABI, but of course int and u_int should have the same size no matter what platform we're on. > Thanks so much for doing this! Thanks for reviewing. Updated patch attached with s/int/u_int/ and some other minor cleanups. Can anyone review this for ABI safety? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid --------------030204000100060308060202 Content-Type: text/plain; charset=us-ascii; name="tx_tso_mss_2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tx_tso_mss_2.patch" Index: netinet/tcp_input.c =================================================================== --- netinet/tcp_input.c (revision 235780) +++ netinet/tcp_input.c (working copy) @@ -3298,6 +3298,7 @@ { int mss = 0; u_long maxmtu = 0; + u_int tx_tso_mss = 0; struct inpcb *inp = tp->t_inpcb; struct hc_metrics_lite metrics; int origoffer; @@ -3321,8 +3322,10 @@ /* Initialize. */ #ifdef INET6 if (isipv6) { - maxmtu = tcp_maxmtu6(&inp->inp_inc, mtuflags); + maxmtu = tcp_maxmtu6_ext(&inp->inp_inc, mtuflags, + &tx_tso_mss); tp->t_maxopd = tp->t_maxseg = V_tcp_v6mssdflt; + tp->t_tx_tso_mss = tx_tso_mss; } #endif #if defined(INET) && defined(INET6) @@ -3330,8 +3333,10 @@ #endif #ifdef INET { - maxmtu = tcp_maxmtu(&inp->inp_inc, mtuflags); + maxmtu = tcp_maxmtu_ext(&inp->inp_inc, mtuflags, + &tx_tso_mss); tp->t_maxopd = tp->t_maxseg = V_tcp_mssdflt; + tp->t_tx_tso_mss = tx_tso_mss; } #endif Index: netinet/tcp_subr.c =================================================================== --- netinet/tcp_subr.c (revision 235780) +++ netinet/tcp_subr.c (working copy) @@ -1708,7 +1708,7 @@ * tcp_mss_update to get the peer/interface MTU. */ u_long -tcp_maxmtu(struct in_conninfo *inc, int *flags) +tcp_maxmtu_ext(struct in_conninfo *inc, int *flags, u_int * tx_tso_mss) { struct route sro; struct sockaddr_in *dst; @@ -1738,15 +1738,26 @@ ifp->if_hwassist & CSUM_TSO) *flags |= CSUM_TSO; } + if (tx_tso_mss != NULL) { + if (ifp->if_capabilities & IFCAP_TSO_MSS) + *tx_tso_mss = ifp->if_tx_tso_mss; + } RTFREE(sro.ro_rt); } return (maxmtu); } + +u_long +tcp_maxmtu(struct in_conninfo *inc, int *flags) +{ + + return (tcp_maxmtu_ext(inc, flags, NULL)); +} #endif /* INET */ #ifdef INET6 u_long -tcp_maxmtu6(struct in_conninfo *inc, int *flags) +tcp_maxmtu6_ext(struct in_conninfo *inc, int *flags, u_int * tx_tso_mss) { struct route_in6 sro6; struct ifnet *ifp; @@ -1775,11 +1786,22 @@ ifp->if_hwassist & CSUM_TSO) *flags |= CSUM_TSO; } + if (tx_tso_mss != NULL) { + if (ifp->if_capabilities & IFCAP_TSO_MSS) + *tx_tso_mss = ifp->if_tx_tso_mss; + } RTFREE(sro6.ro_rt); } return (maxmtu); } + +u_long +tcp_maxmtu6(struct in_conninfo *inc, int *flags) +{ + + return (tcp_maxmtu6_ext(inc, flags, NULL)); +} #endif /* INET6 */ #ifdef IPSEC Index: netinet/tcp_var.h =================================================================== --- netinet/tcp_var.h (revision 235780) +++ netinet/tcp_var.h (working copy) @@ -208,7 +208,9 @@ u_int t_keepintvl; /* interval between keepalives */ u_int t_keepcnt; /* number of keepalives before close */ - uint32_t t_ispare[8]; /* 5 UTO, 3 TBD */ + uint32_t t_ispare[5]; /* 5 UTO */ + uint32_t t_tx_tso_mss; /* max segment size for TSO offload */ + uint32_t t_ispare2[2]; /* 2 TBD */ void *t_pspare2[4]; /* 4 TBD */ uint64_t _pad[6]; /* 6 TBD (1-2 CC/RTT?) */ }; @@ -674,7 +676,9 @@ #endif void tcp_input(struct mbuf *, int); u_long tcp_maxmtu(struct in_conninfo *, int *); +u_long tcp_maxmtu_ext(struct in_conninfo *, int *, u_int *); u_long tcp_maxmtu6(struct in_conninfo *, int *); +u_long tcp_maxmtu6_ext(struct in_conninfo *, int *, u_int *); void tcp_mss_update(struct tcpcb *, int, int, struct hc_metrics_lite *, int *); void tcp_mss(struct tcpcb *, int); Index: netinet/tcp_output.c =================================================================== --- netinet/tcp_output.c (revision 235780) +++ netinet/tcp_output.c (working copy) @@ -748,6 +748,15 @@ } /* + * Some drivers want an even shorter limit to the + * length sent via TSO; respect their wishes. + */ + if (tp->t_tx_tso_mss != 0 && len > tp->t_tx_tso_mss) { + len = tp->t_tx_tso_mss; + sendalot = 1; + } + + /* * Prevent the last segment from being * fractional unless the send sockbuf can * be emptied. Index: dev/xen/netfront/netfront.c =================================================================== --- dev/xen/netfront/netfront.c (revision 235780) +++ dev/xen/netfront/netfront.c (working copy) @@ -135,6 +135,7 @@ * to mirror the Linux MAX_SKB_FRAGS constant. */ #define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2) +#define TX_TSO_MSS (MAX_TX_REQ_FRAGS - 2) * MCLBYTES #define RX_COPY_THRESHOLD 256 @@ -2040,6 +2041,9 @@ if (val) { np->xn_ifp->if_capabilities |= IFCAP_TSO4|IFCAP_LRO; printf(" feature-gso-tcp4"); + + np->xn_ifp->if_capabilities |= IFCAP_TSO_MSS; + np->xn_ifp->if_tx_tso_mss = TX_TSO_MSS; } printf("\n"); Index: net/if.h =================================================================== --- net/if.h (revision 235780) +++ net/if.h (working copy) @@ -230,6 +230,7 @@ #define IFCAP_VLAN_HWTSO 0x40000 /* can do IFCAP_TSO on VLANs */ #define IFCAP_LINKSTATE 0x80000 /* the runtime link state is dynamic */ #define IFCAP_NETMAP 0x100000 /* netmap mode supported/enabled */ +#define IFCAP_TSO_MSS 0x200000 /* TSO size is limited */ #define IFCAP_HWCSUM (IFCAP_RXCSUM | IFCAP_TXCSUM) #define IFCAP_TSO (IFCAP_TSO4 | IFCAP_TSO6) Index: net/if_var.h =================================================================== --- net/if_var.h (revision 235780) +++ net/if_var.h (working copy) @@ -205,7 +205,8 @@ * be used with care where binary compatibility is required. */ char if_cspare[3]; - int if_ispare[4]; + u_int if_tx_tso_mss; /* if IFCAP_TSO_MSS */ + int if_ispare[3]; void *if_pspare[8]; /* 1 netmap, 7 TDB */ }; --------------030204000100060308060202-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 22:22:52 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E7FA1065696; Sun, 3 Jun 2012 22:22:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C779A8FC08; Sun, 3 Jun 2012 22:22:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA02923; Mon, 04 Jun 2012 01:22:48 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SbJCC-000Mzm-5e; Mon, 04 Jun 2012 01:22:48 +0300 Message-ID: <4FCBE3B6.1020003@FreeBSD.org> Date: Mon, 04 Jun 2012 01:22:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-Current , freebsd-net@FreeBSD.org, melifaro@FreeBSD.org References: <4FCBCF7E.9020603@FreeBSD.org> In-Reply-To: <4FCBCF7E.9020603@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: null pointer panic in bpf_peers_present 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, 03 Jun 2012 22:22:52 -0000 on 03/06/2012 23:56 Andriy Gapon said the following: > > I wonder if anybody else is seeing this and if there is a fix... > This is very recent (today's) FreeBSD head with pretty dull network > configuration. During boot I run into the following panic: > > <118>Setting hostname: xxxxx > <118>Starting dhclient. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x10 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805a12a8 > stack pointer = 0x28:0xffffff8249905a10 > frame pointer = 0x28:0xffffff8249905a50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq20: rl0) > trap number = 12 > panic: page fault > cpuid = 0 > curthread: 0xfffffe00115e14b0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff802cc50a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff8051ce2a = kdb_backtrace+0x3a > panic() at 0xffffffff804e9e36 = panic+0x266 > trap_fatal() at 0xffffffff80692f9d = trap_fatal+0x3ad > trap_pfault() at 0xffffffff806930d5 = trap_pfault+0x115 > trap() at 0xffffffff8069383b = trap+0x49b > calltrap() at 0xffffffff8067ec63 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff805a12a8, rsp = 0xffffff8249905a10, rbp = > 0xffffff8249905a50 --- > ether_nh_input() at 0xffffffff805a12a8 = ether_nh_input+0x118 > netisr_dispatch_src() at 0xffffffff805a9a31 = netisr_dispatch_src+0xb1 > netisr_dispatch() at 0xffffffff805a9c41 = netisr_dispatch+0x11 > ether_input() at 0xffffffff805a0c0e = ether_input+0xe > rl_rxeof() at 0xffffffff805f97c8 = rl_rxeof+0x228 > rl_intr() at 0xffffffff805faaa6 = rl_intr+0xf6 > intr_event_execute_handlers() at 0xffffffff804c17e9 = > intr_event_execute_handlers+0xd9 > ithread_loop() at 0xffffffff804c247f = ithread_loop+0x9f > fork_exit() at 0xffffffff804bef25 = fork_exit+0x125 > fork_trampoline() at 0xffffffff8067f18e = fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8249905cf0, rbp = 0 --- > Uptime: 31s My current guess is that the panic occurs because of the newly added (r235745) bpf_ifdetach which is an ifnet_departure_event handler. My rc.conf is configured to do interface renaming and SIOCSIFNAME seems to post ifnet_departure_event followed by ifnet_arrival_event. Not sure if it's a window between ifnet_departure_event and ifnet_arrival_event when if_bpf is NULL, or if if_bpf is never restored in this case. > ether_nh_input+0x118 corresponds to: > (kgdb) list *ether_nh_input+0x118 > 0xffffffff805a12a8 is in ether_nh_input (bpf.h:1248). > 1243 > 1244 static __inline int > 1245 bpf_peers_present(struct bpf_if *bpf) > 1246 { > 1247 > 1248 if (!LIST_EMPTY(&bpf->bif_dlist)) > 1249 return (1); > 1250 return (0); > 1251 } > 1252 > > bpf argument seems to be NULL. > > Because of inlining the backtrace does not show a call to ether_input_internal > where ETHER_BPF_MTAP() invokes bpf_peers_present(). > The system has two network interfaces: rl and re. > -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 22:56:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5685710656DC; Sun, 3 Jun 2012 22:56:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id D25918FC0A; Sun, 3 Jun 2012 22:56:46 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8BA6325D3A9C; Sun, 3 Jun 2012 22:56:45 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 39398BE8444; Sun, 3 Jun 2012 22:56:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Jn7Qlar1PN5d; Sun, 3 Jun 2012 22:56:42 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E9CDDBE8441; Sun, 3 Jun 2012 22:56:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FCB95F6.30204@freebsd.org> Date: Sun, 3 Jun 2012 22:56:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2C0C246D-DFC1-45EE-88D9-C0730538F662@lists.zabbadoz.net> References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> <4FCB95F6.30204@freebsd.org> To: Colin Percival X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Andrew Gallatin Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 22:56:47 -0000 On 3. Jun 2012, at 16:51 , Colin Percival wrote: > On 05/30/12 08:30, Andrew Gallatin wrote: >> On 05/30/12 10:59, Colin Percival wrote: >>> The Xen virtual network interface has an issue (ok, really the issue = is with >>> the linux back-end, but that's what most people are using) where it = can't >>> handle scatter-gather writes with lots of pieces, aka. long mbuf = chains. >>> This currently bites us hard with TSO enabled, since it produces = said long >>> mbuf chains. >>=20 >> I think a better approach would be to have a limit on the size of the >> pre-segmented TCP payload size sent to the driver. I tend to think >> that this would be more generically useful, and it is a better match >> for the NDIS APIs, where a driver must specify the max TSO size. I >> think the changes to the TCP stack might be simpler (eg, they >> would seem to jive better with the existing "maxmtu" approach). >>=20 >> I think this could work for you as well. You could set the Xen max >> tso size to be 32K (derived from 18 pages/skb, multiplied by a = typical >> 2KB mbuf size, with some slack built in). If the chain was too = large, >> you could m_defrag it down to size. >=20 > I've attached a new patch which: > 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to = struct ifnet, > 2. sets these in netfront when the IFCAP_TSO4 flag is set, > 3. extends tcp_maxmtu to read this value, > 4. adds a tx_tso_mss field to struct tcpcb, > 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and > 6. limits TSO lengths to tx_tso_mss in tcp_output. general question - what happens in the IPv6 case? --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sun Jun 3 23:20:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58875106564A for ; Sun, 3 Jun 2012 23:20:58 +0000 (UTC) (envelope-from bounces+73574-866e-freebsd-net=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 0754C8FC08 for ; Sun, 3 Jun 2012 23:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=TP2YYjoqcZPHs/YQTtJTxgKF2/Y=; b=J9KkJeNrCD7HCIl1CMpo/XgzuA8C XSjV/LLPkHso4wR0fPi7EVFsGDww52giYTJx6FPIQui6G6zMjqe7/3XrVLBu6MuL 2377UMOUB1JhPircjwZ5OQgmlpRA2vVjiOL1ScvUkqA/PMLw3SLKn8OZIGoHUaFC RPKPIMYS3Ev9mWw= Received: by 10.41.149.113 with SMTP id f04-10.11496.4FCBF1593 Sun, 03 Jun 2012 23:20:57 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.9.180.5]) by mi3 (SG) with ESMTP id 4fcbf159.132c.447a819 for ; Sun, 03 Jun 2012 18:20:57 -0500 (CST) Received: (qmail 36134 invoked from network); 3 Jun 2012 23:13:15 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by mail.tarsnap.com with ESMTP; 3 Jun 2012 23:13:15 -0000 Received: (qmail 36421 invoked from network); 3 Jun 2012 23:20:45 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 3 Jun 2012 23:20:45 -0000 Message-ID: <4FCBF14D.4000103@freebsd.org> Date: Sun, 03 Jun 2012 16:20:45 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120509 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> <4FCB95F6.30204@freebsd.org> <2C0C246D-DFC1-45EE-88D9-C0730538F662@lists.zabbadoz.net> In-Reply-To: <2C0C246D-DFC1-45EE-88D9-C0730538F662@lists.zabbadoz.net> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Sendgrid-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxEdfJT1DuC3EGxFeOe/vQrg6KslUf8M0zj6cwmIPkV4pNYUpxCWgP6+CbVpL33q5WIMeeuj9MqIjOLONCR8Q0btZ84jWQN2MYq6+E3+V2bJxSp+puHWFFBCkcxkCoDfQw8= Cc: freebsd-net@freebsd.org, Andrew Gallatin Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 23:20:58 -0000 On 06/03/12 15:56, Bjoern A. Zeeb wrote: > On 3. Jun 2012, at 16:51 , Colin Percival wrote: >> I've attached a new patch which: >> 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet, >> 2. sets these in netfront when the IFCAP_TSO4 flag is set, >> 3. extends tcp_maxmtu to read this value, >> 4. adds a tx_tso_mss field to struct tcpcb, >> 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and >> 6. limits TSO lengths to tx_tso_mss in tcp_output. > > general question - what happens in the IPv6 case? It should work just fine; when I said "tcp_maxmtu" I really meant "tcp_maxmtu and tcp_maxmtu6". Of course, this all only affects TSO, and the netfront driver doesn't enable TSO for IPv6 (yet), so in a sense the real answer is "nothing at all". But the infrastructure will be in place for when it's needed. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 00:22:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6814F106566C for ; Mon, 4 Jun 2012 00:22:41 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id EF39C8FC15 for ; Mon, 4 Jun 2012 00:22:40 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 147E77E8CB; Mon, 4 Jun 2012 10:22:33 +1000 (EST) Message-ID: <4FCBFFC8.8000402@freebsd.org> Date: Mon, 04 Jun 2012 10:22:32 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120311 Thunderbird/10.0.2 MIME-Version: 1.0 To: Kevin Oberman References: <4FBF88CE.20209@cs.duke.edu> <4FC82D6C.4050309@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org, Andrew Gallatin , Andrew Gallatin Subject: Re: Major performance hit with ToS setting 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, 04 Jun 2012 00:22:41 -0000 On 06/03/12 15:18, Kevin Oberman wrote: > On Fri, Jun 1, 2012 at 2:48 AM, Lawrence Stewart wrote: >> On 05/31/12 13:33, Kevin Oberman wrote: >> [snip] >>> >>> I used SIFTR at the suggestion of Lawrence Stewart who headed the >>> >>> project to bring plugable congestion algorithms to FreeBSD and found >>> really odd congestion behavior. First, I do see a triple ACK, but the >>> congestion window suddenly drops from 73K to 8K. If I understand >>> CUBIC, it should half the congestion window, not what is happening.. >>> It then increases slowly (in slow start) to 82K. while the slow-start >>> bytes are INCREASING, the congestion window again goes to 8K while the >>> SS size moves from 36K up to 52K. It just continues to bound wildly >>> between 8K (always the low point) and between 64k and 82K. The swings >>> start at 83K and, over the first few seconds the peaks drop to about >>> 64K. >> >> >> Oh, and a comment about this behaviour. Dropping back to 8k (1MSS) is only >> nasty if the TF_{CONG|FAST}RECOVERY flags are *not* set i.e. if you see cwnd >> grow, drop to 8k with those flags set, and then when the flags are unset, >> cwnd starts at the value of ssthresh, then that is perfectly normal recovery >> behaviour. What *is* nasty is if an RTO fires, which will reset cwnd to 8k, >> ssthresh to 2*MSS and make the connection effectively start from scratch >> again. >> >> There is evidence of RTOs in your siftr output, which is bad news e.g here's >> one example of 2 side-by-side log lines from your trace: >> >> # Direction,time,ssthresh,cwnd,flags >> i,1338319593.574706,27044,27044,1630544864 >> o,1338319593.831482,16384,8192,1092625377 >> >> Note the 300ms gap, and how cwnd resets to 1MSS and flags go from 1630544864 >> (TF_WASCRECOVERY|TF_CONGRECOVERY|TF_WASFRECOVERY|TF_FASTRECOVERY) to >> 1092625377 (TF_WASCRECOVERY|TF_WASFRECOVERY). > > What can I say but that you are right. When I looked at the interface > stats I found that the link overflow drops were through the roof! This > confuses me a bit since the traffic is outbound and I woudl assume > from the description on hte Myricom web page that these are input > drops. A problem a problem with that card? On systems that are > working "normally", I still see a sharp drop with the ToS bits set, > but nothing nearly as drastic. Now it is a drop from 4.5G to 728M on a > cross-country (US) circuit. > > I am now looking for issues on the route that might explain the > performance, but the question of why the drop-of only shows up in > FreeBSD 8 means something odd is still going on. It is even possible > that the problem is with 7 and the losses are due to the policy for > ToS 32 on the path. ToS 32 is less than best effort in our network. > Maybe the marking was getting lost on 7. Not likely, but possible. The receiver is FreeBSD 7? If so, have you tuned your reassembly queue on that machine? If not, that could explain the RTOs you're seeing. Send through the output of "sysctl net.inet.tcp.reass" and "netstat -sp tcp" obtained from the receiver immediately before and after running a short ToS=32 test. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 03:14:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E581065670; Mon, 4 Jun 2012 03:14:11 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3488FC17; Mon, 4 Jun 2012 03:14:08 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 6C6E27E88D; Mon, 4 Jun 2012 13:14:06 +1000 (EST) Message-ID: <4FCC27FE.3030205@freebsd.org> Date: Mon, 04 Jun 2012 13:14:06 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120311 Thunderbird/10.0.2 MIME-Version: 1.0 To: Colin Percival References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> <4FCB95F6.30204@freebsd.org> In-Reply-To: <4FCB95F6.30204@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org, Andre Oppermann , Andrew Gallatin Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 03:14:11 -0000 On 06/04/12 02:51, Colin Percival wrote: > On 05/30/12 08:30, Andrew Gallatin wrote: >> On 05/30/12 10:59, Colin Percival wrote: >>> The Xen virtual network interface has an issue (ok, really the issue is with >>> the linux back-end, but that's what most people are using) where it can't >>> handle scatter-gather writes with lots of pieces, aka. long mbuf chains. >>> This currently bites us hard with TSO enabled, since it produces said long >>> mbuf chains. >> >> I think a better approach would be to have a limit on the size of the >> pre-segmented TCP payload size sent to the driver. I tend to think >> that this would be more generically useful, and it is a better match >> for the NDIS APIs, where a driver must specify the max TSO size. I >> think the changes to the TCP stack might be simpler (eg, they >> would seem to jive better with the existing "maxmtu" approach). >> >> I think this could work for you as well. You could set the Xen max >> tso size to be 32K (derived from 18 pages/skb, multiplied by a typical >> 2KB mbuf size, with some slack built in). If the chain was too large, >> you could m_defrag it down to size. > > I've attached a new patch which: > 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet, A minor thing, but I don't like the overloading of the term MSS. Perhaps s/MSS/CHUNKSIZE or another suitably similar but different word/phrase? > 2. sets these in netfront when the IFCAP_TSO4 flag is set, > 3. extends tcp_maxmtu to read this value, > 4. adds a tx_tso_mss field to struct tcpcb, > 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and > 6. limits TSO lengths to tx_tso_mss in tcp_output. Is there a reason to mix signed and unsigned types for the various tx_tso_mss variables? If not, please pick a type and stick with it. I've added andre@ to CC in the hope he will eyeball this too given that he, if I recall correctly, was the original "Mr TSO". Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 03:33:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 116F41065672 for ; Mon, 4 Jun 2012 03:33:22 +0000 (UTC) (envelope-from bounces+73574-866e-freebsd-net=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id C9CEF8FC14 for ; Mon, 4 Jun 2012 03:33:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=647y4ITx+KgMBoYLp2a4oDzeb4I=; b=wLmtKS+x0UIeGjwWJ2L0PciCZaKW YAGruX3LyukgcFvJyoRkHYBxgfF9cWPZfyKMkBRPpJ/odK98BwjjZrx4saGE8UOz WI6WCo9g7rJbLxURQYOhxupSjoVGpY56rO59lvxfFrLt7uFQUTgEh/l+zYoNBcjB 2Ju5amZUgAbCJdY= Received: by 10.41.149.111 with SMTP id f04-08.10408.4FCC2C7FB Mon, 04 Jun 2012 03:33:20 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.8.49.124]) by mi1 (SG) with ESMTP id 4fcc2c7f.1b8a.ef7d8f for ; Sun, 03 Jun 2012 22:33:19 -0500 (CST) Received: (qmail 38807 invoked from network); 4 Jun 2012 03:25:37 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by mail.tarsnap.com with ESMTP; 4 Jun 2012 03:25:37 -0000 Received: (qmail 37521 invoked from network); 4 Jun 2012 03:33:07 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 4 Jun 2012 03:33:07 -0000 Message-ID: <4FCC2C72.7000806@freebsd.org> Date: Sun, 03 Jun 2012 20:33:06 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120509 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lawrence Stewart References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> <4FCB95F6.30204@freebsd.org> <4FCC27FE.3030205@freebsd.org> In-Reply-To: <4FCC27FE.3030205@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Sendgrid-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxEJ7pQio6/S9Skj7KnmnF25GUpXm7O0TX/8tjzMHyF2MtwT0dpFQ46mjKme8B1+9yLow42y/rPEYrdgZRr+wX9rg+XYDzH1f+YX0cU0ihgsDAj0bX0xyVWQZWyvR5cB6Q4= Cc: freebsd-net@freebsd.org, Andre Oppermann , Andrew Gallatin Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 03:33:22 -0000 On 06/03/12 20:14, Lawrence Stewart wrote: > On 06/04/12 02:51, Colin Percival wrote: >> I've attached a new patch which: >> 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet, > > A minor thing, but I don't like the overloading of the term MSS. Perhaps > s/MSS/CHUNKSIZE or another suitably similar but different word/phrase? I don't see this as being overloading; rather, it's using the same term to mean exactly the same thing: Maximum Segment Size, in this case of a TCP segment which is going to be re-segmented in hardware. >> 2. sets these in netfront when the IFCAP_TSO4 flag is set, >> 3. extends tcp_maxmtu to read this value, >> 4. adds a tx_tso_mss field to struct tcpcb, >> 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and >> 6. limits TSO lengths to tx_tso_mss in tcp_output. > > Is there a reason to mix signed and unsigned types for the various tx_tso_mss > variables? If not, please pick a type and stick with it. It's all unsigned now (see updated patch I sent in reply to gallatin@). The use of u_int vs. uint32_t is because I wanted to have this fit into spares in struct ifnet and struct tcpcb and I wasn't 100% certain that there weren't any platforms with sizeof(int) != sizeof(uint32_t). -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 04:07:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D29A1065670; Mon, 4 Jun 2012 04:07:36 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id CEC2A8FC1F; Mon, 4 Jun 2012 04:07:35 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id A72DE7E891; Mon, 4 Jun 2012 14:07:34 +1000 (EST) Message-ID: <4FCC3486.3020104@freebsd.org> Date: Mon, 04 Jun 2012 14:07:34 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120311 Thunderbird/10.0.2 MIME-Version: 1.0 To: Colin Percival References: <4FC635CC.5030608@freebsd.org> <4FC63D27.70807@cs.duke.edu> <4FCB95F6.30204@freebsd.org> <4FCC27FE.3030205@freebsd.org> <4FCC2C72.7000806@freebsd.org> In-Reply-To: <4FCC2C72.7000806@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org, Andre Oppermann , Andrew Gallatin Subject: Re: [please review] TSO mbuf chain length limiting patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 04:07:36 -0000 On 06/04/12 13:33, Colin Percival wrote: > On 06/03/12 20:14, Lawrence Stewart wrote: >> On 06/04/12 02:51, Colin Percival wrote: >>> I've attached a new patch which: >>> 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet, >> >> A minor thing, but I don't like the overloading of the term MSS. Perhaps >> s/MSS/CHUNKSIZE or another suitably similar but different word/phrase? > > I don't see this as being overloading; rather, it's using the same term to mean > exactly the same thing: Maximum Segment Size, in this case of a TCP segment > which is going to be re-segmented in hardware. No, it's not the same thing. "Maximum segment size" and "segment" have very specific meaning in RFCs and data networking parlance. To overload the term in the way that you are is a bad idea IMO. A "segment" is the transport layer's protocol data unit (PDU), with MSS specifying the maximum size of the transport's PDU. I'm not very au fait with the TSO implementation specifics, but my understanding is that we do not "send" a 65k segment to the hardware as a fully specified TCP segment and then have the the hardware also churn out fully specified TCP segments, only smaller in size. We send the hardware a chunk of data and partial header, which is then chopped up and sent as fully specified segments. Assuming my understanding is correct, to refer to the TSO chunk size as MSS is therefore an inappropriate use of the term at best, potentially confusing and misleading at worst. >>> 2. sets these in netfront when the IFCAP_TSO4 flag is set, >>> 3. extends tcp_maxmtu to read this value, >>> 4. adds a tx_tso_mss field to struct tcpcb, >>> 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and >>> 6. limits TSO lengths to tx_tso_mss in tcp_output. >> >> Is there a reason to mix signed and unsigned types for the various tx_tso_mss >> variables? If not, please pick a type and stick with it. > > It's all unsigned now (see updated patch I sent in reply to gallatin@). The Sorry, missed the revised patch. Unsigned looks good to me. > use of u_int vs. uint32_t is because I wanted to have this fit into spares in > struct ifnet and struct tcpcb and I wasn't 100% certain that there weren't any > platforms with sizeof(int) != sizeof(uint32_t). I've got no issue with that. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 06:48:45 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 168AD106566C; Mon, 4 Jun 2012 06:48:45 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF358FC0C; Mon, 4 Jun 2012 06:48:44 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SbR5s-000G3Q-Vs; Mon, 04 Jun 2012 10:48:49 +0400 Message-ID: <4FCC5A46.8020007@FreeBSD.org> Date: Mon, 04 Jun 2012 10:48:38 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Andriy Gapon References: <4FCBCF7E.9020603@FreeBSD.org> <4FCBE3B6.1020003@FreeBSD.org> In-Reply-To: <4FCBE3B6.1020003@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------030701000408000400090005" Cc: freebsd-net@FreeBSD.org, FreeBSD-Current Subject: Re: null pointer panic in bpf_peers_present 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, 04 Jun 2012 06:48:45 -0000 This is a multi-part message in MIME format. --------------030701000408000400090005 Content-Type: text/plain; charset=x-viet-vps; format=flowed Content-Transfer-Encoding: 7bit On 04.06.2012 02:22, Andriy Gapon wrote: > on 03/06/2012 23:56 Andriy Gapon said the following: >> >> I wonder if anybody else is seeing this and if there is a fix... >> This is very recent (today's) FreeBSD head with pretty dull network >> configuration. During boot I run into the following panic: >> >> <118>Setting hostname: xxxxx >> <118>Starting dhclient. >> > My current guess is that the panic occurs because of the newly added (r235745) > bpf_ifdetach which is an ifnet_departure_event handler. My rc.conf is > configured to do interface renaming and SIOCSIFNAME seems to post > ifnet_departure_event followed by ifnet_arrival_event. > > Not sure if it's a window between ifnet_departure_event and ifnet_arrival_event > when if_bpf is NULL, or if if_bpf is never restored in this case. if_bpf is never restored. Can you please try an attached patch ? >> > > --------------030701000408000400090005 Content-Type: text/plain; name="bpf_rename.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bpf_rename.diff" Index: sys/net/bpf.c =================================================================== --- sys/net/bpf.c (revision 236540) +++ sys/net/bpf.c (working copy) @@ -2542,13 +2542,23 @@ bpf_ifdetach(void *arg __unused, struct ifnet *ifp { struct bpf_if *bp; - if ((bp = ifp->if_bpf) == NULL) + BPF_LOCK(); + if ((bp = ifp->if_bpf) == NULL) { + BPF_UNLOCK(); return; + } + if ((bp->flags & BPFIF_FLAG_DYING) == 0) { + BPF_UNLOCK(); + return; + } + CTR3(KTR_NET, "%s: freing BPF instance %p for interface %p", __func__, bp, ifp); ifp->if_bpf = NULL; + BPF_UNLOCK(); + rw_destroy(&bp->bif_lock); free(bp, M_BPF); } --------------030701000408000400090005-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 08:32:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D56BF106564A; Mon, 4 Jun 2012 08:32:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE548FC16; Mon, 4 Jun 2012 08:32:47 +0000 (UTC) Received: by dadv36 with SMTP id v36so5789100dad.13 for ; Mon, 04 Jun 2012 01:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=V+XmC1DtSaW2etM0j/JfDE/zaS3jnnGVJLotb+k3uDY=; b=hyZI4y4G+rbsFHdeP+h4GuDbNG7HuJi/vW097Jv6BI2qwxvz9EzAb/rfOe5nRXSZY6 DPfzl3cgb8wn8LPG/VD84zPyuccuhQHB+m1HaHeGmle5bUca01HYD6LDJCzkkeS2Yb8t /U9ARZV3KqqGHSEvi0j+3tqCr9BnDGXmJAVen3qtUjtjFMWi17vsLILAOdd/BhREGroX xX/K+os9KSp/5DSqh9VTw/TQiDFh5O1mPkD8ZiaHnkwWgtCmH3bSu6KBtTZIent7rb6n PHdgFVCLW+vcs8I53k3SnlccO02YOA1jMtoj4KunJ1x6kA/tM/7vIfY9TUURsM8uuHq/ 7KRg== Received: by 10.68.236.129 with SMTP id uu1mr37060782pbc.77.1338798767136; Mon, 04 Jun 2012 01:32:47 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id vp4sm12545360pbc.61.2012.06.04.01.32.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 01:32:45 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Jun 2012 17:32:39 -0700 From: YongHyeon PYUN Date: Mon, 4 Jun 2012 17:32:39 -0700 To: Xin Li Message-ID: <20120605003239.GA4010@michelle.cdnetworks.com> References: <201205221037.q4MAbhhP008810@freefall.freebsd.org> <4FBBCE08.1080502@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FBBCE08.1080502@delphij.net> User-Agent: Mutt/1.4.2.3i Cc: nemoliu@FreeBSD.org, freebsd-net@FreeBSD.org, d@delphij.net, delphij@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/168217: [bce] Watchdog timeouts with bce(4) on BCM5716 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:32:47 -0000 On Tue, May 22, 2012 at 10:34:00AM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 05/22/12 03:37, yongari@FreeBSD.org wrote: > > Your release information(i386) and environment(amd64) does not > > match. Are you using i386 or PAE? > > Sorry if there is mismatch then it must be I didn't cleared out > freefall information properly. The system is running FreeBSD/amd64 > and not i386 nor PAE. > > > Having backtrace would be nice. > > Will do. > > > It seems you have two differnt controllers(5716 and 5709). Does the > > issue happen only on 5716? > > We have not yet tested on the 5709 part as they are not connected. > > By the way there are some updates from yesterday. Disabling hdr_split > did not helped and the system stops responding again; disabling both > hdr_split and tso seems to make the system survive after 8 hours, we > will continue to watch it and report back if new information available. > > Another thing to note is that we found that on systems that does not > exhibit the same problem, they have oui=0x50ef for the four brgphy's, > and on this system the four have oui=0xaf7 (brgphy0 pnpinfo oui=0xaf7 > model=0x3c rev=0x8 at phyno=1). Not sure if this is related though. > Xin, I'm under the impression that bce_intr() might be called when IFF_DRV_RUNNING is not set. Could you check whether sc->bce_ifp->if_drv_flags set IFF_DRV_RUNNING in bce_intr()? Sorry, one of my box that can host quad-port bce(4) controller died so I can't verify this at the moment until I get a new MB. From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 08:48:38 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2EE71065670; Mon, 4 Jun 2012 08:48:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 91C878FC1E; Mon, 4 Jun 2012 08:48:38 +0000 (UTC) Received: from delta.delphij.net (unknown [IPv6:2001:470:83bf:0:221:5cff:fe6a:37bb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0312FD0B8; Mon, 4 Jun 2012 01:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1338799712; bh=4k/IF/Z6KfTZYxC1vIgcyOFgdTFsks1zhzFnP/G9dBo=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=4xkHa3CYiLffWXoY838jBqdVzeFjulYuw6qc3mfBZn6GFUPEHzKRlRkiezNE5ShS9 FAjT5VpN9tWbYkDdgCgpBrUvF0u9Xd0Hj/thLKb6KR0BKsWYrKt8wQmdtslMOgrGUC tmgox01X0/bnWGGB1GHTr9E0JZx3sbmfIh5tSHzU= Message-ID: <4FCC7650.4040902@delphij.net> Date: Mon, 04 Jun 2012 01:48:16 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: pyunyh@gmail.com References: <201205221037.q4MAbhhP008810@freefall.freebsd.org> <4FBBCE08.1080502@delphij.net> <20120605003239.GA4010@michelle.cdnetworks.com> In-Reply-To: <20120605003239.GA4010@michelle.cdnetworks.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nemoliu@FreeBSD.org, freebsd-net@FreeBSD.org, d@delphij.net, delphij@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/168217: [bce] Watchdog timeouts with bce(4) on BCM5716 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:48:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/04/12 17:32, YongHyeon PYUN wrote: > On Tue, May 22, 2012 at 10:34:00AM -0700, Xin Li wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 05/22/12 03:37, yongari@FreeBSD.org wrote: >>> Your release information(i386) and environment(amd64) does not >>> match. Are you using i386 or PAE? >> >> Sorry if there is mismatch then it must be I didn't cleared out >> freefall information properly. The system is running >> FreeBSD/amd64 and not i386 nor PAE. >> >>> Having backtrace would be nice. >> >> Will do. >> >>> It seems you have two differnt controllers(5716 and 5709). Does >>> the issue happen only on 5716? >> >> We have not yet tested on the 5709 part as they are not >> connected. >> >> By the way there are some updates from yesterday. Disabling >> hdr_split did not helped and the system stops responding again; >> disabling both hdr_split and tso seems to make the system survive >> after 8 hours, we will continue to watch it and report back if >> new information available. >> >> Another thing to note is that we found that on systems that does >> not exhibit the same problem, they have oui=0x50ef for the four >> brgphy's, and on this system the four have oui=0xaf7 (brgphy0 >> pnpinfo oui=0xaf7 model=0x3c rev=0x8 at phyno=1). Not sure if >> this is related though. >> > > Xin, I'm under the impression that bce_intr() might be called when > IFF_DRV_RUNNING is not set. Could you check whether > sc->bce_ifp->if_drv_flags set IFF_DRV_RUNNING in bce_intr()? Sorry, > one of my box that can host quad-port bce(4) controller died so I > can't verify this at the moment until I get a new MB. I've made the following change: Index: sys/dev/bce/if_bce.c =================================================================== - --- sys/dev/bce/if_bce.c (revision 233291) +++ sys/dev/bce/if_bce.c (working copy) @@ -7678,6 +7678,9 @@ bce_intr(void *xsc) BCE_LOCK(sc); + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != IFF_DRV_RUNNING) + BCE_PRINTF("Got interrupt without IFF_DRV_RUNNING!\n"); + DBRUN(sc->interrupts_generated++); /* Synchnorize before we read from interface's status block */ Should we run with that and see if we can catch something? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPzHZQAAoJEG80Jeu8UPuzBBAIAL1Q/Nt+e5okB+8EB/Ah7Gkm +4OT+Y2vB/eW+vP8HgOKsbtE6dJ3w6saTUP0RGPekpeLfdvUVxSfL1lVOCvDPyic 8IoftFoHsSOanfisrTPTiHJet2m2fYOywHPx4tfAXvYvyQON48YHRRugDaQW6WPz azzOVHY27J4Zf2UGqDrbTY5m8yWx8MCePJ3fsBKLcY6RDLHOVpE58ebW+LfNZ9RQ fdZPkRTXcAcvZo8Cgv2F5lo6PdRv6C5MoWgk37rR24DZD3bVcXFCM7qRrkd86TqH OY7mNjfC0QqTDgv/EKty//TtA8C0IO5iu0mRI71ONDKEEte73RiqMz1dC43IEnE= =inpj -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 09:04:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 167751065673; Mon, 4 Jun 2012 09:04:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C18FA8FC18; Mon, 4 Jun 2012 09:04:17 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so6031505pbb.13 for ; Mon, 04 Jun 2012 02:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=2S5ddi1x8dtSKdaOYLfQ2bmLJsyvRX0eFtn1gbAWPYI=; b=akA6qOo1m94QgYJpNw3IF5E77vzW7nq9jSq00eTrJGmQlM2Cnawk0n0QCoPnOJ0pEd IyWuiXSUFW5BlQpQGWfuCC8geA2UNwBRtOBD2sQnPCu4wYsg1fTYSj7eXSngdJ4ZmFdD KVLm/mOZsKoAPFbNRSDpbxwHCRSiXQ/YGSncFcW4ZkcAHnNrezDN+oEx1dmDBv0D1Yav bAhBfxZTBn3eS/z6BER2pOmqW4KLiCXKauaviQYZqWoJqzMGRbwmAVla1J3MVcEtUoAg BK/XylMvbCRr15+bOW8rAlqFrk3+ueiZETV5vEU0cx0u2OCMAipsFGId6eMLq3u6WqK7 lC4Q== Received: by 10.68.234.35 with SMTP id ub3mr37502308pbc.8.1338800657440; Mon, 04 Jun 2012 02:04:17 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id ok6sm12645035pbb.29.2012.06.04.02.04.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 02:04:14 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 04 Jun 2012 18:04:08 -0700 From: YongHyeon PYUN Date: Mon, 4 Jun 2012 18:04:08 -0700 To: Xin Li Message-ID: <20120605010408.GC4010@michelle.cdnetworks.com> References: <201205221037.q4MAbhhP008810@freefall.freebsd.org> <4FBBCE08.1080502@delphij.net> <20120605003239.GA4010@michelle.cdnetworks.com> <4FCC7650.4040902@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FCC7650.4040902@delphij.net> User-Agent: Mutt/1.4.2.3i Cc: nemoliu@FreeBSD.org, freebsd-net@FreeBSD.org, d@delphij.net, delphij@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/168217: [bce] Watchdog timeouts with bce(4) on BCM5716 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 09:04:18 -0000 On Mon, Jun 04, 2012 at 01:48:16AM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 06/04/12 17:32, YongHyeon PYUN wrote: > > On Tue, May 22, 2012 at 10:34:00AM -0700, Xin Li wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >> > >> On 05/22/12 03:37, yongari@FreeBSD.org wrote: > >>> Your release information(i386) and environment(amd64) does not > >>> match. Are you using i386 or PAE? > >> > >> Sorry if there is mismatch then it must be I didn't cleared out > >> freefall information properly. The system is running > >> FreeBSD/amd64 and not i386 nor PAE. > >> > >>> Having backtrace would be nice. > >> > >> Will do. > >> > >>> It seems you have two differnt controllers(5716 and 5709). Does > >>> the issue happen only on 5716? > >> > >> We have not yet tested on the 5709 part as they are not > >> connected. > >> > >> By the way there are some updates from yesterday. Disabling > >> hdr_split did not helped and the system stops responding again; > >> disabling both hdr_split and tso seems to make the system survive > >> after 8 hours, we will continue to watch it and report back if > >> new information available. > >> > >> Another thing to note is that we found that on systems that does > >> not exhibit the same problem, they have oui=0x50ef for the four > >> brgphy's, and on this system the four have oui=0xaf7 (brgphy0 > >> pnpinfo oui=0xaf7 model=0x3c rev=0x8 at phyno=1). Not sure if > >> this is related though. > >> > > > > Xin, I'm under the impression that bce_intr() might be called when > > IFF_DRV_RUNNING is not set. Could you check whether > > sc->bce_ifp->if_drv_flags set IFF_DRV_RUNNING in bce_intr()? Sorry, > > one of my box that can host quad-port bce(4) controller died so I > > can't verify this at the moment until I get a new MB. > > I've made the following change: > > Index: sys/dev/bce/if_bce.c > =================================================================== > - --- sys/dev/bce/if_bce.c (revision 233291) > +++ sys/dev/bce/if_bce.c (working copy) > @@ -7678,6 +7678,9 @@ bce_intr(void *xsc) > > BCE_LOCK(sc); > > + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != IFF_DRV_RUNNING) > + BCE_PRINTF("Got interrupt without IFF_DRV_RUNNING!\n"); > + > DBRUN(sc->interrupts_generated++); > > /* Synchnorize before we read from interface's status block */ > > Should we run with that and see if we can catch something? I think you don't need the full message, just a single byte of character, say 'I', could be used to indicate the condition. > > Cheers, From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 10:55:16 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A7A61065676; Mon, 4 Jun 2012 10:55:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 86AD98FC14; Mon, 4 Jun 2012 10:55:15 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA08179; Mon, 04 Jun 2012 13:55:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SbUwK-0000Ju-Uk; Mon, 04 Jun 2012 13:55:12 +0300 Message-ID: <4FCC940E.2070008@FreeBSD.org> Date: Mon, 04 Jun 2012 13:55:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <4FCBCF7E.9020603@FreeBSD.org> <4FCBE3B6.1020003@FreeBSD.org> <4FCC5A46.8020007@FreeBSD.org> In-Reply-To: <4FCC5A46.8020007@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, FreeBSD-Current Subject: Re: null pointer panic in bpf_peers_present 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, 04 Jun 2012 10:55:16 -0000 on 04/06/2012 09:48 Alexander V. Chernikov said the following: > On 04.06.2012 02:22, Andriy Gapon wrote: >> on 03/06/2012 23:56 Andriy Gapon said the following: >>> >>> I wonder if anybody else is seeing this and if there is a fix... >>> This is very recent (today's) FreeBSD head with pretty dull network >>> configuration. During boot I run into the following panic: >>> >>> <118>Setting hostname: xxxxx >>> <118>Starting dhclient. >>> >> My current guess is that the panic occurs because of the newly added (r235745) >> bpf_ifdetach which is an ifnet_departure_event handler. My rc.conf is >> configured to do interface renaming and SIOCSIFNAME seems to post >> ifnet_departure_event followed by ifnet_arrival_event. >> >> Not sure if it's a window between ifnet_departure_event and ifnet_arrival_event >> when if_bpf is NULL, or if if_bpf is never restored in this case. > if_bpf is never restored. > > Can you please try an attached patch ? I can boot successfully with this patch. Thank you! -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 11:07:45 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0767C10656B4 for ; Mon, 4 Jun 2012 11:07:45 +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 E4E428FC20 for ; Mon, 4 Jun 2012 11:07:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q54B7iET017521 for ; Mon, 4 Jun 2012 11:07:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54B7iB7017519 for freebsd-net@FreeBSD.org; Mon, 4 Jun 2012 11:07:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jun 2012 11:07:44 GMT Message-Id: <201206041107.q54B7iB7017519@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, 04 Jun 2012 11:07:45 -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 -------------------------------------------------------------------------------- p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167768 net [ipfilter] Fatal trap in ipfilter/ipnat o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166550 net [netinet] [patch] Some log lines about arp do not incl o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 402 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 14:28:17 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E5331065839; Mon, 4 Jun 2012 14:28:17 +0000 (UTC) (envelope-from misho@elwix.org) Received: from x0r.aitnet.org (unknown [IPv6:2a00:e40:deba:1::5]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2738FC08; Mon, 4 Jun 2012 14:28:16 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by x0r.aitnet.org (Postfix) with ESMTP id A16D63F7AD; Mon, 4 Jun 2012 17:28:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitnet.org Received: from x0r.aitnet.org ([127.0.0.1]) by localhost (x0r.aitnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXuB1fWS5Vpf; Mon, 4 Jun 2012 17:28:15 +0300 (EEST) Received: from misho.batmbg.com (unknown [212.116.129.162]) by x0r.aitnet.org (Postfix) with ESMTPSA id 393FC3F7AB; Mon, 4 Jun 2012 17:28:15 +0300 (EEST) Date: Mon, 4 Jun 2012 17:29:28 +0300 From: Michael Pounov To: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Message-Id: <20120604172928.3dd24e1f.misho@elwix.org> Organization: ELWIX X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: bpf kernel crash 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, 04 Jun 2012 14:28:17 -0000 Kernel crash when you wish to change interface name from vlan0 to other name It seems to be in arrival/departure events. 1) when I set up vlan0 and change name to mgmt and after that destroy mgmt. kernel crash in bpfdetach() at line 2495. where it tries to find interface structure. 2) when I setup vlan0, change name to mgmt and set ip address. After few seconds kernel crash in vlan_transmit() at line 1029. where it tries to push mbufs to bpf interface, but it is NULL. -- Michael Pounov From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 14:30:43 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E27FE106566B; Mon, 4 Jun 2012 14:30:43 +0000 (UTC) (envelope-from misho@aitbg.com) Received: from x0r.aitnet.org (unknown [IPv6:2a00:e40:deba:1::5]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4A08FC18; Mon, 4 Jun 2012 14:30:43 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by x0r.aitnet.org (Postfix) with ESMTP id DB77E3F7AA; Mon, 4 Jun 2012 17:30:42 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitnet.org Received: from x0r.aitnet.org ([127.0.0.1]) by localhost (x0r.aitnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zJUyPUjU17k; Mon, 4 Jun 2012 17:30:42 +0300 (EEST) Received: from misho.batmbg.com (unknown [212.116.129.162]) by x0r.aitnet.org (Postfix) with ESMTPSA id B20263F7A6; Mon, 4 Jun 2012 17:30:42 +0300 (EEST) Date: Mon, 4 Jun 2012 17:31:54 +0300 From: Michael Pounov To: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Message-Id: <20120604173154.a54b48ac.misho@aitbg.com> Organization: AITNET X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: bpf kernel crash 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, 04 Jun 2012 14:30:44 -0000 Kernel crash when you wish to change interface name from vlan0 to other name It seems to be in arrival/departure events. 1) when I set up vlan0 and change name to mgmt and after that destroy mgmt. kernel crash in bpfdetach() at line 2495. where it tries to find interface structure. 2) when I setup vlan0, change name to mgmt and set ip address. After few seconds kernel crash in vlan_transmit() at line 1029. where it tries to push mbufs to bpf interface, but it is NULL. -- Michael Pounov From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 15:50:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7CD1106564A for ; Mon, 4 Jun 2012 15:50:48 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id A9E098FC1C for ; Mon, 4 Jun 2012 15:50:48 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta15.emeryville.ca.mail.comcast.net with comcast id JDr41j00C1wfjNsAFFpgqz; Mon, 04 Jun 2012 15:49:40 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id JFpe1j00F4NgCEG8jFpfxm; Mon, 04 Jun 2012 15:49:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q54FnbaV021508; Mon, 4 Jun 2012 09:49:37 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Michael Pounov In-Reply-To: <20120604173154.a54b48ac.misho@aitbg.com> References: <20120604173154.a54b48ac.misho@aitbg.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Jun 2012 09:49:36 -0600 Message-ID: <1338824976.36051.197.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: bpf kernel crash 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, 04 Jun 2012 15:50:48 -0000 On Mon, 2012-06-04 at 17:31 +0300, Michael Pounov wrote: > Kernel crash when you wish to change interface name from vlan0 to other name > > It seems to be in arrival/departure events. > > 1) when I set up vlan0 and change name to mgmt and after that destroy mgmt. > kernel crash in bpfdetach() at line 2495. where it tries to find interface structure. > 2) when I setup vlan0, change name to mgmt and set ip address. After few seconds > kernel crash in vlan_transmit() at line 1029. where it tries to push mbufs to bpf interface, but it is NULL. > It sounds like that might be the same problem as this, maybe the same patch will fix it for you... http://lists.freebsd.org/pipermail/freebsd-current/2012-June/034408.html -- Ian From owner-freebsd-net@FreeBSD.ORG Mon Jun 4 15:56:06 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 955E9106564A; Mon, 4 Jun 2012 15:56:06 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 97947156B29; Mon, 4 Jun 2012 15:52:02 +0000 (UTC) Message-ID: <4FCCD844.8070302@FreeBSD.org> Date: Mon, 04 Jun 2012 19:46:12 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Pounov References: <20120604173154.a54b48ac.misho@aitbg.com> In-Reply-To: <20120604173154.a54b48ac.misho@aitbg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: bpf kernel crash 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, 04 Jun 2012 15:56:06 -0000 On 04.06.2012 18:31, Michael Pounov wrote: > Kernel crash when you wish to change interface name from vlan0 to other name > > It seems to be in arrival/departure events. Yes, this is already fixed in r236559. -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 08:25:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74BDE106566B; Tue, 5 Jun 2012 08:25:09 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id D69778FC16; Tue, 5 Jun 2012 08:25:07 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q558P0u7028587 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 10:25:00 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q558P0Jb016927; Tue, 5 Jun 2012 10:25:00 +0200 (MEST) Date: Tue, 5 Jun 2012 10:25:00 +0200 From: Daniel Hartmeier To: freebsd-net@freebsd.org Message-ID: <20120605082500.GD13069@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.12-2006-07-14 Cc: Darren Reed Subject: pfil invariant proposal: mbuf begins with contiguous IP header 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, 05 Jun 2012 08:25:09 -0000 Quoting from pfil(9) When a filter is invoked, the packet appears just as if it ``came off the wire''. That is, all protocol fields are in network byte order. [...] This should be extended to include the guarantee that the mbuf begins with a contiguous IP header, i.e. mtod(*mp, struct ip *) may be used to access all IP header fields. And the hooks should be required to guarantee this for the mbufs they return. All pfil hooks rely on this to be true for input mbufs, and callers of pfil_run_hooks() expect it to be true for resulting mbufs. Currently, ipfilter violates this in certain cases (see kern/168190 for details), which causes errors and crashes in other pfil hooks. For example, ipfilter might run as the first hook, and return an mbuf with a leading segment of m_len == 0. Next, ipfw as the second hook will swap byte order of the IP header, but a subsequent m_pullup() overwrites the header. Finally, pf as the third hook will cause a call to m_copym() with much-too-large length (due to reversed byte order). The following patch both demonstrates and fixes the problem: --- sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 23 Sep 2011 00:51:37 -0000 1.20.4.1 +++ sys/contrib/ipfilter/netinet/ip_fil_freebsd.c 5 Jun 2012 08:05:33 -0000 @@ -183,7 +183,14 @@ fr_check_wrapper(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { struct ip *ip = mtod(*mp, struct ip *); - return fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + int r = fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); + if (*mp != NULL && (*mp)->m_pkthdr.len >= sizeof(struct ip) && + (*mp)->m_len < sizeof(struct ip)) { + printf("fr_check_wrapper: m_len %d fixed\n", + (int)(*mp)->m_len); + *mp = m_pullup(*mp, sizeof(struct ip)); + } + return r; } # ifdef USE_INET6 Maybe someone can provide a more efficient check closer to the origin of the empty leading segment, possibly fr_pullup() calling m_pulldown()? Or simply commit the above without the printf(), if you agree. :) Kind regards, Daniel From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 16:02:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B711065673; Tue, 5 Jun 2012 16:02:07 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 304368FC1C; Tue, 5 Jun 2012 16:02:07 +0000 (UTC) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 05 Jun 2012 09:01:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="108104459" Received: from orsmsx606.amr.corp.intel.com ([10.22.226.128]) by AZSMGA002.ch.intel.com with ESMTP; 05 Jun 2012 09:01:20 -0700 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by orsmsx606.amr.corp.intel.com (10.22.226.128) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 5 Jun 2012 09:01:11 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.60]) by ORSMSX151.amr.corp.intel.com ([169.254.7.30]) with mapi id 14.01.0355.002; Tue, 5 Jun 2012 09:01:05 -0700 From: "Pieper, Jeffrey E" To: Adrian Chadd , "Bjoern A. Zeeb" Thread-Topic: ixgbe(4) intr and pps problems in at least HEAD Thread-Index: AQHNQas+ivzcS7Np9UCDpcZyYPkI8JbpWseAgAKItrA= Date: Tue, 5 Jun 2012 16:01:04 +0000 Message-ID: <2A35EA60C3C77D438915767F458D6568481B1E3C@ORSMSX101.amr.corp.intel.com> References: <90B0A065-634A-47F5-A8B9-3D093865F48A@lists.zabbadoz.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jack F Vogel , FreeBSD Networking Mailing List Subject: RE: ixgbe(4) intr and pps problems in at least HEAD 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, 05 Jun 2012 16:02:07 -0000 -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Adrian Chadd Sent: Sunday, June 03, 2012 11:12 AM To: Bjoern A. Zeeb Cc: Jack F Vogel; FreeBSD Networking Mailing List Subject: Re: ixgbe(4) intr and pps problems in at least HEAD On 3 June 2012 10:05, Bjoern A. Zeeb wrote= : > Hey Jack or anyone on net@, > > having updated my sources of HEAD from Dec/Mar to something of last week > I get a lot of: > > interrupt storm detected on "irq262:"; throttling interrupt source > > That to me almost sounds like no interrupt mitigation or just an > unserviced isr bit. > > Can you go grovelling through the interrupt handler and see what bits > are/aren't being handled? > > > Adrian The README should probably be updated. I noticed this awhile back, and Jack= said just to disable it by setting hw.intr_storm_threshold =3D 0. Doing th= is doesn't seem to affect performance in any way that I've found, and it ge= ts rid of the annoying spam :) Jeff _______________________________________________ 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 Jun 5 16:23:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CBE106564A for ; Tue, 5 Jun 2012 16:23:04 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 874DA8FC0A for ; Tue, 5 Jun 2012 16:23:03 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id AEC11E643B for ; Tue, 5 Jun 2012 17:23:43 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=Y+AqajqzCLeH06bXkegan+G7S b8=; b=K0bjRweOULgzcab+Bedjn3l4kpBHN19zD27fGBbCe40VEldHpEZs5F9h1 P6cmZ25s0346doDuCTVMHG/MaqfEr08OTivZxoFq5xOmaxBKnFAfnruIExHLb/bV qHqLrQ7QeTJKBlnw3XpqIT+i5iUpBqGCGz96/dpOS3Yt6LmfH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=ISKje7l8S3vKFzW04rh KlL91oht0U0Cj4gfsYsSsy7fa5MdEEXN7XrAk9bPSqCiz1YRJdrsgFN55jBHOgz7 H/ao0VMJZa4Pd4/snP55QR0Gdw8IafQt+MaS8n+28aEPThq+iqn2HXyP68JyMAr8 SNe7GyoAaux5hhzxgMKrxPjI= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 954ADE643A for ; Tue, 5 Jun 2012 17:23:43 +0100 (BST) Message-ID: <4FCE3265.9080804@cran.org.uk> Date: Tue, 05 Jun 2012 17:23:01 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Configuration problem with IPv6 router ("cannot forward src") 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, 05 Jun 2012 16:23:04 -0000 I'm trying to set up a IPv6 router (running -current) on my home network. My ISP gives me a /128 via PPP and I have a /48 allocation, which I use to give em0 and tun0 public addresses in different subnets (tun0 is assigned the address via ppp.linkup). I've added all the IPv6 settings to rc.conf (ipv6_gateway_enable, ipv6_network_interfaces, rtadvd_enable etc.) and I can ping IPv6 sites from the router. The problem is that rtadvd continues advertising the default gateway as tun0's link-local address - and pinging from a machine on the network results in "cannot forward src" messages on the router (strangely, despite hisaddr being fe80::205:... in ppp.log, the kernel logs the address as fe80:f::205:...). Is there some extra configuration I've likely missed that's needed when using IPv6 via PPP? -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 17:22:38 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28B291065673 for ; Tue, 5 Jun 2012 17:22:38 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01EE68FC16 for ; Tue, 5 Jun 2012 17:22:37 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8226369pbb.13 for ; Tue, 05 Jun 2012 10:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lCF5Ha8MPP06pNKemPuAh5o+TqFEyDvNC2jFK+OBJas=; b=05tlLoEp1Vqr5PqK23hyGmwhcQcaLtG+vtdgv4Dt8w4P5VD7KTuxApPga5bZ9TSDb+ 3HQhNB4haDvpmTD6hii6MXmsJhI1bkf8loI+RgGnsn6Qqa0hNqTBSM0gF6Fs+IGofKYK ZsBIPzE0SYW+zGQlFELAVlFnx/b/ArIGPAsjX04zfHxzu2AoAXYPPBue9Igz7Me8keFI AKffwwaLJJEbpLAygoUa5GbTqoj44wn3DGj1XFTs3epC9xjFyqgCOMUE8qgOgAHnesgu b2Br01HX2QWkzW2LVbyHiKuv0Z/ekBOO4Wdm5B7LFCfV3cR5sNMcHw+QyZwYGYPJPaCq c5Nw== MIME-Version: 1.0 Received: by 10.68.203.73 with SMTP id ko9mr50782656pbc.66.1338916957434; Tue, 05 Jun 2012 10:22:37 -0700 (PDT) Received: by 10.142.165.21 with HTTP; Tue, 5 Jun 2012 10:22:37 -0700 (PDT) Date: Tue, 5 Jun 2012 10:22:37 -0700 Message-ID: From: Vijay Singh To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: UMA buckets and zone_clust 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, 05 Jun 2012 17:22:38 -0000 Hi. Perhaps a naive question - why dont we have BUCKET_MAX beyond 128? I would think that allocating a full page for buckets would be more efficient and also reduce the number of bucket allocations needed for other UMA zones. On a related note is there a reason why zone_clust does not use UMA_ZONE_MAXBUCKET? Any objections in adding this flag to zone_clust? -vijay From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 18:13:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79CC1065672 for ; Tue, 5 Jun 2012 18:13:17 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A37BE8FC15 for ; Tue, 5 Jun 2012 18:13:17 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A52EB2108B for ; Tue, 5 Jun 2012 14:13:11 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 05 Jun 2012 14:13:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:subject:content-type:content-transfer-encoding; s=smtpout; bh=QoRjX2tCwKb+9AnwrwW7L8/6uCA=; b=kUe7L/8KbJf2FUXTK n/63vBvtpWiRwmH5MHbvRpyAmdBJHTrOb4LgPV6on9piFTW11135ng4wuLeXfYmp oAu0A/HvWjLhSbGiAuXHhKuwSbhbvVd75Kvt+gdLGGBTPQgEblgoSjpWZk5uLWhJ QFigrzEvJi4tZnyHH7T8j4mNao= X-Sasl-enc: 3nb4lS+OZ02iQ+Sq66hn8F1FanKGfERWu8qZEjP7lqmO 1338919991 Received: from [192.168.1.124] (unknown [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPA id EC2638E0187 for ; Tue, 5 Jun 2012 14:13:10 -0400 (EDT) Message-ID: <4FCE4CAB.1080802@freebsd.org> Date: Wed, 06 Jun 2012 04:15:07 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 18:13:18 -0000 To echo comments made on tech-net for NetBSD... --- As much as I dislike the patch you created, I can't see any other way to elegantly solve the problem. The reason that I don't like the change is that it seems silly to have to put the packet in two different mbufs after having put it all in one. I'll file this as a workaround for the code in m_pulldown() being buggy. The patch below should work for FreeBSD (includes IPv6 code.) The greater problem that I see here is what if someone else were to use m_pulldown in their home-brew code that uses pfil ... from that angle, there should be a responsibility to make the interfaces more robust but perhaps that can be achieved with documentation updates. --- But otherwise, the root cause of this problem is not solved with this patch. It's just a workaround. Darren *** ip_fil_freebsd.c.orig 26 Jan 2012 06:03:43 -0000 --- ip_fil_freebsd.c 5 Jun 2012 18:09:25 -0000 *************** *** 171,177 **** fr_check_wrapper(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { struct ip *ip = mtod(*mp, struct ip *); ! return fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp); } # ifdef USE_INET6 --- 171,186 ---- fr_check_wrapper(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { struct ip *ip = mtod(*mp, struct ip *); ! int hlen = ip->ip_hl << 2; ! struct mbuf *m; ! int rv; ! ! rv = fr_check(ip, hlen, ifp, (dir == PFIL_OUT), mp); ! if ((rv == 0) && ((m = *mp) != NULL)) { ! if (m->m_len < hlen) ! *mp = m_pullup(m, hlen); ! } ! return rv; } # ifdef USE_INET6 *************** *** 180,187 **** static int fr_check_wrapper6(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { ! return (fr_check(mtod(*mp, struct ip *), sizeof(struct ip6_hdr), ! ifp, (dir == PFIL_OUT), mp)); } # endif #endif /* __FreeBSD_version >= 501108 */ --- 189,204 ---- static int fr_check_wrapper6(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir) { ! struct mbuf *m; ! int rv; ! ! rv = fr_check(mtod(*mp, struct ip *), sizeof(struct ip6_hdr), ! ifp, (dir == PFIL_OUT), mp); ! if ((rv == 0) && ((m = *mp) != NULL)) { ! if (m->m_len < sizeof(struct ip6_hdr)) ! *mp = m_pullup(m, sizeof(struct ip6_hdr)); ! } ! return rv; } # endif #endif /* __FreeBSD_version >= 501108 */ From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 18:24:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 508F61065687 for ; Tue, 5 Jun 2012 18:24:24 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3988FC16 for ; Tue, 5 Jun 2012 18:24:24 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B7AB920E07 for ; Tue, 5 Jun 2012 14:24:23 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 05 Jun 2012 14:24:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:subject:content-type:content-transfer-encoding; s=smtpout; bh=gGSEQwF8YZp4K5r29vP3LH3/1Ic=; b=dF2z2Utrxs0CqtWcM 8YM+Oxtg9YkLRAFEa6HoLk2yTWf19LMxqj/G8a4bhVbcVTGaEM8wN4/BePoDura5 TGv/rd/W45jF7EK+0TDoIUUVo9jRFF0Jk/DDjRcZDQJma7Dab4rIyiGj7Vb5FAR0 xOTB9tc9P2DwfAfOdGu7szficQ= X-Sasl-enc: nZMZFmfQ04H1zB3+cllL6rM3/eRu9cHXeYXuQdgguQaK 1338920663 Received: from [192.168.1.124] (unknown [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPA id 164BE8E0187 for ; Tue, 5 Jun 2012 14:24:22 -0400 (EDT) Message-ID: <4FCE4F4B.3020300@freebsd.org> Date: Wed, 06 Jun 2012 04:26:19 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: pfil invariant proposal: mbuf begins with contiguous IP header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 18:24:24 -0000 > Quoting from pfil(9) > > When a filter is invoked, the packet appears just as if it ``came off the > wire''. That is, all protocol fields are in network byte order. [...] pfil(9) is already out of date with respect to FreeBSD as FreeBSD passes both ip_len and ip_off through in host byte order. As you noted, pf is confused by this elsewhere and tries to do a m_copym of an incorrect byte count. > This should be extended to include the guarantee that the mbuf begins > with a contiguous IP header, i.e. mtod(*mp, struct ip *) may be used to > access all IP header fields. For the present, this is a sensible addition but long term, I think the pfil interface needs to advance to supporting the mbuf where the packet data starts being in a different mbuf to that which is the start of the packet. Darren From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 18:32:04 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93ADB1065670; Tue, 5 Jun 2012 18:32:04 +0000 (UTC) (envelope-from darrenr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 66D968FC08; Tue, 5 Jun 2012 18:32:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q55IW49O060018; Tue, 5 Jun 2012 18:32:04 GMT (envelope-from darrenr@freefall.freebsd.org) Received: (from darrenr@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q55IW3UC059983; Tue, 5 Jun 2012 18:32:03 GMT (envelope-from darrenr) Date: Tue, 5 Jun 2012 18:32:03 GMT Message-Id: <201206051832.q55IW3UC059983@freefall.freebsd.org> To: bsdbug@bospaling.nl, darrenr@FreeBSD.org, freebsd-net@FreeBSD.org, darrenr@FreeBSD.org From: darrenr@FreeBSD.org Cc: Subject: Re: kern/167768: [ipfilter] Fatal trap in ipfilter/ipnat 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, 05 Jun 2012 18:32:04 -0000 Synopsis: [ipfilter] Fatal trap in ipfilter/ipnat State-Changed-From-To: open->feedback State-Changed-By: darrenr State-Changed-When: Tue Jun 5 18:31:16 UTC 2012 State-Changed-Why: Responsible-Changed-From-To: freebsd-net->darrenr Responsible-Changed-By: darrenr Responsible-Changed-When: Tue Jun 5 18:31:16 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=167768 From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 18:34:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8851B106564A; Tue, 5 Jun 2012 18:34:53 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 349F28FC15; Tue, 5 Jun 2012 18:34:30 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C00AD21019; Tue, 5 Jun 2012 14:34:29 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 05 Jun 2012 14:34:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:content-type :content-transfer-encoding; s=smtpout; bh=/Aq6gEVxTx405pH35s8peJ 9UFxs=; b=cqdF7w12qZJzWQEKacxxOutI5sarQ18RzDuAQXv1UHuoVbB2VKi1dA wwh3WYS7LZvbzoLQDP8ITV6b6jAPtXx7WHBChDftIrRroEZ5zqBN6mg40fia95lw bhVSW4ncHWr3az/8P+Zx7xlgxXO22iSoO3U4hA6ga3GlZmYUwCzbY= X-Sasl-enc: tzae7MuRV5H7GKoz9HRTGiZ0bMdAp1fQ+H6ByTH6p0qv 1338921269 Received: from [192.168.1.124] (unknown [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPA id 97D528E00E9; Tue, 5 Jun 2012 14:34:28 -0400 (EDT) Message-ID: <4FCE51A8.1040703@freebsd.org> Date: Wed, 06 Jun 2012 04:36:24 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: bsdbug@bospaling.nl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-bugs@FreeBSD.org Subject: kern/167768: [ipfilter] Fatal trap in ipfilter/ipnat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 18:34:53 -0000 The problem is that you have a port range of 0 in an ipnat.conf line. Quick solution is to ensure that all ipnat.conf lines specify a range of ports of greater than 0. Otherwise patch below applies. Darren --- /tmp/ip_nat.c.orig 2012-06-06 04:31:31.000000000 +1000 +++ /tmp/ip_nat.c 2012-06-06 04:31:41.000000000 +1000 @@ -2040,7 +2040,7 @@ port = np->in_pnext; } else { port = ipf_random() % (ntohs(np->in_pmax) - - ntohs(np->in_pmin)); + ntohs(np->in_pmin) +1); port += ntohs(np->in_pmin); } port = htons(port); From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 20:27:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65973106564A for ; Tue, 5 Jun 2012 20:27:36 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3C18FC08 for ; Tue, 5 Jun 2012 20:27:36 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7ABF920DE7; Tue, 5 Jun 2012 16:27:35 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 05 Jun 2012 16:27:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:content-type :content-transfer-encoding; s=smtpout; bh=izpkjZKR1O+coGB2fj/Yme TQOnI=; b=mPBuLzBqFMdDbiOp7IaXeGl+/UpPALL6OINZMGwGvd3ay8E7iKC9Zy uw4EaMg7/hahfI+s2b3nHmo4p4ERffKibwfxYU3eF3Cbk3HcJ+aC05/rO9oOMKEw /G2s6SaDngWhnz+1z/YWC+Fhku4M2ySPhAsGjuhnTzzMMvPA0DA64= X-Sasl-enc: D8gdmkOulfndm2z12EImAaMCXosyz1eHqp1O4vTEVt8h 1338928055 Received: from [192.168.1.124] (unknown [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPA id 805178E020B; Tue, 5 Jun 2012 16:27:34 -0400 (EDT) Message-ID: <4FCE6C29.3070903@freebsd.org> Date: Wed, 06 Jun 2012 06:29:29 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: hgcheng@berkeley.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: NAT with Port-block Allocation in FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 20:27:36 -0000 In IPFilter, the "map-block" ipnat rule serves exactly the purpose that you are looking for. It provides address translation of network addresses for N:M and uses ports to multiplex them in. Thus a /16 can be nat'd to a /8 with the other 8 bits used in the port number. The results of the NAT'd packets are such that if you are given an external IP address and port number, you can calculate which internal IP address was used without having to know what was the currently active state of the machine. A typical rule might look like this: map-block le0 10.0.0.0/16 -> 203.1.1.0/24 ports auto Darren From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 20:33:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 572AC106568C for ; Tue, 5 Jun 2012 20:33:58 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id A93D68FC16 for ; Tue, 5 Jun 2012 20:33:57 +0000 (UTC) Received: from [IPv6:2002:508f:aec8::9067:f14:c64c:c60a] (unknown [IPv6:2002:508f:aec8:0:9067:f14:c64c:c60a]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AC1F21C0C0BE9 for ; Tue, 5 Jun 2012 22:33:56 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/mixed; boundary="Apple-Mail=_6CCF2CB6-B5EA-4BB0-AAAE-F354DAE44261" Date: Tue, 5 Jun 2012 22:33:54 +0200 Message-Id: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> To: "freebsd-net@freebsd.org mailing list" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: IP_RECVTOS 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, 05 Jun 2012 20:33:58 -0000 --Apple-Mail=_6CCF2CB6-B5EA-4BB0-AAAE-F354DAE44261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, there is currently no way to receive the TOS byte of a received UDP/IPv4 = packet. The attached patch adds a socket option (IP_RECVTOS) which you can use to get a cmsg of type (IP_RECVTOS) which contains the TOS byte. Much = like IP_RECVTTL does for TTL. Any comments/objections? If there are none, I = would like to commit this to head soon. Best regards Michael --Apple-Mail=_6CCF2CB6-B5EA-4BB0-AAAE-F354DAE44261 Content-Disposition: attachment; filename=recvtos.patch Content-Type: application/octet-stream; name="recvtos.patch" Content-Transfer-Encoding: 7bit Index: in.h =================================================================== --- in.h (revision 236601) +++ in.h (working copy) @@ -462,6 +462,7 @@ #define IP_RECVTTL 65 /* bool; receive IP TTL w/dgram */ #define IP_MINTTL 66 /* minimum TTL for packet or drop */ #define IP_DONTFRAG 67 /* don't fragment packet */ +#define IP_RECVTOS 68 /* bool; receive IP TOS w/dgram */ /* IPv4 Source Filter Multicast API [RFC3678] */ #define IP_ADD_SOURCE_MEMBERSHIP 70 /* join a source-specific group */ Index: in_pcb.c =================================================================== --- in_pcb.c (revision 236601) +++ in_pcb.c (working copy) @@ -2295,6 +2295,10 @@ db_printf("%sINP_DONTFRAG", comma ? ", " : ""); comma = 1; } + if (inp_flags & INP_RECVTOS) { + db_printf("%sINP_RECVTOS", comma ? ", " : ""); + comma = 1; + } if (inp_flags & IN6P_IPV6_V6ONLY) { db_printf("%sIN6P_IPV6_V6ONLY", comma ? ", " : ""); comma = 1; Index: in_pcb.h =================================================================== --- in_pcb.h (revision 236601) +++ in_pcb.h (working copy) @@ -509,6 +509,7 @@ #define INP_DONTFRAG 0x00000800 /* don't fragment packet */ #define INP_BINDANY 0x00001000 /* allow bind to any address */ #define INP_INHASHLIST 0x00002000 /* in_pcbinshash() has been called */ +#define INP_RECVTOS 0x00004000 /* receive incoming IP TOS */ #define IN6P_IPV6_V6ONLY 0x00008000 /* restrict AF_INET6 socket for v6 */ #define IN6P_PKTINFO 0x00010000 /* receive IP6 dst and I/F */ #define IN6P_HOPLIMIT 0x00020000 /* receive hoplimit */ @@ -528,7 +529,7 @@ #define IN6P_MTU 0x80000000 /* receive path MTU */ #define INP_CONTROLOPTS (INP_RECVOPTS|INP_RECVRETOPTS|INP_RECVDSTADDR|\ - INP_RECVIF|INP_RECVTTL|\ + INP_RECVIF|INP_RECVTTL|INP_RECVTOS|\ IN6P_PKTINFO|IN6P_HOPLIMIT|IN6P_HOPOPTS|\ IN6P_DSTOPTS|IN6P_RTHDR|IN6P_RTHDRDSTOPTS|\ IN6P_TCLASS|IN6P_AUTOFLOWLABEL|IN6P_RFC2292|\ Index: ip_output.c =================================================================== --- ip_output.c (revision 236601) +++ ip_output.c (working copy) @@ -984,6 +984,7 @@ case IP_FAITH: case IP_ONESBCAST: case IP_DONTFRAG: + case IP_RECVTOS: error = sooptcopyin(sopt, &optval, sizeof optval, sizeof optval); if (error) @@ -1047,6 +1048,9 @@ case IP_BINDANY: OPTSET(INP_BINDANY); break; + case IP_RECVTOS: + OPTSET(INP_RECVTOS); + break; } break; #undef OPTSET @@ -1156,6 +1160,7 @@ case IP_ONESBCAST: case IP_DONTFRAG: case IP_BINDANY: + case IP_RECVTOS: switch (sopt->sopt_name) { case IP_TOS: @@ -1214,6 +1219,9 @@ case IP_BINDANY: optval = OPTBIT(INP_BINDANY); break; + case IP_RECVTOS: + optval = OPTBIT(INP_RECVTOS); + break; } error = sooptcopyout(sopt, &optval, sizeof optval); break; Index: ip_input.c =================================================================== --- ip_input.c (revision 236601) +++ ip_input.c (working copy) @@ -1684,6 +1684,12 @@ if (*mp) mp = &(*mp)->m_next; } + if (inp->inp_flags & INP_RECVTOS) { + *mp = sbcreatecontrol((caddr_t) &ip->ip_tos, + sizeof(u_char), IP_RECVTOS, IPPROTO_IP); + if (*mp) + mp = &(*mp)->m_next; + } } /* --Apple-Mail=_6CCF2CB6-B5EA-4BB0-AAAE-F354DAE44261-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 5 21:37:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F4AD1065674 for ; Tue, 5 Jun 2012 21:37:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62DC38FC08 for ; Tue, 5 Jun 2012 21:37:32 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8522036pbb.13 for ; Tue, 05 Jun 2012 14:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5zZSkC1E3M0D2GJ7AzSnBl5zWb2WKRepQe21Eo3UHZU=; b=IXl3s4Ga/TqsSTj3omiRV30aL0vz4WrdH7a+fQYevUjFApf2epw/cTypZ8TbYtDIi7 5l/uwjK2aGbvKPWxYZDk3R3ffiUG0+i0srzcO4lxkmjWqfjMxY9BLzbwlp+SnJZE4qqk jAIwatelKU+LwyF2uoLlMGC5+8SZE1ZXqfqFHQXnE2gPco40oNasZZODkNsxuftiUhrG EY9drKtR3qyxzZ4N9Mw21nTb/mwyB4rGwxcYYAmONEsWinID/+k9qZP/9tULhOuw6Fb4 nbM9JxFbZZu2lOZbXVS1YkJ1UUepLdVWLeBVAYHiKt1X30NA/SNcwnSG4Euy7EXDjT5A O1lQ== MIME-Version: 1.0 Received: by 10.68.211.170 with SMTP id nd10mr16247767pbc.68.1338932251917; Tue, 05 Jun 2012 14:37:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Tue, 5 Jun 2012 14:37:31 -0700 (PDT) In-Reply-To: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> Date: Tue, 5 Jun 2012 14:37:31 -0700 X-Google-Sender-Auth: xlNN47dfMuAnvZ7ULPEXJial2MY Message-ID: From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 05 Jun 2012 21:37:32 -0000 Hi, can you please wrap this up in a PR so it's not lost? thanks, Adrian On 5 June 2012 13:33, Michael Tuexen wrote: > Dear all, > > there is currently no way to receive the TOS byte of a received UDP/IPv4 packet. > The attached patch adds a socket option (IP_RECVTOS) which you can use > to get a cmsg of type (IP_RECVTOS) which contains the TOS byte. Much like > IP_RECVTTL does for TTL. Any comments/objections? If there are none, I would > like to commit this to head soon. > > Best regards > Michael > > > _______________________________________________ > 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 Jun 5 22:11:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 129C710657AC; Tue, 5 Jun 2012 22:11:11 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id A10A78FC12; Tue, 5 Jun 2012 22:11:10 +0000 (UTC) Received: from [IPv6:2002:508f:aec8::9067:f14:c64c:c60a] (unknown [IPv6:2002:508f:aec8:0:9067:f14:c64c:c60a]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 189F81C0C0BE9; Wed, 6 Jun 2012 00:11:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Wed, 6 Jun 2012 00:11:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1278) Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 05 Jun 2012 22:11:11 -0000 On Jun 5, 2012, at 11:37 PM, Adrian Chadd wrote: > Hi, >=20 > can you please wrap this up in a PR so it's not lost? Why should it get lost? If there are no objections, I'll commit it. If = there are, we'll see if we can resolve it. Best regards Michael >=20 > thanks, >=20 >=20 > Adrian >=20 > On 5 June 2012 13:33, Michael Tuexen = wrote: >> Dear all, >>=20 >> there is currently no way to receive the TOS byte of a received = UDP/IPv4 packet. >> The attached patch adds a socket option (IP_RECVTOS) which you can = use >> to get a cmsg of type (IP_RECVTOS) which contains the TOS byte. Much = like >> IP_RECVTTL does for TTL. Any comments/objections? If there are none, = I would >> like to commit this to head soon. >>=20 >> Best regards >> Michael >>=20 >>=20 >> _______________________________________________ >> 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" >=20 From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 06:50:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 156B21065675 for ; Wed, 6 Jun 2012 06:50:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB27B8FC14 for ; Wed, 6 Jun 2012 06:50:46 +0000 (UTC) Received: by dadv36 with SMTP id v36so8862813dad.13 for ; Tue, 05 Jun 2012 23:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NZRN5zg8FVKDlWHL/OW7JwpWfsFaTLQfh9DI3QSFCgM=; b=YV9UIP3Qid7Zqbqfs7vDEtYT6ldK3LCM/ReKBnkOu0BBm3FPfbauC9x4PviIcIrHZ1 UGtmp1MiwYe18eF/qZC62p89/ruANKs3fq4j3RM1c3Vl/5du2BeueNFcuSxQ4lMXwwLz GygJJ3/H0YBNmDpRi4y9zV15r2p52W0bmv2QCGB88rdPwQ/W9pxeUeFOQTgWgGZXXhWQ OU/3HC2XvcqlCzrsSw20zOvzhBvXFJb+sLCrIwjQwDnxgXE5QT+RLVeuI58RBDDTXp1M YR9nyAEqTCjUpNpn7K9pHiL2EydWrLlxFIu2rhKqCYPtSvaWIgL1HFxfU4//e6zzQWfj ou/g== MIME-Version: 1.0 Received: by 10.68.223.167 with SMTP id qv7mr55060475pbc.127.1338965446334; Tue, 05 Jun 2012 23:50:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Tue, 5 Jun 2012 23:50:46 -0700 (PDT) In-Reply-To: <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> Date: Tue, 5 Jun 2012 23:50:46 -0700 X-Google-Sender-Auth: WjUiRQ6MkQpdjbWbZL8GF5-590g Message-ID: From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 06 Jun 2012 06:50:47 -0000 On 5 June 2012 15:11, Michael Tuexen wrote: > Why should it get lost? If there are no objections, I'll commit it. If there > are, we'll see if we can resolve it. Oh sweet, you can do that? Yes, I really would like to see this particular feature in FreeBSD. Thanks so much for coding it up! Do you think it's worth adding an example or two which uses this? Adrian From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 07:20:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 479A0106564A; Wed, 6 Jun 2012 07:20:41 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id D4E758FC1B; Wed, 6 Jun 2012 07:20:40 +0000 (UTC) Received: from [192.168.1.103] (p508FA25E.dip.t-dialin.net [80.143.162.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 792A41C0C0BD8; Wed, 6 Jun 2012 09:20:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Wed, 6 Jun 2012 09:20:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1278) Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 06 Jun 2012 07:20:41 -0000 On Jun 6, 2012, at 8:50 AM, Adrian Chadd wrote: > On 5 June 2012 15:11, Michael Tuexen = wrote: >=20 >> Why should it get lost? If there are no objections, I'll commit it. = If there >> are, we'll see if we can resolve it. >=20 > Oh sweet, you can do that? Yes, I really would like to see this > particular feature in FreeBSD. >=20 > Thanks so much for coding it up! >=20 > Do you think it's worth adding an example or two which uses this? Not sure how to add an example, but I've also a paragraph going into man ip: If the IP_RECVTOS option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return the IP TOS (type of service) field for = a UDP datagram. The msg_control field in the msghdr structure points to = a buffer that contains a cmsghdr structure followed by the TOS. The = cms- ghdr fields have the following values: cmsg_len =3D CMSG_LEN(sizeof(u_char)) cmsg_level =3D IPPROTO_IP cmsg_type =3D IP_RECVTOS Best regards Michael >=20 >=20 >=20 > Adrian >=20 From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 08:15:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B69CD1065670 for ; Wed, 6 Jun 2012 08:15:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 85E668FC1C for ; Wed, 6 Jun 2012 08:15:25 +0000 (UTC) Received: by dadv36 with SMTP id v36so8963941dad.13 for ; Wed, 06 Jun 2012 01:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/XHrGyF7+Kae3CmP9uiPETrKfSiXtpPQT1zLViLnbGg=; b=iQxDC7onfkTRQZzIBrk9g9RJyVIpDp0q1O+79YUOBnMxbRpTsXNg5NEQ0sgZ6nZ+1P DFWHMNDY3q6ppd/XF8lhClHtazUYSOzMCGO9XqqRksPUnsmuh4+cNaaIGD9Vbm81/7Xg HnvCjuTqCc0uN5YZAkmqXgw1y2TM5pe4HmrUP/uAeAJFwA9lPmpW/jVfBnW7265W2YJj oC1IC2lamKZEBDEibBGkZyQ4Uuw2N4JbxhPQ8oRWKVRFQFDVbH2TWKUyz43foKVXtLkQ m9iz/4p5OK9xL0JyRECooO4BqZpCfN8RyXbjmRGu75fL32/TX+aTuVQqJKu/KCiTL42/ SHgA== MIME-Version: 1.0 Received: by 10.68.226.226 with SMTP id rv2mr56862379pbc.101.1338970524367; Wed, 06 Jun 2012 01:15:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Wed, 6 Jun 2012 01:15:24 -0700 (PDT) In-Reply-To: <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> Date: Wed, 6 Jun 2012 01:15:24 -0700 X-Google-Sender-Auth: Jlv7i1fATD3f1FrxTuKku2N9kKg Message-ID: From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 06 Jun 2012 08:15:25 -0000 Well, * Is it usable on a TCP socket? * Is it usable on an outbound TCP socket (ie, where the receive end has set the ToS bits on the received ToS), regardless of what you've set for the sending ToS? * Does the receive TOS change during the lifetime of a TCP connection? If so, can this fetch it? * Example code? :) Adrian From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 10:34:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A585106566C; Wed, 6 Jun 2012 10:34:48 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 74A228FC19; Wed, 6 Jun 2012 10:34:47 +0000 (UTC) Received: from [192.168.1.103] (p508FA25E.dip.t-dialin.net [80.143.162.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C72291C0C0BD8; Wed, 6 Jun 2012 12:34:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/mixed; boundary="Apple-Mail=_5120CC7C-A141-480E-8EE0-114EF60EEAB2" From: Michael Tuexen In-Reply-To: Date: Wed, 6 Jun 2012 12:34:43 +0200 Message-Id: <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1278) Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 06 Jun 2012 10:34:48 -0000 --Apple-Mail=_5120CC7C-A141-480E-8EE0-114EF60EEAB2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Jun 6, 2012, at 10:15 AM, Adrian Chadd wrote: > Well, > > * Is it usable on a TCP socket? No. The main application (I see) is to access the ECN bits. In the TCP case, ECN is handled in the kernel, so there is no need to deal with them in userland. On the other hand, TCP is byte stream oriented, so I don't see any packet boundaries. However, the TOS is per packet. Much like the TTL. This is also limited to SOCK_DGRAM. > * Is it usable on an outbound TCP socket (ie, where the receive end > has set the ToS bits on the received ToS), regardless of what you've > set for the sending ToS? You can use the IP_TOS socket option for outgoing traffic. > * Does the receive TOS change during the lifetime of a TCP connection? The sender can change it. > If so, can this fetch it? No. The IP_RECVTOS is similar to the IPV6_RECVTCLASS socket option. > * Example code? :) Attached. Best regards Michael --Apple-Mail=_5120CC7C-A141-480E-8EE0-114EF60EEAB2 Content-Disposition: attachment; filename=v4test.c Content-Type: application/octet-stream; x-mac-type=534D4C34; x-mac-creator=534D554C; x-unix-mode=0644; name="v4test.c" Content-Transfer-Encoding: 7bit /*- * Copyright (c) 2012 Michael Tuexen * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ #include #include #include #include #include #include #include #include #define DATA_BUFFER_SIZE (1<<10) #define CONTROL_BUFFER_SIZE (1<<10) int main(void) { int fd; ssize_t n; struct sockaddr_in addr; struct cmsghdr *cmsg; struct msghdr msg; struct iovec iov; const int on = 1; char dbuf[DATA_BUFFER_SIZE]; char cbuf[CONTROL_BUFFER_SIZE]; char nbuf[INET_ADDRSTRLEN]; const char *name; if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); } if (setsockopt(fd, IPPROTO_IP, IP_RECVTOS, &on, sizeof(on)) < 0) { perror("IP_RECVTOS"); } if (setsockopt(fd, IPPROTO_IP, IP_RECVTTL, &on, sizeof(on)) < 0) { perror("IP_RECVTTL"); } if (setsockopt(fd, IPPROTO_IP, IP_RECVDSTADDR, &on, sizeof(on)) < 0) { perror("IP_RECVDSTADDR"); } memset(&addr, 0, sizeof(struct sockaddr_in)); addr.sin_family = AF_INET; #ifdef HAVE_SIN_LEN addr.sin_len = sizeof(struct sockaddr_in); #endif addr.sin_addr.s_addr = INADDR_ANY; addr.sin_port = htons(9); if (bind(fd, (struct sockaddr*) &addr, sizeof(struct sockaddr_in)) < 0) { perror("bind"); } for (;;) { iov.iov_base = dbuf; iov.iov_len = DATA_BUFFER_SIZE; memset(&msg, 0, sizeof(struct msghdr)); msg.msg_name = &addr; msg.msg_namelen = sizeof(struct sockaddr_in6); msg.msg_iov = &iov; msg.msg_iovlen = 1; msg.msg_control = cbuf; msg.msg_controllen = CONTROL_BUFFER_SIZE; n = recvmsg(fd, &msg, 0); if (n < 0) { perror("recvmsg"); break; } name = inet_ntop(AF_INET, &addr.sin_addr, nbuf, INET_ADDRSTRLEN); printf("Received message of length %ld from %s.\n", n, name); for (cmsg = CMSG_FIRSTHDR(&msg); cmsg != NULL; cmsg = CMSG_NXTHDR(&msg, cmsg)) { printf("level = %d, type = %d, len = %d.\n", cmsg->cmsg_level, cmsg->cmsg_type, cmsg->cmsg_len); if ((cmsg->cmsg_level == IPPROTO_IP) && (cmsg->cmsg_type == IP_RECVTOS) && (cmsg->cmsg_len == CMSG_LEN(sizeof(uint8_t)))) { uint8_t *tos; tos = (uint8_t *)CMSG_DATA(cmsg); printf("Received tos = %d\n", *tos); } if ((cmsg->cmsg_level == IPPROTO_IP) && (cmsg->cmsg_type == IP_RECVTTL) && (cmsg->cmsg_len == CMSG_LEN(sizeof(uint8_t)))) { uint8_t *ttl; ttl = (uint8_t *)CMSG_DATA(cmsg); printf("Received TTL = %d\n", *ttl); } if ((cmsg->cmsg_level == IPPROTO_IP) && (cmsg->cmsg_type == IP_RECVDSTADDR) && (cmsg->cmsg_len == CMSG_LEN(sizeof(struct in_addr)))) { struct in_addr *dst; dst = (struct in_addr *)CMSG_DATA(cmsg); name = inet_ntop(AF_INET, dst, nbuf, INET_ADDRSTRLEN); printf("Destination address %s.\n", name); } } } if (close(fd) < 0) { perror("close"); } return (0); } --Apple-Mail=_5120CC7C-A141-480E-8EE0-114EF60EEAB2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 > > > > Adrian > --Apple-Mail=_5120CC7C-A141-480E-8EE0-114EF60EEAB2-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 14:28:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCFF21065674; Wed, 6 Jun 2012 14:28:53 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id A00AE8FC14; Wed, 6 Jun 2012 14:28:52 +0000 (UTC) Received: from [212.201.126.50] (unknown [212.201.126.50]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3D3241C0B4627; Wed, 6 Jun 2012 16:28:51 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/mixed; boundary="Apple-Mail=_7B8DFA4E-5D92-4CC3-BC8C-C8E0C8E96791" Date: Wed, 6 Jun 2012 16:28:49 +0200 Message-Id: To: "freebsd-net@freebsd.org mailing list" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: "Bjoern A. Zeeb" Subject: Delivering IPV6 CMSGs on mapped sockets for received IPv4 packets 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, 06 Jun 2012 14:28:54 -0000 --Apple-Mail=_7B8DFA4E-5D92-4CC3-BC8C-C8E0C8E96791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, anyone objecting to deliver IPV6_TCLASS, IPV6_HOPLIMIT and IPV6_PKTINFO = cmsgs (when requested, of course) on IPV6 sockets, which have been marked to be not = IPV6_V6ONLY, for each received IPV4 packet? The reported tclass would be the TOS byte, the reported hlim would be = the received TTL, and the reported address would be the mapped IPv6 address. The patch would look like the attached... If noone objects I'll commit the code... Best regards Michael --Apple-Mail=_7B8DFA4E-5D92-4CC3-BC8C-C8E0C8E96791 Content-Disposition: attachment; filename=mapped.patch Content-Type: application/octet-stream; name="mapped.patch" Content-Transfer-Encoding: 7bit Index: ip6_input.c =================================================================== --- ip6_input.c (revision 236601) +++ ip6_input.c (working copy) @@ -1321,19 +1321,28 @@ } #endif - if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) { - if (v4only != NULL) - *v4only = 1; - return (mp); - } - #define IS2292(inp, x, y) (((inp)->inp_flags & IN6P_RFC2292) ? (x) : (y)) /* RFC 2292 sec. 5 */ if ((inp->inp_flags & IN6P_PKTINFO) != 0) { struct in6_pktinfo pi6; - bcopy(&ip6->ip6_dst, &pi6.ipi6_addr, sizeof(struct in6_addr)); - in6_clearscope(&pi6.ipi6_addr); /* XXX */ + if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) { +#ifdef INET + struct ip *ip; + + ip = mtod(m, struct ip *); + pi6.ipi6_addr.s6_addr32[0] = 0; + pi6.ipi6_addr.s6_addr32[1] = 0; + pi6.ipi6_addr.s6_addr32[2] = IPV6_ADDR_INT32_SMP; + pi6.ipi6_addr.s6_addr32[3] = ip->ip_dst.s_addr; +#else + /* We won't hit this code */ + bzero(&pi6.ipi6_addr, sizeof(struct in6_addr)); +#endif + } else { + bcopy(&ip6->ip6_dst, &pi6.ipi6_addr, sizeof(struct in6_addr)); + in6_clearscope(&pi6.ipi6_addr); /* XXX */ + } pi6.ipi6_ifindex = (m && m->m_pkthdr.rcvif) ? m->m_pkthdr.rcvif->if_index : 0; @@ -1345,8 +1354,21 @@ } if ((inp->inp_flags & IN6P_HOPLIMIT) != 0) { - int hlim = ip6->ip6_hlim & 0xff; + int hlim; + if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) { +#ifdef INET + struct ip *ip; + + ip = mtod(m, struct ip *); + hlim = ip->ip_ttl; +#else + /* We won't hit this code */ + hlim = 0; +#endif + } else { + hlim = ip6->ip6_hlim & 0xff; + } *mp = sbcreatecontrol((caddr_t) &hlim, sizeof(int), IS2292(inp, IPV6_2292HOPLIMIT, IPV6_HOPLIMIT), IPPROTO_IPV6); @@ -1354,8 +1376,40 @@ mp = &(*mp)->m_next; } - if (v4only != NULL) - *v4only = 0; + if ((inp->inp_flags & IN6P_TCLASS) != 0) { + int tclass; + + if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) { +#ifdef INET + struct ip *ip; + + ip = mtod(m, struct ip *); + tclass = ip->ip_tos; +#else + /* We won't hit this code */ + tclass = 0; +#endif + } else { + u_int32_t flowinfo; + + flowinfo = (u_int32_t)ntohl(ip6->ip6_flow & IPV6_FLOWINFO_MASK); + flowinfo >>= 20; + tclass = flowinfo & 0xff; + } + *mp = sbcreatecontrol((caddr_t) &tclass, sizeof(int), + IPV6_TCLASS, IPPROTO_IPV6); + if (*mp) + mp = &(*mp)->m_next; + } + + if (v4only != NULL) { + if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION) { + *v4only = 1; + } else { + *v4only = 0; + } + } + return (mp); } @@ -1369,20 +1423,6 @@ if (v4only) return; - if ((in6p->inp_flags & IN6P_TCLASS) != 0) { - u_int32_t flowinfo; - int tclass; - - flowinfo = (u_int32_t)ntohl(ip6->ip6_flow & IPV6_FLOWINFO_MASK); - flowinfo >>= 20; - - tclass = flowinfo & 0xff; - *mp = sbcreatecontrol((caddr_t) &tclass, sizeof(tclass), - IPV6_TCLASS, IPPROTO_IPV6); - if (*mp) - mp = &(*mp)->m_next; - } - /* * IPV6_HOPOPTS socket option. Recall that we required super-user * privilege for the option (see ip6_ctloutput), but it might be too --Apple-Mail=_7B8DFA4E-5D92-4CC3-BC8C-C8E0C8E96791-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 17:18:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17DD8106564A for ; Wed, 6 Jun 2012 17:18:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id DA5378FC16 for ; Wed, 6 Jun 2012 17:18:00 +0000 (UTC) Received: by dadv36 with SMTP id v36so9656977dad.13 for ; Wed, 06 Jun 2012 10:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3lsPW5UZ5S/iFuKQ9WNaT9UlMgYtlWVgAG2xwlWm7bw=; b=xOVKYJX4QN74SMk6wrmiAgS7SI/eAW3IdUZIsWokiK+1AatfJIJCl5nPiBkd6a43Nv c7QZ86QHIjtRAeJGQ5uHlIsmJGrDACEzSuahznCRgPkva2dq743q2LaOp5SlPTQyFIw9 WLveKeBe8v205XH2cGWQh+mEg+mYxfxq3YWVyqoHKeJ+x1iLRtnUohRgAD2aHfUwRFVF XvK4wXNi8QtrIIbPVPeAU5oBfACaHvk9K226PxSojlfhFf/UMx/EjkVD0H/XA6rhTYoR 2C5jkNorZXYRdrmDgGLFHY29giFT2EOZY6J3+RkJ5zqQoFlPB6eMVmC5RB2tcclILplw NLbg== MIME-Version: 1.0 Received: by 10.68.211.170 with SMTP id nd10mr25512644pbc.68.1339003076413; Wed, 06 Jun 2012 10:17:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Wed, 6 Jun 2012 10:17:56 -0700 (PDT) In-Reply-To: <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> Date: Wed, 6 Jun 2012 10:17:56 -0700 X-Google-Sender-Auth: OWvvucWcj2q5B6Pxexz2aHODIks Message-ID: From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 06 Jun 2012 17:18:01 -0000 Hi, For TCP, I've seen the network layer change things (eg setting bits on incoming traffic to mark which interface it came in on), so you can't guarantee the outbound ToS == inbound ToS. Adrian From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 17:54:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FD80106566C; Wed, 6 Jun 2012 17:54:29 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 0447D8FC16; Wed, 6 Jun 2012 17:54:29 +0000 (UTC) Received: from [192.168.1.103] (p508FA25E.dip.t-dialin.net [80.143.162.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 704271C0B4600; Wed, 6 Jun 2012 19:54:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Wed, 6 Jun 2012 19:54:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1278) Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 06 Jun 2012 17:54:29 -0000 On Jun 6, 2012, at 7:17 PM, Adrian Chadd wrote: > Hi, >=20 > For TCP, I've seen the network layer change things (eg setting bits on > incoming traffic to mark which interface it came in on), so you can't > guarantee the outbound ToS =3D=3D inbound ToS. I've not said that inbound =3D=3D outbound... I just wanted to make = clear that there is a socket option of setting the TOS byte for outgoing traffic. The TCP stack might overwrite the ECN bits... I need the IP_RECVTOS functionality for implementing a transport stack = supporting ECN in userland, actually running the SCTP kernel sources (with some = glue code) in userland on top of UDP... Best regards Michael >=20 >=20 >=20 > Adrian >=20 From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 19:13:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F7D1065673 for ; Wed, 6 Jun 2012 19:13:09 +0000 (UTC) (envelope-from philipp_subx@redfish-solutions.com) Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [66.232.79.143]) by mx1.freebsd.org (Postfix) with ESMTP id 351FC8FC1A for ; Wed, 6 Jun 2012 19:13:09 +0000 (UTC) Received: from macbook.redfish-solutions.com ([192.168.1.17]) (authenticated bits=0) by mail.redfish-solutions.com (8.14.5/8.14.5) with ESMTP id q56JD21M001849 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 6 Jun 2012 13:13:03 -0600 Message-ID: <4FCFABBE.7030008@redfish-solutions.com> Date: Wed, 06 Jun 2012 13:13:02 -0600 From: Philip Prindeville User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> In-Reply-To: <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.1.3 Subject: Re: IP_RECVTOS 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, 06 Jun 2012 19:13:09 -0000 On 6/6/12 11:54 AM, Michael Tuexen wrote: > On Jun 6, 2012, at 7:17 PM, Adrian Chadd wrote: > >> Hi, >> >> For TCP, I've seen the network layer change things (eg setting bits on >> incoming traffic to mark which interface it came in on), so you can't >> guarantee the outbound ToS == inbound ToS. > I've not said that inbound == outbound... I just wanted to make clear > that there is a socket option of setting the TOS byte for outgoing > traffic. The TCP stack might overwrite the ECN bits... > > I need the IP_RECVTOS functionality for implementing a transport stack supporting > ECN in userland, actually running the SCTP kernel sources (with some glue code) > in userland on top of UDP... > > Best regards > Michael What about UDT? Can you patch that as well? For certain services (like backups or AFP), it might be useful for a server to be able to detect a QoS-friendly client and reciprocate in kind. -Philip From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 21:35:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 077EB1065672 for ; Wed, 6 Jun 2012 21:35:14 +0000 (UTC) (envelope-from alan.bryan@yahoo.com) Received: from nm12-vm6.bullet.mail.ne1.yahoo.com (nm12-vm6.bullet.mail.ne1.yahoo.com [98.138.91.105]) by mx1.freebsd.org (Postfix) with SMTP id B0F488FC0A for ; Wed, 6 Jun 2012 21:35:13 +0000 (UTC) Received: from [98.138.90.54] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2012 21:35:13 -0000 Received: from [98.138.89.198] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2012 21:35:13 -0000 Received: from [127.0.0.1] by omp1056.mail.ne1.yahoo.com with NNFMP; 06 Jun 2012 21:35:12 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 904014.68340.bm@omp1056.mail.ne1.yahoo.com Received: (qmail 93920 invoked by uid 60001); 6 Jun 2012 21:35:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339018511; bh=R9OyKu7bOF3S/U5lb2ihlPDNp+fIFCPdEPgmwTsqR1c=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=qaSKaoucTAOufbt1L36OT4R28NInDfmcxbjYgsmt/LBhas4YtvS8HtemdTEYPSr4dvw34tEAuKH8OXdUNlvyT0bFCkuT4OTL4kuQTLj0OKqrq7nqDzZY1pb2NS0Xe7mKsi4+NnfX6xM/J5CT9WmrA4snHE2TmRIu3U6ffgAV2Sc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=xqCR59fHHj2dI+vX7ODVXQOwkOMa+GhENzzvnEB9dbRJ5nqG0z8FhMTgKaAJ6BgRzF+qyFBL17v8xA0SnfuUOMaPyjML5TsKZwpH8Tp/DXhhysyJ8ztqiBQL+dWYE3LnFlESVJwKmCqiwLRGYxZcEbtNvwkp0GPkzJiL6jyU4nE=; X-YMail-OSG: w9gnw3QVM1mNerUFn58vmLtK.ZhGJBTNSNHUGd0PGXUFbUR ko9QWzd.A1PhgWJlXVZDHCqEHJjDefkH65YhCYCqG6HSDqr5pgkAt3B1OP6Q 0dTmUQUGf_vWyK3tGzvq6GxwLWWWNGNZ0elvzUYKlvi3F5KcRgPBIhdWtfis KgmMAIL_qHVF98esRy7Exf8e2G6Qqo62XvorY8p2b1LnO77JLXkVRfOpgO5G RtwYyyTNwDW9quvV8xQ3vsasiBikGlX4pKMf2PNYXC9SHfYawJy5cFaTR9JN m_bwH0IkRcg_NCA_adqo1NmOc22rDOfqk13hUY0nIoXK6avxObdnd5UVljkN 1Hg.A3Uu.ivadtEcYZGJwqxn8wkOpx207xz_6QOKSdM_6UPxgoDY.7S.HWKJ f57nT06NlwJJde1H5IxUHzlT4uqj.2w5kCeptON_gXK68g3FDkdXdWIT3u5v lvuQgkRwwDARyR6oOsiT3A8Et Received: from [108.95.48.113] by web130101.mail.mud.yahoo.com via HTTP; Wed, 06 Jun 2012 14:35:11 PDT X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1339018511.22423.YahooMailNeo@web130101.mail.mud.yahoo.com> Date: Wed, 6 Jun 2012 14:35:11 -0700 (PDT) From: alan bryan To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Slow transfers at higher latencies with high BW - RFC 1323 related? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alan bryan List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:35:14 -0000 (also posted to FreeBSD forums) I think I may be having an issue with window scaling (RFC 1323) and am hoping that someone can enlighten me on what's going on. Server: FreeBSD 9, apache22, serving a static 100MB zip file. 192.168.18.30 Client: Mac OS X 10.6, Firefox 192.168.17.47 Network: Only a switch between them - the subnet is 192.168.16/22 Questions: #1: Does this look normal? #2: Is packet #2 specifying a window size of 65535 and a scale of 512? #3: Is packet #5 then shrinking the window size so it can use the 512 scale and still keep the overall calculated window size near 64K? #4: Why is the scale so high? Here's the first 6 packets from wireshark. For packets 5 & 6 I've included the details showing the window size and scaling factor being used for the data transfer. No. Time Source Destination Protocol Length Info 108 6.699922 192.168.17.47 192.168.18.30 TCP 78 49190 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=945617489 TSecr=0 SACK_PERM=1 115 6.781971 192.168.18.30 192.168.17.47 TCP 74 http > 49190 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=512 SACK_PERM=1 TSval=2617517338 TSecr=945617489 116 6.782218 192.168.17.47 192.168.18.30 TCP 66 49190 > http [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSval=945617490 TSecr=2617517338 117 6.782220 192.168.17.47 192.168.18.30 HTTP 490 GET /utils/speedtest/large.file.zip HTTP/1.1 118 6.867070 192.168.18.30 192.168.17.47 TCP 375 [TCP segment of a reassembled PDU] Details: Transmission Control Protocol, Src Port: http (80), Dst Port: 49190 (49190), Seq: 1, Ack: 425, Len: 309 Source port: http (80) Destination port: 49190 (49190) [Stream index: 4] Sequence number: 1 (relative sequence number) [Next sequence number: 310 (relative sequence number)] Acknowledgement number: 425 (relative ack number) Header length: 32 bytes Flags: 0x018 (PSH, ACK) Window size value: 130 [Calculated window size: 66560] [Window size scaling factor: 512] Checksum: 0xd182 [validation disabled] Options: (12 bytes) No-Operation (NOP) No-Operation (NOP) Timestamps: TSval 2617517423, TSecr 945617490 [SEQ/ACK analysis] TCP segment data (309 bytes) 119 6.867131 192.168.18.30 192.168.17.47 TCP 1514 [TCP segment of a reassembled PDU] Details: Transmission Control Protocol, Src Port: http (80), Dst Port: 49190 (49190), Seq: 310, Ack: 425, Len: 1448 Source port: http (80) Destination port: 49190 (49190) [Stream index: 4] Sequence number: 310 (relative sequence number) [Next sequence number: 1758 (relative sequence number)] Acknowledgement number: 425 (relative ack number) Header length: 32 bytes Flags: 0x010 (ACK) Window size value: 130 [Calculated window size: 66560] [Window size scaling factor: 512] Checksum: 0xe5cf [validation disabled] Options: (12 bytes) No-Operation (NOP) No-Operation (NOP) Timestamps: TSval 2617517423, TSecr 945617490 [SEQ/ACK analysis] TCP segment data (1448 bytes) From owner-freebsd-net@FreeBSD.ORG Wed Jun 6 22:18:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A09C4106567A for ; Wed, 6 Jun 2012 22:18:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8328FC19 for ; Wed, 6 Jun 2012 22:18:08 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so140379pbb.13 for ; Wed, 06 Jun 2012 15:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eaS9BN6+AoNW6xR1OMFWzU8TevaRZXk2cA7UBTVQgUs=; b=tWZDkD57op7p4Cxk4+z68ypRe1OV8zOzKMeB9308RCJiDi7+5oB1AKthb5fv7yZJ1c 5Ebevj0obfI/fjtVvbVKow1z4xM/YKM96mRPzzOeBaqFn3LS3Hcb71yLfc5Q4NUDD4I0 Jqf7EHRGhpyUVQ6LTg5wYiW2eQOVGBcZj7J+iCo3movH289PaZAyCBSKc7dlm9swFPOO /kt1q5AgOAo2NMDO7kyQTkHScdd7/dh95vIxtjpaRt/5fvRx5980sLvyPF13y2wKx9KX VjfZ6XhXgeZTU4aDa/SN3lMtntWL8gzeLj5Td9zH8YIPXWKOTXek2W7Ton4AG6cGsLgc QqlQ== MIME-Version: 1.0 Received: by 10.68.129.167 with SMTP id nx7mr704980pbb.80.1339021088028; Wed, 06 Jun 2012 15:18:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Wed, 6 Jun 2012 15:18:07 -0700 (PDT) In-Reply-To: <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> Date: Wed, 6 Jun 2012 15:18:07 -0700 X-Google-Sender-Auth: gyJzSFZsjmVKA8Y3IEEXvJ0GYec Message-ID: From: Adrian Chadd To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 06 Jun 2012 22:18:08 -0000 *nod* sure, I just want to be sure that it's clearly documented what the option does. If it just does UDP for now and not TCP, then so be it, as long as it's documented that way. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 02:28:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08F89106564A; Thu, 7 Jun 2012 02:28:39 +0000 (UTC) (envelope-from prvs=498c8bf01=daved@tamu.edu) Received: from os-mail-3.tamu.edu (os-mail-3.tamu.edu [165.91.23.217]) by mx1.freebsd.org (Postfix) with ESMTP id BF7EF8FC0C; Thu, 7 Jun 2012 02:28:38 +0000 (UTC) X-TAMU-Auth-ID: daved X-TAMU-SenderIP: 71.113.249.248 X-HAT: SG None, P $RELAY, L incoming_auth X-SRBS: None X-EXTLoop1: 71.113.249.248 X-IronPort-AV: E=Sophos;i="4.75,727,1330927200"; d="p7s'?scan'208";a="296793834" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_F81E394A-94A1-4AC0-882F-18FE80AD4BA3"; protocol="application/pkcs7-signature"; micalg=sha1 From: David Duchscher In-Reply-To: <4FCE6C29.3070903@freebsd.org> Date: Wed, 6 Jun 2012 21:27:27 -0500 Message-Id: References: <4FCE6C29.3070903@freebsd.org> To: darrenr@freebsd.org X-Mailer: Apple Mail (2.1278) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, hgcheng@berkeley.edu Subject: Re: NAT with Port-block Allocation 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, 07 Jun 2012 02:28:39 -0000 --Apple-Mail=_F81E394A-94A1-4AC0-882F-18FE80AD4BA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 5, 2012, at 3:29 PM, Darren Reed wrote: > In IPFilter, the "map-block" ipnat rule serves exactly the > purpose that you are looking for. It provides address > translation of network addresses for N:M and uses ports > to multiplex them in. >=20 > Thus a /16 can be nat'd to a /8 with the other 8 bits > used in the port number. >=20 > The results of the NAT'd packets are such that if you are > given an external IP address and port number, you can > calculate which internal IP address was used without having > to know what was the currently active state of the machine. >=20 > A typical rule might look like this: > map-block le0 10.0.0.0/16 -> 203.1.1.0/24 ports auto Darren, This is very interesting. We currently use PF to NAT our wireless = network and we too would like to reduce the logging load. We currently = run around 40-50k state entries per box (4 systems). We are planning on = adding 4 more systems in the next month so we have more room and better = handling of failures. Researching ipnat, I see that modifications to = the ipnat.h header might be needed for it to handle our load. We = currently have 31 vlans with /22 network assigned to the system. Do you = feel ipnat can handle this load? Do you have any recommendations for = the various values? Thanks for your time and help, -- DaveD --Apple-Mail=_F81E394A-94A1-4AC0-882F-18FE80AD4BA3-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 06:53:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D55701065675 for ; Thu, 7 Jun 2012 06:53:43 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9B78FC0A for ; Thu, 7 Jun 2012 06:53:43 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 763A520EBB; Thu, 7 Jun 2012 02:53:37 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 07 Jun 2012 02:53:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=mN+kEYzVCh49YTLJSkSy/M Zv5S8=; b=aWKZnvvmXeer3Ho+juh/uACv0DXjDaWDr2z8YnX2BCSV5CzGywabbW 8FufDr17aUSNJ4vG+8UB9DGSBfkR6dvUA3eM5UCx8Oak/WwTJzFsxzaFZ5b8JGBN F981DB0NIA6SZxIJgljMvpiTM3bO5sshVVs5xbmXz8yPvaN0yLUwE= X-Sasl-enc: yCoF2Tb5wBlnOjc4RB39/HHJsvo48433QN2jwWTaghig 1339052016 Received: from [192.168.1.23] (unknown [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPA id 2016A4836D5; Thu, 7 Jun 2012 02:53:35 -0400 (EDT) Message-ID: <4FD05E29.6010303@freebsd.org> Date: Thu, 07 Jun 2012 17:54:17 +1000 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: David Duchscher References: <4FCE6C29.3070903@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, hbcheng@berkeley.edu Subject: Re: NAT with Port-block Allocation 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, 07 Jun 2012 06:53:43 -0000 David Duchscher wrote: > On Jun 5, 2012, at 3:29 PM, Darren Reed wrote: > >> In IPFilter, the "map-block" ipnat rule serves exactly the >> purpose that you are looking for. It provides address >> translation of network addresses for N:M and uses ports >> to multiplex them in. >> >> Thus a /16 can be nat'd to a /8 with the other 8 bits >> used in the port number. >> >> The results of the NAT'd packets are such that if you are >> given an external IP address and port number, you can >> calculate which internal IP address was used without having >> to know what was the currently active state of the machine. >> >> A typical rule might look like this: >> map-block le0 10.0.0.0/16 -> 203.1.1.0/24 ports auto > > > Darren, > > This is very interesting. We currently use PF to NAT our wireless network and we too would like to reduce the logging load. We currently run around 40-50k state entries per box (4 systems). We are planning on adding 4 more systems in the next month so we have more room and better handling of failures. Researching ipnat, I see that modifications to the ipnat.h header might be needed for it to handle our load. We currently have 31 vlans with /22 network assigned to the system. Do you feel ipnat can handle this load? Do you have any recommendations for the various values? The above rule was designed and used to support NAT'ing of hundreds of networks (if not several thousand) on a couple of NAT boxes where the load was about double that you're seeing over 10 years ago with FreeBSD, so I don't think that there will too much trouble with your load today. The constants that you need to tune are: NAT_TABLE_MAX NAT_TABLE_SZ HOSTMAP_SIZE in /usr/src/sys/contrib/ipfilter/netinet/ip_nat.h HOSTMAP_SIZE should be 1.3 * the number of hosts to be NAT'd NAT_TABLE_MAX should be whatever you are setting your pf size to NAT_TABLE_SZ should be a prime number > 1.3 * NAT_TABLE_MAX On another operating system, there are systems using ipfilter today that track over 1 million current NAT sessions, so I don't think the load will be too much of a problem. Darren From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 07:08:51 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DE5F106564A; Thu, 7 Jun 2012 07:08:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 88A478FC17; Thu, 7 Jun 2012 07:08:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA15979; Thu, 07 Jun 2012 10:08:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ScWpr-000CTf-Qv; Thu, 07 Jun 2012 10:08:48 +0300 Message-ID: <4FD0537C.7070802@FreeBSD.org> Date: Thu, 07 Jun 2012 10:08:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Emanuel Haupt , freebsd-net@FreeBSD.org X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: 'ifconfig tun0 destroy' gets stuck 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, 07 Jun 2012 07:08:51 -0000 I experience a problem where vpnc can not exit cleanly and gets stuck. pstree shows this chain: |-+= 31375 root vpnc | \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom | \--- 13446 root ifconfig tun0 destroy $ procstat -k 13446 PID TID COMM TDNAME KSTACK 13446 102739 ifconfig - mi_switch sleepq_switch sleepq_wait _cv_wait_unlock tun_destroy tun_clone_destroy ifc_simple_destroy if_clone_destroyif if_clone_destroy ifioctl soo_ioctl kern_ioctl sys_ioctl amd64_syscall Xfast_syscall My system is FreeBSD 10.0-CURRENT amd64 r236503. I think that this started happening recently but I am not sure exactly when. Maybe after recent vpnc-scripts update or maybe after base system + kernel update. Any help/hint is very welcome. Thank you! -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 07:27:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D1A5106566B for ; Thu, 7 Jun 2012 07:27:17 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id B09B78FC1D for ; Thu, 7 Jun 2012 07:27:16 +0000 (UTC) Received: from [192.168.1.103] (p508FB23B.dip.t-dialin.net [80.143.178.59]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 762111C0C0BCA; Thu, 7 Jun 2012 09:27:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4FCFABBE.7030008@redfish-solutions.com> Date: Thu, 7 Jun 2012 09:27:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <445BCDCA-5750-4E12-A3BB-B5CAFD9569D4@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> <4FCFABBE.7030008@redfish-solutions.com> To: Philip Prindeville X-Mailer: Apple Mail (2.1278) Cc: freebsd-net@freebsd.org Subject: Re: IP_RECVTOS 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, 07 Jun 2012 07:27:17 -0000 On Jun 6, 2012, at 9:13 PM, Philip Prindeville wrote: > On 6/6/12 11:54 AM, Michael Tuexen wrote: >> On Jun 6, 2012, at 7:17 PM, Adrian Chadd wrote: >>=20 >>> Hi, >>>=20 >>> For TCP, I've seen the network layer change things (eg setting bits = on >>> incoming traffic to mark which interface it came in on), so you = can't >>> guarantee the outbound ToS =3D=3D inbound ToS. >> I've not said that inbound =3D=3D outbound... I just wanted to make = clear >> that there is a socket option of setting the TOS byte for outgoing >> traffic. The TCP stack might overwrite the ECN bits... >>=20 >> I need the IP_RECVTOS functionality for implementing a transport = stack supporting >> ECN in userland, actually running the SCTP kernel sources (with some = glue code) >> in userland on top of UDP... >>=20 >> Best regards >> Michael >=20 > What about UDT? Can you patch that as well? The UDT implementation can use IP_RECVTOS option, however I don't have = the time to look into this for the UDT implementation. Best regards Michael >=20 > For certain services (like backups or AFP), it might be useful for a = server to be able to detect a QoS-friendly client and reciprocate in = kind. >=20 > -Philip > _______________________________________________ > 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" >=20 From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 07:29:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C06E1065672; Thu, 7 Jun 2012 07:29:44 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 3701A8FC19; Thu, 7 Jun 2012 07:29:44 +0000 (UTC) Received: from [192.168.1.103] (p508FB23B.dip.t-dialin.net [80.143.178.59]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 608CA1C0C0BEA; Thu, 7 Jun 2012 09:29:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Thu, 7 Jun 2012 09:29:42 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9549EDB1-CE54-474E-9CDF-5A218B45AAA7@lurchi.franken.de> References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1278) Cc: "freebsd-net@freebsd.org mailing list" Subject: Re: IP_RECVTOS 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, 07 Jun 2012 07:29:44 -0000 On Jun 7, 2012, at 12:18 AM, Adrian Chadd wrote: > *nod* sure, I just want to be sure that it's clearly documented what > the option does. > > If it just does UDP for now and not TCP, then so be it, as long as > it's documented that way. I think the suggested modification to the man page of IP, which I sent earlier to list, makes this clear. Best regards Michael > > > > Adrian > From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 07:30:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 510F41065676 for ; Thu, 7 Jun 2012 07:30:14 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2A78FC18 for ; Thu, 7 Jun 2012 07:30:14 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so691708pbb.13 for ; Thu, 07 Jun 2012 00:30:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=klrZsZGgjEkCNHK8ujwc2T+jo6ufY7Ml6YqK+Acfk+s=; b=HVkMSunrwWQJSs9TgSc8Q3kJKZmc993LRMJsnaoUWWxkALYSi8nIBKuX2mTzMQ4S9M 3apMHs/ImwN8Fg/8ngVbgYU+Rz2mBfBL8mqkAPY4muncdbjmzwQn/0Nr/JTKxKuZSSiY okGwzV4ZubhhLocYLMAVtuyAZGwhkHtj2K5EWro5V0ABfygfKw/dcUCImYOzGzH1Z1LK N0JrW7LMTq6p+QHitWTB8RycDJeAyZPhelGpWeQQtx+2JpOZps+hKqmG9DUrooDH8Vbr Gpuwfvd9ABmE/YDLLXPTPUgiARhDzy3dHIAAkiWdETFq96TYcIv+0tuNaDPRw+y+Svpp jatA== MIME-Version: 1.0 Received: by 10.68.200.197 with SMTP id ju5mr6956886pbc.19.1339054213590; Thu, 07 Jun 2012 00:30:13 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.73.161 with HTTP; Thu, 7 Jun 2012 00:30:13 -0700 (PDT) In-Reply-To: <4FD0537C.7070802@FreeBSD.org> References: <4FD0537C.7070802@FreeBSD.org> Date: Thu, 7 Jun 2012 19:30:13 +1200 X-Google-Sender-Auth: 6brZDHXFsb-Lq2oPLwvmK1jW-kg Message-ID: From: Andrew Thompson To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlSDCuwT0HId7znMWb5IK/jKci4FTS7R9Wx1l+vDlcO9w7BQkMIHRFkc4f8XcRxBhcebhZJ Cc: freebsd-net@freebsd.org, Emanuel Haupt Subject: Re: 'ifconfig tun0 destroy' gets stuck 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, 07 Jun 2012 07:30:14 -0000 On 7 June 2012 19:08, Andriy Gapon wrote: > > I experience a problem where vpnc can not exit cleanly and gets stuck. > pstree shows this chain: > =A0|-+=3D 31375 root vpnc > =A0| \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom > =A0| =A0 \--- 13446 root ifconfig tun0 destroy > > $ procstat -k 13446 > =A0PID =A0 =A0TID COMM =A0 =A0 =A0 =A0 =A0 =A0 TDNAME =A0 =A0 =A0 =A0 =A0= KSTACK > 13446 102739 ifconfig =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mi= _switch sleepq_switch > sleepq_wait _cv_wait_unlock tun_destroy tun_clone_destroy ifc_simple_dest= roy > if_clone_destroyif if_clone_destroy ifioctl soo_ioctl kern_ioctl sys_ioct= l > amd64_syscall Xfast_syscall > > My system is FreeBSD 10.0-CURRENT amd64 r236503. > > I think that this started happening recently but I am not sure exactly wh= en. > Maybe after recent vpnc-scripts update or maybe after base system + kerne= l update. This means the tun device is still open, this behavior hasn't changed in 3.5 years. http://svnweb.freebsd.org/base?view=3Drevision&revision=3D186391 Andrew From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 07:32:10 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 785551065676; Thu, 7 Jun 2012 07:32:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9560F8FC1A; Thu, 7 Jun 2012 07:32:09 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA16212; Thu, 07 Jun 2012 10:32:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ScXCR-000CUq-Qa; Thu, 07 Jun 2012 10:32:07 +0300 Message-ID: <4FD058F6.1000206@FreeBSD.org> Date: Thu, 07 Jun 2012 10:32:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Emanuel Haupt , freebsd-net@FreeBSD.org References: <4FD0537C.7070802@FreeBSD.org> In-Reply-To: <4FD0537C.7070802@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: 'ifconfig tun0 destroy' gets stuck 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, 07 Jun 2012 07:32:10 -0000 on 07/06/2012 10:08 Andriy Gapon said the following: > > I experience a problem where vpnc can not exit cleanly and gets stuck. > pstree shows this chain: > |-+= 31375 root vpnc > | \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom > | \--- 13446 root ifconfig tun0 destroy > > $ procstat -k 13446 > PID TID COMM TDNAME KSTACK > 13446 102739 ifconfig - mi_switch sleepq_switch > sleepq_wait _cv_wait_unlock tun_destroy tun_clone_destroy ifc_simple_destroy > if_clone_destroyif if_clone_destroy ifioctl soo_ioctl kern_ioctl sys_ioctl > amd64_syscall Xfast_syscall > > My system is FreeBSD 10.0-CURRENT amd64 r236503. > > I think that this started happening recently but I am not sure exactly when. > Maybe after recent vpnc-scripts update or maybe after base system + kernel update. Few minutes later... :-) It seems that tun_destroy waits until a tun device is closed, but vpnc does things in the opposite order: it first executes vpnc-script which does ifconfig destroy and only then closes the tun fd. Changing the order in close_tunnel() seems to help, but I am not sure if this is correct. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 07:52:08 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4E171065676; Thu, 7 Jun 2012 07:52:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ADF6B8FC14; Thu, 7 Jun 2012 07:52:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA16409; Thu, 07 Jun 2012 10:52:06 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ScXVl-000CW0-Mj; Thu, 07 Jun 2012 10:52:05 +0300 Message-ID: <4FD05DA5.8030008@FreeBSD.org> Date: Thu, 07 Jun 2012 10:52:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Thompson References: <4FD0537C.7070802@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Emanuel Haupt Subject: Re: 'ifconfig tun0 destroy' gets stuck 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, 07 Jun 2012 07:52:08 -0000 on 07/06/2012 10:30 Andrew Thompson said the following: > On 7 June 2012 19:08, Andriy Gapon wrote: >> >> I experience a problem where vpnc can not exit cleanly and gets stuck. >> pstree shows this chain: >> |-+= 31375 root vpnc >> | \-+- 13412 root /bin/sh /usr/local/sbin/vpnc-script-custom >> | \--- 13446 root ifconfig tun0 destroy >> >> $ procstat -k 13446 >> PID TID COMM TDNAME KSTACK >> 13446 102739 ifconfig - mi_switch sleepq_switch >> sleepq_wait _cv_wait_unlock tun_destroy tun_clone_destroy ifc_simple_destroy >> if_clone_destroyif if_clone_destroy ifioctl soo_ioctl kern_ioctl sys_ioctl >> amd64_syscall Xfast_syscall >> >> My system is FreeBSD 10.0-CURRENT amd64 r236503. >> >> I think that this started happening recently but I am not sure exactly when. >> Maybe after recent vpnc-scripts update or maybe after base system + kernel update. > > This means the tun device is still open, this behavior hasn't changed > in 3.5 years. > > http://svnweb.freebsd.org/base?view=revision&revision=186391 Thank you for this pointer. So I guess that vpnc-script just didn't do ifconfig destroy before... -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 12:42:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F691065674 for ; Thu, 7 Jun 2012 12:42:04 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F75B8FC24 for ; Thu, 7 Jun 2012 12:42:03 +0000 (UTC) Received: by werg1 with SMTP id g1so421375wer.13 for ; Thu, 07 Jun 2012 05:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=dyDeod0QeF3JnHeTky7kXQEy19UrVcJgBRV6gt+p3Yc=; b=gpog7BGqXtUnx1p10VUoIxIaWxgvl2NvYKCvqzRiP8xhICulKCg3ju7SFFhK9AApVz fYMErTrwe5TKFP9EHqYb/eJxoRd0Og6b7dygQFmLvcAyESLdIPeWYqbL+aeSLs25Pqxn JDtoTQaI5heyluOr/xaJ2ck8agNIlRM6zzanNWM3NiORIAhE2nc0dlDf5b3Ncp3pujrT P2x0YoI6Ca9YFvRfEz37COiCz9BWiD0mIfk8w/reXXEjwc6QibDxJI2zd47UMKd0JWHp 9JfuFpnzukl3Jww973gozchW2PifAZHzFryHHXfz1fj/792KxZEqOt7s51YbhETWoNL1 CxgA== Received: by 10.216.202.14 with SMTP id c14mr842096weo.63.1339072922956; Thu, 07 Jun 2012 05:42:02 -0700 (PDT) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id q6sm7142439wiy.0.2012.06.07.05.42.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jun 2012 05:42:01 -0700 (PDT) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2012 15:41:59 +0300 To: freebsd-net Message-Id: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: FreeBSD 8.2-STABLE sending FIN no ACK packets. 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, 07 Jun 2012 12:42:04 -0000 Hello, I've been pointed out by our partner that we are sending TCP packets = with FIN flag and no ACK set, which is triggering alerts on their firewalls. I've investigated, and it appears that some of our FreeBSD hosts are = really sending such packets. (they are running some java applications) I did "tcpdump -s0 -vni em1 '(tcp[tcpflags] & tcp-ack =3D=3D 0) && = (tcp[tcpflags] & tcp-fin !=3D 0)'" to catch them. Is this considered normal? It seems at least Juniper considers this malicious traffic : = http://www.juniper.net/techpubs/software/junos-security/junos-security10.0= /junos-security-swconfig-security/id-72577.html From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 15:00:44 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 75772106566C; Thu, 7 Jun 2012 15:00:44 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 8E3CC1A6C5A; Thu, 7 Jun 2012 15:00:07 +0000 (UTC) Message-ID: <4FD0C1F4.2060108@FreeBSD.org> Date: Thu, 07 Jun 2012 19:00:04 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: net@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: ifconfig accepting hostname as ipv4 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:00:44 -0000 Hello list! Since the early days ifconfig(8) has the following functionality: .. address For the DARPA-Internet family, the address is either a host name present in the host name data base, hosts(5), or a DARPA Internet address expressed in the Internet standard ⌠dot notation■. E.g. one can write `ifconfig em0 some_possibly_unqualified_fqdn` and get inet address assigned to the card with classful mask. Now this can lead to "fun" things if you have misprinted some keyword and this keyword exists in the local DNS zone (or wildcard is configured). The most favorite one (we have wilcard configured in one of our search zones): 18:45 [0] dhcp170-36-red# ifconfig vlan123 desroy 18:45 [0] dhcp170-36-red# echo $? 0 18:45 [0] dhcp170-36-red# ifconfig vlan123 vlan123: flags=8003 metric 0 mtu 1500 ether 00:00:00:00:00:00 inet 213.180.204.242 netmask 0xffffff00 broadcast 213.180.204.255 inet6 fe80::222:4dff:fe50:cd2f%vlan123 prefixlen 64 scopeid 0xd nd6 options=21 vlan: 0 parent interface: This is also one of the reasons why ifconfig sometimes "hangs" on invalid input. Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you can't set valid CIDR address using this notation. Classful era has ended more than 10 years ago, do we still want to keep this behavior? -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 18:24:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9AABF1065672 for ; Thu, 7 Jun 2012 18:24:45 +0000 (UTC) (envelope-from philipp_subx@redfish-solutions.com) Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [66.232.79.143]) by mx1.freebsd.org (Postfix) with ESMTP id 692D58FC21 for ; Thu, 7 Jun 2012 18:24:45 +0000 (UTC) Received: from macbook.redfish-solutions.com ([192.168.1.17]) (authenticated bits=0) by mail.redfish-solutions.com (8.14.5/8.14.5) with ESMTP id q57IOiBj008397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 7 Jun 2012 12:24:44 -0600 Message-ID: <4FD0F1EC.4060109@redfish-solutions.com> Date: Thu, 07 Jun 2012 12:24:44 -0600 From: Philip Prindeville User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.1.3 Subject: Re: IP_RECVTOS 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, 07 Jun 2012 18:24:45 -0000 It might be nice to add a semantic that says, "when accepting connections, match their TOS"... possibly adding ranges of permitted TOS values. On 6/6/12 4:18 PM, Adrian Chadd wrote: > *nod* sure, I just want to be sure that it's clearly documented what > the option does. > > If it just does UDP for now and not TCP, then so be it, as long as > it's documented that way. > > > > Adrian From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 20:09:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A2BE106566C for ; Thu, 7 Jun 2012 20:09:18 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 2D17E8FC0A for ; Thu, 7 Jun 2012 20:09:18 +0000 (UTC) Received: from [192.168.1.103] (p508FB23B.dip.t-dialin.net [80.143.178.59]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 983791C0C0BEA; Thu, 7 Jun 2012 22:09:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4FD0F1EC.4060109@redfish-solutions.com> Date: Thu, 7 Jun 2012 22:09:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D03F00E-2777-4B0B-8E1C-860EA115B6AF@lurchi.franken.de> <7731AEE8-D1BF-4297-8F75-454149D3E303@lurchi.franken.de> <5A4A73CF-95FB-4B33-9652-2E4FD517CF5F@lurchi.franken.de> <5399FCC6-BDC4-47DD-9948-ADD16264EE46@lurchi.franken.de> <8D7E9322-0973-4657-B3FE-8A480C0E0304@lurchi.franken.de> <4FD0F1EC.4060109@redfish-solutions.com> To: Philip Prindeville X-Mailer: Apple Mail (2.1278) Cc: freebsd-net@freebsd.org Subject: Re: IP_RECVTOS 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, 07 Jun 2012 20:09:18 -0000 On Jun 7, 2012, at 8:24 PM, Philip Prindeville wrote: > It might be nice to add a semantic that says, "when accepting = connections, match their TOS"... possibly adding ranges of permitted TOS = values. ... I would leave the matching to the application. However, the suggested patch only supports UDP sockets. Best regards Michael >=20 >=20 > On 6/6/12 4:18 PM, Adrian Chadd wrote: >> *nod* sure, I just want to be sure that it's clearly documented what >> the option does. >>=20 >> If it just does UDP for now and not TCP, then so be it, as long as >> it's documented that way. >>=20 >>=20 >>=20 >> Adrian > _______________________________________________ > 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" >=20 From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 20:28:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE9CF106566C; Thu, 7 Jun 2012 20:28:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE448FC18; Thu, 7 Jun 2012 20:28:40 +0000 (UTC) Received: from [209.249.190.124] (port=63932 helo=[10.2.212.229]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1ScjJu-0000ui-A1; Thu, 07 Jun 2012 16:28:38 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: Date: Thu, 7 Jun 2012 16:28:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Navdeep Parhar X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: freebsd-net@freebsd.org Subject: Re: seq# of RST in tcp_dropwithreset 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, 07 Jun 2012 20:28:40 -0000 On Mar 27, 2012, at 18:13 , Navdeep Parhar wrote: > When the kernel decides to respond with a RST to an incoming TCP > segment, it uses its ack# (if valid) as the seq# of the RST. See this > in tcp_dropwithreset: >=20 > if (th->th_flags & TH_ACK) { > tcp_respond(tp, mtod(m, void *), th, m, (tcp_seq)0, > th->th_ack, TH_RST); > } else { > if (th->th_flags & TH_SYN) > tlen++; > tcp_respond(tp, mtod(m, void *), th, m, th->th_seq+tlen, > (tcp_seq)0, TH_RST|TH_ACK); > } >=20 > This can have some unexpected results. I observed this on a link with > a very high delay (B is FreeBSD, A could be anything). >=20 > 1. There is a segment in flight from A to B. The ack# is X (all tx > from B to A is up to date and acknowledged). > 2. socket is closed on B. B sends a FIN with seq# X. > 3. The segment from A arrives and elicits a RST from B. The seq# of > this RST will again be X. A receives the FIN and then the RST with > identical sequence numbers. The situation resolves itself eventually, > when A retransmits and the retransmitted segment ACKs the FIN too and > so the next time around B sends a RST with the "correct" seq# (one > after the FIN). >=20 > If there is a local tcpcb for the connection with state >=3D > ESTABLISHED, wouldn't it be more accurate to use its snd_max as the > seq# of the RST? >=20 Hi Navdeep, Sorry I missed this so many months ago, but jhb@ was kind enough to = point this query out to me. My understanding of correct operation in this case, is = that we=20 do not want to move the sequence number until we have received the ACK = of our FIN, as any other value would indicate to the TCP on A that we have = received their ACK of our FIN, which, in this case, we have not. The fact that there = isn't a better way to indicate the error is a tad annoying, but, and others can correct = me if they think I'm wrong, this is the correct way for the stacks to come to eventual = agreement on the closing of the connection. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 01:30:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89108106566C for ; Fri, 8 Jun 2012 01:30:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB7E8FC0A for ; Fri, 8 Jun 2012 01:30:54 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so1971732pbb.13 for ; Thu, 07 Jun 2012 18:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=psYWll1/nuDasKIrBWbI99UyrTuFdMHULaXYNE3sgXA=; b=SiEPAMc0PVCoYWUhql3SIHKD3cRH7Fe+gebkwNaO4kmOLH0jlOwX2mQ3hlc+/D3I0/ oUgY2IPGTtCzj/wxPNpkWcB/KbBl80iMEst0Q7SKFcHARIsLjDg726CZRjKL21DpxlVH WubkqByS831cQbBIDU9SClOF0XCFlK8H77w7BsAIunr9Dyi9Of1x3p5vn5bRkiME5oEy zjqmAxUEkfa+UT/z5rwDLW7tHD7xvwnElrN5wr8NI2W4PZem6ho+RmkXR8KRYyGEx1W0 EOiMCpAvw0Uoy6GOZULgJnzqf3XdvvXYNdPsGcRxBqZsrejXegVb8XGEvzgPOEmP6U5J iM+g== MIME-Version: 1.0 Received: by 10.68.234.35 with SMTP id ub3mr15658195pbc.8.1339119054000; Thu, 07 Jun 2012 18:30:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Thu, 7 Jun 2012 18:30:53 -0700 (PDT) In-Reply-To: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> References: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> Date: Thu, 7 Jun 2012 18:30:53 -0700 X-Google-Sender-Auth: V1SPLn2hnWDbfqZtGOOCkIMToEw Message-ID: From: Adrian Chadd To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: FreeBSD 8.2-STABLE sending FIN no ACK packets. 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, 08 Jun 2012 01:30:54 -0000 On 7 June 2012 05:41, Nikolay Denev wrote: > Hello, > > I've been pointed out by our partner that we are sending TCP packets with FIN flag and no ACK set, which is triggering > alerts on their firewalls. > I've investigated, and it appears that some of our FreeBSD hosts are really sending such packets. (they are running some java applications) > I did "tcpdump -s0 -vni em1 '(tcp[tcpflags] & tcp-ack == 0) && (tcp[tcpflags] & tcp-fin != 0)'" to catch them. > > Is this considered normal? > It seems at least Juniper considers this malicious traffic : http://www.juniper.net/techpubs/software/junos-security/junos-security10.0/junos-security-swconfig-security/id-72577.html Would you please file a PR with this, so it doesn't get lost? Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 04:59:24 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 486931065677; Fri, 8 Jun 2012 04:59:24 +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 1C63C8FC1D; Fri, 8 Jun 2012 04:59:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q584xNas072315; Fri, 8 Jun 2012 04:59:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q584xN3D072311; Fri, 8 Jun 2012 04:59:23 GMT (envelope-from linimon) Date: Fri, 8 Jun 2012 04:59:23 GMT Message-Id: <201206080459.q584xN3D072311@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/168244: [arp] [regression] Unable to manually remove permanent ARP entries 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, 08 Jun 2012 04:59:24 -0000 Old Synopsis: [regression] Unable to manually remove permanent ARP entries New Synopsis: [arp] [regression] Unable to manually remove permanent ARP entries Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 8 04:59:01 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=168244 From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 05:00:07 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEA811065705; Fri, 8 Jun 2012 05:00:06 +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 6643E8FC12; Fri, 8 Jun 2012 05:00:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q58506jo072389; Fri, 8 Jun 2012 05:00:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q58506Ql072385; Fri, 8 Jun 2012 05:00:06 GMT (envelope-from linimon) Date: Fri, 8 Jun 2012 05:00:06 GMT Message-Id: <201206080500.q58506Ql072385@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/168245: [arp] [regression] Permanent ARP entry not deleted on interface configuration failure 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, 08 Jun 2012 05:00:07 -0000 Old Synopsis: [regression] Permanent ARP entry not deleted on interface configuration failure New Synopsis: [arp] [regression] Permanent ARP entry not deleted on interface configuration failure Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 8 04:59:39 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=168245 From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 05:00:32 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 501D01065690; Fri, 8 Jun 2012 05:00:32 +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 23C858FC22; Fri, 8 Jun 2012 05:00:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5850WhD072539; Fri, 8 Jun 2012 05:00:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5850VXa072534; Fri, 8 Jun 2012 05:00:31 GMT (envelope-from linimon) Date: Fri, 8 Jun 2012 05:00:31 GMT Message-Id: <201206080500.q5850VXa072534@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/168246: [em] Multiple em(4) not working with qemu 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, 08 Jun 2012 05:00:32 -0000 Old Synopsis: Multiple em(4) not working with qemu New Synopsis: [em] Multiple em(4) not working with qemu Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 8 04:59:39 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=168246 From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 06:17:42 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBC9C1065676; Fri, 8 Jun 2012 06:17:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 83E5D8FC0C; Fri, 8 Jun 2012 06:17:39 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q586Hbfb028609; Fri, 8 Jun 2012 10:17:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q586HbGs028608; Fri, 8 Jun 2012 10:17:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 8 Jun 2012 10:17:37 +0400 From: Gleb Smirnoff To: pf@FreeBSD.org Message-ID: <20120608061737.GA28197@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: [CFT] SMP-friendly pf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pf@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 06:17:43 -0000 Hello, networkers! [net@ in Cc, but further discussion should go on pf@] As you already probably know, or some may be don't yet know, the pf(4) subsystem in FreeBSD is currently working under a single mutex. This mutex is acquired right at the beginning of any packet processing, and is dropped at the end. While one thread is in pf(4) all other threads are blocked on that mutex. Meanwhile modern computers are getting more and more cores, and modern network cards getting more MSI interrupts, each serviced by a separate kernel thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :), is getting a point of hard contention. Three and a half months ago I've started on a project "SMP-friendly pf", which recently have entered alpha stage. As you see from the subject of this mail, this is call for testing. Willing to test? The code lives in projects/pf/head branch in the SVN, and can be checked out with: svn checkout http://svn.freebsd.org/base/projects/pf/head pflock , where argument "pflock" is just directory name for checked out sources. Then you need to build world and kernel from that branch and install them. The branch projects/pf/head gets head merged to it quite often, so if you run head world with a revision equal (or at least close) to last merge, then you don't need to install world, however rebuilding pfctl and snmp_pf from that branch is necessary. If you are about to run this alpha pf on any important box, then you definitely need to establish safety measures: have a second box running stable/9 or head as carp(4) backup, ready to kick in, in case if new pf panics. pfsync(4) connection should also be established between new and backup boxes. pfsync(4) in the new code is wire compatible with stable/9 or head. I'm already running it on routers with 100k - 200k state entries, and forwarding 20k - 40k pps. If you are brave, you should try, too :) Good luck and report any problems to me! Interested in details? From the very beginning of the project it was clear, that code is going to diverge significantly from original OpenBSD code. OpenBSD has always developed pf without taking into account that code can ever get multithreaded, thus quite a lot needed to be changed. Thus, I've started with removing the "#ifdef __FreeBSD__" from the code, and later I didn't hesitate even a fraction of second if I wanted to toss some code. The pros is that now code is much more readable and understandible then in head, the cons is that diff between us and OpenBSD is huge, although amount of shared code is huge, too. So, later on only manual merging of features from OpenBSD is possible and bulk imports of entire pf into FreeBSD are no longer possible. The locking scheme is the following: - There is an rwlock(9) that protects rules and all kind of data that isn't modified by forwarding threads. Forwarding threads reader lock it, ioctl() and other reconfiguring events write lock it. - The states and key states storage had moved from RB-trees to hashes, with separate mutexes per hash slot. This should give us decent parallelism when forwarding packets. - Source nodes storage moved to hash with per-slot locking. - pfsync(4) got separate mutex. - fragment reassembly got separate mutex. Apart from the above key changes, many other optimisations and fixes done. The entire diff is 22k lines large. You can view the projects history here: http://svnweb.freebsd.org/base/projects/pf/head/?view=log (the beginning is on page 2 now, at r232042) I had tried to make informative commit messages. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 06:54:19 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 633281065670 for ; Fri, 8 Jun 2012 06:54:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1ACB78FC0A for ; Fri, 8 Jun 2012 06:54:19 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Sct5N-000EWI-G9 for net@freebsd.org; Fri, 08 Jun 2012 09:54:17 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jun 2012 09:54:17 +0300 From: Daniel Braniss Message-ID: Cc: Subject: recommended 10g cards 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, 08 Jun 2012 06:54:19 -0000 Hi I will be 'experimenting' with 10g in the next few months, so I need to buy some cards, After googling for some time, I noticed that there is not realy much real info, and some of it is a bit dated. Since these cards are pricy, could those that have such cards share some info? cheers, danny From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 07:14:08 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8F6106566B for ; Fri, 8 Jun 2012 07:14:08 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB7F08FC0C for ; Fri, 8 Jun 2012 07:14:07 +0000 (UTC) Received: by eaac13 with SMTP id c13so989403eaa.13 for ; Fri, 08 Jun 2012 00:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=WhOZT/SypBpQkJ7uv1UY63YFsMHCs7J431qTW2OFqNY=; b=EimgM0J8fTlvYk4LXZChfLcKAaRJFS38DUqebnRLMGKpUY242j7tQlf0tBSRSk8ibS TgnvlugSoDGZcWjHBUuhJ1CVDuxzSv6JQJrqGbgUqgV833jsGzsPkeFKNTvUm76OBPIf 0ARHltxASkrpfvHj6E7dKZGS+FAOILZC9RoCw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=WhOZT/SypBpQkJ7uv1UY63YFsMHCs7J431qTW2OFqNY=; b=RVpUcOp0Cdrqx4xFgKT9enhsTGf4FYlsIwcCd183SCgqI5BimAX5jxR7Bjl9HYfg9v KkwxCPnCH9LiDEBhKirzeyzs3Mo/C7Eot9SG32cTyEuWbNktSqpYeF1BS0XgLYL2EHZT NiJmyxW43xie42voNDuvayT9rCOJ7Ej7cTiLdM5YJFU44KoUYdl+KcaRJH+ca5TYYpm5 X1XAwYzKYH8Kf3i8BpJYnBuNMsZhaS0bFzUy66Y94lXxC+/RrF+UQ4WPewJImN4H6x6v 41pVmNfKwXsdR3mXCpkAbE8PUPjJJ+LEKrFtH7oc5L2vuwuRnwJuQV9NvGXjpfsJPo0f 3dIg== Received: by 10.14.29.4 with SMTP id h4mr2973582eea.178.1339139646611; Fri, 08 Jun 2012 00:14:06 -0700 (PDT) Received: from [192.168.10.2] ([82.76.253.74]) by mx.google.com with ESMTPS id gv7sm6415454wib.4.2012.06.08.00.14.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 00:14:05 -0700 (PDT) Date: Fri, 8 Jun 2012 08:14:01 +0100 From: Vlad Galu To: Daniel Braniss Message-ID: <4792CED73A804403ABD1227F9F055114@dudu.ro> In-Reply-To: References: X-Mailer: sparrow 1.6.1 (build 1081.52) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQl3T3qRuxSzcODdE3mDlyR4nZm/q6MHxwry9uZowk+hKxekW/b9BEVa7vYMj2zX7n4/ZOg5 Cc: net@freebsd.org Subject: Re: recommended 10g cards 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, 08 Jun 2012 07:14:08 -0000 On Friday, June 8, 2012 at 7:54 AM, Daniel Braniss wrote: > Hi > I will be 'experimenting' with 10g in the next few months, so > I need to buy some cards, > After googling for some time, I noticed that there is not realy much real > info, and some of it is a bit dated. > Since these cards are pricy, could those that have such cards share some info? > cheers, > danny > Hi Daniel, I have had excellent results with Myricom. Granted, I use their packet sniffing stack and not the standard driver, but I believe they have also made sure it scales just as well in more typical scenarios. Another serious contender to look at is Solarflare. But, as of Novemeber 2011, their FreeBSD driver has been in beta. Then you have the Intel 82599, which is probably the most widespread 10g card out there and has good software & community support. I think it was the first card supported by Luigi's netmap layer. It is probably best that you describe your workload a bit, I am sure you will get better advice then. -- Good, fast and cheap: pick any two. From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 07:21:00 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEDD81065670; Fri, 8 Jun 2012 07:21:00 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from mail.ru.ac.za (mail.ru.ac.za [IPv6:2001:4200:1010:0:250:56ff:fe8d:5]) by mx1.freebsd.org (Postfix) with ESMTP id C3B378FC0A; Fri, 8 Jun 2012 07:20:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ru.ac.za; s=ru-msa; h=X-Authenticated-User:Message-Id:Content-Type:MIME-Version:Date:Subject:To:From; bh=W+K1M+/rI/63bM9JFTjnK3V4xaSLxBtNSmrO9Vc66TQ=; b=XcOZgBHBVnHQLMmHg4AfUMXm2taz7HQRDgok7HuLAHx1OQsDcTyzlZ8+8SytKtkFr2l5ZyYjeRTfAeHlTrQpAbSjgTfBlypZWfPabFtq6wmHHHqHnTNwDUwJXDF+4ciJ; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:64085) by mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SctVB-000KH1-6I; Fri, 08 Jun 2012 09:20:57 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Fri, 8 Jun 2012 09:20:56 +0200 User-Agent: KMail/1.9.10 References: <4FD0C1F4.2060108@FreeBSD.org> In-Reply-To: <4FD0C1F4.2060108@FreeBSD.org> X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: mail.ru.ac.za (2001:4200:1010:0:250:56ff:fe8d:5) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Cc: "Alexander V. Chernikov" , net@freebsd.org Subject: Re: ifconfig accepting hostname as ipv4 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 07:21:00 -0000 On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote: > Hello list! > > Since the early days ifconfig(8) has the following functionality: [hostname in place of literal address] > Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you > can't set valid CIDR address using this notation. I'm not sure that's true. Have you tried it? Because it seems to work here. Jonathan From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 07:43:38 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5598106566C; Fri, 8 Jun 2012 07:43:38 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4DA4A8FC16; Fri, 8 Jun 2012 07:43:38 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SctrG-0005br-30; Fri, 08 Jun 2012 11:43:46 +0400 Message-ID: <4FD1AD1D.4050308@FreeBSD.org> Date: Fri, 08 Jun 2012 11:43:25 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Jonathan McKeown References: <4FD0C1F4.2060108@FreeBSD.org> <201206080920.56986.j.mckeown@ru.ac.za> In-Reply-To: <201206080920.56986.j.mckeown@ru.ac.za> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, net@freebsd.org Subject: Re: ifconfig accepting hostname as ipv4 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 07:43:38 -0000 On 08.06.2012 11:20, Jonathan McKeown wrote: > On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote: >> Hello list! >> >> Since the early days ifconfig(8) has the following functionality: > > [hostname in place of literal address] > >> Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you >> can't set valid CIDR address using this notation. > > I'm not sure that's true. Have you tried it? Because it seems to work here. Strangely enough, it works on another machine. Ok, this one works and can unfortunately be used by other people. However, original question remains. > > Jonathan > From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 08:21:11 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFD46106564A for ; Fri, 8 Jun 2012 08:21:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 633238FC12 for ; Fri, 8 Jun 2012 08:21:11 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1ScuRR-000GKL-Jj; Fri, 08 Jun 2012 11:21:09 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Vlad Galu In-reply-to: <4792CED73A804403ABD1227F9F055114@dudu.ro> References: <4792CED73A804403ABD1227F9F055114@dudu.ro> Comments: In-reply-to Vlad Galu message dated "Fri, 08 Jun 2012 08:14:01 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jun 2012 11:21:09 +0300 From: Daniel Braniss Message-ID: Cc: net@freebsd.org Subject: Re: recommended 10g cards 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, 08 Jun 2012 08:21:11 -0000 > > > On Friday, June 8, 2012 at 7:54 AM, Daniel Braniss wrote: > > > Hi > > I will be 'experimenting' with 10g in the next few months, so > > I need to buy some cards, > > After googling for some time, I noticed that there is not realy much real > > info, and some of it is a bit dated. > > Since these cards are pricy, could those that have such cards share some info? > > cheers, > > danny > > > Hi Daniel, > > I have had excellent results with Myricom. Granted, I use their packet sniffing stack and not the standard driver, but I believe they have also made sure it scales just as well in more typical scenarios. > > Another serious contender to look at is Solarflare. But, as of Novemeber 2011, their FreeBSD driver has been in beta. > > Then you have the Intel 82599, which is probably the most widespread 10g card out there and has good software & community support. I think it was the first card supported by Luigi's netmap layer. > > It is probably best that you describe your workload a bit, I am sure you will get better advice then. > This is too early to say :-), hence the word 'experimenting', but the excuse is that we are in the process of revamping our network infrastructure, which is currently base on an old Nortell Passport 8010 to an new HP 8200, and so far only switches will be linked via 10Ge, and one of our new filers. Our cpu clusters are linked via 1Ge, if and when we get new cpus, it would be nice to have gained some experience, thanks, danny > -- > Good, fast and cheap: pick any two. > > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 09:04:29 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66521106564A; Fri, 8 Jun 2012 09:04:29 +0000 (UTC) (envelope-from j.mckeown@ru.ac.za) Received: from mail.ru.ac.za (mail.ru.ac.za [IPv6:2001:4200:1010:0:250:56ff:fe8d:5]) by mx1.freebsd.org (Postfix) with ESMTP id 20BA68FC17; Fri, 8 Jun 2012 09:04:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ru.ac.za; s=ru-msa; h=X-Authenticated-User:Message-Id:Content-Type:MIME-Version:Date:Subject:To:From; bh=yTKndxVMfoM9Zn9bGD55SCM8l0ginloRz8/Y0GbDkZY=; b=DOaBrGpeqs20IFtmT5LaPKtS3B/wEw76QycGe7wTVGs395R4lm+xBrfO+B5Kkj9B/ixS/ixShvoscqFA4On3oXGVDSaZmUdMiXsR/bEaAzGL9Vl0RXbBqfLwwhy+Wk2H; Received: from vorkosigan.ru.ac.za ([2001:4200:1010:1058:219:d1ff:fe9f:a932]:58928) by mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Scv7J-0004Is-2O; Fri, 08 Jun 2012 11:04:25 +0200 From: Jonathan McKeown Organization: Rhodes University To: freebsd-hackers@freebsd.org Date: Fri, 8 Jun 2012 11:04:24 +0200 User-Agent: KMail/1.9.10 References: <4FD0C1F4.2060108@FreeBSD.org> <201206080920.56986.j.mckeown@ru.ac.za> <4FD1AD1D.4050308@FreeBSD.org> In-Reply-To: <4FD1AD1D.4050308@FreeBSD.org> X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Virus-Scanned: mail.ru.ac.za (2001:4200:1010:0:250:56ff:fe8d:5) X-Authenticated-User: s0900137 from vorkosigan.ru.ac.za (2001:4200:1010:1058:219:d1ff:fe9f:a932) using auth_plaintext Cc: "Alexander V. Chernikov" , net@freebsd.org Subject: Re: ifconfig accepting hostname as ipv4 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 09:04:29 -0000 On Friday 08 June 2012 09:43:25 Alexander V. Chernikov wrote: > On 08.06.2012 11:20, Jonathan McKeown wrote: > > On Thursday 07 June 2012 17:00:04 Alexander V. Chernikov wrote: > >> Hello list! > >> > >> Since the early days ifconfig(8) has the following functionality: > > > > [hostname in place of literal address] > > > >> Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you > >> can't set valid CIDR address using this notation. > > > > I'm not sure that's true. Have you tried it? Because it seems to work > > here. > > Strangely enough, it works on another machine. Ok, this one works and > can unfortunately be used by other people. > > However, original question remains. So your question is, do we want to keep the behaviour of being able to configure an interface by hostname as well as by IP address? My vote is yes. Sure, a typo in the parameters to ifconfig can cause problems under some circumstances. So can a typo in any command. I don't think that's a good enough reason to remove functionality you regard as ``unfortunate''. We find it useful, and a significant aid to maintainability and readability of configuration files. From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 10:39:45 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50BDF1065672; Fri, 8 Jun 2012 10:39:45 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E6FB38FC14; Fri, 8 Jun 2012 10:39:44 +0000 (UTC) Received: by ggnm2 with SMTP id m2so1300430ggn.13 for ; Fri, 08 Jun 2012 03:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UqWBRf8NXOxX6AQmXIwKZa64kdwGdY6Ti0JvKj/Rl+M=; b=L0PNZVN9+fNCeAgAAqepw5tIPsKDHwEE+4q/bg79ukggFLyfVUTfYCSBQai9MtHB84 RJO3kU3vy1avj/IKkYL+YGIFl+hzXRO88cFVx9LrzjAGfxb2tvn5MK27tYH3K60efbUl bOFWYJx7ew8UJxh+BeeIVtfs0MLjbnkrCBVJwWDo/CoylAtRGzHyqHrWGYzR42Oh58AC A4PHX2ZiEqSKoP9mHofppN49fiHM8lQahIy8Xx6uqyv8LX9ks13bEUEx+id+MJlEVXrb dUsxDnJwnAA0TTnFLTJsUaq7Cx7bEKPk47umE+nyRZG9tHEVFm7kLue5R0unumbZAUY6 ULWw== MIME-Version: 1.0 Received: by 10.50.51.132 with SMTP id k4mr2659461igo.17.1339151984072; Fri, 08 Jun 2012 03:39:44 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.35.202 with HTTP; Fri, 8 Jun 2012 03:39:43 -0700 (PDT) In-Reply-To: <20120608061737.GA28197@glebius.int.ru> References: <20120608061737.GA28197@glebius.int.ru> Date: Fri, 8 Jun 2012 12:39:43 +0200 X-Google-Sender-Auth: CxwOsRYjloEtZn2JrSrr4FqjHws Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: [CFT] SMP-friendly pf 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, 08 Jun 2012 10:39:45 -0000 On Fri, Jun 8, 2012 at 8:17 AM, Gleb Smirnoff wrote: > =A0Hello, networkers! > > =A0[net@ in Cc, but further discussion should go on pf@] > > =A0As you already probably know, or some may be don't yet know, the pf(4) > subsystem in FreeBSD is currently working under a single mutex. This mute= x > is acquired right at the beginning of any packet processing, and is dropp= ed > at the end. While one thread is in pf(4) all other threads are blocked on > that mutex. > > =A0Meanwhile modern computers are getting more and more cores, and modern > network cards getting more MSI interrupts, each serviced by a separate ke= rnel > thread in FreeBSD. So the single pf lock, which I call "the pf Giant" :),= is > getting a point of hard contention. > > =A0Three and a half months ago I've started on a project "SMP-friendly pf= ", > which recently have entered alpha stage. As you see from the subject of t= his > mail, this is call for testing. > > > =A0Willing to test? > As i already asked in private wihtout a documentation/schema describing how you protect the various elements in pf(4) this is very hard to review. - What do you do to allow correctness on statistics? - What do you with tables protection, are they under same lock as rules...? - How is if-bound versus floating states maintained? - What is protecting scrub ruleset? - What is protecting nat ruleset? -.... - How you solved synproxy ? Is it scalable? - Do you think you have introduced possiblity of security issues with taskqueues you introduce? There are many how? in this implementation that are difficult to see without you telling! > =A0The code lives in projects/pf/head branch in the SVN, and can be check= ed > out with: > > =A0svn checkout http://svn.freebsd.org/base/projects/pf/head pflock > > , where argument "pflock" is just directory name for checked out sources. > =A0Then you need to build world and kernel from that branch and install t= hem. > The branch projects/pf/head gets head merged to it quite often, so if you > run head world with a revision equal (or at least close) to last merge, t= hen > you don't need to install world, however rebuilding pfctl and snmp_pf fro= m > that branch is necessary. > =A0If you are about to run this alpha pf on any important box, then you > definitely need to establish safety measures: have a second box running > stable/9 or head as carp(4) backup, ready to kick in, in case if new pf > panics. pfsync(4) connection should also be established between new and > backup boxes. pfsync(4) in the new code is wire compatible with stable/9 > or head. > =A0I'm already running it on routers with 100k - 200k state entries, and > forwarding 20k - 40k pps. If you are brave, you should try, too :) Good > luck and report any problems to me! > > > =A0Interested in details? > > =A0From the very beginning of the project it was clear, that code is goin= g > to diverge significantly from original OpenBSD code. OpenBSD has always > developed pf without taking into account that code can ever get > multithreaded, thus quite a lot needed to be changed. Thus, I've started > with removing the "#ifdef __FreeBSD__" from the code, and later I didn't > hesitate even a fraction of second if I wanted to toss some code. The pro= s > is that now code is much more readable and understandible then in head, > the cons is that diff between us and OpenBSD is huge, although amount > of shared code is huge, too. So, later on only manual merging of features > from OpenBSD is possible and bulk imports of entire pf into FreeBSD are > no longer possible. > > =A0The locking scheme is the following: > - There is an rwlock(9) that protects rules and all kind of data that isn= 't > =A0modified by forwarding threads. Forwarding threads reader lock it, ioc= tl() > =A0and other reconfiguring events write lock it. > - The states and key states storage had moved from RB-trees to hashes, wi= th > =A0separate mutexes per hash slot. This should give us decent parallelism > =A0when forwarding packets. > - Source nodes storage moved to hash with per-slot locking. > - pfsync(4) got separate mutex. > - fragment reassembly got separate mutex. > > =A0Apart from the above key changes, many other optimisations and fixes d= one. > The entire diff is 22k lines large. You can view the projects history her= e: > > http://svnweb.freebsd.org/base/projects/pf/head/?view=3Dlog > > (the beginning is on page 2 now, at r232042) I had tried to make informat= ive > commit messages. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 12:43:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DDBB1065686; Fri, 8 Jun 2012 12:43:52 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BD2598FC1C; Fri, 8 Jun 2012 12:43:51 +0000 (UTC) Received: by werg1 with SMTP id g1so727238wer.13 for ; Fri, 08 Jun 2012 05:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TMFvA3zI4S3dJtfrZMh3NuuK1QUWFFYjirxelGcZKMY=; b=XBQxZKjvRqFGz3PLqjz1FarOBugoPbRMV6VdM8FR1pFm0neF0wfwmluNbaprvZs4UY ow5KWXWnzZGazxtqiKerZxNTWZi/XgOJCdVrvm9WCjsk9NqcpazQUbg+1ahbrp14CabW C2i6pK3NE+WccW/lA8dkc8wNs0kfR7b8xPp9RQG7eecW56lH9zNxgESWIgtsfM7kNFXP SVev6U6UGK1r3VKMutkWwElkn557TeUv0+fbVUOYtMatltaCtXZw7ubnpEKRe/nwYNCa E5iI5n7IhFDQqZ1dWlV3YlYZ038DS4KJGDODkkhZCdCe+5yGYpg/flAOWh5dQF9d8qmp YkOQ== Received: by 10.180.106.137 with SMTP id gu9mr14977wib.8.1339159430669; Fri, 08 Jun 2012 05:43:50 -0700 (PDT) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id eb8sm1028553wib.11.2012.06.08.05.43.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 05:43:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: Date: Fri, 8 Jun 2012 15:43:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1278) Cc: freebsd-net Subject: Re: FreeBSD 8.2-STABLE sending FIN no ACK packets. 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, 08 Jun 2012 12:43:52 -0000 On Jun 8, 2012, at 4:30 AM, Adrian Chadd wrote: > On 7 June 2012 05:41, Nikolay Denev wrote: >> Hello, >>=20 >> I've been pointed out by our partner that we are sending TCP packets = with FIN flag and no ACK set, which is triggering >> alerts on their firewalls. >> I've investigated, and it appears that some of our FreeBSD hosts are = really sending such packets. (they are running some java applications) >> I did "tcpdump -s0 -vni em1 '(tcp[tcpflags] & tcp-ack =3D=3D 0) && = (tcp[tcpflags] & tcp-fin !=3D 0)'" to catch them. >>=20 >> Is this considered normal? >> It seems at least Juniper considers this malicious traffic : = http://www.juniper.net/techpubs/software/junos-security/junos-security10.0= /junos-security-swconfig-security/id-72577.html >=20 > Would you please file a PR with this, so it doesn't get lost? >=20 > Thanks, >=20 >=20 > Adrian Filed as kern/168842, and mistakenly duplicated as kern/168843 (the = latter can be closed). As I wrote in the PR, I have a PCAP that I can privately share if = someone is interested. From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 15:11:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD86C1065670 for ; Fri, 8 Jun 2012 15:11:00 +0000 (UTC) (envelope-from kazuaki@aliceblue.jp) Received: from p024afb.tokyff01.ap.so-net.ne.jp (p024afb.tokyff01.ap.so-net.ne.jp [121.2.74.251]) by mx1.freebsd.org (Postfix) with ESMTP id 9C56F8FC1F for ; Fri, 8 Jun 2012 15:11:00 +0000 (UTC) Received: from undine.local (unknown [192.168.11.46]) by p024afb.tokyff01.ap.so-net.ne.jp (Postfix) with ESMTP id D82121A4016 for ; Sat, 9 Jun 2012 00:01:46 +0900 (JST) Message-ID: <4FD213DA.8050300@aliceblue.jp> Date: Sat, 09 Jun 2012 00:01:46 +0900 From: Kazuaki ODA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation 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, 08 Jun 2012 15:11:00 -0000 Hi all, Recently I received a e-mail from our customer that he could not browse our web site. I thought that was strange at first because we and most people could browse without problems, but he could not...umm, why? After some investigation I've found that our web server ignores SYN packet he sent because that has invalid TCP checksum, and his original packet has correct checksum but that is broken after passing our firewall using PF packet filter on 7.4-RELASE. And further more, I've noticed that such a invalid packet is made when original packet has TCP timestamp option and the option does not start at 16-bit word boundary like a packet that has TCP options . After all, disabling "scrub reassemble tcp" rule resolved this problem. But I have some questions: Is this a bug in PF code, or original packet violates RFC? As far as I know, last TCP option must end at 32-bit boundary but there is no restriction for each options about position, order etc. So I think this is a bug. Correct? How many systems in the world that create such a SYN packet? I think that many OSes add NOP options before timestamp option to adjust the starting position, but the one our customer has does not. Unfortunately I cannot get information from him about his network environment... -- Kazuaki ODA From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 15:36:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D108106566C for ; Fri, 8 Jun 2012 15:36:35 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA2E8FC12 for ; Fri, 8 Jun 2012 15:36:34 +0000 (UTC) Received: by eaac13 with SMTP id c13so1466546eaa.13 for ; Fri, 08 Jun 2012 08:36:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=NI/ObvTvAmXnFN8w85uqmkNNKQLtG+UOL3opdmpE9Nk=; b=HiyqVoGkO+P7vNTkHdSXY+CYZqfkoQDhxMSjmKk3jNOjRGazjp+qZSg8w5boXwze5n rrdUzKoy60uR1kNI/VKqE686nHzFwcR8ZDwE9MpM5aESKfJsOJRctSY/PHtZ/lm1s/tH UHOhFX6IHBo4Ix61iQRIjqaFmxaTakfkps10FhMYvr4JFMGYpwLKHh2HivAuFp1DIKA/ KA5l3jIBhfYXpgFVAJ8zd0nOK45j/aMU65IK/Jr0IVypXDFQxfcQOpW7Hy2WhA887d/c RfWEpaw4gPeyXZiJLFbyBDXOP84jIyo/B52JLZppTOcxXSRUxHhmlsnunLQJAx4clmfE pqRQ== Received: by 10.14.37.69 with SMTP id x45mr4135305eea.48.1339169793737; Fri, 08 Jun 2012 08:36:33 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id x52sm23481792eea.11.2012.06.08.08.36.32 (version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 08:36:33 -0700 (PDT) Message-ID: <4FD21BFF.4080803@my.gd> Date: Fri, 08 Jun 2012 17:36:31 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4FD213DA.8050300@aliceblue.jp> In-Reply-To: <4FD213DA.8050300@aliceblue.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn0DL50RVjKWKpm2UdhTfwXuu/teNbn5TY0yzWqWph6Eq1JOdeOPArSi0urQBFLX7o0ObPZ Subject: Re: PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation 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, 08 Jun 2012 15:36:35 -0000 On 6/8/12 5:01 PM, Kazuaki ODA wrote: > Hi all, > > Recently I received a e-mail from our customer that he could not browse > our web site. I thought that was strange at first because we and most > people could browse without problems, but he could not...umm, why? > > After some investigation I've found that our web server ignores SYN > packet he sent because that has invalid TCP checksum, and his original > packet has correct checksum but that is broken after passing our > firewall using PF packet filter on 7.4-RELASE. And further more, I've > noticed that such a invalid packet is made when original packet has TCP > timestamp option and the option does not start at 16-bit word boundary > like a packet that has TCP options . > > After all, disabling "scrub reassemble tcp" rule resolved this problem. > But I have some questions: > > Is this a bug in PF code, or original packet violates RFC? As far as I > know, last TCP option must end at 32-bit boundary but there is no > restriction for each options about position, order etc. So I think this > is a bug. Correct? > > How many systems in the world that create such a SYN packet? I think > that many OSes add NOP options before timestamp option to adjust the > starting position, but the one our customer has does not. Unfortunately > I cannot get information from him about his network environment... > > -- > Kazuaki ODA Oh god, that font... Anyway, Reporting that we experience a problem that looks very much the same here on, at least, 8.1-RELEASE, 8.2-RELEASE. Unconfirmed on 8.3-RELEASE and 8-STABLE as we have not tested. We've also had to disabled tcp reassembly in scrubbing as it incorrectly caused packets to be dropped. From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 15:44:34 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC896106566B for ; Fri, 8 Jun 2012 15:44:34 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 9574F8FC17 for ; Fri, 8 Jun 2012 15:44:34 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q58Fhhju044248; Fri, 8 Jun 2012 08:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1339170224; bh=8tMx6t93H9WtPDI+o6+5cPDWoUr/gsGWXp4k3jP1/O8=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=XA24WuapB8a9ZC31TOCWe7vEOiLSQ0QvbX/9ggF0UiuK/kfjphalXFRkEGefYBKtf ttXpID6T7jGUp/NUAKU9ooyLXWzJYxM9y0OLWNTq/C1jZUsl29fuCNFaTMFZPC9Ub5 zWcdBnQqq9ACdLsjAGHt1gO8gEuDj+OZNNKOhJ7I= From: Sean Bruno To: Daniel Braniss In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Jun 2012 08:43:42 -0700 Message-ID: <1339170222.2854.4.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 170223001 Cc: "net@freebsd.org" Subject: Re: recommended 10g cards 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, 08 Jun 2012 15:44:34 -0000 On Thu, 2012-06-07 at 23:54 -0700, Daniel Braniss wrote: > Hi > I will be 'experimenting' with 10g in the next few months, so > I need to buy some cards, > After googling for some time, I noticed that there is not realy much real > info, and some of it is a bit dated. > Since these cards are pricy, could those that have such cards share some info? > cheers, > danny > The intel 10G and chelsio cards are ones that we've screwed around with here at Yahoo. You probably would have the most likely success with the intel driver, ixgbe(4). Sean From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 16:52:46 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4544F1065675 for ; Fri, 8 Jun 2012 16:52:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 089C98FC1B for ; Fri, 8 Jun 2012 16:52:45 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 640117300B; Fri, 8 Jun 2012 19:11:26 +0200 (CEST) Date: Fri, 8 Jun 2012 19:11:26 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20120608171126.GA29273@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: VALE, a Virtual Local Ethernet. http://info.iet.unipi.it/~luigi/vale/ 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, 08 Jun 2012 16:52:46 -0000 We have just completed a netmap extensions that let you build a local high speed switch called VALE which i think can be very useful. http://info.iet.unipi.it/~luigi/vale/ VALE is a software Virtual Local Ethernet whose ports are accessible using the netmap API. Designed to be used as the interconnect between virtual machines (or as a fast local bus), it works as a learning bridge and supports speeds of up to 20 Mpps with short frames, and an aggregate 70 Gbit/s with 1514-byte packets. The VALE paper contains more details and performance measurements. VALE is implemented as a small extension of the netmap module, and is available for FreeBSD and Linux. The source code includes a backend for qemu and KVM, so you can use VALE to interconnect virtual machines launching them with qemu -net nic -net netmap,ifname=vale0 ... qemu -net nic -net netmap,ifname=vale1 ... ... Processes can talk to a VALE switch too, so you can use the pkt-gen or bridge tools that are part of the netmap distribution, or even the pcap.c module that maps libpcap calls into netmap equivalents. This lets you use VALE for all sort of pcap-based applications. More details, code, bootable images on the VALE page, http://info.iet.unipi.it/~luigi/vale/ feedback welcome, as usual. cheers luigi -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 17:31:12 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83FDB1065672 for ; Fri, 8 Jun 2012 17:31:12 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4688FC1F for ; Fri, 8 Jun 2012 17:31:11 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q58HV94G029357 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 8 Jun 2012 23:31:09 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4FD236D4.6090409@norma.perm.ru> Date: Fri, 08 Jun 2012 23:31:00 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Fri, 08 Jun 2012 23:31:09 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Cc: Subject: if_ipsec 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, 08 Jun 2012 17:31:12 -0000 Hi. I have an idea about new networking feature in FreeBSD. I guess everyone is having ideas from time to time, and lots of these idea having people think that they just had a decent idea. However, only ideas that are complemented by a working code can be considered by the community, and only some of them got commited into the tree, I am fully aware of this fact. Unfortunately, I am not able to produce the code. I guess this is the point where most of the subscribers will (or at least should) stop reading this post. Still, I'm addressing this post for people that have the time and will to do something interesting. I guess that someone may find this interesting. Myself, I find that this could be really useful. (You can skip this part and the next part if you only want to read about the idea) I work about 10 years as a network engineer. My company holds country-wide supermarkets business. I am personally responsible for the network infrastructure of the company. As the company has lots of (hundreds) of branch offices, lots of my time I'm constructing new VPNs between them. My company network infrastructure is build using FreeBSD servers and Cisco (and last year - Juniper) equipment. So I am aware and capable of building VPN of almost any modern type, and this is the post about building it on FreeBSD (this annoying passage was written to give you impression that I'm not just a guy with FreeBSD server at home, holding a couple of movies). So. About VPNs. Another annoying passage about common ways and caveats. Otherwise most of the reading ppl will say 'Why the hell if_ipsec ?' (ppl that are aware of the VPNs can really skip this part). The conventional way to build vpn is to build a tunnel of some sort. This can be an encrypted tunnel, or an unencrypted tunnel. Unencrypted tunnel (gre/ipinip) is obviously unencrypted, but gives you an interface which could be using in routing. Encrypted tunnel (and I'm talking about ipsec) cannot be used for rounting, but is encrypted. Plus, you have to care about policies, and when multiple routers are involved, with hundreds of networks behind them, you have to care about tonns of policies, and this is painful. So, the industry invented a method: you use a gre/ipinip tunnel, you pass the dynamic routing information (you don't care bout networks, you only care abouth the endpoints), and you encrypt this tunnel with ipsec. So, gre + ipsec (of gif + ipsec). This way is supported by all of the major vendors, you can build gre(ipinip)+ipsec tunnel to any Cisco/Juniper device. Though building in to JunOS requires some skill and a deep knowledge. :) (here the idea starts) But what is an gre or gif tunnel ? This is not an interface, but a way to tell the system, that it needs to encapsulate some of the payload with another header, and send it somewhere. So, using ipsec you add an extra header, and using gre(ipinip) you add an extra header. What if we will add an additional ability to understand that some of the ipsec packets are destined to the security gateway (which adds the extra header) itself, like it's possible with gre/ipinip, so we can get rid of one extra header ? Cisco/Juniper did that. So, Cisco has the 'tun mode ipsec ipvX' interface, and Juniper has the st (secure tunnel) interface. How does it work: it's a convenstional ISAKMP IPsec with the ability to treat some of the packets with a particular IP like destined to the local (by this I mean 'this') host. Besides this it's the old IPsec. It's even interoperable between different vendors devices. I don't see any reason why FreeBSD cannot have this ability, since it does have a working Ipsec and working ISAKMP. In order to obtain this functionality FreeBSD needs to have a way to define the templates for the SPD entries, and the way to create these SPD entries after the creation of the interface, based on it's address information. This will really simplify the VPN creating and management. So... here was the idea. :) It came to my head after configuring the Juniper/Cisco VPN (and the config was really short), and after reading quagga-users@ maillist, where some of the subscribers asked about 'tun mode ipsec'. Plus, as far as I know, Linux does not support this too, so we could really score some points. Eugene. From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 18:21:35 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5420106564A for ; Fri, 8 Jun 2012 18:21:35 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 753678FC15 for ; Fri, 8 Jun 2012 18:21:35 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cHxdfqhv+m1xlyN7V9CN0e7cdj/Dy2+mEblOrGhmhlavc8Vqi7YbRcbzvXroYG93; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.45] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Sd3oO-0006I1-RR; Fri, 08 Jun 2012 14:21:28 -0400 Message-ID: <4FD242A7.6090507@earthlink.net> Date: Fri, 08 Jun 2012 14:21:27 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4FD236D4.6090409@norma.perm.ru> In-Reply-To: <4FD236D4.6090409@norma.perm.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79d60f19755eec14ef076c5797979b1ab2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.45 Cc: "net@freebsd.org" Subject: Re: if_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 18:21:35 -0000 On 06/08/2012 01:31 PM, Eugene M. Zheganin wrote: > Hi. > > I have an idea about new networking feature in FreeBSD. > I guess everyone is having ideas from time to time, and lots of these > idea having people think that they just had a decent idea. However, > only ideas that are complemented by a working code can be considered > by the community, and only some of them got commited into the tree, I > am fully aware of this fact. > > Unfortunately, I am not able to produce the code. I guess this is the > point where most of the subscribers will (or at least should) stop > reading this post. Still, I'm addressing this post for people that > have the time and will to do something interesting. I guess that > someone may find this interesting. Myself, I find that this could be > really useful. > > (You can skip this part and the next part if you only want to read > about the idea) I work about 10 years as a network engineer. My > company holds country-wide supermarkets business. I am personally > responsible for the network infrastructure of the company. As the > company has lots of (hundreds) of branch offices, lots of my time I'm > constructing new VPNs between them. My company network infrastructure > is build using FreeBSD servers and Cisco (and last year - Juniper) > equipment. So I am aware and capable of building VPN of almost any > modern type, and this is the post about building it on FreeBSD (this > annoying passage was written to give you impression that I'm not just > a guy with FreeBSD server at home, holding a couple of movies). > > So. About VPNs. Another annoying passage about common ways and > caveats. Otherwise most of the reading ppl will say 'Why the hell > if_ipsec ?' (ppl that are aware of the VPNs can really skip this > part). The conventional way to build vpn is to build a tunnel of some > sort. This can be an encrypted tunnel, or an unencrypted tunnel. > Unencrypted tunnel (gre/ipinip) is obviously unencrypted, but gives > you an interface which could be using in routing. Encrypted tunnel > (and I'm talking about ipsec) cannot be used for rounting, but is > encrypted. Plus, you have to care about policies, and when multiple > routers are involved, with hundreds of networks behind them, you have > to care about tonns of policies, and this is painful. So, the industry > invented a method: you use a gre/ipinip tunnel, you pass the dynamic > routing information (you don't care bout networks, you only care > abouth the endpoints), and you encrypt this tunnel with ipsec. So, gre > + ipsec (of gif + ipsec). This way is supported by all of the major > vendors, you can build gre(ipinip)+ipsec tunnel to any Cisco/Juniper > device. Though building in to JunOS requires some skill and a deep > knowledge. :) > > (here the idea starts) But what is an gre or gif tunnel ? This is not > an interface, but a way to tell the system, that it needs to > encapsulate some of the payload with another header, and send it > somewhere. So, using ipsec you add an extra header, and using > gre(ipinip) you add an extra header. What if we will add an additional > ability to understand that some of the ipsec packets are destined to > the security gateway (which adds the extra header) itself, like it's > possible with gre/ipinip, so we can get rid of one extra header ? > Cisco/Juniper did that. So, Cisco has the 'tun mode ipsec ipvX' > interface, and Juniper has the st (secure tunnel) interface. How does > it work: it's a convenstional ISAKMP IPsec with the ability to treat > some of the packets with a particular IP like destined to the local > (by this I mean 'this') host. Besides this it's the old IPsec. It's > even interoperable between different vendors devices. I don't see any > reason why FreeBSD cannot have this ability, since it does have a > working Ipsec and working ISAKMP. In order to obtain this > functionality FreeBSD needs to have a way to define the templates for > the SPD entries, and the way to create these SPD entries after the > creation of the interface, based on it's address information. This > will really simplify the VPN creating and management. > > So... here was the idea. :) > It came to my head after configuring the Juniper/Cisco VPN (and the > config was really short), and after reading quagga-users@ maillist, > where some of the subscribers asked about 'tun mode ipsec'. Plus, as > far as I know, Linux does not support this too, so we could really > score some Hmm... I just saw a patch on linux-netdev that implements this for linux. > points. > > Eugene. > _______________________________________________ > 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" > -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 19:23:10 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BA851065670 for ; Fri, 8 Jun 2012 19:23:10 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 424958FC17 for ; Fri, 8 Jun 2012 19:23:10 +0000 (UTC) Received: by ggnm2 with SMTP id m2so1783806ggn.13 for ; Fri, 08 Jun 2012 12:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PQXQX+Mvd5joy8j+OwYKBQajrsU2+IkA5hE05+8d5Xs=; b=XLoWQQsQj6DC/na4OoIwGvr/jBoQHA0FnixZa16Jv/V9QIjWMiXu22NTRgpQrjNLjq MwS94Fwm/8tsvx4AbJgzNEgUKP0ETJS9krElD8TJ1I298eRAl3mwsWRdd4YmzW4ZiEOa 45UIQTxe1V+eGkam3yYDIc8UxRL9h1Owv62j1+QSBgJY1rB2XB5b3WCU/uRK1Uit4JA0 KZafSScs/ZhlRKrhbolOXGxigQF+bpfA8mug7f+iMU1LIHdpf2OktwNuHBz5p1QiXKjn a8hbL/vlmqyqpBoRPfQRzjLSmCzQpL/S/8dRNTcb/NeyEySiGt1EVoScGp88rjqcmWl7 M9eg== MIME-Version: 1.0 Received: by 10.60.9.134 with SMTP id z6mr8276096oea.46.1339183389532; Fri, 08 Jun 2012 12:23:09 -0700 (PDT) Received: by 10.182.44.101 with HTTP; Fri, 8 Jun 2012 12:23:09 -0700 (PDT) In-Reply-To: <1339170222.2854.4.camel@powernoodle-l7.corp.yahoo.com> References: <1339170222.2854.4.camel@powernoodle-l7.corp.yahoo.com> Date: Fri, 8 Jun 2012 22:23:09 +0300 Message-ID: From: Sami Halabi To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Daniel Braniss , "net@freebsd.org" Subject: Re: recommended 10g cards 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, 08 Jun 2012 19:23:10 -0000 Hi Danny, I can tell that the 10g 82599 card is stable and works great with ixgbe driver (currently i use 2.3.8 by jack vogel, and the new 2.4 should also be great) on production for daily traffic ranges between 1.5G - 6G+ (i didn't notice any limitation since we didn't push more traffic yet) on fbsd 8 for a year now. good luck. Sami On Fri, Jun 8, 2012 at 6:43 PM, Sean Bruno wrote: > On Thu, 2012-06-07 at 23:54 -0700, Daniel Braniss wrote: > > Hi > > I will be 'experimenting' with 10g in the next few months, so > > I need to buy some cards, > > After googling for some time, I noticed that there is not realy much real > > info, and some of it is a bit dated. > > Since these cards are pricy, could those that have such cards share some > info? > > cheers, > > danny > > > > The intel 10G and chelsio cards are ones that we've screwed around with > here at Yahoo. You probably would have the most likely success with the > intel driver, ixgbe(4). > > Sean > > _______________________________________________ > 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" > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD Expert From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 20:05:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDDD4106566C for ; Fri, 8 Jun 2012 20:05:43 +0000 (UTC) (envelope-from bkolasinski@anl.gov) Received: from lemmy.anl.gov (lemmy.anl.gov [146.137.14.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8A74B8FC19 for ; Fri, 8 Jun 2012 20:05:43 +0000 (UTC) Received: from HETFIELD.anl.gov ([146.137.14.7]) by lemmy.anl.gov ([146.137.14.2]) with mapi; Fri, 8 Jun 2012 15:04:33 -0500 From: "Kolasinski, Brent D." To: "freebsd-net@freebsd.org" Date: Fri, 8 Jun 2012 15:04:37 -0500 Thread-Topic: Netgraph and Netflow-v9 Thread-Index: Ac1FsesqmmGCdpu8RzSBTTXrfXzNiA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Netgraph and Netflow-v9 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, 08 Jun 2012 20:05:43 -0000 Hi All, I have been doing some tests with the FreeBSD ng_netflow module for netflow generation. I am trying to export v9 netflow records to another server running SiLK (which can receive v9 Netlfow from our Cisco routers just fine). When exporting v9 records from our FreeBSD-9-RELEASE server, we are getting this error on our SiLK server (this repeats many times): "rwflowpack[23113]: fBufNext: No Templates Present for Domain 0x000a" Now I modified the settemplates variable in ngctl to send a template every 20 seconds, but we are still getting this. As a sanity check, I tried exporting v5 netflow data from this FreeBSD box to the Silk box, and it happily receives it and processes it. The Silk server is receiving the v9 netflow datagrams, as I can see it with a PCAP. Any ideas as to what I am doing wrong? Am I using the export9 hook correctly in the commands listed below? There is not much documentation covering export9 out there (besides the tiny blurb in the FreeBSD9 Release notes). Here is a detail of my setup: 2 ethernet cards: 1) bce0 -> in promiscuous mode listening to traffic off of a tap 2) bce1 -> nic to be exporting netflow / connected to our network Commands I am using to export v9 netflow records in ngctl: mkpeer bce0: netflow lower iface0 name bce0:lower netflow connect bce0: netflow: upper out0 mkpeer netflow: ksocket export9 inet/dgram/udp msg netflow:export9 connect inet/: Thanks!! ---------- Brent Kolasinski Cyber Security Program Office Argonne National Laboratory Phone: 630-252-2546 From owner-freebsd-net@FreeBSD.ORG Fri Jun 8 21:56:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 588B5106564A; Fri, 8 Jun 2012 21:56:55 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 131098FC16; Fri, 8 Jun 2012 21:56:54 +0000 (UTC) Received: by obcni5 with SMTP id ni5so3822447obc.13 for ; Fri, 08 Jun 2012 14:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/GYoG3cBJzsXQGHWBVOeOqriBwfWsh4PpHLkrEx74+8=; b=Mk1LXAPmJzVq+MJ8HWFSffYG2FWPQbCL2Eft9LRaFDSmKdqlx/oBZhRgvmwNuLyfLj V3q3FpeZWUJ6R54yT0bZgLgfo6X10waLhXAfVZnu4veHLB0L50xeUC6rAShY+TheWsAS vFvcWSfhLpMhmjAAKVp6pdf2lBNeksEmpnuAH4efSs9ekA3AaQ4sy5Wiedq3HE3Hgc6A iCbiQqd8Tg/+zIhmdYZV4YRJijGVCgfVQpo2G7PVsfFWA6cXx0WuJPRg9Ha/1vX7CGrv gYjrKdx6lijwMVVOue8FeA0918wGR23kt+0sjuq0ar198QF4GsI1tJjcv9Kda01A/wFy YsbQ== MIME-Version: 1.0 Received: by 10.60.9.134 with SMTP id z6mr8672465oea.46.1339192614408; Fri, 08 Jun 2012 14:56:54 -0700 (PDT) Received: by 10.182.44.101 with HTTP; Fri, 8 Jun 2012 14:56:54 -0700 (PDT) Date: Sat, 9 Jun 2012 00:56:54 +0300 Message-ID: From: Sami Halabi To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ipfw rules consuming CPU 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, 08 Jun 2012 21:56:55 -0000 Hi, I Manage a FreeBSD server as an edge router & firewall. the setup has 10G interfaces (ixgbe-82599EB) and 1G interfaces(em-82571EB & bce-BCM5709) connected to 10G/1G switches. With the following setup i get higher cpu usage: bce1-upstream provider with little bandwidth, so i use pipes to limit users, and subnets ix0 - Internet Exchange some rules. . . .from 4000 starts pipes for specefic ips bandwidth allocations 04000 6210053001 5845967300616 pipe 1003 ip from 182.46.92.13 to any out xmit bce1 04100 41289897537 3064110648124 pipe 1004 ip from any to 182.46.92.13 in recv bce1 . . . .7000 is the wider pipeline for the whole block 07000 9127154724 4651308720315 pipe 1000 ip from 182.46.92.0/24 to any out xmit bce1 07100 4837016828 458027989917 pipe 1002 ip from any to 182.46.92.0/24 in recv bce1 last rule default to accept... specefic pipes (1003-...) have limits say between 1-10Mbps, and the wider pipe (1000 and 1002) has a global limit of 40MBps that should be reached by all other non-specefic ips, config like this: #Wide ipfw pipe 1000 config bw 40Mbit/s queue 200Kbytes ipfw pipe 1002 config bw 40Mbit/s queue 200Kbytes #specefic ipfw pipe 1003 config bw 9Mbit/s queue 200Kbytes ipfw pipe 1004 config bw 9Mbit/s queue 200Kbytes ipfw pipe 1005 config bw 3Mbit/s queue 200Kbytes ipfw pipe 1006 config bw 3Mbit/s queue 200Kbytes ipfw pipe 1007 config bw 5Mbit/s queue 200Kbytes ipfw pipe 1008 config bw 5Mbit/s queue 200Kbytes ipfw pipe 1009 config bw 10Mbit/s queue 200Kbytes ipfw pipe 1010 config bw 10Mbit/s queue 200Kbytes with this configuration when i have lots of traffic (3-6GB) going via ix0 (not necessarly the ips described above, lets say to a server in my net ip 1832.46.93.4 and users behind the Internet Exchange) i see high cpu usage (70-90%). my first test was to: ipfw add 1 allow all from any to any, and cpu usage drops immediatly to 10-15%. but that not why i want (i wantto keep thelimits) so I add rule right before 4000 and the cpu usage drops down to 10-20%: 03020 1669463072808 1493341413029803 allow ip from any to any via ix0 Any advice why this happens? or should it be there in the first place? I use FreeBSD 8.1-R-p10-amd64. Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 01:51:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AB011065673 for ; Sat, 9 Jun 2012 01:51:38 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id B4BB68FC0A for ; Sat, 9 Jun 2012 01:51:37 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A93DFE6505 for ; Sat, 9 Jun 2012 02:52:22 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=TLY7bnx6usvc 9UOOuDJiFloAxcQ=; b=iMb39momMJ5SsM3YFoQ0AoQFH7Hvm17yI/PCIquUAtp+ zWbtNtoRNXfw+X1s1c9J7GmJ168FBUWX0sc11iJqPL1xqzezdamNmfqPpo++9JIN 5tNeG+XPRiYLmDNgshl2V6HXDHJ3nLraPxV/rTNIvE1qJHAtW6LhB6yNA++SdXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=eD58Uu IWVtiIuaAvJufy+7uKUInN2skSRWFjdv6tDkoctfG26DrIq+4Kb1dgEBwZrf3CMr +PPnNidrq+fID6qibakk9hP8JD6z8bK/CsYSHb/z+dxOuPV7lSuE0NqTlNcf4lBj SyQZINfFppE36MYjAa++a0xsUWmf23tS2+XbU= Received: from [192.168.2.12] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 8AE46E64E4 for ; Sat, 9 Jun 2012 02:52:22 +0100 (BST) Message-ID: <4FD2AC28.8060606@cran.org.uk> Date: Sat, 09 Jun 2012 02:51:36 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4FCE3265.9080804@cran.org.uk> In-Reply-To: <4FCE3265.9080804@cran.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Configuration problem with IPv6 router ("cannot forward src") 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, 09 Jun 2012 01:51:38 -0000 On 05/06/2012 17:23, Bruce Cran wrote: > Is there some extra configuration I've likely missed that's needed > when using IPv6 via PPP? > It turned out to be a problem with PF trying to NAT IPv6 - adding 'inet' to 'nat on $ext_if..." fixed it. -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 05:26:40 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4161E106566B for ; Sat, 9 Jun 2012 05:26:40 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7C7E8FC12 for ; Sat, 9 Jun 2012 05:26:39 +0000 (UTC) Received: by werg1 with SMTP id g1so1252563wer.13 for ; Fri, 08 Jun 2012 22:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p92Ig+BF9O+lwUYRS92c79I29ThidrDCzijb8+C/uk0=; b=ccs11/fHI3zOw+mDHANNwqj1zQKkr0ambMaNy1+b8vUOyJOOeMzexWqbymBG7pgqHQ 7tbZwxUImvpAaByiRaOuXkxRXLvEcTwnD/CI4QQfcqp5GF/+oDKXnc5p2+IdU03o9Wwn bDG/Ek/ZhQoMTXQdqRtSfryhw8csZUQh1zQo+J5Cr0b1CaPJaB6ME9ueguFbQNOTj+n7 jObt7osyT6I8b3Gzt9k9APowaI6jXZGY/N7QQ6sQNp6aIXbgutWqL5dhf6a7e5QUOH06 G7r9o0/2MZLqmtN+UvN8MrND370NjgZ7XVd7cIVwkFJNLm0zVtyt1WU7BcV9dy0N7Ksj F3JA== MIME-Version: 1.0 Received: by 10.180.79.166 with SMTP id k6mr5663527wix.8.1339219598916; Fri, 08 Jun 2012 22:26:38 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.223.155.4 with HTTP; Fri, 8 Jun 2012 22:26:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 22:26:38 -0700 X-Google-Sender-Auth: luUBj1g8tpMD8ujjOxX6isOY_nY Message-ID: From: Kevin Oberman To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: recommended 10g cards 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, 09 Jun 2012 05:26:40 -0000 On Thu, Jun 7, 2012 at 11:54 PM, Daniel Braniss wrote= : > Hi > I will be 'experimenting' with 10g in the next few months, so > I need to buy =A0some cards, > After googling for some time, I noticed that there is not realy much real > info, and some of it is a bit dated. > Since these cards are pricy, could those that have such cards share some = info? > cheers, We use Myricom cards in our 10G network test systems and they have worked out quite well. We are able to drive TCP to over 9Gbs and do US to Austrailia disk to disk transfers at over 5 Gbps. Myricom does the FreeBSD drivers and is active in the FreeBSD community. -- R. Kevin Oberman - Network Engineer rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 07:23:19 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45D1E1065674; Sat, 9 Jun 2012 07:23:19 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id ADC278FC1C; Sat, 9 Jun 2012 07:23:18 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q597NFJP086312; Sat, 9 Jun 2012 09:23:15 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q597NFsN086303; Sat, 9 Jun 2012 09:23:15 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 9 Jun 2012 09:23:15 +0200 (CEST) From: Wojciech Puchar To: "Alexander V. Chernikov" In-Reply-To: <4FD0C1F4.2060108@FreeBSD.org> Message-ID: References: <4FD0C1F4.2060108@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 09 Jun 2012 09:23:15 +0200 (CEST) Cc: hackers@freebsd.org, net@freebsd.org Subject: Re: ifconfig accepting hostname as ipv4 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 07:23:19 -0000 > input. > Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you can't > set valid CIDR address using this notation. > > Classful era has ended more than 10 years ago, do we still want to keep this > behavior? > were not aware of that option, and it is rather stupid option - you should work on addresses not names when configuring network From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 07:37:14 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05B591065670; Sat, 9 Jun 2012 07:37:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A55198FC08; Sat, 9 Jun 2012 07:37:13 +0000 (UTC) Received: by obcni5 with SMTP id ni5so4550949obc.13 for ; Sat, 09 Jun 2012 00:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BIbKVZwsjALX8L8FMYJ1qJ2GLI4GRYSrpEZQO9wlPc8=; b=ukcMo2UjTyuOWUUVd5obvojPz43flDn7DGZVJNnWRnkSN/uzCBs+gTjeHgY2yceuj/ SRsRJkAroJn65+GglzXTZbFjTUpMu+mS2Hr189kzH79OQM3fvQ0CVvVgV5+4Jo5zmURv IoW70qKRZNa4ZBy/00OWWUxH088k0yFDI9LFp/RStDjBnbkXY39Ca3aNpdi8vPdbKioN zaOQU44xuMChDpS2JFwurnLA6sLIB5Svk/64MtELux0t23ZTDJpBjY8vr/wTtByneR0Q AM1bQ7tIe45ZsdAMoy2u0+GL2eOQEM3baAHgC+dsCTlgAQKat8QxCtSCkv2EPYUPsm74 sQzQ== MIME-Version: 1.0 Received: by 10.182.154.67 with SMTP id vm3mr9799878obb.57.1339227433145; Sat, 09 Jun 2012 00:37:13 -0700 (PDT) Received: by 10.76.98.77 with HTTP; Sat, 9 Jun 2012 00:37:13 -0700 (PDT) In-Reply-To: References: <4FD0C1F4.2060108@FreeBSD.org> Date: Sat, 9 Jun 2012 00:37:13 -0700 Message-ID: From: Garrett Cooper To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org, "Alexander V. Chernikov" , net@freebsd.org Subject: Re: ifconfig accepting hostname as ipv4 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 07:37:14 -0000 On Sat, Jun 9, 2012 at 12:23 AM, Wojciech Puchar wrote: >> input. >> Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you >> can't set valid CIDR address using this notation. >> >> Classful era has ended more than 10 years ago, do we still want to keep >> this behavior? >> > were not aware of that option, and it is rather stupid option - you should > work on addresses not names when configuring network I agree that it's not the best configuration in the world, as it would only work 100% if a machine had proper DNS records or a definitive hosts file. There are already enough bugs with static IP configurations and hostnames as-is *I'm looking at you mountlate* -- no sense to introduce more potentially buggy interoperability that only works in a handful of niche cases. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 07:50:17 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 107491065672 for ; Sat, 9 Jun 2012 07:50:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id BAB7B8FC20 for ; Sat, 9 Jun 2012 07:50:16 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SdGQz-0002PX-Hj for net@freebsd.org; Sat, 09 Jun 2012 10:50:09 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: net@freebsd.org In-reply-to: Your message of Fri, 8 Jun 2012 22:26:38 -0700. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jun 2012 10:50:09 +0300 From: Daniel Braniss Message-ID: Cc: Subject: Re: recommended 10g cards 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, 09 Jun 2012 07:50:17 -0000 thanks to all that responded! from the rough polling, it seems that the order list is Intel, Myricom Solarflare, Chelsio Now I'll try and 'borrow' some of these. thanks again, danny From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 10:02:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id A21B8106566C for ; Sat, 9 Jun 2012 10:02:40 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 1F6711A78C3; Sat, 9 Jun 2012 10:01:51 +0000 (UTC) Message-ID: <4FD31F0A.5090306@FreeBSD.org> Date: Sat, 09 Jun 2012 14:01:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Kolasinski, Brent D." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: Netgraph and Netflow-v9 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, 09 Jun 2012 10:02:40 -0000 On 09.06.2012 00:04, Kolasinski, Brent D. wrote: > Hi All, > > I have been doing some tests with the FreeBSD ng_netflow module for > netflow generation. I am trying to export v9 netflow records to another > server running SiLK (which can receive v9 Netlfow from our Cisco routers > just fine). > > When exporting v9 records from our FreeBSD-9-RELEASE server, we are > getting this error on our SiLK server (this repeats many times): > "rwflowpack[23113]: fBufNext: No Templates Present for Domain 0x000a" > > Now I modified the settemplates variable in ngctl to send a template every > 20 seconds, but we are still getting this. It should disappear after 5-10 minutes. We're using several FreeBSD v9 sensors with flowd and it seems to run fine (except first 5 minutes while waiting for template). I'm aware about the problem with templates timeout working incorrectly and I plan to fix this soon. > > As a sanity check, I tried exporting v5 netflow data from this FreeBSD box > to the Silk box, and it happily receives it and processes it. The Silk > server is receiving the v9 netflow datagrams, as I can see it with a PCAP. > > Any ideas as to what I am doing wrong? Am I using the export9 hook > correctly in the commands listed below? There is not much documentation > covering export9 out there (besides the tiny blurb in the FreeBSD9 Release > notes). > > Here is a detail of my setup: > 2 ethernet cards: > 1) bce0 -> in promiscuous mode listening to traffic off of a tap > 2) bce1 -> nic to be exporting netflow / connected to our network > > Commands I am using to export v9 netflow records in ngctl: > > mkpeer bce0: netflow lower iface0 > name bce0:lower netflow > connect bce0: netflow: upper out0 > mkpeer netflow: ksocket export9 inet/dgram/udp > msg netflow:export9 connect inet/: > > > Thanks!! > > ---------- > Brent Kolasinski > Cyber Security Program Office > Argonne National Laboratory > Phone: 630-252-2546 > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 10:16:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 0B0FA1065674; Sat, 9 Jun 2012 10:16:53 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 97FF715EEF9; Sat, 9 Jun 2012 10:15:43 +0000 (UTC) Message-ID: <4FD3224A.3080700@FreeBSD.org> Date: Sat, 09 Jun 2012 14:15:38 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sami Halabi References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: ipfw rules consuming CPU 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, 09 Jun 2012 10:16:53 -0000 On 09.06.2012 01:56, Sami Halabi wrote: > Hi, > > I Manage a FreeBSD server as an edge router& firewall. > the setup has 10G interfaces (ixgbe-82599EB) and 1G interfaces(em-82571EB& > bce-BCM5709) connected to 10G/1G switches. > > With the following setup i get higher cpu usage: > bce1-upstream provider with little bandwidth, so i use pipes to limit > users, and subnets > ix0 - Internet Exchange > > some rules. > . > . > .from 4000 starts pipes for specefic ips bandwidth allocations > 04000 6210053001 5845967300616 pipe 1003 ip from 182.46.92.13 to any > out xmit bce1 > 04100 41289897537 3064110648124 pipe 1004 ip from any to 182.46.92.13 > in recv bce1 You should use pipe tablearg for that. Traversing 4k rules effectively kills all performance. > . > . > . > .7000 is the wider pipeline for the whole block > 07000 9127154724 4651308720315 pipe 1000 ip from 182.46.92.0/24 to > any out xmit bce1 > 07100 4837016828 458027989917 pipe 1002 ip from any to > 182.46.92.0/24 in recv bce1 > last rule default to accept... > > specefic pipes (1003-...) have limits say between 1-10Mbps, and the wider > pipe (1000 and 1002) has a global limit of 40MBps that should be reached by > all other non-specefic ips, config like this: > #Wide > ipfw pipe 1000 config bw 40Mbit/s queue 200Kbytes > ipfw pipe 1002 config bw 40Mbit/s queue 200Kbytes > #specefic > ipfw pipe 1003 config bw 9Mbit/s queue 200Kbytes > ipfw pipe 1004 config bw 9Mbit/s queue 200Kbytes > ipfw pipe 1005 config bw 3Mbit/s queue 200Kbytes > ipfw pipe 1006 config bw 3Mbit/s queue 200Kbytes > ipfw pipe 1007 config bw 5Mbit/s queue 200Kbytes > ipfw pipe 1008 config bw 5Mbit/s queue 200Kbytes > ipfw pipe 1009 config bw 10Mbit/s queue 200Kbytes > ipfw pipe 1010 config bw 10Mbit/s queue 200Kbytes > > > with this configuration when i have lots of traffic (3-6GB) going via ix0 > (not necessarly the ips described above, lets say to a server in my net ip > 1832.46.93.4 and users behind the Internet Exchange) i see high cpu usage > (70-90%). > > my first test was to: ipfw add 1 allow all from any to any, and cpu usage > drops immediatly to 10-15%. > but that not why i want (i wantto keep thelimits) so I add rule right > before 4000 and the cpu usage drops down to 10-20%: > 03020 1669463072808 1493341413029803 allow ip from any to any via ix0 > > > Any advice why this happens? or should it be there in the first place? > I use FreeBSD 8.1-R-p10-amd64. > > Thanks in advance, > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 11:19:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F33761065670; Sat, 9 Jun 2012 11:19:46 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B46B8FC0C; Sat, 9 Jun 2012 11:19:46 +0000 (UTC) Received: by obcni5 with SMTP id ni5so4859616obc.13 for ; Sat, 09 Jun 2012 04:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mzcoWRdB/rHv/jj6MwtqRFo23rqKD7HOsW9BXTVs4og=; b=pOO5FFdbfOdCEIUKaTud2J+6WaOMJyTm8/WpGRwYX2EHMxQeYYgpXVX/P9l6vbxbBx HQb8gNaCPbkHvhq31AT3XLjO4BQXFIX0wghBsXiiF2+S0Uv+MTKVEJiV9kE3mibZVIST 5YSTQb5phci+yFkMGDvDeALq//9zLxR7H+QgDyVN5fQ2yGfdxUezWpoySMhrGfBFZhH6 nSwIfJjKyUezs6YELhgK/wafL/fv9wvu8t35KIXypAtZJLO1AXyCTjc+X8viZezequ0X GMqCBINctI/p8o+WqsTk5WgsXc+JXHzLvjNn+NetIqCjbn6HoGhGCFiYB++ewF4F5hS2 AeIw== MIME-Version: 1.0 Received: by 10.182.18.137 with SMTP id w9mr10346001obd.75.1339240786017; Sat, 09 Jun 2012 04:19:46 -0700 (PDT) Received: by 10.182.44.101 with HTTP; Sat, 9 Jun 2012 04:19:45 -0700 (PDT) In-Reply-To: <4FD3224A.3080700@FreeBSD.org> References: <4FD3224A.3080700@FreeBSD.org> Date: Sat, 9 Jun 2012 14:19:45 +0300 Message-ID: From: Sami Halabi To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: ipfw rules consuming CPU 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, 09 Jun 2012 11:19:47 -0000 Hi, all rules togther less than 80 rules.... how tablearg helps this? each ip & pipe (up & down) are unique... any other advices? Sami On Sat, Jun 9, 2012 at 1:15 PM, Alexander V. Chernikov wrote: > On 09.06.2012 01:56, Sami Halabi wrote: > >> Hi, >> >> I Manage a FreeBSD server as an edge router& firewall. >> >> the setup has 10G interfaces (ixgbe-82599EB) and 1G interfaces(em-82571EB& >> bce-BCM5709) connected to 10G/1G switches. >> >> With the following setup i get higher cpu usage: >> bce1-upstream provider with little bandwidth, so i use pipes to limit >> users, and subnets >> ix0 - Internet Exchange >> >> some rules. >> . >> . >> .from 4000 starts pipes for specefic ips bandwidth allocations >> 04000 6210053001 5845967300616 pipe 1003 ip from 182.46.92.13 to any >> out xmit bce1 >> 04100 41289897537 3064110648124 pipe 1004 ip from any to 182.46.92.13 >> in recv bce1 >> > You should use pipe tablearg for that. Traversing 4k rules effectively > kills all performance. > > > . >> . >> . >> .7000 is the wider pipeline for the whole block >> 07000 9127154724 4651308720315 pipe 1000 ip from 182.46.92.0/24 to >> any out xmit bce1 >> 07100 4837016828 458027989917 pipe 1002 ip from any to >> 182.46.92.0/24 in recv bce1 >> last rule default to accept... >> >> specefic pipes (1003-...) have limits say between 1-10Mbps, and the wider >> pipe (1000 and 1002) has a global limit of 40MBps that should be reached >> by >> all other non-specefic ips, config like this: >> #Wide >> ipfw pipe 1000 config bw 40Mbit/s queue 200Kbytes >> ipfw pipe 1002 config bw 40Mbit/s queue 200Kbytes >> #specefic >> ipfw pipe 1003 config bw 9Mbit/s queue 200Kbytes >> ipfw pipe 1004 config bw 9Mbit/s queue 200Kbytes >> ipfw pipe 1005 config bw 3Mbit/s queue 200Kbytes >> ipfw pipe 1006 config bw 3Mbit/s queue 200Kbytes >> ipfw pipe 1007 config bw 5Mbit/s queue 200Kbytes >> ipfw pipe 1008 config bw 5Mbit/s queue 200Kbytes >> ipfw pipe 1009 config bw 10Mbit/s queue 200Kbytes >> ipfw pipe 1010 config bw 10Mbit/s queue 200Kbytes >> >> >> with this configuration when i have lots of traffic (3-6GB) going via ix0 >> (not necessarly the ips described above, lets say to a server in my net ip >> 1832.46.93.4 and users behind the Internet Exchange) i see high cpu usage >> (70-90%). >> >> my first test was to: ipfw add 1 allow all from any to any, and cpu usage >> drops immediatly to 10-15%. >> but that not why i want (i wantto keep thelimits) so I add rule right >> before 4000 and the cpu usage drops down to 10-20%: >> 03020 1669463072808 1493341413029803 allow ip from any to any via ix0 >> >> >> Any advice why this happens? or should it be there in the first place? >> I use FreeBSD 8.1-R-p10-amd64. >> >> Thanks in advance, >> >> > > -- > WBR, Alexander > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 11:37:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id BEEC91065672; Sat, 9 Jun 2012 11:37:07 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 48D5A201BEC; Sat, 9 Jun 2012 11:36:20 +0000 (UTC) Message-ID: <4FD3352F.5060007@FreeBSD.org> Date: Sat, 09 Jun 2012 15:36:15 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sami Halabi References: <4FD3224A.3080700@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: ipfw rules consuming CPU 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, 09 Jun 2012 11:37:07 -0000 On 09.06.2012 15:19, Sami Halabi wrote: > Hi, > all rules togther less than 80 rules.... However, it is too much. You should reduce this to 10 rules or less (at least for main traffic flow). (Btw, there is related http://wiki.freebsd.org/NetworkPerformanceTuning wiki page) > > how tablearg helps this? each ip & pipe (up & down) are unique... ipfw table 1 add 182.46.92.0/24 1000 ipfw table 1 add XXX.XXX.XX.0/24 1001 .. ipfw table 2 add 182.46.92.0/24 1002 ipfw table 2 add XXX.XXX.XX.0/24 1003 ipfw add 4000 pipe tablearg from table(1) to any out xmit bce1 ipfw add 4100 pipe tablearg from any to table(1) in recv bce1 It is often a good idea to split in/out rules initially (e.g. skipto 10000 ip from any to any out) You can send me your ipfw config and we can discuss it more detailed. > > any other advices? > > Sami > > On Sat, Jun 9, 2012 at 1:15 PM, Alexander V. Chernikov > > wrote: > > On 09.06.2012 01:56, Sami Halabi wrote: > > Hi, > > I Manage a FreeBSD server as an edge router& firewall. > > the setup has 10G interfaces (ixgbe-82599EB) and 1G > interfaces(em-82571EB& > bce-BCM5709) connected to 10G/1G switches. > > With the following setup i get higher cpu usage: > bce1-upstream provider with little bandwidth, so i use pipes to > limit > users, and subnets > ix0 - Internet Exchange > > some rules. > . > . > .from 4000 starts pipes for specefic ips bandwidth allocations > 04000 6210053001 5845967300616 pipe 1003 ip from > 182.46.92.13 to any > out xmit bce1 > 04100 41289897537 3064110648124 pipe 1004 ip from any to > 182.46.92.13 > in recv bce1 > > You should use pipe tablearg for that. Traversing 4k rules > effectively kills all performance. > > > . > . > . > .7000 is the wider pipeline for the whole block > 07000 9127154724 4651308720315 pipe 1000 ip from > 182.46.92.0/24 to > any out xmit bce1 > 07100 4837016828 458027989917 pipe 1002 ip from any to > 182.46.92.0/24 in recv bce1 > last rule default to accept... > > specefic pipes (1003-...) have limits say between 1-10Mbps, and > the wider > pipe (1000 and 1002) has a global limit of 40MBps that should be > reached by > all other non-specefic ips, config like this: > #Wide > ipfw pipe 1000 config bw 40Mbit/s queue 200Kbytes > ipfw pipe 1002 config bw 40Mbit/s queue 200Kbytes > #specefic > ipfw pipe 1003 config bw 9Mbit/s queue 200Kbytes > ipfw pipe 1004 config bw 9Mbit/s queue 200Kbytes > ipfw pipe 1005 config bw 3Mbit/s queue 200Kbytes > ipfw pipe 1006 config bw 3Mbit/s queue 200Kbytes > ipfw pipe 1007 config bw 5Mbit/s queue 200Kbytes > ipfw pipe 1008 config bw 5Mbit/s queue 200Kbytes > ipfw pipe 1009 config bw 10Mbit/s queue 200Kbytes > ipfw pipe 1010 config bw 10Mbit/s queue 200Kbytes > > > with this configuration when i have lots of traffic (3-6GB) > going via ix0 > (not necessarly the ips described above, lets say to a server in > my net ip > 1832.46.93.4 and users behind the Internet Exchange) i see high > cpu usage > (70-90%). > > my first test was to: ipfw add 1 allow all from any to any, and > cpu usage > drops immediatly to 10-15%. > but that not why i want (i wantto keep thelimits) so I add rule > right > before 4000 and the cpu usage drops down to 10-20%: > 03020 1669463072808 1493341413029803 allow ip from any to any > via ix0 > > > Any advice why this happens? or should it be there in the first > place? > I use FreeBSD 8.1-R-p10-amd64. > > Thanks in advance, > > > > -- > WBR, Alexander > > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 15:02:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 742531065674; Sat, 9 Jun 2012 15:02:15 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9188FC17; Sat, 9 Jun 2012 15:02:14 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E5A947300B; Sat, 9 Jun 2012 17:21:01 +0200 (CEST) Date: Sat, 9 Jun 2012 17:21:01 +0200 From: Luigi Rizzo To: "Alexander V. Chernikov" Message-ID: <20120609152101.GA39170@onelab2.iet.unipi.it> References: <4FD3224A.3080700@FreeBSD.org> <4FD3352F.5060007@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD3352F.5060007@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Sami Halabi , freebsd-ipfw@freebsd.org Subject: Re: ipfw rules consuming CPU 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, 09 Jun 2012 15:02:15 -0000 On Sat, Jun 09, 2012 at 03:36:15PM +0400, Alexander V. Chernikov wrote: > On 09.06.2012 15:19, Sami Halabi wrote: > >Hi, > >all rules togther less than 80 rules.... > However, it is too much. > You should reduce this to 10 rules or less (at least for main traffic flow). you should definitely try hard to use tablearg or similar tricks to reduce the number of rules traversed. A couple of years ago we did some detailed measurement of the cost of the various operations, see "Dummynet revisited" and "An emulation tool for PlanetLab" at http://info.iet.unipi.it/~luigi/research.html cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 15:44:17 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 000871065672 for ; Sat, 9 Jun 2012 15:44: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 74EEA8FC0C for ; Sat, 9 Jun 2012 15:44:16 +0000 (UTC) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q59ES1Db010957 for ; Sat, 9 Jun 2012 16:28:01 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 801B02CBD18 for ; Sat, 9 Jun 2012 16:27:56 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_7f2ea6bb87e1eea129bb2584420b95f0" Date: Sat, 09 Jun 2012 16:27:56 +0200 From: Gustau Perez Querol To: Message-ID: X-Sender: gperez@entel.upc.edu User-Agent: RoundCube Webmail/0.5.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]); Sat, 09 Jun 2012 16:28:01 +0200 (CEST) Cc: Subject: Panic with if_bridge when removing components 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, 09 Jun 2012 15:44:17 -0000 --=_7f2ea6bb87e1eea129bb2584420b95f0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Hi, I'm seeing panics when removing an interface of a bridge. The system runs HEAD/AMD64 r236733. I see no changes to if_bridge.c in the last two days, so I would say the problem's still there. I also checked stable and the problem should be there too. The problem is that I have a bridge composed of two ethernet interfaces, an ath interface and a tap. As soon as I remove any of them the system panics. Because the system runs openvpn with the tap connected to the bridge, when the system starts to reboot, the openvpn daemon removes the tap and thus causing also the panic. The panic comes because at sys/net/if_bridge.c:943 the struct *ifnet->if_bridge of the interface removed is set to NULL too early. Because of this, at sys/net/if_bridge.c:996 we call if_bridge.c:bridge_linkstate where the struct *ifnet->if_bridge is needed. This causes the panic. I can pastebin the core file if needed. I'm attaching a simple patch that solves it. The struct *ifnet->if_bridge could be set to null only if the interface removed is gone, but I think it won't hurt to set it to null in any case. Regards, Gustau --=_7f2ea6bb87e1eea129bb2584420b95f0 Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=if_bridge.diff Content-Disposition: attachment; filename=if_bridge.diff ZGlmZiAtLWdpdCBhL3N5cy9uZXQvaWZfYnJpZGdlLmMgYi9zeXMvbmV0L2lmX2JyaWRnZS5jCmlu ZGV4IDI3MWVmMzAuLjZjMTEyZGUgMTAwNjQ0Ci0tLSBhL3N5cy9uZXQvaWZfYnJpZGdlLmMKKysr IGIvc3lzL25ldC9pZl9icmlkZ2UuYwpAQCAtOTQwLDcgKzk0MCw2IEBAIGJyaWRnZV9kZWxldGVf bWVtYmVyKHN0cnVjdCBicmlkZ2Vfc29mdGMgKnNjLCBzdHJ1Y3QgYnJpZGdlX2lmbGlzdCAqYmlm LAogCWlmIChiaWYtPmJpZl9mbGFncyAmIElGQklGX1NUUCkKIAkJYnN0cF9kaXNhYmxlKCZiaWYt PmJpZl9zdHApOwogCi0JaWZzLT5pZl9icmlkZ2UgPSBOVUxMOwogCUJSSURHRV9YTE9DSyhzYyk7 CiAJTElTVF9SRU1PVkUoYmlmLCBiaWZfbmV4dCk7CiAJQlJJREdFX1hEUk9QKHNjKTsKQEAgLTk5 NCw2ICs5OTMsNyBAQCBicmlkZ2VfZGVsZXRlX21lbWJlcihzdHJ1Y3QgYnJpZGdlX3NvZnRjICpz Yywgc3RydWN0IGJyaWRnZV9pZmxpc3QgKmJpZiwKIAl9CiAJYnN0cF9kZXN0cm95KCZiaWYtPmJp Zl9zdHApOwkvKiBwcmVwYXJlIHRvIGZyZWUgKi8KIAlicmlkZ2VfbGlua3N0YXRlKGlmcyk7CisJ aWZzLT5pZl9icmlkZ2UgPSBOVUxMOwogCUJSSURHRV9MT0NLKHNjKTsKIAlmcmVlKGJpZiwgTV9E RVZCVUYpOwogfQo= --=_7f2ea6bb87e1eea129bb2584420b95f0-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 17:07:31 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0904106566C for ; Sat, 9 Jun 2012 17:07:31 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id D64958FC12 for ; Sat, 9 Jun 2012 17:07:29 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id EF82ED4812B; Sat, 9 Jun 2012 19:07:22 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id D712BE4B; Sat, 9 Jun 2012 19:07:21 +0200 (CEST) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id A56D5EB6E; Sat, 9 Jun 2012 17:07:21 +0000 (UTC) Date: Sat, 9 Jun 2012 19:07:21 +0200 From: Jeremie Le Hen To: "Eugene M. Zheganin" Message-ID: <20120609170721.GA40355@felucia.tataz.chchile.org> Mail-Followup-To: "Eugene M. Zheganin" , "net@freebsd.org" References: <4FD236D4.6090409@norma.perm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD236D4.6090409@norma.perm.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "net@freebsd.org" Subject: Re: if_ipsec 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, 09 Jun 2012 17:07:31 -0000 Hi Eugene, On Fri, Jun 08, 2012 at 11:31:00PM +0600, Eugene M. Zheganin wrote: > Hi. > > I have an idea about new networking feature in FreeBSD. > I guess everyone is having ideas from time to time, and lots of these > idea having people think that they just had a decent idea. However, only > ideas that are complemented by a working code can be considered by the > community, and only some of them got commited into the tree, I am fully > aware of this fact. > > Unfortunately, I am not able to produce the code. I guess this is the > point where most of the subscribers will (or at least should) stop > reading this post. Still, I'm addressing this post for people that have > the time and will to do something interesting. I guess that someone may > find this interesting. Myself, I find that this could be really useful. > > (You can skip this part and the next part if you only want to read about > the idea) I work about 10 years as a network engineer. My company holds > country-wide supermarkets business. I am personally responsible for the > network infrastructure of the company. As the company has lots of > (hundreds) of branch offices, lots of my time I'm constructing new VPNs > between them. My company network infrastructure is build using FreeBSD > servers and Cisco (and last year - Juniper) equipment. So I am aware and > capable of building VPN of almost any modern type, and this is the post > about building it on FreeBSD (this annoying passage was written to give > you impression that I'm not just a guy with FreeBSD server at home, > holding a couple of movies). > > So. About VPNs. Another annoying passage about common ways and caveats. > Otherwise most of the reading ppl will say 'Why the hell if_ipsec ?' > (ppl that are aware of the VPNs can really skip this part). The > conventional way to build vpn is to build a tunnel of some sort. This > can be an encrypted tunnel, or an unencrypted tunnel. Unencrypted > tunnel (gre/ipinip) is obviously unencrypted, but gives you an > interface which could be using in routing. Encrypted tunnel (and I'm > talking about ipsec) cannot be used for rounting, but is encrypted. > Plus, you have to care about policies, and when multiple routers are > involved, with hundreds of networks behind them, you have to care about > tonns of policies, and this is painful. So, the industry invented a > method: you use a gre/ipinip tunnel, you pass the dynamic routing > information (you don't care bout networks, you only care abouth the > endpoints), and you encrypt this tunnel with ipsec. So, gre + ipsec (of > gif + ipsec). This way is supported by all of the major vendors, you can > build gre(ipinip)+ipsec tunnel to any Cisco/Juniper device. Though > building in to JunOS requires some skill and a deep knowledge. :) > > (here the idea starts) But what is an gre or gif tunnel ? This is not an > interface, but a way to tell the system, that it needs to encapsulate > some of the payload with another header, and send it somewhere. So, > using ipsec you add an extra header, and using gre(ipinip) you add an > extra header. What if we will add an additional ability to understand > that some of the ipsec packets are destined to the security gateway > (which adds the extra header) itself, like it's possible with > gre/ipinip, so we can get rid of one extra header ? Cisco/Juniper did > that. So, Cisco has the 'tun mode ipsec ipvX' interface, and Juniper has > the st (secure tunnel) interface. How does it work: it's a convenstional > ISAKMP IPsec with the ability to treat some of the packets with a > particular IP like destined to the local (by this I mean 'this') host. > Besides this it's the old IPsec. It's even interoperable between > different vendors devices. I don't see any reason why FreeBSD cannot > have this ability, since it does have a working Ipsec and working > ISAKMP. In order to obtain this functionality FreeBSD needs to have a > way to define the templates for the SPD entries, and the way to create > these SPD entries after the creation of the interface, based on it's > address information. This will really simplify the VPN creating and > management. > > So... here was the idea. :) > It came to my head after configuring the Juniper/Cisco VPN (and the > config was really short), and after reading quagga-users@ maillist, > where some of the subscribers asked about 'tun mode ipsec'. Plus, as far > as I know, Linux does not support this too, so we could really score > some points. I'm not sure I've understood what you're asking. As a network engineer, I'm sure you know there are two modes with IPSec: tunnel and transport. Tunnel mode is weird because it practically creates an encrypted tunnel, but the later is invisible from the OS, IIRC. With transport mode just encrypt the payload (that is, the data after the IP header) when the SPD says so. What it usually done for convenience is to create a gif(4) or gre(4) tunnel to another network, which is then encrypted using IPSec transport mode. The inner IP/GRE header is considered as the payload and it is encrypted. The benefit of this approach is that you "see" your tunnel, it looks more natural from a system point of view. I haven't used IPSec in tunnel mode for more than a decades, so I don't remember how it is manageable. But with the IPSec transport mode + gif/gre tunnel, you see a full-fledged interface toward the other network, through which you can route your traffic. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 17:12:34 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6EC91065673; Sat, 9 Jun 2012 17:12:34 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5BD8FC0A; Sat, 9 Jun 2012 17:12:33 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q59HCWY1085420; Sun, 10 Jun 2012 00:12:32 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FD38400.3030109@rdtc.ru> Date: Sun, 10 Jun 2012 00:12:32 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: jlh@freebsd.org, "net@freebsd.org" References: <4FD236D4.6090409@norma.perm.ru> <20120609170721.GA40355@felucia.tataz.chchile.org> In-Reply-To: <20120609170721.GA40355@felucia.tataz.chchile.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Subject: Re: if_ipsec 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, 09 Jun 2012 17:12:34 -0000 10.06.2012 00:07, Jeremie Le Hen пишет: > I'm not sure I've understood what you're asking. As a network engineer, > I'm sure you know there are two modes with IPSec: tunnel and transport. > > Tunnel mode is weird because it practically creates an encrypted tunnel, > but the later is invisible from the OS, IIRC. Basically, he wants tunnel mode to create full-blown network interface without overhead for extra gre/gif packet header. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 20:07:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5E81106566B for ; Sat, 9 Jun 2012 20:07:10 +0000 (UTC) (envelope-from mike@magicislandtechnologies.com) Received: from mail.magicislandtechnologies.com (mail.magicislandtechnologies.com [74.208.96.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0018FC16 for ; Sat, 9 Jun 2012 20:07:10 +0000 (UTC) Received: (qmail 10442 invoked from network); 10 Jun 2012 04:11:12 +0400 Received: from adsl-99-121-29-49.dsl.sfldmi.sbcglobal.net (HELO ?99.121.29.49?) (99.121.29.49) by mail.magicislandtechnologies.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Jun 2012 04:11:12 +0400 Message-ID: <4FD3B05E.3050006@magicislandtechnologies.com> Date: Sat, 09 Jun 2012 16:21:50 -0400 From: Michael Spratt User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <4FD3224A.3080700@FreeBSD.org> In-Reply-To: <4FD3224A.3080700@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Sami Halabi , freebsd-ipfw@freebsd.org Subject: Re: ipfw rules consuming CPU 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, 09 Jun 2012 20:07:10 -0000 I have Linux & FreeBSD systems running ipfw with 80 rules with 70Mb/s symmetric, passing traffic for about 1000-1200 hosts. Alexander V. Chernikov wrote: > On 09.06.2012 01:56, Sami Halabi wrote: >> Hi, >> >> I Manage a FreeBSD server as an edge router& firewall. >> the setup has 10G interfaces (ixgbe-82599EB) and 1G >> interfaces(em-82571EB& >> bce-BCM5709) connected to 10G/1G switches. >> >> With the following setup i get higher cpu usage: >> bce1-upstream provider with little bandwidth, so i use pipes to limit >> users, and subnets >> ix0 - Internet Exchange >> >> some rules. >> . >> . >> .from 4000 starts pipes for specefic ips bandwidth allocations >> 04000 6210053001 5845967300616 pipe 1003 ip from 182.46.92.13 >> to any >> out xmit bce1 >> 04100 41289897537 3064110648124 pipe 1004 ip from any to >> 182.46.92.13 >> in recv bce1 > You should use pipe tablearg for that. Traversing 4k rules effectively > kills all performance. > >> . >> . >> . >> .7000 is the wider pipeline for the whole block >> 07000 9127154724 4651308720315 pipe 1000 ip from >> 182.46.92.0/24 to >> any out xmit bce1 >> 07100 4837016828 458027989917 pipe 1002 ip from any to >> 182.46.92.0/24 in recv bce1 >> last rule default to accept... >> >> specefic pipes (1003-...) have limits say between 1-10Mbps, and the >> wider >> pipe (1000 and 1002) has a global limit of 40MBps that should be >> reached by >> all other non-specefic ips, config like this: >> #Wide >> ipfw pipe 1000 config bw 40Mbit/s queue 200Kbytes >> ipfw pipe 1002 config bw 40Mbit/s queue 200Kbytes >> #specefic >> ipfw pipe 1003 config bw 9Mbit/s queue 200Kbytes >> ipfw pipe 1004 config bw 9Mbit/s queue 200Kbytes >> ipfw pipe 1005 config bw 3Mbit/s queue 200Kbytes >> ipfw pipe 1006 config bw 3Mbit/s queue 200Kbytes >> ipfw pipe 1007 config bw 5Mbit/s queue 200Kbytes >> ipfw pipe 1008 config bw 5Mbit/s queue 200Kbytes >> ipfw pipe 1009 config bw 10Mbit/s queue 200Kbytes >> ipfw pipe 1010 config bw 10Mbit/s queue 200Kbytes >> >> >> with this configuration when i have lots of traffic (3-6GB) going via >> ix0 >> (not necessarly the ips described above, lets say to a server in my >> net ip >> 1832.46.93.4 and users behind the Internet Exchange) i see high cpu >> usage >> (70-90%). >> >> my first test was to: ipfw add 1 allow all from any to any, and cpu >> usage >> drops immediatly to 10-15%. >> but that not why i want (i wantto keep thelimits) so I add rule right >> before 4000 and the cpu usage drops down to 10-20%: >> 03020 1669463072808 1493341413029803 allow ip from any to any via ix0 >> >> >> Any advice why this happens? or should it be there in the first place? >> I use FreeBSD 8.1-R-p10-amd64. >> >> Thanks in advance, >> > > From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 20:19:01 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 06AE21065677 for ; Sat, 9 Jun 2012 20:19:01 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 85B4217728F for ; Sat, 9 Jun 2012 20:18:17 +0000 (UTC) Message-ID: <4FD3AF84.7080108@FreeBSD.org> Date: Sun, 10 Jun 2012 00:18:12 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: net@freebsd.org Content-Type: multipart/mixed; boundary="------------020105060805080907060909" Cc: Subject: [commit approval request] sbin/ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 20:19:01 -0000 This is a multi-part message in MIME format. --------------020105060805080907060909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Andrey, Konstantin! Please approve the following commit: -- Update maximum number of tables available in ipfw to reflect changes done in r233478. Approved by: (mentor) MFC after: 3 days -- -- WBR, Alexander --------------020105060805080907060909 Content-Type: text/plain; charset=UTF-8; name="man_ipfw_tables_max.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="man_ipfw_tables_max.diff" Index: sbin/ipfw/ipfw.8 =================================================================== --- sbin/ipfw/ipfw.8 (revision 236818) +++ sbin/ipfw/ipfw.8 (working copy) @@ -1,7 +1,7 @@ .\" .\" $FreeBSD$ .\" -.Dd March 9, 2012 +.Dd June 10, 2012 .Dt IPFW 8 .Os .Sh NAME @@ -1733,7 +1733,7 @@ Lookup tables are useful to handle large sparse sets of addresses or other search keys (e.g. ports, jail IDs, interface names). In the rest of this section we will use the term ``address''. -There may be up to 4096 different lookup tables, numbered 0 to 4095. +There may be up to 65535 different lookup tables, numbered 0 to 65534. .Pp Each entry is represented by an .Ar addr Ns Op / Ns Ar masklen --------------020105060805080907060909-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 20:19:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6DA5106564A; Sat, 9 Jun 2012 20:19:11 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0A38FC1E; Sat, 9 Jun 2012 20:19:11 +0000 (UTC) Received: by obcni5 with SMTP id ni5so5571284obc.13 for ; Sat, 09 Jun 2012 13:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FP48LHnFG2rGApaMwpUftineE5NSzHabfW2hXfQDx2E=; b=dtGjDqsL7YQAmBV0Tyl/0QcmJUxokHecL1CIuHZQYf9cmo0Uc0F8zhOb/tfSzCM21A SA8C7U/xnTY3Id8/cmeWnp9hZ28SpQlpX/Y9fY8w55+vgXMQseHLKrmjEZOjOdywz3W0 FM7TgHrOHTgPd0Rx0iRang6D69wYExlh3SBsjzCtYzlZPS+8tqowNuxO8+X+NnYBlxYP oQXP/Em7PQMv7qrbpKIRnEMBQzsobu+0q+dWaMmMWhFRIJNsvGlGidt3GCdUhb+5Te4b Z4onDd8pAIbZa9SoVGLDNsgfeyD3lKANA43qcfLs5c444VDmwnRx6gIgGw+h6BmDO8YX C6Fg== MIME-Version: 1.0 Received: by 10.182.36.102 with SMTP id p6mr11332923obj.77.1339273150978; Sat, 09 Jun 2012 13:19:10 -0700 (PDT) Received: by 10.182.44.101 with HTTP; Sat, 9 Jun 2012 13:19:10 -0700 (PDT) In-Reply-To: <4FD3B05E.3050006@magicislandtechnologies.com> References: <4FD3224A.3080700@FreeBSD.org> <4FD3B05E.3050006@magicislandtechnologies.com> Date: Sat, 9 Jun 2012 23:19:10 +0300 Message-ID: From: Sami Halabi To: Michael Spratt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Alexander V. Chernikov" , freebsd-ipfw@freebsd.org Subject: Re: ipfw rules consuming CPU 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, 09 Jun 2012 20:19:11 -0000 on my box with 130 rules 100Mbit the cpu don't go above 5%. I daily manage 1.5-6GB. Thanks in advance, Sami On Sat, Jun 9, 2012 at 11:21 PM, Michael Spratt < mike@magicislandtechnologies.com> wrote: > I have Linux & FreeBSD systems running ipfw with 80 rules with 70Mb/s > symmetric, passing traffic for about 1000-1200 hosts. > > > Alexander V. Chernikov wrote: > >> On 09.06.2012 01:56, Sami Halabi wrote: >> >>> Hi, >>> >>> I Manage a FreeBSD server as an edge router& firewall. >>> the setup has 10G interfaces (ixgbe-82599EB) and 1G >>> interfaces(em-82571EB& >>> bce-BCM5709) connected to 10G/1G switches. >>> >>> With the following setup i get higher cpu usage: >>> bce1-upstream provider with little bandwidth, so i use pipes to limit >>> users, and subnets >>> ix0 - Internet Exchange >>> >>> some rules. >>> . >>> . >>> .from 4000 starts pipes for specefic ips bandwidth allocations >>> 04000 6210053001 5845967300616 pipe 1003 ip from 182.46.92.13 to >>> any >>> out xmit bce1 >>> 04100 41289897537 3064110648124 pipe 1004 ip from any to >>> 182.46.92.13 >>> in recv bce1 >>> >> You should use pipe tablearg for that. Traversing 4k rules effectively >> kills all performance. >> >> . >>> . >>> . >>> .7000 is the wider pipeline for the whole block >>> 07000 9127154724 4651308720315 pipe 1000 ip from 182.46.92.0/24to >>> any out xmit bce1 >>> 07100 4837016828 458027989917 pipe 1002 ip from any to >>> 182.46.92.0/24 in recv bce1 >>> last rule default to accept... >>> >>> specefic pipes (1003-...) have limits say between 1-10Mbps, and the wider >>> pipe (1000 and 1002) has a global limit of 40MBps that should be reached >>> by >>> all other non-specefic ips, config like this: >>> #Wide >>> ipfw pipe 1000 config bw 40Mbit/s queue 200Kbytes >>> ipfw pipe 1002 config bw 40Mbit/s queue 200Kbytes >>> #specefic >>> ipfw pipe 1003 config bw 9Mbit/s queue 200Kbytes >>> ipfw pipe 1004 config bw 9Mbit/s queue 200Kbytes >>> ipfw pipe 1005 config bw 3Mbit/s queue 200Kbytes >>> ipfw pipe 1006 config bw 3Mbit/s queue 200Kbytes >>> ipfw pipe 1007 config bw 5Mbit/s queue 200Kbytes >>> ipfw pipe 1008 config bw 5Mbit/s queue 200Kbytes >>> ipfw pipe 1009 config bw 10Mbit/s queue 200Kbytes >>> ipfw pipe 1010 config bw 10Mbit/s queue 200Kbytes >>> >>> >>> with this configuration when i have lots of traffic (3-6GB) going via ix0 >>> (not necessarly the ips described above, lets say to a server in my net >>> ip >>> 1832.46.93.4 and users behind the Internet Exchange) i see high cpu usage >>> (70-90%). >>> >>> my first test was to: ipfw add 1 allow all from any to any, and cpu usage >>> drops immediatly to 10-15%. >>> but that not why i want (i wantto keep thelimits) so I add rule right >>> before 4000 and the cpu usage drops down to 10-20%: >>> 03020 1669463072808 1493341413029803 allow ip from any to any via ix0 >>> >>> >>> Any advice why this happens? or should it be there in the first place? >>> I use FreeBSD 8.1-R-p10-amd64. >>> >>> Thanks in advance, >>> >>> >> >> > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sat Jun 9 21:29:05 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEB3C106566B; Sat, 9 Jun 2012 21:29:05 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id ED8BA8FC08; Sat, 9 Jun 2012 21:29:04 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so1363831wib.13 for ; Sat, 09 Jun 2012 14:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dxGBpzWGUaTKy79D8V6ufq4W+au7G1hxdEGx1LBXn2g=; b=i5v9K3VVa7WvJ1Ld0aFXNONSWmaM6Z2du/8q21Wq+oMvtFhKE3rWh2m/vSL/uw7RC1 CDu2trdKaWKK/EToBh0qV7eUq7uN5EpAJsPpXO668FyIPFbLrq6NtKPTrTKkwNJtfGkn d8B6jgBO8ZaORhVZ84MiwngnawKV2MywF+MVhMC+4cecI97kSluYavxggaymfMJN6GhQ qqPjqLqXomb+tedFJkRn9AA3HRyE+VNjYdiYFuOSfCGAuyqmk4/lGUTVcn18tofjGNqz PkS/iuYqzn3EdUbECuO2cS3TNyoAWB1lSqnrM83D3kyZOfA8Xo9a+naLF9vHJjN/o9ck WI6g== MIME-Version: 1.0 Received: by 10.180.24.193 with SMTP id w1mr9823264wif.5.1339277342378; Sat, 09 Jun 2012 14:29:02 -0700 (PDT) Received: by 10.223.155.4 with HTTP; Sat, 9 Jun 2012 14:29:02 -0700 (PDT) In-Reply-To: References: <4FD0C1F4.2060108@FreeBSD.org> Date: Sat, 9 Jun 2012 14:29:02 -0700 Message-ID: From: Kevin Oberman To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wojciech Puchar , hackers@freebsd.org, "Alexander V. Chernikov" , net@freebsd.org Subject: Re: ifconfig accepting hostname as ipv4 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 21:29:05 -0000 On Sat, Jun 9, 2012 at 12:37 AM, Garrett Cooper wrote: > On Sat, Jun 9, 2012 at 12:23 AM, Wojciech Puchar > wrote: >>> input. >>> Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you >>> can't set valid CIDR address using this notation. >>> >>> Classful era has ended more than 10 years ago, do we still want to keep >>> this behavior? >>> >> were not aware of that option, and it is rather stupid option - you shou= ld >> work on addresses not names when configuring network > > =A0 =A0I agree that it's not the best configuration in the world, as it > would only work 100% if a machine had proper DNS records or a > definitive hosts file. > =A0 =A0There are already enough bugs with static IP configurations and > hostnames as-is *I'm looking at you mountlate* -- no sense to > introduce more potentially buggy interoperability that only works in a > handful of niche cases. The idea was that you could enter all of the local interface names in /etc/hosts and than just put the names into the ifconfig commands. It was handy for keeping track of what port connected where on systems that had numerous interfaces, though this was more common in the day of async serial lines and modems. I'll admit that I have mixed feelings about its practicality today, though it does not hurt anything, as far as I can tell. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com