From owner-freebsd-net@FreeBSD.ORG Sun Oct 20 00:30:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F263191; Sun, 20 Oct 2013 00:30:27 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D15882A30; Sun, 20 Oct 2013 00:30:26 +0000 (UTC) X-Envelope-From: egrosbein@rdtc.ru X-Envelope-To: freebsd-net@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r9K0UFBa058391; Sun, 20 Oct 2013 07:30:15 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <52632417.8090609@rdtc.ru> Date: Sun, 20 Oct 2013 07:30:15 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Intel 82580 lagg(4) problem References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> <20131018112519.Horde.OAQo4gNXUK8BEHk3Ha0pIw2@mail.polynet.lviv.ua> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eg.sd.rdtc.ru Cc: FreeBSD Net , Andriy Kopystyansky , mybsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 00:30:27 -0000 On 19.10.2013 00:48, Adrian Chadd wrote: > Oh wait a sec - you mean that you're running freebsd-8.4 but with the > freebsd-8.3 driver (and freebsd-8.4 lagg?) igb(4) statistics are broken in 8.4 due to bad MFC, look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182828 kern/182828 was closed by glebius@ but the problem not fixed and that PR has a fix. From owner-freebsd-net@FreeBSD.ORG Sun Oct 20 04:57:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 96A42378; Sun, 20 Oct 2013 04:57:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 448142539; Sun, 20 Oct 2013 04:57:56 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id s14so3004281qeb.33 for ; Sat, 19 Oct 2013 21:57: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:message-id:subject :from:to:cc:content-type; bh=1YopUDXhCQipptRVai/K2ykrkdOsrQTnr3p3Fss+G24=; b=N6G6aY+P3nKgGa9VJcAmGGhE5zcV0tQwGYrM2BNVZUoJv7I6acIgd9Ug2/44NsW+lW nfhbzB4UNaogo73HhdTxgca+vrCgdQcMEUd542hn6ooUtoqCC3NeAHjBL2aiDvkWtYFR MIlUpFVeandCdaOkH2x0Q3vMzn0BiRhoZh1YHSbXfODesJ8Vd/tkRzLWyS7NToJScs5m ehU2DRCQ+1yzoh3RXNQQnFW3M/LDHjPZv3kz5XjOvhwrWXPA/dlQe+QxKedlJgVuGTWt phDXJ+ExuU6D2vceXtp276CaaEDCLHNM6rSvJ5cbqiahc2G/IyAXW3KcrhQ5qh4c1OaU RbIw== MIME-Version: 1.0 X-Received: by 10.49.0.208 with SMTP id 16mr14636224qeg.25.1382245074907; Sat, 19 Oct 2013 21:57:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 19 Oct 2013 21:57:54 -0700 (PDT) In-Reply-To: <52632417.8090609@rdtc.ru> References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> <20131018112519.Horde.OAQo4gNXUK8BEHk3Ha0pIw2@mail.polynet.lviv.ua> <52632417.8090609@rdtc.ru> Date: Sat, 19 Oct 2013 21:57:54 -0700 X-Google-Sender-Auth: 4CSGRyMIORKaE9i3sMuhh2Zfm8I Message-ID: Subject: Re: Intel 82580 lagg(4) problem From: Adrian Chadd To: Eugene Grosbein , Jack F Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Andriy Kopystyansky , mybsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 04:57:56 -0000 Hi, I've re-opened the PR and bounced it to jack. He did the e1000 merge and didn't bring over the required drbr changes (or remove them from the e1000 merge.) Thanks, -adrian On 19 October 2013 17:30, Eugene Grosbein wrote: > On 19.10.2013 00:48, Adrian Chadd wrote: > > Oh wait a sec - you mean that you're running freebsd-8.4 but with the > > freebsd-8.3 driver (and freebsd-8.4 lagg?) > > igb(4) statistics are broken in 8.4 due to bad MFC, > look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182828 > > kern/182828 was closed by glebius@ but the problem not fixed > and that PR has a fix. > > From owner-freebsd-net@FreeBSD.ORG Sun Oct 20 06:58:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F97B43D for ; Sun, 20 Oct 2013 06:58:36 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 271EA2921 for ; Sun, 20 Oct 2013 06:58:36 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id v10so970687pde.29 for ; Sat, 19 Oct 2013 23:58:35 -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:message-id:subject :from:to:cc:content-type; bh=GQ1vox+GqnpBt6yqJB5FRYEfbePjZg3tUjaErR/UUJU=; b=jHWHqpiL/0RqxHeEaqFOoW7kqaPtg9WIOwsL4QaQbpQZdMRnvsl+o9NwI/KIv1XRoZ KIpkjHfVGffOzvd8rD9Rsuei31Me7BdTip5ZsQV1GLnQ7ykLxLXnKurzpLHV7O0ftnti qw+veNzS3+PDQN3rxXOn4NO1zIPh0ik0oJMEkoZQqIwj7TxDQQCI+G9ALkLHVEVpYc89 9krbmNkegK9jMZxjR/qiTjbIwDsyeDlsmw0bc3TzNp3H2NV99d+YYfqQTuZI0840xQ3f uLv4GMhrMpDAnuy8hZVwfVWPC/mTRIEFhXEnfU03kIWoXpsqIGbRgR6ek6rk0IY/s9sQ xk5A== MIME-Version: 1.0 X-Received: by 10.66.65.134 with SMTP id x6mr325083pas.142.1382252315730; Sat, 19 Oct 2013 23:58:35 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.67.23.101 with HTTP; Sat, 19 Oct 2013 23:58:35 -0700 (PDT) In-Reply-To: <1381227544.227894604@f404.i.mail.ru> References: <1381160691.954872513@f116.i.mail.ru> <1381227544.227894604@f404.i.mail.ru> Date: Sat, 19 Oct 2013 23:58:35 -0700 X-Google-Sender-Auth: Z3ZWkpZb2kTBzDiVlelhrnOkF9k Message-ID: Subject: Re: Re[5]: Assymetric NIC performance problem From: Kevin Oberman To: Konstantin Kuzvesov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 06:58:36 -0000 On Tue, Oct 8, 2013 at 3:19 AM, Konstantin Kuzvesov wrote: > On Mon, Oct 7, 2013 at 16:57 -07:00, Kevin Oberman > wrote: > > On Mon, Oct 7, 2013 at 8:44 AM, Konstantin Kuzvesov > > wrote: > > > I've got a FreeBSD file server running Samba, file upload speeds are okay, > but downloads are too slow. > First, I decided it is Samba's fault, but then I ran iperf tests... > > On a windows machine with gigabit NIC: > Z:\iperf>iperf -c 192.168.0.1 > ------------------------------------------------------------ > Client connecting to 192.168.0.1, TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.0.2 port 1064 connected with 192.168.0.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.2 sec 12.4 MBytes 10.2 Mbits/sec > > Z:\iperf>iperf -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.0.2 port 5001 connected with 192.168.0.1 port 41220 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-10.0 sec 716 MBytes 600 Mbits/sec > > And on a another with FastEthernet NIC: > C:\iperf>iperf.exe -c 192.168.0.1 > ------------------------------------------------------------ > Client connecting to 192.168.0.1, TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.0.5 port 4756 connected with 192.168.0.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.1 sec 11.4 MBytes 9.42 Mbits/sec > > C:\iperf>iperf.exe -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.0.5 port 5001 connected with 192.168.0.1 port 18558 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-10.0 sec 106 MBytes 88.5 Mbits/sec > > Both tests show server's NIC performance degradation to around 10Mbit/s > when traffic goes from server to client. And everything works fine in other > direction. > > I verified the cables and hub by simply connecting server and a test > machine with a new short patch cord. I tried to change server's NIC from > D-Link DGE-528T to Planet ENW-9604. And it became even worse - > using Planet NIC > speeds slowed down to around 500Mbit/s to server and the same 10Mbit/s to > client. I tried to change NIC's media to 100BaseTX, it didn't help too. > What else should I try to fix the problem? Maybe my system requires is just > misconfigured? > > System configuration: > OS: FreeBSD 9.2-release > Kernel: generic > Firewall: none > /boot/loader.conf - load zfs modules only > /etc/sysctl.conf - empty > NIC: D-Link DGE-528T / Planet ENW-9604 > > -- > Konstantin Kuzvesov > > > Output from ifconfig would probably be helpful, but I'd also suggest that > you capture packets (or, at least headers) for at least the start of the > transfer and look at them with wireshark or some similar tool. > > wireshark can tell you quite a bit and, if you feed the capture into > tcptrace, you can really see what is happening. (Note, wireshark provides > indications of problems that can make sense to people not conversant with > the gory details of TCP, though some issues may not be obvious. tcptrace > output can be utterly cryptic if you don't understand a lot of the details > of TCP and congestion control. > > Both wireshark and tcptrace are in ports and are best installed on a > workstation. The tcpdump output can be used as input to both. ("tcpdump -pw > FILE -i INTERFACE host ADDRESS" can do the job. Then copy the capture to > the right place for analysis. But start with configuration and counters for > the interface (netstat -i). > -- > R. Kevin Oberman, Network Engineer > E-mail: rkoberman@gmail.com > > > Sorry, I didn't know that UDP bandwidth must be specified manually, > otherwise it defaults to 1.0Mbit/s. > New UDP tests show that there must be some TCP misconfiguration: > > > #iperf -s -u > ------------------------------------------------------------ > Server listening on UDP port 5001 > Receiving 1470 byte datagrams > UDP buffer size: 41.1 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.0.1 port 5001 connected with 192.168.0.2 port 1039 > > [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams > [ 3] 0.0-10.0 sec 626 MBytes 525 Mbits/sec 0.062 ms 13181/459995 (2.9%) > > [ 3] 0.0-10.0 sec 1 datagrams received out-of-order > > #iperf -c 192.168.0.2 -u -b 1000M > ------------------------------------------------------------ > Client connecting to 192.168.0.2, UDP port 5001 > Sending 1470 byte datagrams > UDP buffer size: 9.00 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.0.1 port 15347 connected with 192.168.0.2 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 882 MBytes 740 Mbits/sec > [ 3] Sent 632673 datagrams > [ 3] WARNING: did not receive ack of last datagram after 10 tries. > > The only problem wireshark showed to me is wrong IP header checksums in > packets originated from server. > > -- > Konstantin Kuzvesov > > Sorry for the long break, but my wife and I have been traveling and I am just catching up on things. Ugh! 740 Mbit/sec is pretty bad. UDP at .95G should not be a problem. As you probably know, the checksum fails since checksums are off-loaded. I have no experience with your card. I can say that RealTek based cards are generally not the best, so that may be an issue, but I can't be sure. 740M is really pretty poor, though. I am assuming that these systems are within a very few microseconds of each other. I also assume the systems are both running the same version of FreeBSD and the same hardware with the same configurations. If this is not the case, please let me know as it might change things. Can you examine the inter-packet delay? Plotting it would be interesting and can be done from the packet capture with any of several tools. The UDP rate should be VERY consistent for UDP. Perhaps less so for TCP. I suspect that at least the TCP timings will be inconsistent. The trick is figuring out why. If the UDP times are not consistent, then something very bad is going on in the transmitting system. Even if they are consistent, something is not right. Can you provide the packet capture of the TCP test? It need only be the headers (the first 40 bytes). iperf data is pretty boring. :-) I think that wireshark can "edit" the capture if you need to obfuscate the address. I also realized that the FreeBSD port is still iperf-2.03. Version 3 has been out for quite a while. I'll drop the maintainer a note asking if there is a reason for not updating the port. This should not be relevant to any testing you are doing other than to eliminate some bogus messages. It does clean up the code and adds a few nice capabilities. The people who maintain iperf work in the tools and research groups where I work (at least until the end of November), so I am probably more aware then most of development work. I will also ask Jon about any issues the code might have on FreeBSD since Linux is now used for development of our tools. (Not my idea.) -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Oct 20 07:39:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E2FA8B57 for ; Sun, 20 Oct 2013 07:39:14 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7DBCA2AA8 for ; Sun, 20 Oct 2013 07:39:14 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hm4so2630800wib.8 for ; Sun, 20 Oct 2013 00:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=W12hy1/oglZUB1XJb/qKAFKv7YzrfmV86VvbrPlbwP4=; b=CX14zU8qAPxPcjoIMwHwsZbImsd8EHrm2Zh6zxlH87ngZH9rMq1xfXYzCG3bISoMAt XB6k90RoXnKSKTPdXTwWaA5q1kkw9ikmWBxgTx8fwH+k5VgEao/4obmgXA8PSI4QJ5Ho LC/CK1IJQJiXFcUte2MGbsQkCDEFxjCaZyXHhxDgfuZD3GJij5Xc92ot5bvdBPwIOrE5 b9/NtjlDlsaBJuN4YTgYM86gyDY32Lpn+I9QYsNjqEN78PaHsEQv4DcfnkhuUrPt20ep 7QIMnUGGord/LSxLepOxyYDM0UuBlcW+g9W/FC8RsfUHSXC/4rgHmosZbhmR7cJYmKZt iuuA== X-Received: by 10.194.240.197 with SMTP id wc5mr9170604wjc.23.1382254752878; Sun, 20 Oct 2013 00:39:12 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.119.73 with HTTP; Sun, 20 Oct 2013 00:38:52 -0700 (PDT) In-Reply-To: References: From: h bagade Date: Sun, 20 Oct 2013 11:08:52 +0330 X-Google-Sender-Auth: pEfu-e7es9y6jelGHGe2KJAtFzY Message-ID: Subject: Re: Netmap and in-kernel IPFW interactions! To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Raimundo Santos X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 07:39:15 -0000 On Sat, Oct 19, 2013 at 8:13 PM, Luigi Rizzo wrote: > > On Sat, Oct 19, 2013 at 9:32 AM, h bagade wrote: > >> On Sat, Oct 19, 2013 at 6:58 PM, Raimundo Santos >> wrote: >> >> > On 19 October 2013 06:00, h bagade wrote: >> > >> >> >> I've changed em and igb drivers too. In this situation, I think that they >> are using netmap and grow-up performance is a sign of the change. I've >> used pkt-gen for performance checking. >> > > you use netmap only when you use a netmap-aware tool, > such as pkt-gen. > > The normal stack still uses the regular drivers. > > cheers > luigi > I am somehow confused how it is possible that netmap-aware tools use netmap datapath and others still use the regular driver! Isn't that the changed NIC driver either send the packets to userspace(in case of netmap) or to the kernel(as usual)? Netmap is really interesting and I am eager to know the architecture and how packets flow using netmap or not. From owner-freebsd-net@FreeBSD.ORG Sun Oct 20 20:05:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5CD86BF1 for ; Sun, 20 Oct 2013 20:05:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B5762C96 for ; Sun, 20 Oct 2013 20:05:51 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id 8so3276562qea.32 for ; Sun, 20 Oct 2013 13:05:50 -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=lToUZc1gbmnjOVRtLVA5Dntivohb5CUm/P7W3w0OUCE=; b=HzoB4id0oj7U6NUPay+6+15n2tZgZTsCwgMZs/6GYrq2rgYaM8om2EXQughlLBDIkN KkOeqOVlXdUH/mTh1wJyPsst14PxxXDDjchsEMTvloL4L4P0Ux8nCHg6EkMXw5oR/eMM yOWgMX1OxZe9PvnceWnOdmnHE4z4tK5ezozw4iZgkIg9oXUcqD5S6CZ/SaLSPGSY+Gzm ubSLqoa+pu75ggy7jHtMPMDVBUDy7rMpTZKAoUkDD7c8tauR7sT13HgnuAcwa7QUW7Z3 0s7sypus5OMAUYv54HmfNn7WQBtiLU9jFfAddH1urTtVLtRTtbAwkNHE1MUAgicqe1jr Fq2g== MIME-Version: 1.0 X-Received: by 10.224.24.131 with SMTP id v3mr19192912qab.48.1382299550286; Sun, 20 Oct 2013 13:05:50 -0700 (PDT) Received: by 10.224.207.66 with HTTP; Sun, 20 Oct 2013 13:05:50 -0700 (PDT) Received: by 10.224.207.66 with HTTP; Sun, 20 Oct 2013 13:05:50 -0700 (PDT) In-Reply-To: References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> <20131018112519.Horde.OAQo4gNXUK8BEHk3Ha0pIw2@mail.polynet.lviv.ua> Date: Sun, 20 Oct 2013 13:05:50 -0700 Message-ID: Subject: Re: Intel 82580 lagg(4) problem From: Adrian Chadd To: Andriy Kopystyansky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , mybsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 20:05:51 -0000 So.. Diff the driver between 8.3 and 8.4. What changed? Adrian On Oct 18, 2013 1:48 PM, "Adrian Chadd" wrote: > Oh wait a sec - you mean that you're running freebsd-8.4 but with the > freebsd-8.3 driver (and freebsd-8.4 lagg?) > > > -adrian > > > > On 18 October 2013 01:25, Andriy Kopystyansky wrote= : > >> >> =D0=A6=D0=B8=D1=82=D1=83=D1=8E mybsd : >> >> >> Set net.link.lagg.0.use_flowid=3D0 not solve the problem. >>> >>> My system is freebsd 8.4, use the e1000 driver from freebsd 8.3 solves >>> this problem . >>> Should confirm that the problem is driver >>> >>> I have already submitted the BUG. >>> http://www.freebsd.org/cgi/**query-pr.cgi?pr=3D182917 >>> >>> >> I can confirm, e1000 driver from freebsd 8.3 works as expected, i've got >> almost 1.8 Gb/s over lagg(4) interface, whereas using default driver fro= m >> 9.1 couldnt get more than 1.2Gb/s. >> Trying iperf test to two different dst: >> 1) [SUM] 0.0-54.5 sec 5.50 GBytes 867 Mbits/sec >> 2) [SUM] 0.0-90.1 sec 9.25 GBytes 882 Mbits/sec >> >> ifstat on lagg,igb using 8.3 driver: >> anri@host:[11:01]~#ifstat -i lagg1,igb0,igb2 >> lagg1 igb0 igb2 >> >> KB/s in KB/s out KB/s in KB/s out KB/s in KB/s out >> 21748.67 221021.3 10419.36 122968.5 11442.13 150645.1 >> 22010.81 222652.2 10954.49 125154.8 11161.90 150698.2 >> >> Test above was performed with net.link.lagg.1.use_flowid=3D1 >> Setting this to =3D0 leads to slightly less throughput, and noticable cp= u >> overhead. (I havent any non-ip traffic). >> >> -- >> >> >> >> >> >> ______________________________**_________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org<= freebsd-net-unsubscribe@freebsd.org> >> " >> > > From owner-freebsd-net@FreeBSD.ORG Sun Oct 20 20:10:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CCD29C9E for ; Sun, 20 Oct 2013 20:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA5D22CC0 for ; Sun, 20 Oct 2013 20:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9KKA1Bc097983 for ; Sun, 20 Oct 2013 20:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9KKA1Xa097982; Sun, 20 Oct 2013 20:10:01 GMT (envelope-from gnats) Date: Sun, 20 Oct 2013 20:10:01 GMT Message-Id: <201310202010.r9KKA1Xa097982@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Eitan Adler Subject: Re: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Eitan Adler List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 20:10:01 -0000 The following reply was made to PR kern/157410; it has been noted by GNATS. From: Eitan Adler To: bug-followup Cc: Subject: Re: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use Date: Sun, 20 Oct 2013 16:04:34 -0400 ---------- Forwarded message ---------- From: Loganaden Velvindron Date: Mon, Jul 1, 2013 at 4:30 PM Subject: Re: kern/157410: [ip6] IPv6 Router Advertisements Cause Excessive CPU Use To: freebsd-net@freebsd.org Cc: bz@freebsd.org On Mon, Jul 01, 2013 at 12:58:23PM -0700, Loganaden Velvindron wrote: > Hi I came across this old PR. It appears that it's not fixed in -current. > > I attempted to port the diff to our FreeBSD 9.1 release machines which > have IPv6 connectivity and are affected by RA flooding. > > I can report that it mitigates RA_flooding. > > Feedback welcomed. I'd be happy to polish it so that it can > make it to 9.2 and 10.0 :-) > > I broke down the diffs into separate ones. > > The last diff (nd6_rtr.diff) was garbled and another diff was missing. I'm resending the whole patchset. --- in6.c.orig 2013-06-30 23:07:46.000000000 +0400 +++ in6.c 2013-07-01 19:20:15.000000000 +0400 @@ -2694,6 +2694,8 @@ in6_domifattach(struct ifnet *ifp) ext->nd_ifinfo = nd6_ifattach(ifp); ext->scope6_id = scope6_ifattach(ifp); ext->lltable = lltable_init(ifp, AF_INET6); + ext->nprefixes = 0; + ext->ndefrouters = 0; if (ext->lltable != NULL) { ext->lltable->llt_free = in6_lltable_free; ext->lltable->llt_prefix_free = in6_lltable_prefix_free; --- in6_proto.c.orig 2013-06-30 23:07:58.000000000 +0400 +++ in6_proto.c 2013-07-01 21:05:08.000000000 +0400 @@ -413,7 +413,8 @@ VNET_DEFINE(int, ip6_rr_prune) = 5; /* r * walk list every 5 sec. */ VNET_DEFINE(int, ip6_mcast_pmtu) = 0; /* enable pMTU discovery for multicast? */ VNET_DEFINE(int, ip6_v6only) = 1; - +VNET_DEFINE(int, ip6_maxifprefixes) = 16; +VNET_DEFINE(int, ip6_maxifdefrouters) = 16; VNET_DEFINE(int, ip6_keepfaith) = 0; VNET_DEFINE(time_t, ip6_log_time) = (time_t)0L; #ifdef IPSTEALTH @@ -524,6 +525,10 @@ SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6C &VNET_NAME(ip6stat), ip6stat, ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGPACKETS, maxfragpackets, CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, ""); +SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXIFPREFIXES, maxifprefixes, + CTLFLAG_RW, &VNET_NAME(ip6_maxifprefixes), 0, ""); +SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXIFDEFROUTERS, maxifdefrouters, + CTLFLAG_RW, &VNET_NAME(ip6_maxifdefrouters), 0, ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_ACCEPT_RTADV, accept_rtadv, CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, "Default value of per-interface flag for accepting ICMPv6 Router" --- in6_var.h.orig 2013-06-30 23:08:28.000000000 +0400 +++ in6_var.h 2013-07-01 22:38:03.000000000 +0400 @@ -104,6 +104,8 @@ struct in6_ifextra { struct scope6_id *scope6_id; struct lltable *lltable; struct mld_ifinfo *mld_ifinfo; + int nprefixes; + int ndefrouters; }; #define LLTABLE6(ifp) (((struct in6_ifextra *)(ifp)->if_afdata[AF_INET6])->lltable) --- ip6_var.h.orig 2013-06-30 23:09:22.000000000 +0400 +++ ip6_var.h 2013-07-01 20:28:30.000000000 +0400 @@ -315,6 +315,8 @@ VNET_DECLARE(int, ip6_maxfragpackets); / * queue */ VNET_DECLARE(int, ip6_maxfrags); /* Maximum fragments in reassembly * queue */ +VNET_DECLARE(int, ip6_maxifprefixes); +VNET_DECLARE(int, ip6_maxifdefrouters); VNET_DECLARE(int, ip6_accept_rtadv); /* Acts as a host not a router */ VNET_DECLARE(int, ip6_no_radr); /* No defroute from RA */ VNET_DECLARE(int, ip6_norbit_raif); /* Disable R-bit in NA on RA --- nd6.h.orig 2013-06-30 23:09:42.000000000 +0400 +++ nd6.h 2013-07-01 22:16:09.000000000 +0400 @@ -277,6 +277,7 @@ struct nd_prefix { u_char ndpr_plen; int ndpr_refcnt; /* reference couter from addresses */ }; +#define ndpr_next ndpr_entry.le_next #define ndpr_raf ndpr_flags #define ndpr_raf_onlink ndpr_flags.onlink --- in6.h.orig 2013-07-02 00:24:36.000000000 +0400 +++ in6.h 2013-07-01 21:58:04.000000000 +0400 @@ -607,7 +607,6 @@ struct ip6_mtuinfo { #define IPV6CTL_ISATAPRTR 43 /* isatap router */ #endif #define IPV6CTL_MCAST_PMTU 44 /* enable pMTU discovery for multicast? */ - /* New entries should be added here from current IPV6CTL_MAXID value. */ /* to define items, should talk with KAME guys first, for *BSD compatibility */ #define IPV6CTL_STEALTH 45 @@ -619,6 +618,9 @@ struct ip6_mtuinfo { #define IPV6CTL_RFC6204W3 50 /* Accept defroute even when forwarding enabled */ #define IPV6CTL_MAXID 51 +#define IPV6CTL_MAXIFPREFIXES 52 +#define IPV6CTL_MAXIFDEFROUTERS 53 + #endif /* __BSD_VISIBLE */ /* --- nd6_rtr.c.orig 2013-06-30 23:10:24.000000000 +0400 +++ nd6_rtr.c 2013-07-01 22:40:29.000000000 +0400 @@ -83,6 +83,7 @@ static void nd6_rtmsg(int, struct rtentr static int in6_init_prefix_ltimes(struct nd_prefix *); static void in6_init_address_ltimes __P((struct nd_prefix *, struct in6_addrlifetime *)); +static void purge_detached(struct ifnet *); static int nd6_prefix_onlink(struct nd_prefix *); static int nd6_prefix_offlink(struct nd_prefix *); @@ -565,6 +566,7 @@ defrtrlist_del(struct nd_defrouter *dr) { struct nd_defrouter *deldr = NULL; struct nd_prefix *pr; + struct in6_ifextra *ext = dr->ifp->if_afdata[AF_INET6]; /* * Flush all the routing table entries that use the router @@ -597,6 +599,12 @@ defrtrlist_del(struct nd_defrouter *dr) if (deldr) defrouter_select(); + ext->ndefrouters--; + if (ext->ndefrouters < 0) { + log(LOG_WARNING, "defrtrlist_del: negative count on %s\n", + dr->ifp->if_xname); + } + free(dr, M_IP6NDP); } @@ -734,6 +742,7 @@ static struct nd_defrouter * defrtrlist_update(struct nd_defrouter *new) { struct nd_defrouter *dr, *n; + struct in6_ifextra *ext = new->ifp->if_afdata[AF_INET6]; int s = splnet(); if ((dr = defrouter_lookup(&new->rtaddr, new->ifp)) != NULL) { @@ -775,6 +784,12 @@ defrtrlist_update(struct nd_defrouter *n splx(s); return (dr); } + /*struct in6_ifextra *ext = new->ifp->if_afdata[AF_INET6];*/ + if (ip6_maxifdefrouters >= 0 && + ext->ndefrouters >= ip6_maxifdefrouters) { + splx(s); + return (NULL); + } /* entry does not exist */ if (new->rtlifetime == 0) { @@ -810,6 +825,8 @@ insert: defrouter_select(); + ext->ndefrouters++; + splx(s); return (n); @@ -868,6 +885,44 @@ nd6_prefix_lookup(struct nd_prefixctl *k return (search); } +static void +purge_detached(struct ifnet *ifp) +{ + struct nd_prefix *pr, *pr_next; + struct in6_ifaddr *ia; + struct ifaddr *ifa, *ifa_next; + + for (pr = nd_prefix.lh_first; pr; pr = pr_next) { + pr_next = pr->ndpr_next; + + /* + * This function is called when we need to make more room for + * new prefixes rather than keeping old, possibly stale ones. + * Detached prefixes would be a good candidate; if all routers + * that advertised the prefix expired, the prefix is also + * probably stale. + */ + if (pr->ndpr_ifp != ifp || + IN6_IS_ADDR_LINKLOCAL(&pr->ndpr_prefix.sin6_addr) || + ((pr->ndpr_stateflags & NDPRF_DETACHED) == 0 && + !LIST_EMPTY(&pr->ndpr_advrtrs))) + continue; + + for (ifa = ifp->if_addrlist.tqh_first; ifa; ifa = ifa_next) { + ifa_next = ifa->ifa_list.tqe_next; + if (ifa->ifa_addr->sa_family != AF_INET6) + continue; + ia = (struct in6_ifaddr *)ifa; + if ((ia->ia6_flags & IN6_IFF_AUTOCONF) == + IN6_IFF_AUTOCONF && ia->ia6_ndpr == pr) { + in6_purgeaddr(ifa); + } + } + if (pr->ndpr_refcnt == 0) + prelist_remove(pr); + } +} + int nd6_prelist_add(struct nd_prefixctl *pr, struct nd_defrouter *dr, struct nd_prefix **newp) @@ -876,6 +931,14 @@ nd6_prelist_add(struct nd_prefixctl *pr, int error = 0; int i, s; char ip6buf[INET6_ADDRSTRLEN]; + struct in6_ifextra *ext = pr->ndpr_ifp->if_afdata[AF_INET6]; + + if (ip6_maxifprefixes >= 0) { + if (ext->nprefixes >= ip6_maxifprefixes / 2) + purge_detached(pr->ndpr_ifp); + if (ext->nprefixes >= ip6_maxifprefixes) + return ENOMEM; + } new = (struct nd_prefix *)malloc(sizeof(*new), M_IP6NDP, M_NOWAIT); if (new == NULL) @@ -923,7 +986,7 @@ nd6_prelist_add(struct nd_prefixctl *pr, if (dr) pfxrtr_add(new, dr); - + ext->nprefixes++; return 0; } @@ -933,6 +996,7 @@ prelist_remove(struct nd_prefix *pr) struct nd_pfxrouter *pfr, *next; int e, s; char ip6buf[INET6_ADDRSTRLEN]; + struct in6_ifextra *ext = pr->ndpr_ifp->if_afdata[AF_INET6]; /* make sure to invalidate the prefix until it is really freed. */ pr->ndpr_vltime = 0; @@ -965,6 +1029,12 @@ prelist_remove(struct nd_prefix *pr) LIST_FOREACH_SAFE(pfr, &pr->ndpr_advrtrs, pfr_entry, next) { free(pfr, M_IP6NDP); } + + ext->nprefixes--; + if (ext->nprefixes < 0) { + log(LOG_WARNING, "prelist_remove: negative count on %s\n", + pr->ndpr_ifp->if_xname); + } splx(s); free(pr, M_IP6NDP); _______________________________________________ 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" -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 00:44:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99A5DF30; Mon, 21 Oct 2013 00:44:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BA372CD3; Mon, 21 Oct 2013 00:44:13 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id r9L0i4mP085117 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Oct 2013 17:44:06 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <526478D0.1000601@freebsd.org> Date: Mon, 21 Oct 2013 08:44:00 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Colin Percival , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> In-Reply-To: <52605EC9.6090406@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 00:44:14 -0000 On 10/18/13 6:03 AM, Colin Percival wrote: > Hi all, > > I know {TSO, LRO, ACKing policy} has been discussed here recently, and I don't > want to rehash everything, but I'm seeing some very bad misbehaviour with LRO > and delayed ACKing turned on. > > Running 'fetch -o /dev/null https://www.amazon.com/' on an EC2 instance running [...] is this just for -current? > Out of 142 ms that this TCP connection is alive, 100 ms was wasted. This seems > like something which ought to be fixed... > From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 01:44:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0C991E2D for ; Mon, 21 Oct 2013 01:44:08 +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 BEF342022 for ; Mon, 21 Oct 2013 01:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=m45Vb5BjwCn9XcF5dnBPlyVZTBM=; b=PeSWdjAcWJzgBmtQST iWLEfm56CS5miH7VV1i+GJzGz8Zu8eOBtRj0EtFseBmt4yaZzB+bohvFodd+q3+l Q/d8ISCAFcBJdflppBKpIc10YZtr2JUu7tt8kdoTpnlvG9keYYSatPTEsoIdOdcp 9X4B2+s+gbYUIUoALJkltG8gw= Received: by mf21 with SMTP id mf21.9550.526486E67 Mon, 21 Oct 2013 01:44:06 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi17 (SG) with ESMTP id 141d8aef453.185.2457f70 for ; Mon, 21 Oct 2013 01:44:06 +0000 (UTC) Received: (qmail 85133 invoked from network); 21 Oct 2013 01:44:05 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 21 Oct 2013 01:44:05 -0000 Received: (qmail 75352 invoked from network); 21 Oct 2013 01:42:54 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 21 Oct 2013 01:42:54 -0000 Message-ID: <5264869E.4000308@freebsd.org> Date: Sun, 20 Oct 2013 18:42:54 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> In-Reply-To: <526478D0.1000601@freebsd.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxH0p0B8WINVqHgZLJ6EVWriWAfOAcdgKav5Hsrd2jvz7v3UcsmVho1qt3IYgqW2c47ipqOfZ/gaNgswyDsrqUHxrNWLt5DMFEOfBjgkp8Nvogg6Ymxs3bWxiL9WS33rG1M= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 01:44:08 -0000 On 10/20/13 17:44, Julian Elischer wrote: > On 10/18/13 6:03 AM, Colin Percival wrote: >> I know {TSO, LRO, ACKing policy} has been discussed here recently, and I don't >> want to rehash everything, but I'm seeing some very bad misbehaviour with LRO >> and delayed ACKing turned on. >> >> Running 'fetch -o /dev/null https://www.amazon.com/' on an EC2 instance running > [...] > is this just for -current? Good question. Turns out that it isn't -- on 9.2 I see a 95.5 ms delayed ACK: > 00:00:00.000000 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [S], seq 3310207763, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 292712 ecr 0], length 0 > 00:00:00.001031 IP 176.32.98.166.443 > 10.142.129.245.59172: Flags [S.], seq 3504196464, ack 3310207764, win 8190, options [mss 1460,nop,wscale 6], length 0 > 00:00:00.001139 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 > 00:00:00.002269 IP 176.32.98.166.443 > 10.142.129.245.59172: Flags [.], ack 1, win 127, length 0 > 00:00:00.002938 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [P.], seq 1:140, ack 1, win 1026, length 139 > 00:00:00.003815 IP 176.32.98.166.443 > 10.142.129.245.59172: Flags [.], seq 1:4097, ack 140, win 108, length 4096 > 00:00:00.099328 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [.], ack 4097, win 1026, length 0 but not on 9.1... although that might just be that LRO isn't happening: > 00:00:00.000000 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [S], seq 2729946716, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 64564 ecr 0], length 0 > 00:00:00.000722 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [S.], seq 595247561, ack 2729946717, win 8190, options [mss 1460,nop,wscale 6], length 0 > 00:00:00.000820 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 > 00:00:00.001998 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], ack 1, win 127, length 0 > 00:00:00.002716 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [P.], seq 1:140, ack 1, win 1026, length 139 > 00:00:00.003527 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], ack 140, win 108, length 0 > 00:00:00.003834 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], seq 1:1461, ack 140, win 108, length 1460 > 00:00:00.003850 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], seq 1461:2921, ack 140, win 108, length 1460 > 00:00:00.003870 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [.], ack 2921, win 981, length 0 > 00:00:00.003888 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [P.], seq 2921:4097, ack 140, win 108, length 1176 > 00:00:00.003973 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [.], ack 4097, win 1026, length 0 I can't find any changes in netfront.c or tcp_lro.c to explain why 9.1 and 9.2 are behaving differently -- anyone have any ideas? -- 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 Oct 21 08:52:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 900A3D0F for ; Mon, 21 Oct 2013 08:52:53 +0000 (UTC) (envelope-from anri@polynet.lviv.ua) Received: from postal.polynet.lviv.ua (postal.polynet.lviv.ua [195.22.112.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2969E2621 for ; Mon, 21 Oct 2013 08:52:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polynet.lviv.ua; s=dkimpolynet; h=Subject:Content-Transfer-Encoding:MIME-Version:Content-Type:In-Reply-To:References:To:From:Message-ID:Date; bh=G1TtzfUv3VRIAB/o8gyC1uQ7xjmPqs8pHfCbWH6HVmo=; b=b6G5f02+41rw19ut0ywYVztdRMj7I0E4xOP3w9YPkXyLTJvlOO6F08XqVwsBRHPsnhW+2LhjjWlPqOxgoWQLwNcWGDQaleWURw28oTxesq9IbgI0YUHXdY8q7TATe6rOSr+vBIyF6TK2E6cZuzcSFYJOHL5Lqk4gfLKc/6jMXmw=; Received: from postoffice.lp.lviv.ua ([192.168.0.6] helo=postal.polynet.lviv.ua) by postal.polynet.lviv.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VYBEJ-0001Wl-Mz for freebsd-net@freebsd.org; Mon, 21 Oct 2013 11:52:51 +0300 Received: from vega.polynet.lviv.ua (vega.polynet.lviv.ua [195.22.112.3]) by mail.polynet.lviv.ua (Horde Framework) with HTTP; Mon, 21 Oct 2013 11:52:51 +0300 Date: Mon, 21 Oct 2013 11:52:51 +0300 Message-ID: <20131021115251.Horde.GEMc-A7kT55W11hnsIFv3g1@mail.polynet.lviv.ua> From: Andriy Kopystyansky To: freebsd-net@freebsd.org References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> <20131018112519.Horde.OAQo4gNXUK8BEHk3Ha0pIw2@mail.polynet.lviv.ua> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.5-git) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.0.6 X-SA-Exim-Mail-From: anri@polynet.lviv.ua X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on postal.polynet.lviv.ua X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.8 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.2 Subject: Re: Intel 82580 lagg(4) problem X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on postal.polynet.lviv.ua) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 08:52:53 -0000 Actually, it was running FreeBSD 8.4 with driver=20=20 from=208.3, and by his advise i'm using this driver on my FreeBSD 9.1.=20= =20 Native=20driver came with FreeBSD9.1, or the new one downloaded from=20=20 Intel=20site (igb-2.3.10) seems to be useless in LACP lagg(4). =D0=A6=D0=B8=D1=82=D1=83=D1=8E=20Adrian=20Chadd=20: >=20So..=20Diff=20the=20driver=20between=208.3=20and=208.4.=20What=20change= d? > >=20Adrian >=20On=20Oct=2018,=202013=201:48=20PM,=20"Adrian=20Chadd"=20=20wrote: > >>=20Oh=20wait=20a=20sec=20-=20you=20mean=20that=20you're=20running=20freeb= sd-8.4=20but=20with=20the >>=20freebsd-8.3=20driver=20(and=20freebsd-8.4=20lagg?) >> >> >>=20-adrian >> >> >> >>=20On=2018=20October=202013=2001:25,=20Andriy=20Kopystyansky=20wrote: >> >>> >>>=20=D0=A6=D0=B8=D1=82=D1=83=D1=8E=20mybsd=20: >>> >>> >>>=20=20Set=20net.link.lagg.0.use_flowid=3D0=20not=20solve=20the=20problem= .. >>>> >>>>=20My=20system=20is=20freebsd=208.4,=20use=20the=20e1000=20driver=20fro= m=20freebsd=208.3=20solves >>>>=20this=20problem=20. >>>>=20Should=20confirm=20that=20the=20problem=20is=20driver >>>> >>>>=20I=20have=20already=20submitted=20the=20BUG. >>>>=20http://www.freebsd.org/cgi/**query-pr.cgi?pr=3D182917 >>>> >>>> >>>=20I=20can=20confirm,=20e1000=20driver=20from=20freebsd=208.3=20works=20= as=20expected,=20i've=20got >>>=20almost=201.8=20Gb/s=20over=20lagg(4)=20interface,=20whereas=20using= =20default=20driver=20from >>>=209.1=20couldnt=20get=20more=20than=201.2Gb/s. >>>=20Trying=20iperf=20test=20to=20two=20different=20dst: >>>=201)=20[SUM]=20=200.0-54.5=20sec=20=205.50=20GBytes=20=20=20867=20Mbits= /sec >>>=202)=20[SUM]=20=200.0-90.1=20sec=20=209.25=20GBytes=20=20=20882=20Mbits= /sec >>> >>>=20ifstat=20on=20lagg,igb=20using=208.3=20driver: >>>=20anri@host:[11:01]~#ifstat=20-i=20lagg1,igb0,igb2 >>>=20=20=20=20=20=20=20lagg1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20igb0=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20igb2 >>> >>>=20=20KB/s=20in=20=20KB/s=20out=20=20=20KB/s=20in=20=20KB/s=20out=20=20= =20KB/s=20in=20=20KB/s=20out >>>=2021748.67=20=20221021.3=20=2010419.36=20=20122968.5=20=2011442.13=20= =20150645.1 >>>=2022010.81=20=20222652.2=20=2010954.49=20=20125154.8=20=2011161.90=20= =20150698.2 >>> >>>=20Test=20above=20was=20performed=20with=20net.link.lagg.1.use_flowid=3D= 1 >>>=20Setting=20this=20to=20=3D0=20leads=20to=20slightly=20less=20throughpu= t,=20and=20noticable=20cpu >>>=20overhead. (I havent any non-ip traffic). >>> >>> -- >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to=20=20 >>>=20"freebsd-net-unsubscribe@**freebsd.org >>> " >>> >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 10:04:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9FA97A5D for ; Mon, 21 Oct 2013 10:04:08 +0000 (UTC) (envelope-from universite@ukr.net) Received: from frv197.fwdcdn.com (frv197.fwdcdn.com [212.42.77.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57E632A89 for ; Mon, 21 Oct 2013 10:04:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=Rt+Kcudso+d1ojNyajlWB2w2feMlg/hSqb1e2cBHR8U=; b=Qjw0inJAExtn2hLGLu5aqKjnAHLc0zTwUDXf8VYuHMSErufyApvZEI7YVZMU36EH6EKjarlq0/G/9P9epU7cT+mD32sgl/IxszYKtkhardJSOOkavXWW+yD0s+lAOpGrRR8L51gtwpW5ws3oJw7y36EoIBv34/1RPOYVjozyBq4=; Received: from [10.10.10.35] (helo=frv35.ukr.net) by frv197.fwdcdn.com with smtp ID 1VYCL7-000Lem-QO for freebsd-net@freebsd.org; Mon, 21 Oct 2013 13:03:57 +0300 Date: Mon, 21 Oct 2013 13:03:55 +0300 From: Vladislav Prodan Subject: Re[2]: bce(4) on the Dell PE 2950 To: sbruno@freebsd.org X-Mailer: freemail.ukr.net 5.0 Message-Id: <1382348528.946877215.p9ajhvig@frv35.ukr.net> In-Reply-To: <1382120967.1386.1.camel@localhost> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> <525F7CC9.4000800@ukr.net> <1382030121.2570.1.camel@localhost> <52606B26.5090809@ukr.net> <1382099580.21269.35571405.3EE3ACE7@webmail.messagingengine.com> <52612E3E.9060607@inbox.im> <1382120967.1386.1.camel@localhost> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.ukr.net; Mon, 21 Oct 2013 13:03:55 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: freebsd-net@freebsd.org, Nicolas de Bari Embriz Garcia Rojas X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 10:04:08 -0000 > On Fri, 2013-10-18 at 13:49 +0100, Nicolas de Bari Embriz Garcia Rojas > wrote: > > What is the latest stable firmware and in what firmware version you get > > this issue ? > > > > regards > > > This ridiculous web link *should* take you there to get new firmware: > http://www.dell.com/support/drivers/us/en/555/DriverDetails/Product/poweredge-2950?driverId=P32M4&osCode=RH60&fileId=3230162487&languageCode=EN&categoryId=NI > > Known "good" firmware output from bce(4) on bootup: > > bce0: mem > 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci9 > miibus0: on bce0 > bce0: Ethernet address: 00:18:8b:52:0e:42 > bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) > bce1: mem > 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci5 > miibus1: on bce1 > bce1: Ethernet address: 00:18:8b:52:0e:40 > bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C > (5.0.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (ipms 1.6.0) Hello I downloaded the latest driver available online Dell - 7.6.15. I installed a Windows Live CD. Now I have a B/C (7.4.0), and you have the above text - 5.0.4 Now I have, like, the timeouts are gone, but the VLANs on bce something does not work ... -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 11:06:51 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD3E3A54 for ; Mon, 21 Oct 2013 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9A5D2E1E for ; Mon, 21 Oct 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9LB6pqf018717 for ; Mon, 21 Oct 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9LB6p4J018715 for freebsd-net@FreeBSD.org; Mon, 21 Oct 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Oct 2013 11:06:51 GMT Message-Id: <201310211106.r9LB6p4J018715@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN Realtek® 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181699 net [ipsec] [patch] IPsec does scale to large SPD / SADB o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181225 net [infiniband] [patch] unloading ipoib crashes the kerne o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/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/166462 net [gre] gre(4) when using a tunnel source address from c 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 p kern/165903 net mbuf leak 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/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/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/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S 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/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 [new driver] [request]: Port brcm80211 driver from Lin 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 p 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/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/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/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 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 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/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 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 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/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging 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/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ 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 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/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/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 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 469 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 12:07:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2F6A67D7 for ; Mon, 21 Oct 2013 12:07:34 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D9C372378 for ; Mon, 21 Oct 2013 12:07:33 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VYEGQ-0006T0-CI for freebsd-net@freebsd.org; Mon, 21 Oct 2013 14:07:14 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Oct 2013 14:07:14 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Oct 2013 14:07:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Subject: Re: Netmap and in-kernel IPFW interactions! Date: Mon, 21 Oct 2013 14:06:52 +0200 Lines: 41 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hMfln7fn4gObt5OXNuSiISq8laik0HXDF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: X-Enigmail-Version: 1.5.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 12:07:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hMfln7fn4gObt5OXNuSiISq8laik0HXDF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20/10/2013 09:38, h bagade wrote: > I am somehow confused how it is possible that netmap-aware tools use ne= tmap > datapath and others still use the regular driver! Isn't that the change= d > NIC driver either send the packets to userspace(in case of netmap) or t= o > the kernel(as usual)? I think you are misunderstanding what netmap does. It is not a type of a "driver", it has almost nothing to do with the way regular network packets are processed in the kernel. It is an API which allow specially created userspace program to send and receive raw packeges to/from the network card, bypassing the normal TCP/IP processing. It does not do anything other that that (e.g. it doesn't magically speed up network traffic with regular programs, etc.). --hMfln7fn4gObt5OXNuSiISq8laik0HXDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlJlGN1fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSwmlgCgnGyT9X4rBJo6IWV2nvT2m0f/ wPEAn3bsqzsAXIdHu+/RGQmbb+7hv4G5 =RvrB -----END PGP SIGNATURE----- --hMfln7fn4gObt5OXNuSiISq8laik0HXDF-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 15:15:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 890393FC for ; Mon, 21 Oct 2013 15:15:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E825E2E6F for ; Mon, 21 Oct 2013 15:15:36 +0000 (UTC) Received: (qmail 42324 invoked from network); 21 Oct 2013 15:47:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2013 15:47:36 -0000 Message-ID: <5265450C.1060601@freebsd.org> Date: Mon, 21 Oct 2013 17:15:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Colin Percival , Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> In-Reply-To: <5264869E.4000308@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:15:37 -0000 On 21.10.2013 03:42, Colin Percival wrote: > On 10/20/13 17:44, Julian Elischer wrote: >> On 10/18/13 6:03 AM, Colin Percival wrote: >>> I know {TSO, LRO, ACKing policy} has been discussed here recently, and I don't >>> want to rehash everything, but I'm seeing some very bad misbehaviour with LRO >>> and delayed ACKing turned on. >>> >>> Running 'fetch -o /dev/null https://www.amazon.com/' on an EC2 instance running >> [...] >> is this just for -current? > > Good question. Turns out that it isn't -- on 9.2 I see a 95.5 ms delayed ACK: > >> 00:00:00.000000 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [S], seq 3310207763, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 292712 ecr 0], length 0 >> 00:00:00.001031 IP 176.32.98.166.443 > 10.142.129.245.59172: Flags [S.], seq 3504196464, ack 3310207764, win 8190, options [mss 1460,nop,wscale 6], length 0 >> 00:00:00.001139 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 >> 00:00:00.002269 IP 176.32.98.166.443 > 10.142.129.245.59172: Flags [.], ack 1, win 127, length 0 >> 00:00:00.002938 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [P.], seq 1:140, ack 1, win 1026, length 139 >> 00:00:00.003815 IP 176.32.98.166.443 > 10.142.129.245.59172: Flags [.], seq 1:4097, ack 140, win 108, length 4096 >> 00:00:00.099328 IP 10.142.129.245.59172 > 176.32.98.166.443: Flags [.], ack 4097, win 1026, length 0 > > but not on 9.1... although that might just be that LRO isn't happening: >> 00:00:00.000000 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [S], seq 2729946716, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 64564 ecr 0], length 0 >> 00:00:00.000722 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [S.], seq 595247561, ack 2729946717, win 8190, options [mss 1460,nop,wscale 6], length 0 >> 00:00:00.000820 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 >> 00:00:00.001998 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], ack 1, win 127, length 0 >> 00:00:00.002716 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [P.], seq 1:140, ack 1, win 1026, length 139 >> 00:00:00.003527 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], ack 140, win 108, length 0 >> 00:00:00.003834 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], seq 1:1461, ack 140, win 108, length 1460 >> 00:00:00.003850 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [.], seq 1461:2921, ack 140, win 108, length 1460 >> 00:00:00.003870 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [.], ack 2921, win 981, length 0 >> 00:00:00.003888 IP 176.32.98.166.443 > 10.148.177.92.48728: Flags [P.], seq 2921:4097, ack 140, win 108, length 1176 >> 00:00:00.003973 IP 10.148.177.92.48728 > 176.32.98.166.443: Flags [.], ack 4097, win 1026, length 0 > > I can't find any changes in netfront.c or tcp_lro.c to explain why 9.1 and > 9.2 are behaving differently -- anyone have any ideas? The last time I looked our soft-LRO had a few remaining issues. One of them was that in certain situations reordering may happen with segments that can't be aggregated into a LRO state. The other was that the driver is responsible to manage the flushing of LRO states that haven't seen updates in some time. Most drivers likely don't do that correctly for the simple reason that IIRC never has been a description on how to do that correctly. This may explain why there is so much latency. Normally a LRO state should not wait more than 5-10ms before flushing. Also the total amount of time it can aggregate segments is not limited which can be bad too. IIRC Navdeep did a couple of changes to the Chelsio driver to work around some of these problems. Taking a closer look at tcp_lro.c and fixing these issues is on my todo list but I haven't come by it yet. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 16:41:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CF01A1DA for ; Mon, 21 Oct 2013 16:41:02 +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 55F572456 for ; Mon, 21 Oct 2013 16:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=YAwzhzPJSvmB3nuYkJU9bH92cNI=; b=oivrmVhqaIxPUYOvmQ loYL/8A67W4vVoBUs/Gz/M+3sgh8bfHtV64VGTTdwsKadvkTOKZQwko5sp8Zg9Ir CTZNC65zwxol5dbHDW7BdHau58h5fvZIvqorxTyfK9jpQW/HWKv+e6syAYvelz9h dI12Efoimfq+ovThfnPZB5Owk= Received: by filter-173.sjc1.sendgrid.net with SMTP id filter-173.20385.5265591C2 Mon, 21 Oct 2013 16:41:00 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi23 (SG) with ESMTP id 141dbe41701.621.5f90c2 for ; Mon, 21 Oct 2013 16:41:00 +0000 (UTC) Received: (qmail 15764 invoked from network); 21 Oct 2013 16:40:59 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 21 Oct 2013 16:40:59 -0000 Received: (qmail 79968 invoked from network); 21 Oct 2013 16:39:46 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 21 Oct 2013 16:39:46 -0000 Message-ID: <526558D2.3010505@freebsd.org> Date: Mon, 21 Oct 2013 09:39:46 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Andre Oppermann , Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> In-Reply-To: <5265450C.1060601@freebsd.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxGf5pR9AmGV/QFF/MWIo0qUAkcm2F9VWiGcDB9KU8Q7kK0NtthMy+EzcQzHKBg38K6Xuia5KOw/MujnwFGQvvsGxapLk7iXrAAC/nAsoVHiNW9h6ZZICYpiJgQdZj6AEUM= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:41:02 -0000 On 10/21/13 08:15, Andre Oppermann wrote: > On 21.10.2013 03:42, Colin Percival wrote: >> I can't find any changes in netfront.c or tcp_lro.c to explain why 9.1 and >> 9.2 are behaving differently -- anyone have any ideas? > > The last time I looked our soft-LRO had a few remaining issues. One of > them was that in certain situations reordering may happen with segments > that can't be aggregated into a LRO state. The other was that the driver > is responsible to manage the flushing of LRO states that haven't seen > updates in some time. It looks like the netfront driver flushes LRO every time it finishes reading packets -- if anything, it's too aggressive: /* * Flush any outstanding LRO work */ while (!SLIST_EMPTY(&lro->lro_active)) { queued = SLIST_FIRST(&lro->lro_active); SLIST_REMOVE_HEAD(&lro->lro_active, next); tcp_lro_flush(lro, queued); } So unless that code is broken somehow (it looks reasonable to me) I don't think it's a problem of data getting stuck in soft-LRO. Looking at the TCP stack on the other hand confuses me -- I see code which seems to be saying that we can delay-ACK any time that we're receiving data and don't have a delayed ACK already pending, without any regard for the fact that we might be receiving 2+ MSS at once... am I missing something here? -- 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 Oct 21 17:17:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF7EC645; Mon, 21 Oct 2013 17:17:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90AC72724; Mon, 21 Oct 2013 17:17:43 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id r9LHHccg088184 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 10:17:41 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <526561AD.8030906@freebsd.org> Date: Tue, 22 Oct 2013 01:17:33 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Colin Percival , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> <526558D2.3010505@freebsd.org> In-Reply-To: <526558D2.3010505@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:17:43 -0000 On 10/22/13 12:39 AM, Colin Percival wrote: > So unless that code is broken somehow (it looks reasonable to me) I > don't think it's a problem of data getting stuck in soft-LRO. > Looking at the TCP stack on the other hand confuses me -- I see code > which seems to be saying that we can delay-ACK any time that we're > receiving data and don't have a delayed ACK already pending, without > any regard for the fact that we might be receiving 2+ MSS at once... > am I missing something here? see what happens if you always send there.. From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 17:29:08 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EAB50B84 for ; Mon, 21 Oct 2013 17:29:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A523827D9 for ; Mon, 21 Oct 2013 17:29:05 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id r9LHSx7X088223 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 10:29:03 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <52656455.3060408@freebsd.org> Date: Tue, 22 Oct 2013 01:28:53 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Slawa Olhovchenkov , freebsd-net@FreeBSD.ORG Subject: Re: long standing tcp bug: kern/25986 References: <20131021121122.GA48316@zxy.spb.ru> In-Reply-To: <20131021121122.GA48316@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:29:09 -0000 On 10/21/13 8:11 PM, Slawa Olhovchenkov wrote: > This PR contains patch. Can anybody commit it? > > Bug opened from 2001-Mar-22 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > really belongs in -net CCing to there Andre? From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 18:00:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF2EE5BC for ; Mon, 21 Oct 2013 18:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B399329BF for ; Mon, 21 Oct 2013 18:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9LI01Ua008950 for ; Mon, 21 Oct 2013 18:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9LI004U008949; Mon, 21 Oct 2013 18:00:00 GMT (envelope-from gnats) Date: Mon, 21 Oct 2013 18:00:00 GMT Message-Id: <201310211800.r9LI004U008949@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Subject: Re: kern/164475: [gre] gre misses RUNNING flag after a reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:00:01 -0000 The following reply was made to PR kern/164475; it has been noted by GNATS. From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= To: bug-followup@freebsd.org, eugene@zhegan.in Cc: Subject: Re: kern/164475: [gre] gre misses RUNNING flag after a reboot Date: Mon, 21 Oct 2013 19:57:51 +0200 Hi, still the same problem on 9.2-RELEASE. Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 19:57:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 099DF73B for ; Mon, 21 Oct 2013 19:57:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F73121B1 for ; Mon, 21 Oct 2013 19:57:38 +0000 (UTC) Received: (qmail 43226 invoked from network); 21 Oct 2013 20:29:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2013 20:29:36 -0000 Message-ID: <52658726.4030106@freebsd.org> Date: Mon, 21 Oct 2013 21:57:26 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Colin Percival , Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> <526558D2.3010505@freebsd.org> In-Reply-To: <526558D2.3010505@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:57:40 -0000 On 21.10.2013 18:39, Colin Percival wrote: > On 10/21/13 08:15, Andre Oppermann wrote: >> On 21.10.2013 03:42, Colin Percival wrote: >>> I can't find any changes in netfront.c or tcp_lro.c to explain why 9.1 and >>> 9.2 are behaving differently -- anyone have any ideas? >> >> The last time I looked our soft-LRO had a few remaining issues. One of >> them was that in certain situations reordering may happen with segments >> that can't be aggregated into a LRO state. The other was that the driver >> is responsible to manage the flushing of LRO states that haven't seen >> updates in some time. > > It looks like the netfront driver flushes LRO every time it finishes reading > packets -- if anything, it's too aggressive: > /* > * Flush any outstanding LRO work > */ > while (!SLIST_EMPTY(&lro->lro_active)) { > queued = SLIST_FIRST(&lro->lro_active); > SLIST_REMOVE_HEAD(&lro->lro_active, next); > tcp_lro_flush(lro, queued); > } > > So unless that code is broken somehow (it looks reasonable to me) I don't think > it's a problem of data getting stuck in soft-LRO. > > Looking at the TCP stack on the other hand confuses me -- I see code which seems > to be saying that we can delay-ACK any time that we're receiving data and don't > have a delayed ACK already pending, without any regard for the fact that we > might be receiving 2+ MSS at once... am I missing something here? This is an excellent observation! Our tcp doesn't know about LRO and I prepared the mbuf header to carry information about the number of merged LRO segments. That's not done yet again. However a small heuristic in tcp_input looking for segment > mss should be sufficient for now. Let me have a look at patching it into a suitable place. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 20:11:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E818F93 for ; Mon, 21 Oct 2013 20:11:49 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 597B222E4 for ; Mon, 21 Oct 2013 20:11:49 +0000 (UTC) Received: (qmail 43291 invoked from network); 21 Oct 2013 20:43:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2013 20:43:46 -0000 Message-ID: <52658A79.6070705@freebsd.org> Date: Mon, 21 Oct 2013 22:11:37 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Colin Percival , Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> <526558D2.3010505@freebsd.org> <52658726.4030106@freebsd.org> In-Reply-To: <52658726.4030106@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:11:50 -0000 On 21.10.2013 21:57, Andre Oppermann wrote: > On 21.10.2013 18:39, Colin Percival wrote: >> On 10/21/13 08:15, Andre Oppermann wrote: >>> On 21.10.2013 03:42, Colin Percival wrote: >>>> I can't find any changes in netfront.c or tcp_lro.c to explain why 9.1 and >>>> 9.2 are behaving differently -- anyone have any ideas? >>> >>> The last time I looked our soft-LRO had a few remaining issues. One of >>> them was that in certain situations reordering may happen with segments >>> that can't be aggregated into a LRO state. The other was that the driver >>> is responsible to manage the flushing of LRO states that haven't seen >>> updates in some time. >> >> It looks like the netfront driver flushes LRO every time it finishes reading >> packets -- if anything, it's too aggressive: >> /* >> * Flush any outstanding LRO work >> */ >> while (!SLIST_EMPTY(&lro->lro_active)) { >> queued = SLIST_FIRST(&lro->lro_active); >> SLIST_REMOVE_HEAD(&lro->lro_active, next); >> tcp_lro_flush(lro, queued); >> } >> >> So unless that code is broken somehow (it looks reasonable to me) I don't think >> it's a problem of data getting stuck in soft-LRO. >> >> Looking at the TCP stack on the other hand confuses me -- I see code which seems >> to be saying that we can delay-ACK any time that we're receiving data and don't >> have a delayed ACK already pending, without any regard for the fact that we >> might be receiving 2+ MSS at once... am I missing something here? > > This is an excellent observation! Our tcp doesn't know about LRO > and I prepared the mbuf header to carry information about the number > of merged LRO segments. That's not done yet again. However a small > heuristic in tcp_input looking for segment > mss should be sufficient > for now. Let me have a look at patching it into a suitable place. Please check out the patch below. Haven't tested it myself yet though. -- Andre Index: netinet/tcp_input.c =================================================================== --- netinet/tcp_input.c (revision 256780) +++ netinet/tcp_input.c (working copy) @@ -508,10 +508,13 @@ * the ack that opens up a 0-sized window and * - delayed acks are enabled or * - this is a half-synchronized T/TCP connection. + * - the segment size is not larger than the MSS and LRO wasn't used + * for this segment. */ -#define DELAY_ACK(tp) \ +#define DELAY_ACK(tp, tlen) \ ((!tcp_timer_active(tp, TT_DELACK) && \ (tp->t_flags & TF_RXWIN0SENT) == 0) && \ + (tlen <= tp->t_maxopd) && \ (V_tcp_delack_enabled || (tp->t_flags & TF_NEEDSYN))) /* @@ -1863,7 +1866,7 @@ } /* NB: sorwakeup_locked() does an implicit unlock. */ sorwakeup_locked(so); - if (DELAY_ACK(tp)) { + if (DELAY_ACK(tp, tlen)) { tp->t_flags |= TF_DELACK; } else { tp->t_flags |= TF_ACKNOW; @@ -1954,7 +1957,7 @@ * If there's data, delay ACK; if there's also a FIN * ACKNOW will be turned on later. */ - if (DELAY_ACK(tp) && tlen != 0) + if (DELAY_ACK(tp, tlen) && tlen != 0) tcp_timer_activate(tp, TT_DELACK, tcp_delacktime); else @@ -2926,7 +2929,7 @@ if (th->th_seq == tp->rcv_nxt && LIST_EMPTY(&tp->t_segq) && TCPS_HAVEESTABLISHED(tp->t_state)) { - if (DELAY_ACK(tp)) + if (DELAY_ACK(tp, tlen)) tp->t_flags |= TF_DELACK; else tp->t_flags |= TF_ACKNOW; From owner-freebsd-net@FreeBSD.ORG Mon Oct 21 20:59:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A79E72A3 for ; Mon, 21 Oct 2013 20:59:29 +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 391D025AC for ; Mon, 21 Oct 2013 20:59:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=q3//Gt3EDmh2JVCh8h5XXPrDqSQ=; b=HlOI+g+66792c0A5rs nf8qC2c25KNe/kxdtBw/VJbBUJRaDHDWMjZaDn9qnGIUdTEx6CH7yHct3ozf9fhi ScsdqlV7uoWyniBHSNRpEMFC7NvVog+ealpwYf/YEKlHhlC0Fvq7ymrfJW5IYNX6 PhmkF5a2ww8EtS1OPnnA9VkXs= Received: by mf68.sendgrid.net with SMTP id mf68.17008.526595AC6 Mon, 21 Oct 2013 20:59:24 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi19 (SG) with ESMTP id 141dcd0a635.19b5.24f26ac for ; Mon, 21 Oct 2013 20:59:23 +0000 (UTC) Received: (qmail 23378 invoked from network); 21 Oct 2013 20:59:22 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 21 Oct 2013 20:59:22 -0000 Received: (qmail 2552 invoked from network); 21 Oct 2013 20:58:17 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 21 Oct 2013 20:58:17 -0000 Message-ID: <52659569.8090301@freebsd.org> Date: Mon, 21 Oct 2013 13:58:17 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Andre Oppermann , Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> <526558D2.3010505@freebsd.org> <52658726.4030106@freebsd.org> <52658A79.6070705@freebsd.org> In-Reply-To: <52658A79.6070705@freebsd.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxEPn0wRwSHzIPisqQSDBEelTYC5H5HWKw4NsLSHPP/hO2upTof4UXUPLSdEvWgS/+/wqWDLS780QS+XPN+QB5CK7FW+uWTRHSxOijdnwo5sKO/Z79Du1tgPDWPvK0EPZsM= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:59:29 -0000 On 10/21/13 13:11, Andre Oppermann wrote: > On 21.10.2013 21:57, Andre Oppermann wrote: >> This is an excellent observation! Our tcp doesn't know about LRO >> and I prepared the mbuf header to carry information about the number >> of merged LRO segments. That's not done yet again. However a small >> heuristic in tcp_input looking for segment > mss should be sufficient >> for now. Let me have a look at patching it into a suitable place. > > Please check out the patch below. Haven't tested it myself yet though. Yes, this works: > 00:00:00.000000 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [S], seq 3220740500, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 350742 ecr 0], length 0 > 00:00:00.000613 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [S.], seq 1783557911, ack 3220740501, win 8190, options [mss 1460,nop,wscale 6], length 0 > 00:00:00.000657 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 > 00:00:00.001842 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 1, win 127, length 0 > 00:00:00.032269 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [P.], seq 1:318, ack 1, win 1026, length 317 > 00:00:00.033080 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 318, win 108, length 0 > 00:00:00.033115 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], seq 1:4097, ack 318, win 108, length 4096 > 00:00:00.033129 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 4097, win 962, length 0 Please commit this fix and get it merged for 10.0-RELEASE! -- 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 Tue Oct 22 07:00:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D98AE6D; Tue, 22 Oct 2013 07:00:00 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B763F2305; Tue, 22 Oct 2013 06:59:59 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id h11so5081725wiv.16 for ; Mon, 21 Oct 2013 23:59:58 -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:from:date:message-id :subject:to:cc:content-type; bh=SbfY8cRdHhxhAy7X/TZVBbwFd+/YcjmIruxWv/hz7PY=; b=m284cBqGZvFO4XyMeWzJ3ZFqiyLeQ33fSwfA0byuu86N8DMyyt7FQOoGLj0FW/ZYab jVosNPQe2qcrEi2PmINi7Dwzuh5Q5U82uImx4YSLbOUmB7kcDSc89vilyAHuPa3u5OWo g7nW0NOLfgjHmHXV+e5gmS0/EOMF5M92t/5+M+7ejXHS2AtbETYJEDye+iJ3yKA2gXT5 3X2vlqKmF2ESrJqh/FGZEcU2dtju0a/2lMFrbNYjVBW8Iqz/84zR1gEv3IG72Uo1YCJX A1q7QcvGC6Ws66XM2tFH15/8oMHLjkO4CUAkK2Y9tOC35OOHk0SZ2m6SZYAQsEVqEVX3 zOAw== X-Received: by 10.180.160.212 with SMTP id xm20mr12889789wib.23.1382425198050; Mon, 21 Oct 2013 23:59:58 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.119.73 with HTTP; Mon, 21 Oct 2013 23:59:36 -0700 (PDT) In-Reply-To: References: From: h bagade Date: Tue, 22 Oct 2013 10:29:36 +0330 X-Google-Sender-Auth: CPmzrR0vLIjSyv0qryOouwe-1lk Message-ID: Subject: Re: Netmap and in-kernel IPFW interactions! To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 07:00:00 -0000 On Mon, Oct 21, 2013 at 3:36 PM, Ivan Voras wrote: > On 20/10/2013 09:38, h bagade wrote: > > > I am somehow confused how it is possible that netmap-aware tools use > netmap > > datapath and others still use the regular driver! Isn't that the changed > > NIC driver either send the packets to userspace(in case of netmap) or to > > the kernel(as usual)? > > I think you are misunderstanding what netmap does. It is not a type of a > "driver", it has almost nothing to do with the way regular network > packets are processed in the kernel. It is an API which allow specially > created userspace program to send and receive raw packeges to/from the > network card, bypassing the normal TCP/IP processing. It does not do > anything other that that (e.g. it doesn't magically speed up network > traffic with regular programs, etc.). > > Thank you very much Ivan. Your explanation clarifies me and I find that I had a wrong expectation from netmap. From owner-freebsd-net@FreeBSD.ORG Tue Oct 22 08:01:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5115E590 for ; Tue, 22 Oct 2013 08:01:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E274266D for ; Tue, 22 Oct 2013 08:01:21 +0000 (UTC) Received: (qmail 44809 invoked from network); 22 Oct 2013 08:33:11 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2013 08:33:11 -0000 Message-ID: <526630C3.4090008@freebsd.org> Date: Tue, 22 Oct 2013 10:01:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Colin Percival , Julian Elischer , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> <526558D2.3010505@freebsd.org> <52658726.4030106@freebsd.org> <52658A79.6070705@freebsd.org> <52659569.8090301@freebsd.org> In-Reply-To: <52659569.8090301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 08:01:22 -0000 On 21.10.2013 22:58, Colin Percival wrote: > On 10/21/13 13:11, Andre Oppermann wrote: >> On 21.10.2013 21:57, Andre Oppermann wrote: >>> This is an excellent observation! Our tcp doesn't know about LRO >>> and I prepared the mbuf header to carry information about the number >>> of merged LRO segments. That's not done yet again. However a small >>> heuristic in tcp_input looking for segment > mss should be sufficient >>> for now. Let me have a look at patching it into a suitable place. >> >> Please check out the patch below. Haven't tested it myself yet though. > > Yes, this works: >> 00:00:00.000000 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [S], seq 3220740500, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 350742 ecr 0], length 0 >> 00:00:00.000613 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [S.], seq 1783557911, ack 3220740501, win 8190, options [mss 1460,nop,wscale 6], length 0 >> 00:00:00.000657 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 1, win 1026, length 0 >> 00:00:00.001842 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 1, win 127, length 0 >> 00:00:00.032269 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [P.], seq 1:318, ack 1, win 1026, length 317 >> 00:00:00.033080 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], ack 318, win 108, length 0 >> 00:00:00.033115 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags [.], seq 1:4097, ack 318, win 108, length 4096 >> 00:00:00.033129 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags [.], ack 4097, win 962, length 0 > > Please commit this fix and get it merged for 10.0-RELEASE! I committed it to my staging branch pending review: http://svnweb.freebsd.org/changeset/base/256879 It should go into HEAD later this week and the MFC to 10.x then depends on re@'s take on it. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Oct 22 19:42:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3F7A636; Tue, 22 Oct 2013 19:42:08 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 932A322C6; Tue, 22 Oct 2013 19:42:08 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id pa12so5409986veb.6 for ; Tue, 22 Oct 2013 12:42:07 -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=Ot0BI8ZRT49L47kI9cMvxwUR/6atwDAxmJtjyfSH+dw=; b=rKLaMGttT/q/277VrNfFCJ08dURuMAevE/L5E3uVGD6Ny9qEmbJ18/d8qqd/7x/x/6 j0jAehxS2bMNTfVl6RCVHP5ViPsi4Bo6oaxeE0VCckkVs4xqSxXNSVZ3kT8u9STIRPT/ 0vnob+rKwq/xsU5qg8sXm7e9hFK8t8Py2lOG8u0zKv/CWiQwl8vhSihLcKE1JVJnZdOx cGOhOALCLlwbn+9nFisn5ux6GeZGZPq8sT0yrBMOv0z43HC9j16BpycbeqjOCnS27oD9 eSKeTCnNxvsdjTXzgSsL31AAxysY/WbV8vN2uh2/7aV0X8GqO3JjqdyQhJ7XU5nwRLzm 0fow== MIME-Version: 1.0 X-Received: by 10.58.207.15 with SMTP id ls15mr5917081vec.17.1382470927625; Tue, 22 Oct 2013 12:42:07 -0700 (PDT) Received: by 10.220.30.130 with HTTP; Tue, 22 Oct 2013 12:42:07 -0700 (PDT) Date: Tue, 22 Oct 2013 15:42:07 -0400 Message-ID: Subject: istgt causes massive jumbo nmbclusters loss From: Zaphod Beeblebrox To: FreeBSD Net , freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 19:42:09 -0000 I have a server FreeBSD virtual.accountingreality.com 9.2-STABLE FreeBSD 9.2-STABLE #13 r256549M: Tue Oct 15 16:29:48 EDT 2013 root@virtual.accountingreality.com:/usr/obj/usr/src/sys/VRA amd64 That has an em0 with jumbo packets enabled: em0: flags=8843 metric 0 mtu 9014 It has (among other things): ZFS, NFS, iSCSI (via istgt) and Samba. Every day or two, it looses it's ability to talk to the network. ifconfig down/up on em0 gives the message about not being able to allocate the receive buffers... With everything running, but with specifically iSCSI not used, everything seems good. When I start hitting istgt, I see the denied stat for 9k mbufs rise very rapidly (this amount only took a few seconds): [1:47:347]root@virtual:/usr/local/etc/iet> netstat -m 1313/877/2190 mbufs in use (current/cache/total) 20/584/604/523514 mbuf clusters in use (current/cache/total/max) 20/364 mbuf+clusters out of packet secondary zone in use (current/cache) 239/359/598/261756 4k (page size) jumbo clusters in use (current/cache/total/max) 1023/376/1399/77557 9k jumbo clusters in use (current/cache/total/max) 0/0/0/43626 16k jumbo clusters in use (current/cache/total/max) 10531K/6207K/16738K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/50199/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ... the denied number rises... and somewhere in the millions or more the machine stops --- but even with the large number of denied 9k clusters, the "9k jumbo clusters in use" line will always indicate some available. ... so is this a tuning or a bug issue? I've tried ietd --- basically it doesn't want to work with a zfs zvol, it seems (refuses to use it). From owner-freebsd-net@FreeBSD.ORG Tue Oct 22 20:54:34 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CA1C3263 for ; Tue, 22 Oct 2013 20:54:34 +0000 (UTC) (envelope-from leguidedupne@plesk-vl6.ihost-web.com) Received: from plesk-vl6.ihost-web.com (plesk-vl6.ihost-web.com [74.115.206.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A40CD27BC for ; Tue, 22 Oct 2013 20:54:34 +0000 (UTC) Received: by plesk-vl6.ihost-web.com (Postfix, from userid 10308) id 15B9D980F0F; Tue, 22 Oct 2013 16:47:44 -0400 (EDT) To: net@freebsd.org Subject: RE: Teeny bitch gets a badass poundage from big dick X-Priority: 3 (Normal) Message-Id: <20131022204744.15B9D980F0F@plesk-vl6.ihost-web.com> Date: Tue, 22 Oct 2013 16:47:44 -0400 (EDT) From: leguidedupne@plesk-vl6.ihost-web.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:54:34 -0000 COOL =) did you see this? [1]Teeny bitch gets a badass poundage from big dick References 1. http://samui-video-guide.com/modules/mod_ariimagepopup/includes/kernel/Utils/xml.php From owner-freebsd-net@FreeBSD.ORG Wed Oct 23 03:32:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F44E794; Wed, 23 Oct 2013 03:32:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 351362D52; Wed, 23 Oct 2013 03:32:44 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id r9N3WYNX093777 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 20:32:36 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5267434E.7050901@freebsd.org> Date: Wed, 23 Oct 2013 11:32:30 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andre Oppermann , Colin Percival , freebsd-net@freebsd.org Subject: Re: LRO causing stretch ACK violations interacts badly with delayed ACKing References: <52605EC9.6090406@freebsd.org> <526478D0.1000601@freebsd.org> <5264869E.4000308@freebsd.org> <5265450C.1060601@freebsd.org> <526558D2.3010505@freebsd.org> <52658726.4030106@freebsd.org> <52658A79.6070705@freebsd.org> <52659569.8090301@freebsd.org> <526630C3.4090008@freebsd.org> In-Reply-To: <526630C3.4090008@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 03:32:45 -0000 On 10/22/13 4:01 PM, Andre Oppermann wrote: > On 21.10.2013 22:58, Colin Percival wrote: >> On 10/21/13 13:11, Andre Oppermann wrote: >>> On 21.10.2013 21:57, Andre Oppermann wrote: >>>> This is an excellent observation! Our tcp doesn't know about LRO >>>> and I prepared the mbuf header to carry information about the number >>>> of merged LRO segments. That's not done yet again. However a small >>>> heuristic in tcp_input looking for segment > mss should be >>>> sufficient >>>> for now. Let me have a look at patching it into a suitable place. >>> >>> Please check out the patch below. Haven't tested it myself yet >>> though. >> >> Yes, this works: >>> 00:00:00.000000 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags >>> [S], seq 3220740500, win 65535, options [mss 1460,nop,wscale >>> 6,sackOK,TS val 350742 ecr 0], length 0 >>> 00:00:00.000613 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags >>> [S.], seq 1783557911, ack 3220740501, win 8190, options [mss >>> 1460,nop,wscale 6], length 0 >>> 00:00:00.000657 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags >>> [.], ack 1, win 1026, length 0 >>> 00:00:00.001842 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags >>> [.], ack 1, win 127, length 0 >>> 00:00:00.032269 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags >>> [P.], seq 1:318, ack 1, win 1026, length 317 >>> 00:00:00.033080 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags >>> [.], ack 318, win 108, length 0 >>> 00:00:00.033115 IP 176.32.98.166.443 > 10.148.229.78.24405: Flags >>> [.], seq 1:4097, ack 318, win 108, length 4096 >>> 00:00:00.033129 IP 10.148.229.78.24405 > 176.32.98.166.443: Flags >>> [.], ack 4097, win 962, length 0 >> >> Please commit this fix and get it merged for 10.0-RELEASE! > > I committed it to my staging branch pending review: > http://svnweb.freebsd.org/changeset/base/256879 > > It should go into HEAD later this week and the MFC to 10.x then depends > on re@'s take on it. > I think it's true for 9.2 as well. not sure about 8 or 9.1 From owner-freebsd-net@FreeBSD.ORG Wed Oct 23 16:47:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9FB58B49 for ; Wed, 23 Oct 2013 16:47:49 +0000 (UTC) (envelope-from eocallaghan@alterapraxis.com) Received: from smtp.alterapraxis.com (unknown [101.164.33.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F1FF2CFE for ; Wed, 23 Oct 2013 16:47:49 +0000 (UTC) Received: from smtp.alterapraxis.com (tony [127.0.0.1]) by smtp.alterapraxis.com (Postfix) with ESMTP id 2F779634852 for ; Wed, 23 Oct 2013 03:04:00 +1100 (EST) Received: from tinkerbell.alterapraxis.com (unknown [101.164.33.212]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: eocallaghan@alterapraxis.com) by smtp.alterapraxis.com (Postfix) with ESMTPSA id D98E1634851 for ; Wed, 23 Oct 2013 03:03:58 +1100 (EST) Date: Wed, 23 Oct 2013 03:05:51 +1100 From: Edward O'Callaghan To: freebsd-net@freebsd.org Subject: [PATCH] Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethernet controllers such as the one found in PR183167. Message-ID: <20131023030551.06edd9ab.eocallaghan@alterapraxis.com> Organization: Altera Praxis Pty Ltd X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/9K1z=m0GG5It.lPFHVcc9=b"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:47:49 -0000 --Sig_/9K1z=m0GG5It.lPFHVcc9=b Content-Type: multipart/mixed; boundary="MP_/nb8L4g75CtAlq1WfYJzlJLf" --MP_/nb8L4g75CtAlq1WfYJzlJLf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, If someone could review this please, it needs better testing. I was only really initially trying to fix my own bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D183167 Kind Regards, --MP_/nb8L4g75CtAlq1WfYJzlJLf Content-Type: text/x-patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=0001-Add-preliminary-support-for-some-newer-RTL8111-8168-.patch =46rom 7d54f474d91b362c3e90894ab99ccf7655c60204 Mon Sep 17 00:00:00 2001 From: Edward O'Callaghan Date: Wed, 23 Oct 2013 01:16:14 +1100 Subject: [PATCH] Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethernet controllers such as the one found in PR183167. Organization: Altera Praxis Pty Ltd. To: freebsd-net@freebsd.org Signed-off-by: Edward O'Callaghan --- sys/dev/re/if_re.c | 6 ++++++ sys/pci/if_rlreg.h | 3 +++ 2 files changed, 9 insertions(+) diff --git a/sys/dev/re/if_re.c b/sys/dev/re/if_re.c index 381fa87..0ea330a 100644 --- a/sys/dev/re/if_re.c +++ b/sys/dev/re/if_re.c @@ -234,6 +234,9 @@ static const struct rl_hwrev re_hwrevs[] =3D { { RL_HWREV_8168E, RL_8169, "8168E/8111E", RL_JUMBO_MTU_9K}, { RL_HWREV_8168E_VL, RL_8169, "8168E/8111E-VL", RL_JUMBO_MTU_6K}, { RL_HWREV_8168F, RL_8169, "8168F/8111F", RL_JUMBO_MTU_9K}, + { RL_HWREV_8168G, RL_8169, "8168G/8111G", RL_MTU}, + { RL_HWREV_8168EP, RL_8169, "8168G/8111EP", RL_MTU}, + { RL_HWREV_8168GU, RL_8169, "8168G/8111GU", RL_MTU}, { RL_HWREV_8411, RL_8169, "8411", RL_JUMBO_MTU_9K}, { 0, 0, NULL, 0 } }; @@ -1451,6 +1454,7 @@ re_attach(device_t dev) RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_AUTOPAD | RL_FLAG_JUMBOV2 | RL_FLAG_WAIT_TXPOLL | RL_FLAG_WOL_MANLINK; break; + case RL_HWREV_8168GU: case RL_HWREV_8168E: sc->rl_flags |=3D RL_FLAG_PHYWAKE | RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | @@ -1458,7 +1462,9 @@ re_attach(device_t dev) RL_FLAG_WOL_MANLINK; break; case RL_HWREV_8168E_VL: + case RL_HWREV_8168EP: case RL_HWREV_8168F: + case RL_HWREV_8168G: case RL_HWREV_8411: sc->rl_flags |=3D RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | diff --git a/sys/pci/if_rlreg.h b/sys/pci/if_rlreg.h index 142fe48..95550b7 100644 --- a/sys/pci/if_rlreg.h +++ b/sys/pci/if_rlreg.h @@ -192,6 +192,9 @@ #define RL_HWREV_8106E 0x44800000 #define RL_HWREV_8168F 0x48000000 #define RL_HWREV_8411 0x48800000 +#define RE_HWREV_8168G 0x4C000000 +#define RE_HWREV_8168EP 0x50000000 +#define RE_HWREV_8168GU 0x50800000 /* 8106EUS */ #define RL_HWREV_8139 0x60000000 #define RL_HWREV_8139A 0x70000000 #define RL_HWREV_8139AG 0x70800000 --=20 1.8.4.1 --MP_/nb8L4g75CtAlq1WfYJzlJLf-- --Sig_/9K1z=m0GG5It.lPFHVcc9=b Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJSZqJlAAoJENeyf/ug44dtkrcP+gO8nssASNzOGprRfyz7f3AP hQiIanOVPZYUv9bTirO92uM9VEdQ8PDsZxV8veoqgDqKw5z2KSgzDP4ZXhh3tlhe BKqmdrRAT4e6lfGwYd20eSDciGjrLGtRxgpmqrFJuOjkNG3Jd6SP9ZwZsG4LjtpX at+DdXqAB87os1jGuygPYQpKDdwax/iwU3fSIrjIh3MZXNcVQCFPETNddg7mTNDs DxTKCk5CX8jJXzR7A+kFU45B/YRPAj7uBQPcJdgAOnKMkiuLFWS72vPTXU/3SSfS 1X10O5qqPwGZlqxU0kA8R3nCmrISOIRttxRyJtvVeDbPuDzodIlE6S10QXLmOfTO 54XAli2vHKfHvyK+HczMUUF1oOXs2DwiKN02kiV+CT74SlgrJPbasd1SiWzqVgW9 Kg/G/lH9aXSge+neEaWoy8TF/8a1nYf2rA/K7G48zK18lGe4/g8dH6ZVSwSp6HaB nzw4JzTM4oXIUeskF85qU+JCEh8yjxkHLMacl2+fGWdjhfV4OtCRqlWD5KEyScAT wJZuYjET7xbCnhCDpvkLAsscB/LVQYCVN+QQFmvHZKe++DScTAdeiyuIVvhpibwP z9lfusqJrzvfVuGEcLtFZOPaIE9iBjWt7KqBiLJCcszbPB094YbLONdCHRJ2dlYt Cjz9+ogNLxf9zsGbnzl+ =md3X -----END PGP SIGNATURE----- --Sig_/9K1z=m0GG5It.lPFHVcc9=b-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 23 23:32:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CF132AEF for ; Wed, 23 Oct 2013 23:32:56 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6698928D4 for ; Wed, 23 Oct 2013 23:32:56 +0000 (UTC) Received: by mail-ea0-f172.google.com with SMTP id r16so809305ead.31 for ; Wed, 23 Oct 2013 16:32:54 -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=otOV144LIrcdVkeCK+8ee8NQ/xVhVq2TCMzvzKiDOdI=; b=oM4ufA9F+F4O39oWpvitU1eBatund+oUN+MDbDaFYUvE+WlTWJxwcYvuB4xbV/v+iY fOQupIaiL1+4ffX/l3iLA4VrqftZo9AVvdMbXKVALHREv0+yKcLrSVKbBrQdp52qB718 F3MIuO5KnQD/+V1/fGurC0bpF2IaU5Ey+2iL2Z1vXM/xIL1RCRgQAhn5TRHWbNgBTCCI jCT6H5tvuBu1ywt3pS/E84DwMyI3mTNQjAN4ach7Y89R2XgEz9LZOqDKFiddzQgLk5cS koGfY2kAZAaSjkbKVitYsKn4HC2qZcL/kp47XWnQq4K9QvM8/MLD3YMVGdZvT06Q/6Ow Ikdw== MIME-Version: 1.0 X-Received: by 10.14.219.198 with SMTP id m46mr4257428eep.41.1382571174128; Wed, 23 Oct 2013 16:32:54 -0700 (PDT) Received: by 10.14.127.195 with HTTP; Wed, 23 Oct 2013 16:32:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Oct 2013 16:32:54 -0700 Message-ID: Subject: Re: Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution) From: hiren panchasara To: Takuya ASADA Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 23:32:56 -0000 On Mon, Oct 7, 2013 at 5:49 PM, hiren panchasara wrote: > On Mon, Oct 7, 2013 at 12:01 AM, Takuya ASADA wrote: >> Hi, >> >> This is updated version of "ixgbetool" patch. > I will try to give this a try tomorrow. Alright, sorry for the delay. I now have bandwidth/setup to test this. > > Cheers, > Hiren >> Here's improved feature list: >> - signature filter list feature available >> - user-defined filter can be use with an ATR. How does this work? You identify user-defined flows and apply ATR on the rest of the flows? >> To enable it, add "hw.ixgbe.cooperative_atr=1" on /boot/loader.conf >> >> Usage is as follows: >> ixgbetool [operation] >> add_sig_filter >> >> show_sig_filter >> del_sig_filter I believe, I can somehow test whether the signature filter works or not by generating custom traffic, creating matching filter, directing the traffic to a specific queue and watch that queue. But how do I test/see ATR (application targeted receive) in action? Traffic for a specific application should follow the application on different cpus, right? Any guidance on how to do that would be great. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Thu Oct 24 21:08:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E2E469B7 for ; Thu, 24 Oct 2013 21:08:49 +0000 (UTC) (envelope-from mrstalker@simvol7.ru) Received: from smtp1.mtw.ru (smtp.mtw.ru [37.228.88.77]) by mx1.freebsd.org (Postfix) with ESMTP id A17B02B13 for ; Thu, 24 Oct 2013 21:08:48 +0000 (UTC) Received: from mail.mtw.ru (unknown [93.95.102.138]) (Authenticated sender: mrstalker-simvol7ru) by smtp1.mtw.ru (Postfix) with ESMTPA id 1E8E4DDB1 for ; Thu, 24 Oct 2013 22:23:00 +0400 (MSK) Received: from 37.147.154.147 (SquirrelMail authenticated user mrstalker-simvol7ru); by mail.mtw.ru with HTTP; Fri, 25 Oct 2013 00:42:15 +0400 (MSK) Message-ID: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> Date: Fri, 25 Oct 2013 00:42:15 +0400 (MSK) Subject: How delete the interface route in FreeBSD 9.2 (MPD5)? From: "MrStalker" To: freebsd-net@freebsd.org. User-Agent: SquirrelMail/1.5.0 X-Priority: 3 Importance: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mrstalker@simvol7.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 21:08:50 -0000 Hello! For my internet provider (L2TP VPN connection) is required a route to the VPN server via local gate. I'm using MPD5. But, MPD5 creates route to the VPN server via its same interface... root@Eviko:/home/mrstalker # netstat -nrf inet Routing tables Internet: Destination       Gateway           Flags   Refs     Use Netif Expire default           85.21.230.206     UGS        0       8   ng0 85.21.230.206     link#7            UH         0       8   ng0 What will not work... However earlier, it was possible delete this route and then create right route. root@Test2:/home/mrstalker # route delete 85.21.230.206 delete host 85.21.230.206 root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 add host 85.21.230.206: gateway 10.165.32.1 When i trying FreeBSD 9.2, this is no longer working... Thread about it at the forum http://forums.freebsd.org/showthread.php?t=42547 Later I found source of problem: http://svnweb.freebsd.org/base?view=revision&revision=248895 Now I can't delete the interface route (ng0). What does impossible work with the internet provider. How? How now resolve this problem? I need to add route to the vpn server via local gate... Please help me resolve this trouble. Since the release of FreeBSD 9.2 I trying to find a solution. From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 07:08:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9F22C96D for ; Fri, 25 Oct 2013 07:08:54 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF10321AD for ; Fri, 25 Oct 2013 07:08:53 +0000 (UTC) X-Envelope-From: egrosbein@rdtc.ru X-Envelope-To: freebsd-net@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r9P78i48063590; Fri, 25 Oct 2013 14:08:44 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <526A18FC.6030402@rdtc.ru> Date: Fri, 25 Oct 2013 14:08:44 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: mrstalker@simvol7.ru Subject: Re: How delete the interface route in FreeBSD 9.2 (MPD5)? References: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> In-Reply-To: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eg.sd.rdtc.ru Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 07:08:54 -0000 On 25.10.2013 03:42, MrStalker wrote: > Hello! > For my internet provider (L2TP VPN connection) is required a route to > the VPN server via local gate. > I'm using MPD5. > But, MPD5 creates route to the VPN server via its same interface... > root@Eviko:/home/mrstalker # netstat -nrf inet > Routing tables > Internet: > Destination� � � � � � � Gateway� � � � � � � � � � � Flags� � � > Refs� � � � � Use� Netif Expire > default� � � � � � � � � � � 85.21.230.206� � � � � > UGS� � � � � � � � 0� � � � � � � 8� � � ng0 > 85.21.230.206� � � � � link#7� � � � � � � � � � � � > UH� � � � � � � � � 0� � � � � � � 8� � � ng0 > What will not work... > However earlier, it was possible delete this route and then create > right route. > root@Test2:/home/mrstalker # route delete 85.21.230.206 > delete host 85.21.230.206 > root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 > add host 85.21.230.206: gateway 10.165.32.1 > When i trying FreeBSD 9.2, this is no longer working... > Thread about it at the forum > http://forums.freebsd.org/showthread.php?t=42547 > Later I found source of problem: > http://svnweb.freebsd.org/base?view=revision&revision=248895 > Now I can't delete the interface route (ng0). What does impossible work > with the� internet provider. > How? How now resolve this problem? > I need to add route to the vpn server via local gate... > Please help me resolve this trouble. Since the release of FreeBSD 9.2 I > trying to find a solution. You have to create your static route to vpn server before mpd5 starts. Use /etc/rc.conf: static_routes="vpn" route_vpn="85.21.230.206 10.165.32.1" Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 07:10:17 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 015C6A79 for ; Fri, 25 Oct 2013 07:10:17 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 75EAD21D4 for ; Fri, 25 Oct 2013 07:10:16 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r9P7A9ZP094885 for ; Fri, 25 Oct 2013 00:10:10 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <526A1951.6030505@rawbw.com> Date: Fri, 25 Oct 2013 00:10:09 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: net@FreeBSD.org Subject: Atheros 5424/2424 device periodically gets into state with 'no carrier' or 'device timeout' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 07:10:17 -0000 I have a laptop with this device which periodically spontaneously loses connection, gets into 'no carrier' state. '/etc/rc.d/netif restart' doesn't help. I believe it brings it down and up too fast. '/etc/rc.d/netif stop && sleep 3 && /etc/rc.d/netif start' usually helps. But this command sometimes also leaves it into 'no career' state. I also saw the situation when after the hot reboot ath0 came up with messages 'device timeout', and was never usable. Yuri 9.2-STABLE ath0: mem 0x8b100000-0x8b10ffff irq 18 at device 0.0 on pci4 ath0: AR2425 mac 14.2 RF5424 phy 7.0 From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 09:20:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6693AD7C for ; Fri, 25 Oct 2013 09:20:33 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 060442883 for ; Fri, 25 Oct 2013 09:20:32 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so3452686wgg.4 for ; Fri, 25 Oct 2013 02:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=gJmPAvc2xA78bd6FBC5OKVpn8nCVlimmnlYu5B8dFv0=; b=JXXdR7iGgqNqMN6J1GJ/daE5kxBBy9j33WsZSmn7TX0ihmbhiBb89ve22lrJaxbHBt 1Zk7NevhC33ALowglm0F9ktE7oeRptbsXFe4Jc/vCIFdw6JbuQFmrB05ID3AYWxBjBc5 /9B0Rtc40Ye0kEtRgl0J2P2mThScqR7Oy9IuuRvAGtkv26xypRVPjJokTb5vIDpbWdKg TnA0A0DNIjNcW4D5213eMHbhsq1odTQliB9WU10EUqQ2DjkWSDvEX4rrOXKwDMpyGMDp vUQ0Iogd5W36NJZltNdspU8ya+GcoNmfgqjburTDL5AXoERIA0XkwD0U2NCkYzoAtY6/ FXrw== X-Received: by 10.180.83.228 with SMTP id t4mr1648993wiy.12.1382692831404; Fri, 25 Oct 2013 02:20:31 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.236.131 with HTTP; Fri, 25 Oct 2013 02:20:11 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 25 Oct 2013 11:20:11 +0200 X-Google-Sender-Auth: kDEle2ok3BU5I_YY94qZVn9B-wM Message-ID: Subject: Can't configure a simple IPSec (manual SA/SP) To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:20:33 -0000 Hi all, I'm trying to configure simple static IPSec SA/SP in tunnel mode on my FreeBSD 9.2-RELEASE (crypto + ipsec added to the kernel) but the IPSec configuration seems to be ignored. local private net (em0): 10.0.12.0/24 local end-point IP (em1): 10.0.23.2 remote private net: 10.0.45.0/24 remote end-point IP: 10.0.34.4 I'm configuring the static SA/SP entries like that: flush; spdflush; spdadd 10.0.12.0/24 10.0.45.0/24 any -P out ipsec esp/tunnel/10.0.23.2-10.0.34.4/require; spdadd 10.0.45.0/24 10.0.12.0/24 any -P in ipsec esp/tunnel/10.0.34.4-10.0.23.2/require; add 10.0.23.2 10.0.34.4 esp 0x1000 -E 3des-cbc "3des_compliant_password1"; add 10.0.34.4 10.0.23.2 esp 0x1001 -E 3des-cbc "3des_compliant_password2"; This configuration seems correctly applied: [root@R2]~# setkey -D 10.0.34.4 10.0.23.2 esp mode=any spi=4097(0x00001001) reqid=0(0x00000000) E: 3des-cbc 33646573 5f636f6d 706c6961 6e745f70 61737377 6f726432 seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Oct 25 10:33:11 2013 current: Oct 25 11:08:49 2013 diff: 2138(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=2024 refcnt=1 10.0.23.2 10.0.34.4 esp mode=any spi=4096(0x00001000) reqid=0(0x00000000) E: 3des-cbc 33646573 5f636f6d 706c6961 6e745f70 61737377 6f726431 seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Oct 25 10:33:11 2013 current: Oct 25 11:08:49 2013 diff: 2138(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=2024 refcnt=1 [root@R2]~# setkey -DP 10.0.45.0/24[any] 10.0.12.0/24[any] any in ipsec esp/tunnel/10.0.34.4-10.0.23.2/require spid=2 seq=1 pid=2025 refcnt=1 10.0.12.0/24[any] 10.0.45.0/24[any] any out ipsec esp/tunnel/10.0.23.2-10.0.34.4/require spid=1 seq=0 pid=2025 refcnt=1 But when a machine in local_private_net try to ping a remote_private_net, the traffic is not tunnel/encrypted: [root@R2]~# tcpdump -pni em1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 10:35:21.284571 IP 10.0.12.1 > 10.0.45.5: ICMP echo request, id 48913, seq 0, length 64 10:35:22.288836 IP 10.0.12.1 > 10.0.45.5: ICMP echo request, id 48913, seq 1, length 64 10:35:23.298386 IP 10.0.12.1 > 10.0.45.5: ICMP echo request, id 48913, seq 2, length 64 I've try to enable IPSEC_DEBUG on my kernel: I've got nothing in my log. How can I get a more verbose IPsec log for spotting my problem ? Thanks, Olivier From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 13:42:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41AEF205 for ; Fri, 25 Oct 2013 13:42:28 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id B371127E7 for ; Fri, 25 Oct 2013 13:42:27 +0000 (UTC) Received: from nono (nono.zen.inc [192.168.1.95]) by smtp.zeninc.net (smtpd) with ESMTP id A6B052798C5 for ; Fri, 25 Oct 2013 15:35:18 +0200 (CEST) Received: by nono (Postfix, from userid 1000) id 8AD9221F5F; Fri, 25 Oct 2013 15:35:18 +0200 (CEST) Date: Fri, 25 Oct 2013 15:35:18 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Subject: Re: Can't configure a simple IPSec (manual SA/SP) Message-ID: <20131025133517.GA5588@zeninc.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:42:28 -0000 On Fri, Oct 25, 2013 at 11:20:11AM +0200, Olivier Cochard-Labb? wrote: > Hi all, Hi. > I'm trying to configure simple static IPSec SA/SP in tunnel mode on my > FreeBSD 9.2-RELEASE (crypto + ipsec added to the kernel) but the IPSec > configuration seems to be ignored. > > local private net (em0): 10.0.12.0/24 > local end-point IP (em1): 10.0.23.2 > remote private net: 10.0.45.0/24 > remote end-point IP: 10.0.34.4 > > I'm configuring the static SA/SP entries like that: > > flush; > spdflush; > spdadd 10.0.12.0/24 10.0.45.0/24 any -P out ipsec > esp/tunnel/10.0.23.2-10.0.34.4/require; > spdadd 10.0.45.0/24 10.0.12.0/24 any -P in ipsec > esp/tunnel/10.0.34.4-10.0.23.2/require; > add 10.0.23.2 10.0.34.4 esp 0x1000 -E 3des-cbc "3des_compliant_password1"; > add 10.0.34.4 10.0.23.2 esp 0x1001 -E 3des-cbc "3des_compliant_password2"; > > This configuration seems correctly applied: [seems good] > But when a machine in local_private_net try to ping a > remote_private_net, the traffic is not tunnel/encrypted: > > [root@R2]~# tcpdump -pni em1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes > 10:35:21.284571 IP 10.0.12.1 > 10.0.45.5: ICMP echo request, id 48913, > seq 0, length 64 > 10:35:22.288836 IP 10.0.12.1 > 10.0.45.5: ICMP echo request, id 48913, > seq 1, length 64 > 10:35:23.298386 IP 10.0.12.1 > 10.0.45.5: ICMP echo request, id 48913, > seq 2, length 64 > > I've try to enable IPSEC_DEBUG on my kernel: I've got nothing in my log. > > How can I get a more verbose IPsec log for spotting my problem ? I'm not sure your problem is directly related to your IPsec configuration: your packet may just not reach the IPsec stack for some reason to be understood. Do you use some bridging configuration ? Do you have some kind of filtering/NAT rules ? Some complex routing tables ? Can you send the output (on your IPsec gate) of: sysctl -a net.inet.ip.fastforwarding Have also a look at the output of "netstat -s", and check all sections related to IPsec (pfkey, ipsec, esp). Yvan. From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 15:08:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5DBC728D for ; Fri, 25 Oct 2013 15:08:05 +0000 (UTC) (envelope-from mrstalker@simvol7.ru) Received: from smtp1.mtw.ru (smtp.mtw.ru [37.228.88.77]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4232C76 for ; Fri, 25 Oct 2013 15:08:04 +0000 (UTC) Received: from [127.0.0.1] (37-147-128-249.broadband.corbina.ru [37.147.128.249]) (Authenticated sender: mrstalker-simvol7ru) by smtp1.mtw.ru (Postfix) with ESMTPSA id 25415E8A0 for ; Fri, 25 Oct 2013 18:56:15 +0400 (MSK) Message-ID: <526A894E.1070305@simvol7.ru> Date: Fri, 25 Oct 2013 19:07:58 +0400 From: MrStalker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: How delete the interface route in FreeBSD 9.2 (MPD5)? References: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> <526A18FC.6030402@rdtc.ru> In-Reply-To: <526A18FC.6030402@rdtc.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:08:05 -0000 25.10.2013 11:08, Eugene Grosbein пишет: > On 25.10.2013 03:42, MrStalker wrote: >> Hello! >> For my internet provider (L2TP VPN connection) is required a route to the VPN server via local gate. >> I'm using MPD5. >> But, MPD5 creates route to the VPN server via its same interface... >> >> root@Eviko:/home/mrstalker # netstat -nrf inet >> Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 85.21.230.206 UGS 0 8 ng0 >> 85.21.230.206 link#7 UH 0 8 ng0 >> >> What will not work... >> >> However earlier, it was possible delete this route and then create right route. >> root@Test2:/home/mrstalker # route delete 85.21.230.206 >> delete host 85.21.230.206 >> root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 >> add host 85.21.230.206: gateway 10.165.32.1 >> >> When i trying FreeBSD 9.2, this is no longer working... >> Thread about it at the forumhttp://forums.freebsd.org/showthread.php?t=42547 >> Later I found source of problem: >> http://svnweb.freebsd.org/base?view=revision&revision=248895 >> >> Now I can't delete the interface route (ng0). What does impossible work with the internet provider. >> >> How? How now resolve this problem? >> I need to add route to the vpn server via local gate... >> >> Please help me resolve this trouble. Since the release of FreeBSD 9.2 I trying to find a solution. > You have to create your static route to vpn server before mpd5 starts. > Use /etc/rc.conf: > > static_routes="vpn" > route_vpn="85.21.230.206 10.165.32.1" > > Eugene Grosbein Unfortunately failed... root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 85.21.230.206 10.165.32.1 UGHS 0 0 re0 root@Eviko:/home/mrstalker # service mpd5 start Starting mpd5. root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 85.21.230.206 link#7 UH 0 4 ng0 Route via ng0 overwrites the static route. From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 16:05:26 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 74DC0F9B for ; Fri, 25 Oct 2013 16:05:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36A792072 for ; Fri, 25 Oct 2013 16:05:26 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id cm18so677285qab.10 for ; Fri, 25 Oct 2013 09:05:25 -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:message-id:subject :from:to:cc:content-type; bh=s5yEQie9v/iqipklBkmD5kL8HJB5LrBbjXzPUVQN1ro=; b=dzViq9ZFVDgvC3w3urLWsrpJc2gXULl+qoqHJELFJpE+VXWFrCuEvB5G3/8NKUg0D4 unfnGmQ9Ef+zNGGBj8itCG7n/dBQk4BuvShSuFXgHbIKVCS8LHb7piCAGnhXC74rAed8 Eo0Lzcl+QQXISLfK4UJFIqnNCQAPu07n0Y0lVvUTaTiKX2z4z2nXDsTb4ZfUlgd1T80x /OM8KA6kiHJnMvs40WvxcZ8rXmNWqEkNqb98c7YuIioa+nZAvFx50Gja/mwAxvnyfFev poMVdjI8bns+cEqsaoDu4kUQNaXCnM88LUniK9cqza/dwucY6sI225XMB+GbTge4jkrE 5clQ== MIME-Version: 1.0 X-Received: by 10.224.157.14 with SMTP id z14mr12348300qaw.90.1382717125364; Fri, 25 Oct 2013 09:05:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 25 Oct 2013 09:05:25 -0700 (PDT) In-Reply-To: <526A1951.6030505@rawbw.com> References: <526A1951.6030505@rawbw.com> Date: Fri, 25 Oct 2013 09:05:25 -0700 X-Google-Sender-Auth: _Rxt_W4IGrmzK0K_YsMu-MIQh5w Message-ID: Subject: Re: Atheros 5424/2424 device periodically gets into state with 'no carrier' or 'device timeout' From: Adrian Chadd To: Yuri Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:05:26 -0000 Hi, Can you update to -HEAD? I've fixed a whole bunch of bugs in -HEAD with the ath driver. There are also a bunch more debugging tools we can use. Thanks, -adrian On 25 October 2013 00:10, Yuri wrote: > I have a laptop with this device which periodically spontaneously loses > connection, gets into 'no carrier' state. > '/etc/rc.d/netif restart' doesn't help. I believe it brings it down and up > too fast. > '/etc/rc.d/netif stop && sleep 3 && /etc/rc.d/netif start' usually helps. > But this command sometimes also leaves it into 'no career' state. > I also saw the situation when after the hot reboot ath0 came up with > messages 'device timeout', and was never usable. > > Yuri > > > 9.2-STABLE > ath0: mem 0x8b100000-0x8b10ffff irq 18 at device 0.0 > on pci4 > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > ______________________________**_________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org > " > From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 16:13:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7FC3E3B7; Fri, 25 Oct 2013 16:13:54 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA657210F; Fri, 25 Oct 2013 16:13:53 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id t61so4102802wes.34 for ; Fri, 25 Oct 2013 09:13:52 -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:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=x5nXEqMVWdXhIW2QfseO5uTnGzSp21d5Rd1f19qD6Pc=; b=iRM6JxXjMQr5bBkmhox3e3zc+wJh3zPj3KKcut3fwGmQMKMXcv3v6ZpTjf/M7+3DLO vgHj533bQWF17NswHzc9suxVboFBHsZ5b7NODq0yU5wPkAzeLoPKAgAlNjppvNJcHuc0 iFetISO1vWsp7taT1Bxmx07lCcrX+CjJk34UeSvO+3zqdpItsERfoXuxOk2znYc8xFjo wAgYVcA8JIRTD+tHRcsEKHcoxXUxYhT5AAGGv8AqJFCP/Bqh84dMVVxXsOBvXtELn2Vc OAT65NdMe+Gm3ctaDiO/OxCn87Ub3hPacRUDiXOHmSHnXTvbpkNjCY0GZskQ5lwYePTe wJ9g== X-Received: by 10.180.83.228 with SMTP id t4mr3238679wiy.12.1382717632391; Fri, 25 Oct 2013 09:13:52 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.236.131 with HTTP; Fri, 25 Oct 2013 09:13:32 -0700 (PDT) In-Reply-To: <20131025133517.GA5588@zeninc.net> References: <20131025133517.GA5588@zeninc.net> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 25 Oct 2013 18:13:32 +0200 X-Google-Sender-Auth: Sz7BMM1gbpxBKdjhfmh4uCHO1P8 Message-ID: Subject: Re: Can't configure a simple IPSec (manual SA/SP) To: VANHULLEBUS Yvan Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:13:54 -0000 On Fri, Oct 25, 2013 at 3:35 PM, VANHULLEBUS Yvan wrote= : > Do you use some bridging configuration ? Do you have some kind of > filtering/NAT rules ? Some complex routing tables ? No bridging, no firewall, no complex routing: the IPSec gate Fhave only one default gateway. > > > Can you send the output (on your IPsec gate) of: > sysctl -a net.inet.ip.fastforwarding [root@R2]~# sysctl -a net.inet.ip.fastforwarding net.inet.ip.fastforwarding: 1 I didn't understand why you ask me the status of the fastforwarding: Then I've disabled it, and re-try my IPsec configuration=85 Problem solved ! I've found the notice regarding fastforwarding being not compatible with IPSec in the inet(4) man page: I was not aware of this compatibility issue. I've proposed a little improvement on the rc.d/ipsec script for checking the fastforwarding state : PR/183303. Thanks a lot's Yvan !! From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 16:56:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E1E5A92B for ; Fri, 25 Oct 2013 16:56:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A6A6A2379 for ; Fri, 25 Oct 2013 16:56:17 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id r9PGuCHU004908 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 09:56:15 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <526AA2A7.4010904@freebsd.org> Date: Sat, 26 Oct 2013 00:56:07 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: MrStalker , freebsd-net@freebsd.org Subject: Re: How delete the interface route in FreeBSD 9.2 (MPD5)? References: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> <526A18FC.6030402@rdtc.ru> <526A894E.1070305@simvol7.ru> In-Reply-To: <526A894E.1070305@simvol7.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:56:18 -0000 On 10/25/13 11:07 PM, MrStalker wrote: > > 25.10.2013 11:08, Eugene Grosbein пишет: >> On 25.10.2013 03:42, MrStalker wrote: >>> Hello! >>> For my internet provider (L2TP VPN connection) is required a route >>> to the VPN server via local gate. >>> I'm using MPD5. >>> But, MPD5 creates route to the VPN server via its same interface... >>> >>> root@Eviko:/home/mrstalker # netstat -nrf inet >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Netif >>> Expire >>> default 85.21.230.206 UGS 0 8 ng0 >>> 85.21.230.206 link#7 UH 0 8 ng0 >>> >>> What will not work... >>> >>> However earlier, it was possible delete this route and then create >>> right route. >>> root@Test2:/home/mrstalker # route delete 85.21.230.206 >>> delete host 85.21.230.206 >>> root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 >>> add host 85.21.230.206: gateway 10.165.32.1 >>> >>> When i trying FreeBSD 9.2, this is no longer working... >>> Thread about it at the >>> forumhttp://forums.freebsd.org/showthread.php?t=42547 >>> Later I found source of problem: >>> http://svnweb.freebsd.org/base?view=revision&revision=248895 >>> >>> Now I can't delete the interface route (ng0). What does impossible >>> work with the internet provider. >>> >>> How? How now resolve this problem? >>> I need to add route to the vpn server via local gate... >>> >>> Please help me resolve this trouble. Since the release of FreeBSD >>> 9.2 I trying to find a solution. >> You have to create your static route to vpn server before mpd5 starts. >> Use /etc/rc.conf: >> >> static_routes="vpn" >> route_vpn="85.21.230.206 10.165.32.1" >> >> Eugene Grosbein > Unfortunately failed... > > root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 > 85.21.230.206 10.165.32.1 UGHS 0 0 re0 > root@Eviko:/home/mrstalker # service mpd5 start > Starting mpd5. > root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 > 85.21.230.206 link#7 UH 0 4 ng0 > > Route via ng0 overwrites the static route. then you have set it up wrong. you need a specific static route to the far end that does not go through tunnel. the only other possibilty is to have mpd use a separate fib.. e.g. setfib 3 route add (destination route) setfib 3 mpd (args) then you can allow the default route etc to go through the tunnel as the tunnel iteself will use a different routing table. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 17:04:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C7052A11; Fri, 25 Oct 2013 17:04:27 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9913123D3; Fri, 25 Oct 2013 17:04:27 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id q10so4265758pdj.28 for ; Fri, 25 Oct 2013 10:04:27 -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=fhcZmb2hNtq4I9rPXw8OLJ0R7+ySzsqtIhqEM8rV9FY=; b=hp5xbzNxUZrrtSg6nVAyioYrg8TvojgkOZees1PVKVPEhwKzO2PUjakDwizosl6vui XtrSHtF/rxGTgLnFs9HGbD3wnevBdAS2EyGyTJ8vNC5mjTTdj/w4C/OPt/UqnGXhVGOR ZFXR+cx/qOTg7z26tTGdFSHWxG5s7J8upfzstChU02kazQJjh2c20QAu7pcKh0mtxBjm xss9K49olg4Pedy7qxMrTrIg1nCysvf3jUFPNBmIbb66a7qfPYNQw2TWVMIO6Z4aNFsl hwwcw2RLBvGE5h7e9T3TqaywxIxj7qnx0iV8ngj2wTJ8lewSVWr4TV2bWEWUsmT/fBTi 00FA== MIME-Version: 1.0 X-Received: by 10.66.197.135 with SMTP id iu7mr11775156pac.149.1382720667222; Fri, 25 Oct 2013 10:04:27 -0700 (PDT) Received: by 10.70.30.98 with HTTP; Fri, 25 Oct 2013 10:04:27 -0700 (PDT) Received: by 10.70.30.98 with HTTP; Fri, 25 Oct 2013 10:04:27 -0700 (PDT) In-Reply-To: <526AA2A7.4010904@freebsd.org> References: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> <526A18FC.6030402@rdtc.ru> <526A894E.1070305@simvol7.ru> <526AA2A7.4010904@freebsd.org> Date: Fri, 25 Oct 2013 20:04:27 +0300 Message-ID: Subject: Re: How delete the interface route in FreeBSD 9.2 (MPD5)? From: Sami Halabi To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, MrStalker X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:04:27 -0000 You need to setup the up.sh script to modify the default route to go through the old default route... I have set this up at home... I'll post you the script when i'll be home. Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 25 =D7=91=D7=90=D7=95=D7=A7 2013 19:56= , "Julian Elischer" =D7=9B=D7=AA=D7=91: > On 10/25/13 11:07 PM, MrStalker wrote: > >> >> 25.10.2013 11:08, Eugene Grosbein =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> On 25.10.2013 03:42, MrStalker wrote: >>> >>>> Hello! >>>> For my internet provider (L2TP VPN connection) is required a route to >>>> the VPN server via local gate. >>>> I'm using MPD5. >>>> But, MPD5 creates route to the VPN server via its same interface... >>>> >>>> root@Eviko:/home/mrstalker # netstat -nrf inet >>>> Routing tables >>>> >>>> Internet: >>>> Destination Gateway Flags Refs Use Netif >>>> Expire >>>> default 85.21.230.206 UGS 0 8 ng0 >>>> 85.21.230.206 link#7 UH 0 8 ng0 >>>> >>>> What will not work... >>>> >>>> However earlier, it was possible delete this route and then create >>>> right route. >>>> root@Test2:/home/mrstalker # route delete 85.21.230.206 >>>> delete host 85.21.230.206 >>>> root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 >>>> add host 85.21.230.206: gateway 10.165.32.1 >>>> >>>> When i trying FreeBSD 9.2, this is no longer working... >>>> Thread about it at the forumhttp://forums.freebsd.** >>>> org/showthread.php?t=3D42547 >>>> Later I found source of problem: >>>> http://svnweb.freebsd.org/**base?view=3Drevision&revision=3D**248895 >>>> >>>> Now I can't delete the interface route (ng0). What does impossible wor= k >>>> with the internet provider. >>>> >>>> How? How now resolve this problem? >>>> I need to add route to the vpn server via local gate... >>>> >>>> Please help me resolve this trouble. Since the release of FreeBSD 9.2 = I >>>> trying to find a solution. >>>> >>> You have to create your static route to vpn server before mpd5 starts. >>> Use /etc/rc.conf: >>> >>> static_routes=3D"vpn" >>> route_vpn=3D"85.21.230.206 10.165.32.1" >>> >>> Eugene Grosbein >>> >> Unfortunately failed... >> >> root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 >> 85.21.230.206 10.165.32.1 UGHS 0 0 re0 >> root@Eviko:/home/mrstalker # service mpd5 start >> Starting mpd5. >> root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 >> 85.21.230.206 link#7 UH 0 4 ng0 >> >> Route via ng0 overwrites the static route. >> > then you have set it up wrong. > you need a specific static route to the far end that does not go through > tunnel. > > the only other possibilty is to have mpd use a separate fib.. > e.g. > > setfib 3 route add (destination route) > setfib 3 mpd (args) > then you can allow the default route etc to go through the tunnel > as the tunnel iteself will use a different routing table. > > > ______________________________**_________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org<= freebsd-net-unsubscribe@freebsd.org> >> " >> >> >> > ______________________________**_________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org > " From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 21:38:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 626429C9 for ; Fri, 25 Oct 2013 21:38:10 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2FBF82382 for ; Fri, 25 Oct 2013 21:38:10 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so4206444pad.23 for ; Fri, 25 Oct 2013 14:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dokukino.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OmjmVklGxAtCU65DXOl5CL/sfH4fe7GGycShTMQtFHQ=; b=NolITtjZQc5oBXLRJtnclI3nsbBovOTjoQcvbu1V30GgmnscJ33g3AYwRkt0rLR2PD O099HAhojLrgPONcXPJoRLW6ubVVeMWLxR+bJe54qbnihfj96hVTi4g6zz6Fwatn8E3u ESSU6f8yyeONBRjAS/aMJ+E0Xu0Py0F2bUiJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OmjmVklGxAtCU65DXOl5CL/sfH4fe7GGycShTMQtFHQ=; b=IEKl5UC2XE5QXT3O5u759/3lgg06vaG7z+nWkg3Y3gfX+76hgPJLa17rv4mo46r0b/ NevpDy4FIzHWO5Apn3i5hlfiBo29VOXzzBz9c36auiHiskyv6/5Oetel32R3M1UDMaKi L4AB2KaSMXDD1AEZqiUJZ1tCs3KnVilDN/gfw6+bu187dLz3Z7bDdMn9tkY4Er249thk O/NQl7rZmNryUmCqEXq5FNi3MR9/Wepz4gk5eYplF8Ulj4CrSxBhRg6Po3vl2U9WpeaG R0C6sDaeA8yMppBkrV2bMAw285LQXi92nsSGmXdWa08qOWwVR1pD9h9xF3ZcZeCdtP1B udLg== X-Gm-Message-State: ALoCoQnDXW/12NWaNT0SktrK5eKrBUAuYPMfoVT8w4C+S8FJUUt8/G+xwtHVncCZhEqJaSKHpvOI X-Received: by 10.66.162.167 with SMTP id yb7mr12905933pab.16.1382737089666; Fri, 25 Oct 2013 14:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.138 with HTTP; Fri, 25 Oct 2013 14:37:29 -0700 (PDT) In-Reply-To: References: From: Takuya ASADA Date: Sat, 26 Oct 2013 06:37:29 +0900 Message-ID: Subject: Re: Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution) To: hiren panchasara Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:38:10 -0000 2013/10/24 hiren panchasara > On Mon, Oct 7, 2013 at 5:49 PM, hiren panchasara > wrote: > > On Mon, Oct 7, 2013 at 12:01 AM, Takuya ASADA wrote: > >> Hi, > >> > >> This is updated version of "ixgbetool" patch. > > I will try to give this a try tomorrow. > > Alright, sorry for the delay. I now have bandwidth/setup to test this. > > > > Cheers, > > Hiren > >> Here's improved feature list: > >> - signature filter list feature available > >> - user-defined filter can be use with an ATR. > > How does this work? You identify user-defined flows and apply ATR on > the rest of the flows? > I made a hash table for user-defined filters, insert a filter entry into a hash table when it added. And when ixgbe driver try to change queue assignment by ATR, lookup a hash table and prevent changing if the entry is on a hash table. >> To enable it, add "hw.ixgbe.cooperative_atr=1" on /boot/loader.conf > >> > >> Usage is as follows: > >> ixgbetool [operation] > >> add_sig_filter > >> > >> show_sig_filter > >> del_sig_filter > > I believe, I can somehow test whether the signature filter works or > not by generating custom traffic, creating matching filter, directing > the traffic to a specific queue and watch that queue. > > But how do I test/see ATR (application targeted receive) in action? > Traffic for a specific application should follow the application on > different cpus, right? Any guidance on how to do that would be great. > To do it specifically, we should add debug printf on ixgbe_rxeof, printout hash value and queue number. Actually, if test flow is only one, you can see which queue is processing the flow by using "top -P". If ATR is working properly, ixgbe will changes queue assign every few moments (unless communicating process is pinned by cpuset command). But I don't see such behavior when I using ATR, even my patch is not applied. I'm guessing ixgbe_atr() function is failing to detect current CPU of communicating process. Could be it required extra kernel parameter configuration to enable ATR, but I haven't find any informations for it. From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 21:41:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B8F78B11; Fri, 25 Oct 2013 21:41:41 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8969E23DD; Fri, 25 Oct 2013 21:41:41 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id ma3so445958pbc.4 for ; Fri, 25 Oct 2013 14:41:41 -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=s2+zLIGKxvauUY+i9CU6+bNcVXFpmaFeg8F7KhIanaY=; b=N9fhRmlifjbsIaEEPxoZk/1iStL29ueserKyJcuej/y1mjyWavNsJABHHrWsEA7q+e gHJNu6dz4UqSz+qHhRZt/abCpfPfrSvRe65P6/u1+QIJPTyMBA44ivwghnQ053eB0VUO tozPBrF5fa1SK7ZBxcs1CeHIMTEhJFH8B0PTAYANz0cZQzY/I0zG7LtQgISjVwJwoP5Z iM1Q85nasVOyN52o1oEob5WRe+0kElrgDliOVC4F41LQV4zwRrrXbTsRs4v9r1pS+8r/ dEPteZCL32IE3Cluj3FZcDttk/RKiqAIa0dOniwhm5LGsHPus6onA3yz+dzB5sVEucJM bxdQ== MIME-Version: 1.0 X-Received: by 10.68.180.34 with SMTP id dl2mr8900917pbc.6.1382737301236; Fri, 25 Oct 2013 14:41:41 -0700 (PDT) Received: by 10.70.30.98 with HTTP; Fri, 25 Oct 2013 14:41:41 -0700 (PDT) In-Reply-To: References: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> <526A18FC.6030402@rdtc.ru> <526A894E.1070305@simvol7.ru> <526AA2A7.4010904@freebsd.org> Date: Sat, 26 Oct 2013 00:41:41 +0300 Message-ID: Subject: Re: How delete the interface route in FreeBSD 9.2 (MPD5)? From: Sami Halabi To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , MrStalker X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:41:41 -0000 Hi, here is what I did: 1. in the mpd.conf under l2tp_cliet section: set iface route default set iface up-script /usr/local/etc/mpd5/io-up set iface down-script /usr/local/etc/mpd5/io-down 2. io-up has the following: #!/bin/sh /usr/bin/netstat -nr >> /tmp/io-up-netstat LocalGW=3D`/usr/local/etc/mpd5/GW` echo $LocalGW > /tmp/.GW route delete $4 route add $4 $LocalGW route delete default route add default $4 echo $4 > /tmp/pptp_GW cp /etc/resolv.conf /etc/rsolv.conf-1 echo nameserver `echo $6|awk '{print $2;}'` > /etc/resolv.conf echo nameserver `echo $7|awk '{print $2;}'` >> /etc/resolv.conf echo $0 $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 >> /tmp/io-up /usr/bin/netstat -nr >> /tmp/io-up-netstat 3. io-down has the following: #!/bin/sh /usr/bin/netstat -nr >> /tmp/io-down-netstat LocalGW=3D`cat /tmp/.GW` vpnGW=3D`cat /tmp/pptp_GW` route delete $vpnGW route delete default route add default $LocalGW cp /etc/resolv.conf-1 /etc/rsolv.conf echo $0 $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 >> /tmp/io-down /usr/bin/netstat -nr >> /tmp/io-down-netstat 4. /usr/local/etc/mpd5/GW has the following: #!/bin/csh -f /usr/bin/netstat -nr | /usr/bin/grep default | /usr/bin/awk '{print $2;}' Hope this helps. Sami On Fri, Oct 25, 2013 at 8:04 PM, Sami Halabi wrote: > You need to setup the up.sh script to modify the default route to go > through the old default route... I have set this up at home... I'll post > you the script when i'll be home. > > Sami > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 25 =D7=91=D7=90=D7=95=D7=A7 2013 19:= 56, "Julian Elischer" =D7=9B=D7=AA=D7=91: > > On 10/25/13 11:07 PM, MrStalker wrote: >> >>> >>> 25.10.2013 11:08, Eugene Grosbein =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> >>>> On 25.10.2013 03:42, MrStalker wrote: >>>> >>>>> Hello! >>>>> For my internet provider (L2TP VPN connection) is required a route to >>>>> the VPN server via local gate. >>>>> I'm using MPD5. >>>>> But, MPD5 creates route to the VPN server via its same interface... >>>>> >>>>> root@Eviko:/home/mrstalker # netstat -nrf inet >>>>> Routing tables >>>>> >>>>> Internet: >>>>> Destination Gateway Flags Refs Use Netif >>>>> Expire >>>>> default 85.21.230.206 UGS 0 8 ng0 >>>>> 85.21.230.206 link#7 UH 0 8 ng0 >>>>> >>>>> What will not work... >>>>> >>>>> However earlier, it was possible delete this route and then create >>>>> right route. >>>>> root@Test2:/home/mrstalker # route delete 85.21.230.206 >>>>> delete host 85.21.230.206 >>>>> root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 >>>>> add host 85.21.230.206: gateway 10.165.32.1 >>>>> >>>>> When i trying FreeBSD 9.2, this is no longer working... >>>>> Thread about it at the forumhttp://forums.freebsd.** >>>>> org/showthread.php?t=3D42547 >>>>> Later I found source of problem: >>>>> http://svnweb.freebsd.org/**base?view=3Drevision&revision=3D**248895<= http://svnweb.freebsd.org/base?view=3Drevision&revision=3D248895> >>>>> >>>>> Now I can't delete the interface route (ng0). What does impossible >>>>> work with the internet provider. >>>>> >>>>> How? How now resolve this problem? >>>>> I need to add route to the vpn server via local gate... >>>>> >>>>> Please help me resolve this trouble. Since the release of FreeBSD 9.2 >>>>> I trying to find a solution. >>>>> >>>> You have to create your static route to vpn server before mpd5 starts. >>>> Use /etc/rc.conf: >>>> >>>> static_routes=3D"vpn" >>>> route_vpn=3D"85.21.230.206 10.165.32.1" >>>> >>>> Eugene Grosbein >>>> >>> Unfortunately failed... >>> >>> root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 >>> 85.21.230.206 10.165.32.1 UGHS 0 0 re0 >>> root@Eviko:/home/mrstalker # service mpd5 start >>> Starting mpd5. >>> root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 >>> 85.21.230.206 link#7 UH 0 4 ng0 >>> >>> Route via ng0 overwrites the static route. >>> >> then you have set it up wrong. >> you need a specific static route to the far end that does not go through >> tunnel. >> >> the only other possibilty is to have mpd use a separate fib.. >> e.g. >> >> setfib 3 route add (destination route) >> setfib 3 mpd (args) >> then you can allow the default route etc to go through the tunnel >> as the tunnel iteself will use a different routing table. >> >> >> ______________________________**_________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org= >>> " >>> >>> >>> >> ______________________________**_________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org<= freebsd-net-unsubscribe@freebsd.org> >> " > > --=20 Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Fri Oct 25 23:02:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0B6D371 for ; Fri, 25 Oct 2013 23:02:21 +0000 (UTC) (envelope-from sergv326@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A05828A1 for ; Fri, 25 Oct 2013 23:02:18 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id z15so1011706ead.5 for ; Fri, 25 Oct 2013 16:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type:subject :from:date:to:message-id; bh=bm3EEjLtZE3NBGx2kaQmddAvgQVaWuu6+ZWaQDTfG+Y=; b=r96FmXJ2pCqPbo/UsJt0nMp4Ha3iWCbeEy4anVPwJ3Qtn2cM//+j4qVFlr6FPs4GwC LCxV18z5BKkKgZEEkjAQO7cVaBFsG0K8KMa/iRfjZYJEcIrf3ABx1PyH9yo47obC2dDX drz8IobJDNiIOpBy4zDvcWj/J+8sk7s2sRnXc1iQapCKCUdVCM13woYm1I2YW5xS5y9O RzDUxMh79UzxChCM3UFcjSdwMifNdZqYRwZVDpDox3menXd1WAtZsnuQKOsDmLtSpwBS 6Uge9u+QQTQGNlfWIpm1rFMrg/mCexVfC57Pk/edpmTsHVWubG+sSRJ+fwKcNtnaDUQG Cy+w== X-Received: by 10.15.54.2 with SMTP id s2mr1604eew.139.1382742136501; Fri, 25 Oct 2013 16:02:16 -0700 (PDT) Received: from [10.250.251.251] ([85.26.232.123]) by mx.google.com with ESMTPSA id u46sm23406156eep.17.2013.10.25.16.02.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 16:02:15 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> References: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> MIME-Version: 1.0 Subject: Re: How delete the interface route in FreeBSD 9.2 (MPD5)? From: sergv326 Date: Sat, 26 Oct 2013 03:01:37 +0400 To: mrstalker@simvol7.ru, MrStalker , freebsd-net@freebsd.org. Message-ID: <40d6d33c-c635-4a00-a577-1301326e5266@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:02:21 -0000 You don't need to use "route default" at all. Make all routing table changes via up-down scripts. You have sufficient set of variables which you can use via $1 $2 $3 etc... MrStalker пишет: > Hello! > For my internet provider (L2TP VPN connection) is required a route to > the VPN server via local gate. > I'm using MPD5. > But, MPD5 creates route to the VPN server via its same interface... > root@Eviko:/home/mrstalker # netstat -nrf inet > Routing tables > Internet: > Destination� � � � � � � Gateway� � � � � � � � � � � Flags� � � > Refs� � � � � Use� Netif Expire > default� � � � � � � � � � � 85.21.230.206� � � � � > UGS� � � � � � � � 0� � � � � � � 8� � � ng0 > 85.21.230.206� � � � � link#7� � � � � � � � � � � � > UH� � � � � � � � � 0� � � � � � � 8� � � ng0 > What will not work... > However earlier, it was possible delete this route and then create > right route. > root@Test2:/home/mrstalker # route delete 85.21.230.206 > delete host 85.21.230.206 > root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 > add host 85.21.230.206: gateway 10.165.32.1 > When i trying FreeBSD 9.2, this is no longer working... > Thread about it at the forum > http://forums.freebsd.org/showthread.php?t=42547 > Later I found source of problem: > http://svnweb.freebsd.org/base?view=revision&revision=248895 >Now I can't delete the interface route (ng0). What does impossible work > with the� internet provider. > How? How now resolve this problem? > I need to add route to the vpn server via local gate... >Please help me resolve this trouble. Since the release of FreeBSD 9.2 I > trying to find a solution. > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Sat Oct 26 05:16:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1B2A468C; Sat, 26 Oct 2013 05:16:37 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD03B2898; Sat, 26 Oct 2013 05:16:36 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id cz12so3484737veb.10 for ; Fri, 25 Oct 2013 22:16:35 -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=/hvMeaanInXv5QqAZtU4dvM/HJ/CJCgogt6t5S1Ky1M=; b=n3Q4ggUXcJ7Km/pYWUpiyb82I3Eyt2wU0pNEayNpueiKJ+PRl0i0av0haSyg1xKT0d 6kiauQ+aSlfEpsoviUAzaXLCFhEg9O3ZVLYlQ7ZSkR8leZyLX9bYv3MvyMHUaGlaQ8Om hLsChT4oP2jfqflgp3a4xkRNgHihUtx7hjJnWsAox/Nq8+h09fpn/oQa+1hUU0hC6NkB uO8uHbrEZVqwElEk8geey0IR37vZNgT+xAtBIY9cB2hKGv2tMEPQM9siCy8iZwEXfzmc RN30m9AjNFeCWa+JSNxFdyAQ+RCHB6kvEJdsuwyWJiJJSoW4DJBhV55+0fQi4Qiqy99G X5Hw== MIME-Version: 1.0 X-Received: by 10.58.146.71 with SMTP id ta7mr6806976veb.23.1382764595491; Fri, 25 Oct 2013 22:16:35 -0700 (PDT) Received: by 10.220.30.130 with HTTP; Fri, 25 Oct 2013 22:16:35 -0700 (PDT) Date: Sat, 26 Oct 2013 01:16:35 -0400 Message-ID: Subject: Or it could be ZFS memory starvation and 9k packets (was Re: istgt causes massive jumbo nmbclusters loss) From: Zaphod Beeblebrox To: FreeBSD Net , freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 05:16:37 -0000 At first I thought this was entirely the interaction of istgt and 9k packets, but after some observation (and a few more hangs) I'm reasonably positive it's a form of resource starvation related to ZFS and 9k packets. To reliably trigger the hang, I need to do something that triggers a demand for 9k packets (like istgt traffic, but also bit torrent traffic --- as you see the MTU is 9014) and it must have been some time since the system booted. ZFS is fairly busy (with both NFS and SMB guests), so it generally takes quite a bit of the 8G of memory for itself. Now... below the netstat -m shows 1399 9k bufs with 376 available. When the network gets busy, I've seen 4k or even 5k bufs in total... never near the 77k max. After some time of lesser activity, the number of 9k buffers returns to this level. When the problem occurs, the number of denied buffers will shoot up at the rate of several hundred or even several thousand per second, but the system will not be "out" of memory. Top will show 800 meg often in the free column when this happens. While it's happening, when I'm logged into the console, none of these stats seem out of place, save the number of denied 9k buffer allocations and the "cache" of 9k buffers will be less than 10 (but I've never seen it at 0). On Tue, Oct 22, 2013 at 3:42 PM, Zaphod Beeblebrox wrote: > I have a server > > FreeBSD virtual.accountingreality.com 9.2-STABLE FreeBSD 9.2-STABLE #13 > r256549M: Tue Oct 15 16:29:48 EDT 2013 > root@virtual.accountingreality.com:/usr/obj/usr/src/sys/VRA amd64 > > That has an em0 with jumbo packets enabled: > > em0: flags=8843 metric 0 mtu 9014 > > It has (among other things): ZFS, NFS, iSCSI (via istgt) and Samba. > > Every day or two, it looses it's ability to talk to the network. ifconfig > down/up on em0 gives the message about not being able to allocate the > receive buffers... > > With everything running, but with specifically iSCSI not used, everything > seems good. When I start hitting istgt, I see the denied stat for 9k mbufs > rise very rapidly (this amount only took a few seconds): > > [1:47:347]root@virtual:/usr/local/etc/iet> netstat -m > 1313/877/2190 mbufs in use (current/cache/total) > 20/584/604/523514 mbuf clusters in use (current/cache/total/max) > 20/364 mbuf+clusters out of packet secondary zone in use (current/cache) > 239/359/598/261756 4k (page size) jumbo clusters in use > (current/cache/total/max) > 1023/376/1399/77557 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/43626 16k jumbo clusters in use (current/cache/total/max) > 10531K/6207K/16738K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/50199/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > ... the denied number rises... and somewhere in the millions or more the > machine stops --- but even with the large number of denied 9k clusters, the > "9k jumbo clusters in use" line will always indicate some available. > > ... so is this a tuning or a bug issue? I've tried ietd --- basically it > doesn't want to work with a zfs zvol, it seems (refuses to use it). > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 26 05:52:41 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4AE029F1 for ; Sat, 26 Oct 2013 05:52:41 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3E8629F0 for ; Sat, 26 Oct 2013 05:52:40 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r9Q5qcwK092749; Sat, 26 Oct 2013 01:52:38 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r9Q5qcIv092748; Sat, 26 Oct 2013 01:52:38 -0400 (EDT) (envelope-from wollman) Date: Sat, 26 Oct 2013 01:52:38 -0400 (EDT) From: Garrett Wollman Message-Id: <201310260552.r9Q5qcIv092748@hergotha.csail.mit.edu> To: zbeeble@gmail.com Subject: Re: Or it could be ZFS memory starvation and 9k packets (was Re: istgt causes massive jumbo nmbclusters loss) X-Newsgroups: mit.lcs.mail.freebsd-net In-Reply-To: Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 26 Oct 2013 01:52:38 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 05:52:41 -0000 In article you write: >Now... below the netstat -m shows 1399 9k bufs with 376 available. When >the network gets busy, I've seen 4k or even 5k bufs in total... never near >the 77k max. After some time of lesser activity, the number of 9k buffers >returns to this level. The network interface (driver) almost certainly should not be using 9k mbufs. These buffers are physically contiguous, and after not too much activity, it will be nearly impossible to allocate three physically contiguous buffers. >> That has an em0 with jumbo packets enabled: >> >> em0: flags=8843 metric 0 mtu 9014 I don't know for certain about em(4), but it very likely should not be using 9k mbufs. Intel network hardware has done scatter-gather since nearly the year dot. (Seriously, I wrote a network driver for the i82586 back at the very beginning of FreeBSD's existence, and *that* part had scatter-gather. No jumbo frames, though!) The entire existence of 9k and 16k mbufs is probably a mistake. There should not be any network interfaces that are modern enough to do jumbo frames but ancient enough to require physically contiguous pages for each frame. I don't know if the em(4) driver is written such that you can just disable the use of those mbufs, though. You could try making this change, though. Look for this code in if_em.c: /* ** Figure out the desired mbuf ** pool for doing jumbos */ if (adapter->max_frame_size <= 2048) adapter->rx_mbuf_sz = MCLBYTES; else if (adapter->max_frame_size <= 4096) adapter->rx_mbuf_sz = MJUMPAGESIZE; else adapter->rx_mbuf_sz = MJUM9BYTES; Comment out the last two lines and change the else if (...) to else. It's not obvious that the rest of the code can cope with this, but it does work that way on other Intel hardware so it seems like it may be worth a shot. -GAWollman From owner-freebsd-net@FreeBSD.ORG Sat Oct 26 09:23:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A5795357 for ; Sat, 26 Oct 2013 09:23:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB17D21B5 for ; Sat, 26 Oct 2013 09:23:01 +0000 (UTC) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-net@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id r9Q9MpZX078071; Sat, 26 Oct 2013 16:22:52 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <526B89EB.7090409@grosbein.net> Date: Sat, 26 Oct 2013 16:22:51 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: MrStalker Subject: Re: How delete the interface route in FreeBSD 9.2 (MPD5)? References: <63600.37.147.154.147.1382647335.squirrel@37.147.154.147> <526A18FC.6030402@rdtc.ru> <526A894E.1070305@simvol7.ru> In-Reply-To: <526A894E.1070305@simvol7.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eg.sd.rdtc.ru Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 09:23:02 -0000 On 25.10.2013 22:07, MrStalker wrote: > > 25.10.2013 11:08, Eugene Grosbein ÐÉÛÅÔ: >> On 25.10.2013 03:42, MrStalker wrote: >>> Hello! >>> For my internet provider (L2TP VPN connection) is required a route to the VPN server via local gate. >>> I'm using MPD5. >>> But, MPD5 creates route to the VPN server via its same interface... >>> >>> root@Eviko:/home/mrstalker # netstat -nrf inet >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Netif Expire >>> default 85.21.230.206 UGS 0 8 ng0 >>> 85.21.230.206 link#7 UH 0 8 ng0 >>> >>> What will not work... >>> >>> However earlier, it was possible delete this route and then create right route. >>> root@Test2:/home/mrstalker # route delete 85.21.230.206 >>> delete host 85.21.230.206 >>> root@Test2:/home/mrstalker # route add 85.21.230.206 10.165.32.1 >>> add host 85.21.230.206: gateway 10.165.32.1 >>> >>> When i trying FreeBSD 9.2, this is no longer working... >>> Thread about it at the forumhttp://forums.freebsd.org/showthread.php?t=42547 >>> Later I found source of problem: >>> http://svnweb.freebsd.org/base?view=revision&revision=248895 >>> >>> Now I can't delete the interface route (ng0). What does impossible work with the internet provider. >>> >>> How? How now resolve this problem? >>> I need to add route to the vpn server via local gate... >>> >>> Please help me resolve this trouble. Since the release of FreeBSD 9.2 I trying to find a solution. >> You have to create your static route to vpn server before mpd5 starts. >> Use /etc/rc.conf: >> >> static_routes="vpn" >> route_vpn="85.21.230.206 10.165.32.1" >> >> Eugene Grosbein > Unfortunately failed... > > root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 > 85.21.230.206 10.165.32.1 UGHS 0 0 re0 > root@Eviko:/home/mrstalker # service mpd5 start > Starting mpd5. > root@Eviko:/home/mrstalker # netstat -nrf inet|grep 85.21.230.206 > 85.21.230.206 link#7 UH 0 4 ng0 > > Route via ng0 overwrites the static route. You should try to prevent mpd from installing this route (and removing yours static one) in first place. Try to add this command to your mpd.conf to bundle context: set ipcp ranges 0.0.0.0/0 1.1.1.1/0 From owner-freebsd-net@FreeBSD.ORG Sat Oct 26 11:49:50 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CC82B18F; Sat, 26 Oct 2013 11:49:50 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9E428CE; Sat, 26 Oct 2013 11:49:50 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Va2PE-000AzY-DQ; Sat, 26 Oct 2013 15:51:48 +0400 Date: Sat, 26 Oct 2013 15:51:48 +0400 From: Slawa Olhovchenkov To: Julian Elischer , Andre Oppermann Subject: Re: long standing tcp bug: kern/25986 Message-ID: <20131026115148.GJ63359@zxy.spb.ru> References: <20131021121122.GA48316@zxy.spb.ru> <52656455.3060408@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52656455.3060408@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-net@FreeBSD.ORG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 11:49:50 -0000 On Tue, Oct 22, 2013 at 01:28:53AM +0800, Julian Elischer wrote: > On 10/21/13 8:11 PM, Slawa Olhovchenkov wrote: > > This PR contains patch. Can anybody commit it? > > > > Bug opened from 2001-Mar-22 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > really belongs in -net > CCing to there > > Andre? Also sockets infinite stick in CLOSED state. From owner-freebsd-net@FreeBSD.ORG Sat Oct 26 11:51:42 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 63707249; Sat, 26 Oct 2013 11:51:42 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39974290F; Sat, 26 Oct 2013 11:51:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9QBpg2b029362; Sat, 26 Oct 2013 11:51:42 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9QBpgOK029361; Sat, 26 Oct 2013 11:51:42 GMT (envelope-from ae) Date: Sat, 26 Oct 2013 11:51:42 GMT Message-Id: <201310261151.r9QBpgOK029361@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-net@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/181699: [ipsec] [patch] IPsec does scale to large SPD / SADB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 11:51:42 -0000 Synopsis: [ipsec] [patch] IPsec does scale to large SPD / SADB Responsible-Changed-From-To: freebsd-net->ae Responsible-Changed-By: ae Responsible-Changed-When: Sat Oct 26 11:51:12 UTC 2013 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=181699 From owner-freebsd-net@FreeBSD.ORG Sat Oct 26 18:55:20 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F34E159 for ; Sat, 26 Oct 2013 18:55:20 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E9992D50 for ; Sat, 26 Oct 2013 18:55:19 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id c14so2363459vea.0 for ; Sat, 26 Oct 2013 11:55:19 -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=yNdU9k4G49LfaZJ6BtlEvU8UMxbwTl0DV8qcdC/BObQ=; b=fKFW156PbsJVjuipT3XnP5ye8ZsNjIl64WmRKmaA7Y/Dj1Lg/aYeP/ZJrcrlM8RDYo kh99ukZO16KKzsWOmtKxWdua0ULgKqQDx68+6noYeRC4w6gG1k8nHSCpUtsEdM6IGzzX AE9kk+P5TTWtSxUynipAJvdXGVVgYuQbLLMXeDIlCPB6zQEZQk5dEAtLldDyE4Q4M42+ +2/5Zcr0f87oiCd6mx8pWuxfYGzcyRDtC5jXFMyOD04amXgfsOaMUgHgbpKy8c1LsXL2 CKViZ/xWdBIq2v4WDCF4+zfC9zr0EcZqHueZU5E3Hl0tVaQMrh3J1kUoyrcfaHQ75Chn RlsA== MIME-Version: 1.0 X-Received: by 10.52.118.73 with SMTP id kk9mr6893426vdb.13.1382813719122; Sat, 26 Oct 2013 11:55:19 -0700 (PDT) Received: by 10.220.30.130 with HTTP; Sat, 26 Oct 2013 11:55:19 -0700 (PDT) In-Reply-To: <201310260552.r9Q5qcIv092748@hergotha.csail.mit.edu> References: <201310260552.r9Q5qcIv092748@hergotha.csail.mit.edu> Date: Sat, 26 Oct 2013 14:55:19 -0400 Message-ID: Subject: Re: Or it could be ZFS memory starvation and 9k packets (was Re: istgt causes massive jumbo nmbclusters loss) From: Zaphod Beeblebrox To: Garrett Wollman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 18:55:20 -0000 To be clear, I made just this patch: Index: if_em.c =================================================================== --- if_em.c (revision 256870) +++ if_em.c (working copy) @@ -1343,10 +1343,10 @@ */ if (adapter->hw.mac.max_frame_size <= 2048) adapter->rx_mbuf_sz = MCLBYTES; - else if (adapter->hw.mac.max_frame_size <= 4096) + else /*if (adapter->hw.mac.max_frame_size <= 4096) */ adapter->rx_mbuf_sz = MJUMPAGESIZE; - else - adapter->rx_mbuf_sz = MJUM9BYTES; + /* else + adapter->rx_mbuf_sz = MJUM9BYTES; */ /* Prepare receive descriptors and buffers */ if (em_setup_receive_structures(adapter)) { (which is against 9.2-STABLE if you're looking). The result is that no 9k clusters appear to be allocated. I'm still running the system as before, but so far the problem has not recurred. Of note, given your comment, is that this patch doesn't appear to break anything, either. Should I send-pr it? On Sat, Oct 26, 2013 at 1:52 AM, Garrett Wollman < wollman@hergotha.csail.mit.edu> wrote: > In article < > CACpH0MfEy50Y5QOZCdn2co_JmY_QPfVRxYwK-73W0WYsHB-Fqw@mail.gmail.com> you > write: > > >Now... below the netstat -m shows 1399 9k bufs with 376 available. When > >the network gets busy, I've seen 4k or even 5k bufs in total... never near > >the 77k max. After some time of lesser activity, the number of 9k buffers > >returns to this level. > > The network interface (driver) almost certainly should not be using 9k > mbufs. These buffers are physically contiguous, and after not too > much activity, it will be nearly impossible to allocate three > physically contiguous buffers. > > >> That has an em0 with jumbo packets enabled: > >> > >> em0: flags=8843 metric 0 mtu > 9014 > > I don't know for certain about em(4), but it very likely should not be > using 9k mbufs. Intel network hardware has done scatter-gather since > nearly the year dot. (Seriously, I wrote a network driver for the > i82586 back at the very beginning of FreeBSD's existence, and *that* > part had scatter-gather. No jumbo frames, though!) > > The entire existence of 9k and 16k mbufs is probably a mistake. There > should not be any network interfaces that are modern enough to do > jumbo frames but ancient enough to require physically contiguous pages > for each frame. I don't know if the em(4) driver is written such that > you can just disable the use of those mbufs, though. You could try > making this change, though. Look for this code in if_em.c: > > /* > ** Figure out the desired mbuf > ** pool for doing jumbos > */ > if (adapter->max_frame_size <= 2048) > adapter->rx_mbuf_sz = MCLBYTES; > else if (adapter->max_frame_size <= 4096) > adapter->rx_mbuf_sz = MJUMPAGESIZE; > else > adapter->rx_mbuf_sz = MJUM9BYTES; > > Comment out the last two lines and change the else if (...) to else. > It's not obvious that the rest of the code can cope with this, but it > does work that way on other Intel hardware so it seems like it may be > worth a shot. > > -GAWollman > From owner-freebsd-net@FreeBSD.ORG Sat Oct 26 23:18:31 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2F73BD26 for ; Sat, 26 Oct 2013 23:18:31 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DDE6D2914 for ; Sat, 26 Oct 2013 23:18:30 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r9QNITKN004438; Sat, 26 Oct 2013 19:18:29 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r9QNIT2N004435; Sat, 26 Oct 2013 19:18:29 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21100.19909.244225.943956@hergotha.csail.mit.edu> Date: Sat, 26 Oct 2013 19:18:29 -0400 From: Garrett Wollman To: Zaphod Beeblebrox Subject: Re: Or it could be ZFS memory starvation and 9k packets (was Re: istgt causes massive jumbo nmbclusters loss) In-Reply-To: References: <201310260552.r9Q5qcIv092748@hergotha.csail.mit.edu> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 26 Oct 2013 19:18:29 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 23:18:31 -0000 < said: > The result is that no 9k clusters appear to be allocated. I'm still > running the system as before, but so far the problem has not recurred. Of > note, given your comment, is that this patch doesn't appear to break > anything, either. Should I send-pr it? You bet. Otherwise it will get lost. Hopefully it can be assigned to whoever is maintaining this driver as a reminder. -GAWollman