From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 08:59:34 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 796B8ECF for ; Sun, 7 Jun 2015 08:59:34 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CC501B65 for ; Sun, 7 Jun 2015 08:59:33 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id 1AE6F250A64 for ; Sun, 7 Jun 2015 10:50:34 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yi5i5kkt-Hz for ; Sun, 7 Jun 2015 10:50:31 +0200 (CEST) Received: from [192.168.52.11] (1F2EC6DD.catv.pool.telekom.hu [31.46.198.221]) by green.field.hu (Postfix) with ESMTPA id E78C9250A86 for ; Sun, 7 Jun 2015 10:50:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1433667031; bh=7QbYoWDFp9edOy/eb83kiyUGECjuXVfZ+N3LgoH3dGw=; h=Date:From:To:Subject:References:In-Reply-To; b=YSFNVGLO0EXrMTNPAsB8lEAAW46Y2DVLgUfD94jdsJZRFFWmMZoTcfUUPLpPNW2Vf ZEV663MgGpO3If4d31nk/33uX9vml3t/tg7fV7symROGtfJ88Rn4s9QiYaqSTsgZgr tFAFP9tJclVNuW29XPJyQRoKoCman5xxBo7V4j1E= Message-ID: <557405D3.2010909@field.hu> Date: Sun, 07 Jun 2015 10:50:27 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <2404899099-25362@alcyone.saas.tuxis.net> <5564308A.7010502@field.hu> In-Reply-To: <5564308A.7010502@field.hu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Jun 2015 08:59:34 -0000 Hi All, It worked fine for two weeks but I had a network outage 2 days ago then today. Tried to disable rxcsum and txcsum after the first one, didn't help. Don't know what else to do it's a shame that I can't use this card with fbsd i REALLY don't want to install linux instead but my production servers outages are not welcomed by the customers.. 2015.05.26. 10:36 keltezéssel, Cs írta: > Thanks Mark, good idea. I found this thread which is exactly the same > problem as mine: > https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ > > Will see if it helps in a couple weeks. > > Regards, > Csaba > > 2015.05.26. 10:30 keltezéssel, Mark Schouten írta: >> Oh, didn't see your lowest remark. Then, the next thing that comes >> past here a few times per week is 'Try disabling TSO'. >> >> >> Met vriendelijke groeten, >> >> -- >> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >> Mark Schouten | Tuxis Internet Engineering >> KvK: 61527076 | http://www.tuxis.nl/ >> T: 0318 200208 | info@tuxis.nl >> >> >> >> Van: Cs >> Aan: Mark Schouten >> Cc: >> Verzonden: 25-5-2015 11:12 >> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after high >> traffic >> >> It was on 1500 for ~3 years :) >> Regards, >> Csaba >> On May 25, 2015, 10:30, at 10:30, Mark Schouten >> wrote: >>> Try lowering your mtu to 1500, that worked miracles for me.. >>> >>> -- >>> Mark Schouten >>> Tuxis Internet Engineering >>> mark@tuxis.nl / 0318 200208 >>> >>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>> Hi all, >>>> I have two FreeBSd 10.1-RELEASE servers connected to each other. >>>> They >>> were connected via cross link, but they are connected to a cisco switch >>> now (the problem was the same with cross link too). When transferring >>> huge files (50-500GB backup files) via Gigabit (it is important!) the >>> network randomly dies. The backup runs every day/week and sometimes the >>> connection is ok for months sometimes it happens twice a week. When the >>> network dies I can log in to the server via IPMI and use the console >>> everything is OK, but can't send anything out on the network. ifconfig >>> em0 down/up doesn't help nor netif restart. The problem never occured >>> when I used 100Mbit connection between them, but it was 3com NIC (xl), >>> gigabit adapter is Intel (em0). When I limit the transfer rate (rsync >>> bandwith limit or ipfw pipe) the problem is much more rare. >>>> I tried to set these tuning parameters on both servers with >>>> different >>> buffer size but nothing helped: >>>> # cat /etc/sysctl.conf >>>> security.bsd.see_other_uids=0 >>>> net.inet.tcp.recvspace=512000 >>>> net.route.netisr_maxqlen=2048 >>>> kern.ipc.nmbclusters=1310720 >>>> net.inet.tcp.sendbuf_max=16777216 >>>> net.inet.tcp.recvbuf_max=16777216 >>>> kern.ipc.soacceptqueue=32768 >>>> # cat /boot/loader.conf >>>> geom_mirror_load="YES" # RAID1 disk driver (see gmirror(8)) >>>> ipfw_load="YES" >>>> net.inet.ip.fw.default_to_accept=1 >>>> kern.maxusers=4096 >>>> accf_data_load="YES" >>>> The duplex settings are identical on both servers. >>>> Server A: >>>> em1: flags=8843 metric 0 mtu >>> 9000 >>> options=4219b >>> >>> >>>> ether 00:25:90:24:52:66 >>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>> nd6 options=29 >>>> media: Ethernet autoselect (1000baseT ) >>>> status: active >>>> Server B: >>>> em0: flags=8843 metric 0 mtu >>> 9000 >>> options=4219b >>> >>> >>>> ether 00:30:48:dd:fe:3e >>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>> nd6 options=29 >>>> media: Ethernet autoselect (1000baseT ) >>>> status: active >>>> Today I tried to set mtu to 9000 but in tcpdump I see that during >>>> scp >>> it is still 1500: >>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee (incorrect -> >>> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS val >>> 3103966325 ecr 853712893], length 0 >>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags [DF], >>> proto TCP (6), length 1500) >>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags [DF], >>> proto TCP (6), length 1500) >>>> Any ideas? Thanks guys! >>>> _______________________________________________ >>>> 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 09:21:56 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C789366 for ; Sun, 7 Jun 2015 09:21:56 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27D5A11A1 for ; Sun, 7 Jun 2015 09:21:55 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id DA24E1872C; Sun, 7 Jun 2015 02:21:54 -0700 (PDT) Date: Sun, 7 Jun 2015 02:21:54 -0700 From: hiren panchasara To: Cs Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic Message-ID: <20150607092154.GP20409@strugglingcoder.info> References: <2404899099-25362@alcyone.saas.tuxis.net> <5564308A.7010502@field.hu> <557405D3.2010909@field.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zn4k3Q+N5puqXur4" Content-Disposition: inline In-Reply-To: <557405D3.2010909@field.hu> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Jun 2015 09:21:56 -0000 --zn4k3Q+N5puqXur4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 06/07/15 at 10:50P, Cs wrote: > Hi All, >=20 > It worked fine for two weeks but I had a network outage 2 days ago then= =20 > today. Tried to disable rxcsum and txcsum after the first one, didn't=20 > help. Don't know what else to do it's a shame that I can't use this card= =20 > with fbsd i REALLY don't want to install linux instead but my production= =20 > servers outages are not welcomed by the customers.. I tried to follow the thread but apologies if I've missed something. You already tried disabling TSO but it didn't help, it seems. We need more details here. Can you get on serial console and check if you see anything when network becomes unaccessible? Anything in dmesg or /var/log/message? Does 'netstat -m' show any buffer allocation failures when this happens? You seem to indicate that this only happens at 'high' traffic. How much is that traffic? Is this something that you can trigger easily? Cheers, Hiren --zn4k3Q+N5puqXur4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVdA0yXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lF4cH/09zrSIfrFmNzTwviAZOjy2Z O2DhorRp9JwkuolxycYVKQPfsYwlhapdniTPSKlDk5IKzU8cBl23r+aGsfDqkBuV xuZhbMhYYusjIwdgYJsalzvhZ3pbY5ezhaWSiwxV9FLgB63DVcu/krH8n36y/fQt zdB311cNWIjMsQK00AGapTtxH5hX091w+NVZA5ibhsBk9kUCJlm6rP+/f8ma8Uzd G7J+EFZpzdIRRcZQ5+7juR7GXVU83xM/VoPVLkeqIx3nPeQgRA2RW7vSiEygJT6C ooKhx7UEZjmjxrhySmr28eOTs2GbLMTxdRPRgXqHNOnK79ihkU9ifIG87/eEAnk= =vUe2 -----END PGP SIGNATURE----- --zn4k3Q+N5puqXur4-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 09:31:42 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 595E7538 for ; Sun, 7 Jun 2015 09:31:42 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11B4213C3 for ; Sun, 7 Jun 2015 09:31:41 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id 28BEC250A78 for ; Sun, 7 Jun 2015 11:31:40 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZWHZVzqragJ for ; Sun, 7 Jun 2015 11:31:37 +0200 (CEST) Received: from [192.168.52.11] (1F2EC6DD.catv.pool.telekom.hu [31.46.198.221]) by green.field.hu (Postfix) with ESMTPA id 9FA28250A64 for ; Sun, 7 Jun 2015 11:31:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1433669497; bh=t7A/DFzW/RsmuXgj8jPBYCWE9LLUYlU4FLc0a6W9nnU=; h=Date:From:To:Subject:References:In-Reply-To; b=LnqKZy2z/QnlbEW9u1vG+5zTRWVZ0MiSSLyFKDGZYfuJJPk+opcwl9aLwpLitSS/m uBwFBV3MAwg2F0LTo9TehpO8KltJDNnw2wW72UhFnl615JG7xFAeEcv+xUXH/M3eCk O5LOCww6iFuXLKxBb+FPL9wQxE5uki3ifdS2etso= Message-ID: <55740F76.20301@field.hu> Date: Sun, 07 Jun 2015 11:31:34 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <2404899099-25362@alcyone.saas.tuxis.net> <5564308A.7010502@field.hu> <557405D3.2010909@field.hu> <20150607092154.GP20409@strugglingcoder.info> In-Reply-To: <20150607092154.GP20409@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Jun 2015 09:31:42 -0000 that's correct, disabling TSO didn't help however I did not disable vlanhwtso so it's my next step but I don't use vlans. I can access the server via IPMI checked the netstat no buffer problem there, no error in /var/log/messages just the ntpd no route to host caused by the network outage. about high traffic: during the night other server sent 10GB backup to this server via em0 interface. the problem is much more the transfer rate than the size of the file, but I can't reproduce it just wait to happen again. Cheers, Csaba 2015.06.07. 11:21 keltezéssel, hiren panchasara írta: > On 06/07/15 at 10:50P, Cs wrote: >> Hi All, >> >> It worked fine for two weeks but I had a network outage 2 days ago then >> today. Tried to disable rxcsum and txcsum after the first one, didn't >> help. Don't know what else to do it's a shame that I can't use this card >> with fbsd i REALLY don't want to install linux instead but my production >> servers outages are not welcomed by the customers.. > I tried to follow the thread but apologies if I've missed something. You > already tried disabling TSO but it didn't help, it seems. We need more > details here. > > Can you get on serial console and check if you see anything when network > becomes unaccessible? Anything in dmesg or /var/log/message? Does > 'netstat -m' show any buffer allocation failures when this happens? > > You seem to indicate that this only happens at 'high' traffic. How much > is that traffic? Is this something that you can trigger easily? > > Cheers, > Hiren From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 13:18:58 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B920633B; Sun, 7 Jun 2015 13:18:58 +0000 (UTC) (envelope-from jason.unovitch@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96208165C; Sun, 7 Jun 2015 13:18:58 +0000 (UTC) (envelope-from jason.unovitch@gmail.com) Received: by iebgx4 with SMTP id gx4so82928832ieb.0; Sun, 07 Jun 2015 06:18:57 -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=7ju4TgEGegflKy/xkxMssV8KMcnbyC9yTUcZcBJHhv4=; b=R9cNDVVtvDff6f465gwPvd6acmZ+4ltm3VGyk5Vk08Ep7KA8m5PPDG8iadWH5BvriI u9qgqnGjgkvALSVfT2KC0lci4l5W4rryHRbTvhNw6h0VbweuCykPFlMpTdWS/7U+rHGs 3K/MNPiXzZYzbZDiwogwFEOBjL8tq+XwyR7fxkwexihWl3PybnuCxbmMNKq4UT8L/vsO Oh+kwGpbkDf/efzYsWzKXKeoP1qW7wh9SlWwmctpV/wKpiVloHJ1dJf/b4oYnu4fHcOS 23KqtgBmUjcHrZAq0wN/bexDJyfd+y6v/q1tAiRe3/cTAEWoBBqECbzk+BIcBVhtqp5W sh2Q== MIME-Version: 1.0 X-Received: by 10.107.35.203 with SMTP id j194mr14929907ioj.45.1433683137696; Sun, 07 Jun 2015 06:18:57 -0700 (PDT) Received: by 10.36.27.13 with HTTP; Sun, 7 Jun 2015 06:18:57 -0700 (PDT) In-Reply-To: <55734E7F.2070308@Plominski.eu> References: <55734E7F.2070308@Plominski.eu> Date: Sun, 7 Jun 2015 09:18:57 -0400 Message-ID: Subject: Re: IPsec-Tools 0-Day Denial of Service From: Jason Unovitch To: "Daniel DP. Plominski" Cc: freebsd-net@freebsd.org, freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Jun 2015 13:18:58 -0000 On Sat, Jun 6, 2015 at 3:48 PM, Daniel DP. Plominski wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > https://www.altsci.com/ipsec/ipsec-tools-sa.html > > security/ipsec-tools build with gssapi: CRASHED > > (FreeBSD 10.1 + ipsec-tools 0.8.2_1) > > best regards > Daniel > -----BEGIN PGP SIGNATURE----- See https://bugs.freebsd.org/200334. The issue was documented as being fixed here https://svnweb.freebsd.org/ports?view=revision&revision=386793 and documented in VuXML here http://www.vuxml.org/freebsd/35431f79-fe3e-11e4-ba63-000c292ee6b8.html. It seems highly unlikely someone was waiting for you to install ipsec-tools and start sending packets to cause a DoS. Are you sure this isn't just a run time issue? Perhaps with the off by default GSSAPI option? The correct avenue to report that would be via https://bugs.freebsd.org/bugzilla/ vice the mailing list. Jason From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 13:33:18 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE220789 for ; Sun, 7 Jun 2015 13:33:18 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9730F1A8D for ; Sun, 7 Jun 2015 13:33:18 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by ieclw1 with SMTP id lw1so83404364iec.3 for ; Sun, 07 Jun 2015 06:33:18 -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=izGvVRYXtyskqxUS57Ae+I1N2rbejZ4SrI98WLKBWew=; b=EbPi1+DVOnk0Ky9MHOB2ea1GOxRpgOsWSUsl6ooHMTsT52n2bJGtkW6LAmbDNoNQMu Od/k2jKEidzJimvremBt5gLQv4yCncFr3RaceuUZ6IQEuSovmjyhiyb0cxUQ4j3We80g Uzj/b76HEQHC9RCb7Pchrrw8mG2jnjQbgW5yHFfmIfvDsmBqNreKo1LcDy9W8MzgwwJ6 H+I4q+8yJSYfTBVaFcvByoXfzHqQ8dkqjZWUYYGmbOJbE2fbrnQOyvW3c61xpcPFbDU7 XBAWrkRGuCPBFMXEQYWNGtQE436HyqRPdHpjJD9iDiP0UWZzX7bYIWf+7o4Sd134fdA9 jCUw== MIME-Version: 1.0 X-Received: by 10.107.138.208 with SMTP id c77mr14978846ioj.24.1433683997913; Sun, 07 Jun 2015 06:33:17 -0700 (PDT) Received: by 10.64.236.10 with HTTP; Sun, 7 Jun 2015 06:33:17 -0700 (PDT) In-Reply-To: <556F2159.1010704@selasky.org> References: <556F1AC7.3030505@selasky.org> <556F2159.1010704@selasky.org> Date: Sun, 7 Jun 2015 21:33:17 +0800 Message-ID: Subject: Re: Adding RTL8153 support to rue(4) USB to Ethernet driver From: Ben Woods To: Hans Petter Selasky Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Jun 2015 13:33:18 -0000 On 3 June 2015 at 23:46, Hans Petter Selasky wrote: > On 06/03/15 17:42, Ben Woods wrote: >> >> Thank you for your help HPS! How can we make this work out of the box >> in the future? > > > Hi, > > In dev/usb/quirk/usb_quirk.c you can add a quirk that config index 1 should > be selected by default for your device. > > --HPS > Thanks again for your help HPS. I have submitted a bug report with my patch here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200693 I am curious why the cdce driver is used, as I was expecting it to use the rue(4) driver. Regardless, I have tested this patch and confirmed it works on FreeBSD current. Regards, Ben From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 14:03:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F53BD7D for ; Sun, 7 Jun 2015 14:03:32 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED9C4119B for ; Sun, 7 Jun 2015 14:03:31 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id DACC4250A6D for ; Sun, 7 Jun 2015 16:03:27 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM9InmIqQsBv for ; Sun, 7 Jun 2015 16:03:24 +0200 (CEST) Received: from [192.168.52.11] (1F2EC6DD.catv.pool.telekom.hu [31.46.198.221]) by green.field.hu (Postfix) with ESMTPA id 989B9250A64 for ; Sun, 7 Jun 2015 16:03:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1433685804; bh=FeJv97zWhIvCoAZShtRJTQT1BMHPYWbIptolSRjMhw8=; h=Date:From:To:Subject:References:In-Reply-To; b=dtKMNd5r6J7RSzrD8v2S3hJmU5HWKvHRrDQOBdJwk0qKhK8moqbVu2+EY9U/tQh1L Qt1dSRo6o7wE0LnSuMSWWBOII0MzD8xydOZS0ZqtQnLOBoK3+UEvVWLrYr+nfp1ezO jIJKBG/DUd2kvR8kVJ3w2b8iNnC6/WQxHhIRKS2M= Message-ID: <55744F28.5000402@field.hu> Date: Sun, 07 Jun 2015 16:03:20 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> In-Reply-To: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Jun 2015 14:03:32 -0000 ok, just lowered it to 1500 but please also note that it was on 1500 for 2 years 2015.06.07. 14:57 keltezéssel, Rick Macklem írta: > Since disabling TSO didn't help, you could try dropping to 1500mtu > on both interfaces. Some people run into problems when 9K jumbo clusters > fragment the kernel address space used to allocate mbufs. > > Good luck with it, rick > > ----- Original Message ----- >> Hi All, >> >> It worked fine for two weeks but I had a network outage 2 days ago >> then >> today. Tried to disable rxcsum and txcsum after the first one, didn't >> help. Don't know what else to do it's a shame that I can't use this >> card >> with fbsd i REALLY don't want to install linux instead but my >> production >> servers outages are not welcomed by the customers.. >> >> 2015.05.26. 10:36 keltezéssel, Cs írta: >>> Thanks Mark, good idea. I found this thread which is exactly the >>> same >>> problem as mine: >>> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ >>> >>> Will see if it helps in a couple weeks. >>> >>> Regards, >>> Csaba >>> >>> 2015.05.26. 10:30 keltezéssel, Mark Schouten írta: >>>> Oh, didn't see your lowest remark. Then, the next thing that comes >>>> past here a few times per week is 'Try disabling TSO'. >>>> >>>> >>>> Met vriendelijke groeten, >>>> >>>> -- >>>> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >>>> Mark Schouten | Tuxis Internet Engineering >>>> KvK: 61527076 | http://www.tuxis.nl/ >>>> T: 0318 200208 | info@tuxis.nl >>>> >>>> >>>> >>>> Van: Cs >>>> Aan: Mark Schouten >>>> Cc: >>>> Verzonden: 25-5-2015 11:12 >>>> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after >>>> high >>>> traffic >>>> >>>> It was on 1500 for ~3 years :) >>>> Regards, >>>> Csaba >>>> On May 25, 2015, 10:30, at 10:30, Mark Schouten >>>> >>>> wrote: >>>>> Try lowering your mtu to 1500, that worked miracles for me.. >>>>> >>>>> -- >>>>> Mark Schouten >>>>> Tuxis Internet Engineering >>>>> mark@tuxis.nl / 0318 200208 >>>>> >>>>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>>>> Hi all, >>>>>> I have two FreeBSd 10.1-RELEASE servers connected to each >>>>>> other. >>>>>> They >>>>> were connected via cross link, but they are connected to a cisco >>>>> switch >>>>> now (the problem was the same with cross link too). When >>>>> transferring >>>>> huge files (50-500GB backup files) via Gigabit (it is important!) >>>>> the >>>>> network randomly dies. The backup runs every day/week and >>>>> sometimes the >>>>> connection is ok for months sometimes it happens twice a week. >>>>> When the >>>>> network dies I can log in to the server via IPMI and use the >>>>> console >>>>> everything is OK, but can't send anything out on the network. >>>>> ifconfig >>>>> em0 down/up doesn't help nor netif restart. The problem never >>>>> occured >>>>> when I used 100Mbit connection between them, but it was 3com NIC >>>>> (xl), >>>>> gigabit adapter is Intel (em0). When I limit the transfer rate >>>>> (rsync >>>>> bandwith limit or ipfw pipe) the problem is much more rare. >>>>>> I tried to set these tuning parameters on both servers with >>>>>> different >>>>> buffer size but nothing helped: >>>>>> # cat /etc/sysctl.conf >>>>>> security.bsd.see_other_uids=0 >>>>>> net.inet.tcp.recvspace=512000 >>>>>> net.route.netisr_maxqlen=2048 >>>>>> kern.ipc.nmbclusters=1310720 >>>>>> net.inet.tcp.sendbuf_max=16777216 >>>>>> net.inet.tcp.recvbuf_max=16777216 >>>>>> kern.ipc.soacceptqueue=32768 >>>>>> # cat /boot/loader.conf >>>>>> geom_mirror_load="YES" # RAID1 disk driver (see gmirror(8)) >>>>>> ipfw_load="YES" >>>>>> net.inet.ip.fw.default_to_accept=1 >>>>>> kern.maxusers=4096 >>>>>> accf_data_load="YES" >>>>>> The duplex settings are identical on both servers. >>>>>> Server A: >>>>>> em1: flags=8843 metric 0 >>>>>> mtu >>>>> 9000 >>>>> options=4219b >>>>> >>>>> >>>>>> ether 00:25:90:24:52:66 >>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>> nd6 options=29 >>>>>> media: Ethernet autoselect (1000baseT ) >>>>>> status: active >>>>>> Server B: >>>>>> em0: flags=8843 metric 0 >>>>>> mtu >>>>> 9000 >>>>> options=4219b >>>>> >>>>> >>>>>> ether 00:30:48:dd:fe:3e >>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>> nd6 options=29 >>>>>> media: Ethernet autoselect (1000baseT ) >>>>>> status: active >>>>>> Today I tried to set mtu to 9000 but in tcpdump I see that >>>>>> during >>>>>> scp >>>>> it is still 1500: >>>>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee >>>>>> (incorrect -> >>>>> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS >>>>> val >>>>> 3103966325 ecr 853712893], length 0 >>>>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags >>>>>> [DF], >>>>> proto TCP (6), length 1500) >>>>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags >>>>>> [DF], >>>>> proto TCP (6), length 1500) >>>>>> Any ideas? Thanks guys! >>>>>> _______________________________________________ >>>>>> 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@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jun 7 21:00:50 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43B9AEB9 for ; Sun, 7 Jun 2015 21:00:50 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BAAD1390 for ; Sun, 7 Jun 2015 21:00:50 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t57L0naH035671 for ; Sun, 7 Jun 2015 21:00:49 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201506072100.t57L0naH035671@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 07 Jun 2015 21:00:49 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Jun 2015 21:00:50 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t 3 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 03:01:19 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1221F8D1 for ; Mon, 8 Jun 2015 03:01:19 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1F241825 for ; Mon, 8 Jun 2015 03:01:18 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by qcej9 with SMTP id j9so45987556qce.1 for ; Sun, 07 Jun 2015 20:01:17 -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=IiIB3jbt4nOKupzV8FtOMCOiAQqRa1hIv5icueGxCYE=; b=bxdzkSivc3l/iq7KFLSPSU3BYh9maBHTRmY1pNafQajcQog7XPfPivgrns9mE3jpKS ZTs3FOb1LVIjrYMS4BYSsx6/uNbcqybfa+afd/ZGaOrkUtAj76yDprPU1IldbDoh4WAT cDOTjI23epKVekXkZ+9fzPQU/dFri2aO/T2nrK3ydiHSmIlKi8wv50er9DyG1RtdeWTv 5Jh4PeOd6nucxKUu8VEaD3y8w4G1fRgBBnkNBEOufxpbe96wC4sze5nIOfxpHGRE0M2X 9UvERe56VLGW8gCjEVbKuV6JT2CI8SQyUOmD5SK5N/p3xupZasEq/5pBBb91a2lPa3ou wL8A== MIME-Version: 1.0 X-Received: by 10.229.236.71 with SMTP id kj7mr17858656qcb.16.1433732477570; Sun, 07 Jun 2015 20:01:17 -0700 (PDT) Received: by 10.96.18.202 with HTTP; Sun, 7 Jun 2015 20:01:17 -0700 (PDT) In-Reply-To: <55744F28.5000402@field.hu> References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> Date: Mon, 8 Jun 2015 00:01:17 -0300 Message-ID: Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Christopher Forgeron To: Cs Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Jun 2015 03:01:19 -0000 You know what helped me: 'vmstat 5' Leave that running. If the last thing on the console after a crash/hang is vmstat showing 8k of memory left, then you're in the same problem-park as me. My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in less than 5 seconds, and then crashing/panicking/hanging. There's others with this issues if you search for it; a sysctl to vm.v_free_min to double or triple that value may help, but first let us know if that's what is bonking your sever. On Sun, Jun 7, 2015 at 11:03 AM, Cs wrote: > ok, just lowered it to 1500 but please also note that it was on 1500 for = 2 > years > > 2015.06.07. 14:57 keltez=C3=A9ssel, Rick Macklem =C3=ADrta: > >> Since disabling TSO didn't help, you could try dropping to 1500mtu >> on both interfaces. Some people run into problems when 9K jumbo clusters >> fragment the kernel address space used to allocate mbufs. >> >> Good luck with it, rick >> >> ----- Original Message ----- >> >>> Hi All, >>> >>> It worked fine for two weeks but I had a network outage 2 days ago >>> then >>> today. Tried to disable rxcsum and txcsum after the first one, didn't >>> help. Don't know what else to do it's a shame that I can't use this >>> card >>> with fbsd i REALLY don't want to install linux instead but my >>> production >>> servers outages are not welcomed by the customers.. >>> >>> 2015.05.26. 10:36 keltez=C3=A9ssel, Cs =C3=ADrta: >>> >>>> Thanks Mark, good idea. I found this thread which is exactly the >>>> same >>>> problem as mine: >>>> >>>> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-netw= ork-down.49264/ >>>> >>>> Will see if it helps in a couple weeks. >>>> >>>> Regards, >>>> Csaba >>>> >>>> 2015.05.26. 10:30 keltez=C3=A9ssel, Mark Schouten =C3=ADrta: >>>> >>>>> Oh, didn't see your lowest remark. Then, the next thing that comes >>>>> past here a few times per week is 'Try disabling TSO'. >>>>> >>>>> >>>>> Met vriendelijke groeten, >>>>> >>>>> -- >>>>> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >>>>> Mark Schouten | Tuxis Internet Engineering >>>>> KvK: 61527076 | http://www.tuxis.nl/ >>>>> T: 0318 200208 | info@tuxis.nl >>>>> >>>>> >>>>> >>>>> Van: Cs >>>>> Aan: Mark Schouten >>>>> Cc: >>>>> Verzonden: 25-5-2015 11:12 >>>>> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after >>>>> high >>>>> traffic >>>>> >>>>> It was on 1500 for ~3 years :) >>>>> Regards, >>>>> Csaba >>>>> On May 25, 2015, 10:30, at 10:30, Mark Schouten >>>>> >>>>> wrote: >>>>> >>>>>> Try lowering your mtu to 1500, that worked miracles for me.. >>>>>> >>>>>> -- >>>>>> Mark Schouten >>>>>> Tuxis Internet Engineering >>>>>> mark@tuxis.nl / 0318 200208 >>>>>> >>>>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>>>>> Hi all, >>>>>>> I have two FreeBSd 10.1-RELEASE servers connected to each >>>>>>> other. >>>>>>> They >>>>>>> >>>>>> were connected via cross link, but they are connected to a cisco >>>>>> switch >>>>>> now (the problem was the same with cross link too). When >>>>>> transferring >>>>>> huge files (50-500GB backup files) via Gigabit (it is important!) >>>>>> the >>>>>> network randomly dies. The backup runs every day/week and >>>>>> sometimes the >>>>>> connection is ok for months sometimes it happens twice a week. >>>>>> When the >>>>>> network dies I can log in to the server via IPMI and use the >>>>>> console >>>>>> everything is OK, but can't send anything out on the network. >>>>>> ifconfig >>>>>> em0 down/up doesn't help nor netif restart. The problem never >>>>>> occured >>>>>> when I used 100Mbit connection between them, but it was 3com NIC >>>>>> (xl), >>>>>> gigabit adapter is Intel (em0). When I limit the transfer rate >>>>>> (rsync >>>>>> bandwith limit or ipfw pipe) the problem is much more rare. >>>>>> >>>>>>> I tried to set these tuning parameters on both servers with >>>>>>> different >>>>>>> >>>>>> buffer size but nothing helped: >>>>>> >>>>>>> # cat /etc/sysctl.conf >>>>>>> security.bsd.see_other_uids=3D0 >>>>>>> net.inet.tcp.recvspace=3D512000 >>>>>>> net.route.netisr_maxqlen=3D2048 >>>>>>> kern.ipc.nmbclusters=3D1310720 >>>>>>> net.inet.tcp.sendbuf_max=3D16777216 >>>>>>> net.inet.tcp.recvbuf_max=3D16777216 >>>>>>> kern.ipc.soacceptqueue=3D32768 >>>>>>> # cat /boot/loader.conf >>>>>>> geom_mirror_load=3D"YES" # RAID1 disk driver (see gmirror(8)) >>>>>>> ipfw_load=3D"YES" >>>>>>> net.inet.ip.fw.default_to_accept=3D1 >>>>>>> kern.maxusers=3D4096 >>>>>>> accf_data_load=3D"YES" >>>>>>> The duplex settings are identical on both servers. >>>>>>> Server A: >>>>>>> em1: flags=3D8843 metric 0 >>>>>>> mtu >>>>>>> >>>>>> 9000 >>>>>> >>>>>> options=3D4219b >>>>>> >>>>>> >>>>>> ether 00:25:90:24:52:66 >>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>> nd6 options=3D29 >>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>> status: active >>>>>>> Server B: >>>>>>> em0: flags=3D8843 metric 0 >>>>>>> mtu >>>>>>> >>>>>> 9000 >>>>>> >>>>>> options=3D4219b >>>>>> >>>>>> >>>>>> ether 00:30:48:dd:fe:3e >>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>> nd6 options=3D29 >>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>> status: active >>>>>>> Today I tried to set mtu to 9000 but in tcpdump I see that >>>>>>> during >>>>>>> scp >>>>>>> >>>>>> it is still 1500: >>>>>> >>>>>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee >>>>>>> (incorrect -> >>>>>>> >>>>>> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS >>>>>> val >>>>>> 3103966325 ecr 853712893], length 0 >>>>>> >>>>>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags >>>>>>> [DF], >>>>>>> >>>>>> proto TCP (6), length 1500) >>>>>> >>>>>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags >>>>>>> [DF], >>>>>>> >>>>>> proto TCP (6), length 1500) >>>>>> >>>>>>> Any ideas? Thanks guys! >>>>>>> _______________________________________________ >>>>>>> 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@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@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 Jun 8 04:04:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4034E26C for ; Mon, 8 Jun 2015 04:04:32 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm19-vm2.bullet.mail.ne1.yahoo.com (nm19-vm2.bullet.mail.ne1.yahoo.com [98.138.91.95]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E9F216CB for ; Mon, 8 Jun 2015 04:04:31 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1433736098; bh=hHXvy+NGEAJzzdzh2mxGF51GpBDwtNhGhwt3YacZhZc=; h=Date:From:Reply-To:To:Subject:From:Subject; b=uEWDC3p/88bkU9YJm7K7JTALUXeKNrwHnVt2bwt4UBKCU799fDuk8chcTZvOY7xheWgF2UtuBr1LnPgJnHAeJ0j+bpa8dZsAvYWxytyUW4V7CM8sr37exb8wlvOOfp1G0GlsgRYoG2LdlHG0gG1twStH7T3KjleUoTSgcOf7c0KLmzyfpOu6+rY2zHHjcQQJ6BqVZJeDJD47aVwcb1MkwgMJyRN6Ku3MboG+UkYXHsGcHeAxeYQga6Mq9fOH1SSV2/zOF0e2AlYSNp5uGXngeFmg4wggCQ8zdPLBTu9dXzNEcFwCiq+awIWc+9NB9LjsDKbsTiAOPsEYUVgTIWwFBw== Received: from [98.138.100.118] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2015 04:01:38 -0000 Received: from [98.138.88.234] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2015 04:01:38 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 08 Jun 2015 04:01:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 494058.17483.bm@omp1034.mail.ne1.yahoo.com X-YMail-OSG: DnGMZ7MVM1mZsijHLJMpZLZSP_dTQ9ob1KBgKx8b10gA3dw3okqBxkmH4C7AZ0h .Sc_PYJFBVpmn.42NBECHiSZbVbBdOcFaZ5MD37WIeeox9wkat2X4PtieuhURgM2PARHXm1XDUST IkSSVjtOdnGptsEnwZdxF2VZIrzRQ5TK7pBGOl2UaD8BTIGNy4r1ec9vwBfPTTWAvBxXjMhnNM6_ zK9CuzJ5A4s_dL5RzjRClF7XxOIM6DoaHkCuzgevTdET._f0kQ02egzVmWbCviPMOne6HF_WzJ63 egMtQWveuZQaMRZJj0GQkwAGbX7FI.BjkI6ImVWCHrS9zJIiDfh2kOW4PiGtwdsZylhR36mlj0YF 5Mm7JRfv6cy2YZ8Hj3Y0CcEWPWeNqd6mYId_KNMMwg_pqvpDHHMybu0VEDEPr0vCigruIX6lRqGP DC.vOWMtOupQ6UFqFQOFzlZ3G4PJK0mPjo_C3Juyy8B4TX5cAx7Xc01mSJsL8L6UGNg6caNdufRc _OjNu8CoqnANGCLg- Received: by 98.138.101.167; Mon, 08 Jun 2015 04:01:38 +0000 Date: Mon, 8 Jun 2015 04:01:37 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: "freebsd-net@freebsd.org" Message-ID: <744980604.6877496.1433736097641.JavaMail.yahoo@mail.yahoo.com> Subject: patm device on FreeBSD 9.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Jun 2015 04:04:32 -0000 I've recently configured my kernel with the following options=C2=A0=C2=A0= =C2=A0=C2=A0device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 patm=20 =C2=A0=C2=A0=C2=A0=C2=A0device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ut= opia=20 =C2=A0=C2=A0=C2=A0=C2=A0device=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at= m=20 =C2=A0=C2=A0=C2=A0=C2=A0options=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NATM=20 =C2=A0=C2=A0=C2=A0=C2=A0options=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LIBMBPO= OL=20 In order to use patm device on my FreeBSD 9.2 AMD64.Here are the configurat= ions for a back to back connection=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0ifconfig patm0 10.10.10.1 255.0.0.0=20 =C2=A0=C2=A0=C2=A0=C2=A0atmconfig natam add 10.10.10.2 0 100 aal5=20 =C2=A0 after setting these configurations, I can not even ping the other side! Ano= ther problem is that using tcpdum on patm0 interface causes the following e= rror:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0tcpdump:=C2=A0=C2=A0=C2=A0 patm0: No such device=20 =C2=A0=C2=A0=C2=A0=C2=A0(BIOCSETIF failed: Device not configured)=20 =C2=A0 Please help me using this device on my system.=20 Thanks in advance ... From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 20:22:27 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80092AAC for ; Mon, 8 Jun 2015 20:22:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A6C11958 for ; Mon, 8 Jun 2015 20:22:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t58KMRKi084551 for ; Mon, 8 Jun 2015 20:22:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200629] ether_type not set in ether header in mbuf for vlan packet Date: Mon, 08 Jun 2015 20:22:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Jun 2015 20:22:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200629 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Jun 8 22:45:44 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3616C373 for ; Mon, 8 Jun 2015 22:45:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 01C701BD7 for ; Mon, 8 Jun 2015 22:45:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DUBAAJGnZV/95baINchEiDGMM4gW4RAQEBAQEBAYEKhEyBCwINGQJfiECaK49fpAABCgEBAR6BIY50gyOBRQWgB4N6iA6GTYNZJIIJHIFuIoF3gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,576,1427774400"; d="scan'208";a="214991352" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Jun 2015 18:45:38 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 06A01B3FD0 for ; Mon, 8 Jun 2015 18:45:37 -0400 (EDT) Date: Mon, 8 Jun 2015 18:45:37 -0400 (EDT) From: Rick Macklem To: freebsd-net Message-ID: <597381612.53959816.1433803537015.JavaMail.root@uoguelph.ca> Subject: setting if_hw_tsomax{segcount, segsize} in net drivers MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Jun 2015 22:45:44 -0000 Hi, I just looked at stable/10 and found the following 4 drivers have set the if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize fields: ./xen/netfront/netfront.c ./cxgbe/t4_main.c ./oce/oce_if.c ./vmware/vmxnet3/if_vmx.c If you are the author/maintainer for a network device driver that does TSO and is not on the above list...please, please fill in the above fields before the call to ether_ifattach(), so that TSO will hopefully work correctly with NFS/iSCSI. (I said "hopefully" because there might be other bugs related to TSO in your driver that I wouldn't know about.) Maybe someone could mention this at BSDCan too? Thanks in advance for doing this, rick ps: I would be really nice to get this done for 10.2 imho. From owner-freebsd-net@FreeBSD.ORG Tue Jun 9 14:10:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D83444 for ; Tue, 9 Jun 2015 14:10:14 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A52A918E6 for ; Tue, 9 Jun 2015 14:10:14 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by qkx62 with SMTP id 62so9836942qkx.3 for ; Tue, 09 Jun 2015 07:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XiQwR98sJIIHe7nDnhDPLInl4A6CeYIzHIRMUXo1E+g=; b=Ft0GbkFCaWzytKLMAg/bg5vvjTkevPGi3nmS8CmeL5L7irzssUavfkL7MqnCU2j8ys 3AwuZxoDeWyOcn1IhVB/WRPexaC/rQHqTC9fTthKEtKWneYIIWYZIxqhNl7n5LSldWs6 0ORkNk1Ch1kSWhovJYmPQDv9rOkwLVxcbqyfgp4c0X0gUyYiTqRdAGTdDtfsi171Kegg zyva6A6cIz5fIeEn8A1M6aIgzKyj8yLDYcrTyYlTsX6vt0XG43BMPHYAjj3KjWeiD7GC aWPczQdn69a8VyD4SvX2m7DC6ha8A07oebvy8DOulv5ccmbz7MN9WCTkaeKbpjer+En0 sZWw== MIME-Version: 1.0 X-Received: by 10.140.31.162 with SMTP id f31mr21092362qgf.23.1433859013763; Tue, 09 Jun 2015 07:10:13 -0700 (PDT) Received: by 10.96.18.202 with HTTP; Tue, 9 Jun 2015 07:10:13 -0700 (PDT) In-Reply-To: <597381612.53959816.1433803537015.JavaMail.root@uoguelph.ca> References: <597381612.53959816.1433803537015.JavaMail.root@uoguelph.ca> Date: Tue, 9 Jun 2015 11:10:13 -0300 Message-ID: Subject: Re: setting if_hw_tsomax{segcount, segsize} in net drivers From: Christopher Forgeron To: Rick Macklem Cc: freebsd-net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Jun 2015 14:10:15 -0000 Thanks for keeping up on this Rick. TSO needs to be fixed on FreeBSD, but it does not seem to be a hot-button topic. I still suffer from TSO issues, and thus turn it off in a standard build - but I noticed that machines that were VMWare 5.1-6.0, running the vmx driver, they did not have problems if TSO was on. I dug into the source far enough to see that vmx doesn't look to allocate more than a 4k mbuf unlike ixgeb/others, but I didn't test/dig further. On Mon, Jun 8, 2015 at 7:45 PM, Rick Macklem wrote: > Hi, > > I just looked at stable/10 and found the following 4 drivers have > set the if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize > fields: > > ./xen/netfront/netfront.c > ./cxgbe/t4_main.c > ./oce/oce_if.c > ./vmware/vmxnet3/if_vmx.c > > If you are the author/maintainer for a network device driver that does > TSO and is not on the above list...please, please fill in the above > fields before the call to ether_ifattach(), so that TSO will hopefully > work correctly with NFS/iSCSI. (I said "hopefully" because there might > be other bugs related to TSO in your driver that I wouldn't know about.) > > Maybe someone could mention this at BSDCan too? > > Thanks in advance for doing this, rick > ps: I would be really nice to get this done for 10.2 imho. > _______________________________________________ > 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 Wed Jun 10 20:47:11 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1703B902 for ; Wed, 10 Jun 2015 20:47:11 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id D82491C32 for ; Wed, 10 Jun 2015 20:47:10 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.100] (vpn01-01.tdx.co.uk [62.13.130.213]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id t5AKioaR035351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Jun 2015 21:44:51 +0100 (BST) Date: Wed, 10 Jun 2015 21:44:50 +0100 From: Karl Pielorz To: freebsd-net@FreeBSD.org Subject: Realtek Issues (re) on PC Engines APU1 Board... Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Jun 2015 20:47:11 -0000 Hi, I've recently bought an APU1 (by PC Engines) - this was to start to replace a number of ALIX boards we use from them with FreeBSD. However - I'm having issues with the onboard (Realtek) interfaces on it. These show up in dmesg as: " Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 re0: port 0x1000-0x10ff mem 0xf7a00000-0xf7a00fff,0xf7900000-0xf7903fff irq 16 at device 0.0 on pci1 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:0d:xx:xx:xx:xx " Ditto for re1, and re2 The box works OK - but if you throw a lot of traffic at it (e.g. >50Mbits) it just "stops". No messages on console (it's a serial console) - nothing logged, no kernel panic - it just grinds to a halt (my serial console dies as well) - and I have to reboot it. The box at the moment is running natd (using re1 to nat for traffic seen on re0). It's running FreeBSD 10.1-RELEASE-p10 The only stuff I see logged (occasionally) is: " re1: watchdog timeout re1: link state changed to DOWN re1: link state changed to UP re1: watchdog timeout re1: link state changed to DOWN re1: link state changed to UP re1: watchdog timeout re1: link state changed to DOWN re1: link state changed to UP " Any suggestions? Cheers, -Karl From owner-freebsd-net@FreeBSD.ORG Wed Jun 10 21:06:27 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7AB7F68 for ; Wed, 10 Jun 2015 21:06:27 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 82E221110 for ; Wed, 10 Jun 2015 21:06:27 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.100] (vpn01-01.tdx.co.uk [62.13.130.213]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id t5AL6PWT036833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Jun 2015 22:06:26 +0100 (BST) Date: Wed, 10 Jun 2015 22:06:25 +0100 From: Karl Pielorz To: freebsd-net@FreeBSD.org Subject: Re: Realtek Issues (re) on PC Engines APU1 Board... Message-ID: <066F0471D6AE7795BFB049A3@Karls-Mac-mini.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Jun 2015 21:06:27 -0000 Ok, I moved the traffic off of re1 (should have tried this before) to re2 - and it seems (so far) stable, so maybe just re1 is having issues... dmesg for re1 is: " pcib2: irq 17 at device 5.0 on pci0 pci2: on pcib2 re1: port 0x2000-0x20ff mem 0xf7c00000-0xf7c00fff,0xf7b00000-0xf7b03fff irq 17 at device 0.0 on pci2 re1: Using 1 MSI-X message re1: ASPM disabled re1: Chip rev. 0x2c000000 re1: MAC rev. 0x00200000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Ethernet address: 00:0d:xx:xx:xx:xx " I'll leave it running on that for now, and try to crash the box a few times (i.e. sling a lot of traffic through it repeatedly). Unfortunately we need all 3 interfaces working when these boxes are deployed - so longer term, avoiding re1 isn't really an option :( Since moving from re1 to re2 (and rebooting) - I've not seen any watchdog timeout errors for any re interface. -Karl --On 10 June 2015 21:44:50 +0100 Karl Pielorz wrote: > > Hi, > > I've recently bought an APU1 (by PC Engines) - this was to start to > replace a number of ALIX boards we use from them with FreeBSD. > > However - I'm having issues with the onboard (Realtek) interfaces on it. > These show up in dmesg as: > > " > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 450 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 4.0 on pci0 > pci1: on pcib1 > re0: port > 0x1000-0x10ff mem 0xf7a00000-0xf7a00fff,0xf7900000-0xf7903fff irq 16 at > device 0.0 on pci1 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x2c000000 > re0: MAC rev. 0x00200000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 00:0d:xx:xx:xx:xx > " > > Ditto for re1, and re2 > > The box works OK - but if you throw a lot of traffic at it (e.g. > >50Mbits) it just "stops". > > No messages on console (it's a serial console) - nothing logged, no > kernel panic - it just grinds to a halt (my serial console dies as well) > - and I have to reboot it. > > The box at the moment is running natd (using re1 to nat for traffic seen > on re0). > > It's running FreeBSD 10.1-RELEASE-p10 > > The only stuff I see logged (occasionally) is: > > " > re1: watchdog timeout > re1: link state changed to DOWN > re1: link state changed to UP > re1: watchdog timeout > re1: link state changed to DOWN > re1: link state changed to UP > re1: watchdog timeout > re1: link state changed to DOWN > re1: link state changed to UP > " > > Any suggestions? > > Cheers, > > -Karl > > _______________________________________________ > 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 Wed Jun 10 23:58:11 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75A645AC for ; Wed, 10 Jun 2015 23:58:11 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FCBC1C00 for ; Wed, 10 Jun 2015 23:58:10 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Z2psk-0006Dy-8h; Thu, 11 Jun 2015 01:58:06 +0200 Message-ID: <5578CECE.2050703@gont.com.ar> Date: Wed, 10 Jun 2015 20:57:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: FreeBSD Net Subject: PF support for IPv6 Extension Headers Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 10 Jun 2015 23:58:11 -0000 Folks, What's the level f support of PF wrt IPv6 Extension Headers? pf.conf(5) talks about an implicit block rule for packets employing the routing header, but I've not been able to find anything about e.g., * Filtering packets on a per-EH-type-occurrence (e.g. "block packets that contain a Destination Options Header") * Filtering packets base on the EH size * Filtering packets based on the number of EHs they contain (e.g., drop the packet if it employs more than 5 EHs) etc. Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 13:50:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5356FC03 for ; Thu, 11 Jun 2015 13:50:02 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1361B108C for ; Thu, 11 Jun 2015 13:50:01 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id F085519354; Thu, 11 Jun 2015 15:49:58 +0200 (CEST) Received: by vega.codepro.be (Postfix, from userid 1001) id 31F1BF552; Thu, 11 Jun 2015 15:49:57 +0200 (CEST) Date: Thu, 11 Jun 2015 15:49:57 +0200 From: Kristof Provost To: Fernando Gont Cc: FreeBSD Net Subject: Re: PF support for IPv6 Extension Headers Message-ID: <20150611134957.GC2301@vega.codepro.be> References: <5578CECE.2050703@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5578CECE.2050703@gont.com.ar> X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 13:50:02 -0000 (From a very quick look at the code) On 2015-06-10 20:57:02 (-0300), Fernando Gont wrote: > What's the level f support of PF wrt IPv6 Extension Headers? > It's pretty limited. There's code for a few specific header types (fragment, routing, AH, hopopts and dstopts) but nothing generic. That means that none of the things you described (filtering per EH type, EH size or number of EHs) are supported. > pf.conf(5) talks about an implicit block rule for packets employing the > routing header, ... > That appears to be only for the type 0 routing header. Packets with RH0 are always dropped, but other routing headers are left unmolested. See https://www.ietf.org/rfc/rfc5095.txt . Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 02:49:14 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADB12C85 for ; Fri, 12 Jun 2015 02:49:14 +0000 (UTC) (envelope-from johnjen@reynoldsnet.org) Received: from fed1rmfepo203.cox.net (fed1rmfepo203.cox.net [68.230.241.148]) by mx1.freebsd.org (Postfix) with ESMTP id 887871D7F for ; Fri, 12 Jun 2015 02:49:14 +0000 (UTC) (envelope-from johnjen@reynoldsnet.org) Received: from fed1rmimpo305 ([68.230.241.173]) by fed1rmfepo203.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20150612024907.NWHE11247.fed1rmfepo203.cox.net@fed1rmimpo305> for ; Thu, 11 Jun 2015 22:49:07 -0400 Received: from ip70-176-23-2.ph.ph.cox.net ([70.176.23.2]) by fed1rmimpo305 with cox id fEp61q00z02iXum01Ep6qM; Thu, 11 Jun 2015 22:49:07 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020201.557A48A3.002B,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=f9qW8pOM c=1 sm=1 a=HP9fQ7nnypBwy8j/o7h0OA==:17 a=IRX8Ue4JTZcA:10 a=05pWP5ZVAAAA:8 a=XAFQembCKUMA:10 a=0oQO5syo36WfVM3oBgUA:9 a=wPNLvfGTeEIA:10 a=uVuP_BGVSbsB0OCOctkA:9 a=_W_S_7VecoQA:10 a=-GfI8uYdf6DjkxlU:21 a=HP9fQ7nnypBwy8j/o7h0OA==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from whale.home-net (whale.home-net [192.168.1.2]) by ip70-176-23-2.ph.ph.cox.net (8.14.7/8.14.7) with ESMTP id t5C2n5Hq013853 for ; Thu, 11 Jun 2015 19:49:06 -0700 (MST) (envelope-from johnjen@reynoldsnet.org) Message-ID: <557A48A2.4090805@reynoldsnet.org> Date: Thu, 11 Jun 2015 19:49:06 -0700 From: John Reynolds User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: question on NAT + IPFW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 02:49:14 -0000 Hello all, I've read in sections 30.4.4 and 30.4.3 of the handbook about using IPFW and I've got some clarification questions. 1) When you're using any sort of firewall rules outside the open/client/simple/closed, etc. pre-canned types in rc.firewall, but instead using rules from a file, the way I read the handbook, you MUST use specific "nat" rules (divert natd) in your ipfw file along with setting "natd_enable" to YES. Correct? 2) In the example found in 30.4.4 where it is using "stateful" rules, it made specific mention that the "nat" stuff needed to be placed after the rules to allow traffic in on the trusted interface but before the "check-state" rule. Given that, if I wanted to completely block off one of my local addresses would I also do it *before* the "divert natd" rule? I have a situation where I need to just simply "block all traffic" from some teenagers' mobile devices after a certain period of the day (don't ask .... teenagers......). So, would that rule look like this: $cmd 005 allow all from any to any via xl0 # exclude LAN traffic $cmd 010 allow all from any to any via lo0 # exclude loopback traffic $cmd 020 deny log all from 192.168.1.20 to any via xl0 # new rule $cmd 100 divert natd ip from any to any in via $pif # NAT any inbound packets $cmd 101 check-state (assuming 192.168.1.20 was the internal IP address for the mobile device I want to thwart) Would this accomplish what I'm hoping for? I currently don't have any real FW to speak of--ipfw is there but the type is "open," so I'm trying to learn as I go along in order to setup an actual firewall for this box @ the same time. Thanks in advance, -Jr From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 06:49:43 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68F18780 for ; Fri, 12 Jun 2015 06:49:43 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8F8519DD for ; Fri, 12 Jun 2015 06:49:42 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3m7CMv2DkMzbll; Fri, 12 Jun 2015 08:49:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1434091769; x=1435906170; bh=tvYvEH+Sdtkb8ULU8Ra4XqDM158XO4G7VJVypWDnoSw=; b= PjX0mj+xj1Vpjf75jeyJydwcjJ9QfJKGBaWKCM57nwCZHqSrxHZ+twzshkURlR0Y 7RtLlSJR+OBsqQhYike3F70Me1SyZuaoyuDX2bTH9MrhzyLWUnl8pZNfNmcelAgG ZISQ57zmu67GEiPODk3gw8PVx/O7MVEbZXX6uPierI8= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id 2Lf94m4wCI-A; Fri, 12 Jun 2015 08:49:29 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 12 Jun 2015 08:49:29 +0200 (CEST) Message-ID: <557A80F8.1070109@madpilot.net> Date: Fri, 12 Jun 2015 08:49:28 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Reynolds , freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW References: <557A48A2.4090805@reynoldsnet.org> In-Reply-To: <557A48A2.4090805@reynoldsnet.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 06:49:43 -0000 On 06/12/15 04:49, John Reynolds wrote: > Hello all, I've read in sections 30.4.4 and 30.4.3 of the handbook about > using IPFW and I've got some clarification questions. > > 1) When you're using any sort of firewall rules outside the > open/client/simple/closed, etc. pre-canned types in rc.firewall, but > instead using rules from a file, the way I read the handbook, you MUST > use specific "nat" rules (divert natd) in your ipfw file along with > setting "natd_enable" to YES. Correct? Yes and no, with modern ipfw I'd suggest you use in kernel nat in place of userspace nat, it's orders of magnitude faster and can bear much higher loads. Documentation about it in the handbook is a lacking unluckily. You need to configure it with a command like: ipfw -q nat 1 config if pppoe0 same_ports this configures one instance. then use it like this: ipfw add 1000 nat 1 all from any to any in via pppoe0 it's almost the same as with natd, jut a sligthly different syntax. it's documented in ipfw(8). > > 2) In the example found in 30.4.4 where it is using "stateful" rules, it > made specific mention that the "nat" stuff needed to be placed after the > rules to allow traffic in on the trusted interface but before the > "check-state" rule. Given that, if I wanted to completely block off one > of my local addresses would I also do it *before* the "divert natd" rule? Depends on how your firewall is structured, you should place any stateful rule(usually allow ones) after check-state, and block rules(which are not stateful usually) before it. This also helps lowering the firewall load, although with modern hardware it's really necessary to optimize firewalls only on fast links. For residential connectivity you're not likely to have speed problems in handling packets. > > I have a situation where I need to just simply "block all traffic" from > some teenagers' mobile devices after a certain period of the day (don't > ask .... teenagers......). So, would that rule look like this: > > $cmd 005 allow all from any to any via xl0 # exclude LAN traffic > $cmd 010 allow all from any to any via lo0 # exclude loopback traffic > > $cmd 020 deny log all from 192.168.1.20 to any via xl0 # new rule > > $cmd 100 divert natd ip from any to any in via $pif # NAT any > inbound packets > $cmd 101 check-state > > (assuming 192.168.1.20 was the internal IP address for the mobile device > I want to thwart) > > Would this accomplish what I'm hoping for? I currently don't have any > real FW to speak of--ipfw is there but the type is "open," so I'm trying > to learn as I go along in order to setup an actual firewall for this box > @ the same time. looks correct, assuming xl0 is your internal interface (better put it in a variable and use the variable in your rules imho) Making a complex ruleset requires some work and testing, it's not easy to get it right the first time, especially when one starts using it. Hope this helps! -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 06:59:46 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2E5A903 for ; Fri, 12 Jun 2015 06:59:46 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EBF31C1F for ; Fri, 12 Jun 2015 06:59:46 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3m7Cbf50Lbzbll; Fri, 12 Jun 2015 08:59:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1434092381; x=1435906782; bh=3VHy0W5k4+cL/oXwZhFFDnjK0RI2H/2yFYrwzhAcWTY=; b= LR3q4AFmZCo+qp6agQUuUC/eDL51TCex2IJw/owrbJZnQYuMxnKxcmd2Xq9N10u4 y4qe6Mf9KYLOA42PfzhmrKSMqZB/r2xRwR+jOKd1LPuctRKPvfTlxgoygKX9Rxpc zdB2aAsz4VuNgw06Dk3slDye6/miTsev1mZBvtsTlqM= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id lY8tZX5En7a3; Fri, 12 Jun 2015 08:59:41 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 12 Jun 2015 08:59:40 +0200 (CEST) Message-ID: <557A835C.1090106@madpilot.net> Date: Fri, 12 Jun 2015 08:59:40 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Reynolds , freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW References: <557A48A2.4090805@reynoldsnet.org> <557A80F8.1070109@madpilot.net> In-Reply-To: <557A80F8.1070109@madpilot.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 06:59:47 -0000 On 06/12/15 08:49, Guido Falsi wrote: > On 06/12/15 04:49, John Reynolds wrote: >> >> I have a situation where I need to just simply "block all traffic" from >> some teenagers' mobile devices after a certain period of the day (don't >> ask .... teenagers......). So, would that rule look like this: >> >> $cmd 005 allow all from any to any via xl0 # exclude LAN traffic >> $cmd 010 allow all from any to any via lo0 # exclude loopback traffic >> >> $cmd 020 deny log all from 192.168.1.20 to any via xl0 # new rule >> >> $cmd 100 divert natd ip from any to any in via $pif # NAT any >> inbound packets >> $cmd 101 check-state >> >> (assuming 192.168.1.20 was the internal IP address for the mobile device >> I want to thwart) >> >> Would this accomplish what I'm hoping for? I currently don't have any >> real FW to speak of--ipfw is there but the type is "open," so I'm trying >> to learn as I go along in order to setup an actual firewall for this box >> @ the same time. > > looks correct, assuming xl0 is your internal interface (better put it in > a variable and use the variable in your rules imho) Forgot one thing, working around this block is as easy as changing the machine IP, teenager can learn this easily and it can be done in a lot of ways, even if they are not root(or equivalent) on their machine, they can just boot from a CD with some live OS. You could have a better block by also checking the MAC address, like this: $cmd 021 deny log MAC any 00:aa:00:00:00:00:01 via xl0 (not tested) MAC addresses can be modified too but it's somewhat more difficult. -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 07:03:51 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BB1B9C2 for ; Fri, 12 Jun 2015 07:03:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8364F1E1B for ; Fri, 12 Jun 2015 07:03:48 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t5C73SfG080594; Fri, 12 Jun 2015 17:03:30 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 12 Jun 2015 17:03:28 +1000 (EST) From: Ian Smith To: John Reynolds cc: freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW In-Reply-To: <557A48A2.4090805@reynoldsnet.org> Message-ID: <20150612155031.H74737@sola.nimnet.asn.au> References: <557A48A2.4090805@reynoldsnet.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 07:03:51 -0000 On Thu, 11 Jun 2015 19:49:06 -0700, John Reynolds wrote: > Hello all, I've read in sections 30.4.4 and 30.4.3 of the handbook about > using IPFW and I've got some clarification questions. > > 1) When you're using any sort of firewall rules outside the > open/client/simple/closed, etc. pre-canned types in rc.firewall, but > instead using rules from a file, the way I read the handbook, you MUST > use specific "nat" rules (divert natd) in your ipfw file along with > setting "natd_enable" to YES. Correct? The handbook hasn't caught up with more recent (like >5 years) history; these days more people are using in-kernel NAT, for which there is a usage example in the 'client' ruleset in rc.firewall, but unfortunately not also the 'simple' ruleset, which would more suit your setup, unless you've drunk the "everything must be done statefully" kool-aid :) So sure, if using natd(8) then set natd_enable and use divert rule/s, or firewall_nat_enable=YES and nat rule/s (refer /etc/defaults/rc.conf). > 2) In the example found in 30.4.4 where it is using "stateful" rules, it > made specific mention that the "nat" stuff needed to be placed after the > rules to allow traffic in on the trusted interface but before the > "check-state" rule. Given that, if I wanted to completely block off one > of my local addresses would I also do it *before* the "divert natd" rule? Yes, blocking on ingress is the way to go, best done early unless e.g. you wanted to permit access to some internal services but not external. > I have a situation where I need to just simply "block all traffic" from > some teenagers' mobile devices after a certain period of the day (don't > ask .... teenagers......). So, would that rule look like this: > > $cmd 005 allow all from any to any via xl0 # exclude LAN traffic > $cmd 010 allow all from any to any via lo0 # exclude loopback traffic > > $cmd 020 deny log all from 192.168.1.20 to any via xl0 # new rule But that already allowed everything via xl0 at rule 5, You could do rule 5 _after_ blocking certain internal addresses, the order used here is not important, as long as it's before the divert (or nat) rule. > $cmd 100 divert natd ip from any to any in via $pif # NAT any > inbound packets That should rather specify 'ip4' as natd falls over handed ip6 packets. > $cmd 101 check-state > > (assuming 192.168.1.20 was the internal IP address for the mobile device > I want to thwart) Given you want to do this at certain times of day, rather than messing with the ruleset as you go I'd suggest using a table, perhaps like: $cmd 4 deny log all from table\(99\) to any in recv xl0 and using a system cron job - and/or manually as required - to either: /sbin/ipfw table 99 add 192.168.1.20 or /sbin/ipfw table 99 delete 192.168.1.20 as appropriate. > Would this accomplish what I'm hoping for? I currently don't have any > real FW to speak of--ipfw is there but the type is "open," so I'm trying > to learn as I go along in order to setup an actual firewall for this box > @ the same time. I'll suggest having a good look over 'simple' as perhaps a more suitable model for your sort of network, and using ipfw(8) as primary reference especially re tables and nat|natd usage, but you can add something like the above to any ruleset. The handbook doesn't even mention tables :( cheers, Ian From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 08:08:15 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63B35AC6 for ; Fri, 12 Jun 2015 08:08:15 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE7A81F68 for ; Fri, 12 Jun 2015 08:08:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t5C87sj3082887; Fri, 12 Jun 2015 18:07:54 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 12 Jun 2015 18:07:54 +1000 (EST) From: Ian Smith To: Guido Falsi cc: John Reynolds , freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW In-Reply-To: <557A835C.1090106@madpilot.net> Message-ID: <20150612174047.Q74737@sola.nimnet.asn.au> References: <557A48A2.4090805@reynoldsnet.org> <557A80F8.1070109@madpilot.net> <557A835C.1090106@madpilot.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 08:08:15 -0000 On Fri, 12 Jun 2015 08:59:40 +0200, Guido Falsi wrote: > > looks correct, assuming xl0 is your internal interface (better put it in > > a variable and use the variable in your rules imho) > > Forgot one thing, working around this block is as easy as changing the > machine IP, teenager can learn this easily and it can be done in a lot > of ways, even if they are not root(or equivalent) on their machine, they > can just boot from a CD with some live OS. You could have a better block > by also checking the MAC address, like this: > > $cmd 021 deny log MAC any 00:aa:00:00:00:00:01 via xl0 > > (not tested) > > MAC addresses can be modified too but it's somewhat more difficult. While that's all true, blocking at layer 2 requires extra work that may be beyond what's needed here, to have ipfw deal with layer 2 traffic. sysctl net.link.ether.ipfw=1 must be set for ipfw to see layer 2 packets at all, and then you'd need to follow ipfw(8) section PACKET FLOW to separate the layer 2 and 3 traffic in order to look at MAC addresses on the appropriate one of the extra two passes through ipfw this entails. Maybe best not telling the teenagers exactly how you're blocking them, which at least gives you a headstart in the race :) cheers, Ian From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 08:24:11 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB6D0F0C for ; Fri, 12 Jun 2015 08:24:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 958281560 for ; Fri, 12 Jun 2015 08:24:10 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3m7FT40PRzzbll; Fri, 12 Jun 2015 10:24:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1434097446; x=1435911847; bh=iBonFr7gW/T8Si2f/NMxABmiRhYUelAviifRMheGFiI=; b= YmM049RUA+HC1feEqhlGtJFo1caGvGB0AZT1ob1+Cm7LPem/fuh3eiRD3dAGH8nO +6cNmuZaOG37L84odFFjT03QMl8BoqubJXT2PKYMGSx2KkJZLEZHcTS2jLP+iBQe ov/H/6xX+Er+TJuWg8vi/vX4hw/l88DTZo/uKpU1hzc= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id Gar5ieXstiuj; Fri, 12 Jun 2015 10:24:06 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 12 Jun 2015 10:24:06 +0200 (CEST) Message-ID: <557A9725.7050506@madpilot.net> Date: Fri, 12 Jun 2015 10:24:05 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Smith CC: John Reynolds , freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW References: <557A48A2.4090805@reynoldsnet.org> <557A80F8.1070109@madpilot.net> <557A835C.1090106@madpilot.net> <20150612174047.Q74737@sola.nimnet.asn.au> In-Reply-To: <20150612174047.Q74737@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 08:24:11 -0000 On 06/12/15 10:07, Ian Smith wrote: > On Fri, 12 Jun 2015 08:59:40 +0200, Guido Falsi wrote: > > > > looks correct, assuming xl0 is your internal interface (better put it in > > > a variable and use the variable in your rules imho) > > > > Forgot one thing, working around this block is as easy as changing the > > machine IP, teenager can learn this easily and it can be done in a lot > > of ways, even if they are not root(or equivalent) on their machine, they > > can just boot from a CD with some live OS. You could have a better block > > by also checking the MAC address, like this: > > > > $cmd 021 deny log MAC any 00:aa:00:00:00:00:01 via xl0 > > > > (not tested) > > > > MAC addresses can be modified too but it's somewhat more difficult. > > While that's all true, blocking at layer 2 requires extra work that may > be beyond what's needed here, to have ipfw deal with layer 2 traffic. > > sysctl net.link.ether.ipfw=1 must be set for ipfw to see layer 2 packets > at all, and then you'd need to follow ipfw(8) section PACKET FLOW to > separate the layer 2 and 3 traffic in order to look at MAC addresses on > the appropriate one of the extra two passes through ipfw this entails. > Uhm, I forgot to check these details. Yes, layer 2 is a lot more work anyway, I avoid it if possible. I also did not read carefully the example given, my fault on that too :) -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 10:02:05 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11061BC6 for ; Fri, 12 Jun 2015 10:02:05 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C6E01E05 for ; Fri, 12 Jun 2015 10:02:04 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5CA21IF025158 for ; Fri, 12 Jun 2015 12:02:01 +0200 (CEST) Received: from [IPv6:2003:55:6b30:5800:6899:c861:6225:ffaa] (p200300556B3058006899C8616225FFAA.dip0.t-ipconnect.de [IPv6:2003:55:6b30:5800:6899:c861:6225:ffaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3m7Hf06tPzz99n5 for ; Fri, 12 Jun 2015 12:02:00 +0200 (CEST) Message-ID: <557AAE18.1040902@tzi.de> Date: Fri, 12 Jun 2015 12:02:00 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Realtek Issues (re) on PC Engines APU1 Board... References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 10:02:05 -0000 Hi Karl, did you already upgrade your Firmware? You get it from: http://www.pcengines.ch/apu1d4.htm (Build 9/8/2014) You install it with: flashrom --programmer internal -w apu140908.rom \ -c "MX25L1605A/MX25L1606E" That solved our realtek issues. Kind regards Julian From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 10:35:17 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D20E983 for ; Fri, 12 Jun 2015 10:35:17 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF5B416D4 for ; Fri, 12 Jun 2015 10:35:16 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id EE705250A64 for ; Fri, 12 Jun 2015 12:17:41 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2RWyfICejTd for ; Fri, 12 Jun 2015 12:17:34 +0200 (CEST) Received: from [10.10.10.153] (unknown [188.227.229.50]) by green.field.hu (Postfix) with ESMTPA id F03EA250A78 for ; Fri, 12 Jun 2015 12:17:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1434104254; bh=OeEBo8sLOFjHNjthz6vjEV3lZQfH6UpoXGfkJ/5gH54=; h=Date:From:To:Subject:References:In-Reply-To; b=pP7gs3ptV/MGgmjn5rR5Kuj+svpydfYp3/qqPErzgzI2dU1Bl6DnYHbvqtN2HjmZE fR0IeA3UpemAefJ+VPwE3vslfpmgXg9E+c9R/vpHcUN8hnIDIDHl4Lz2g9cP4aRhW+ 8/xn3ww9BbeREdd6aLdv0uQEhqkQ5gptdlFT4WB0= Message-ID: <557AB1BB.60502@field.hu> Date: Fri, 12 Jun 2015 12:17:31 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 10:35:17 -0000 it seems it's not memory related. Server just died a few minutes ago during transporting the backup (400GB) around 800Mbps speed.. will disable remote backup, it's a shame that em driver is such a crap. 2015.06.08. 5:01 keltezéssel, Christopher Forgeron írta: > You know what helped me: > > 'vmstat 5' > > Leave that running. If the last thing on the console after a crash/hang is > vmstat showing 8k of memory left, then you're in the same problem-park as > me. > > My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in less than 5 seconds, and > then crashing/panicking/hanging. > > There's others with this issues if you search for it; a sysctl > to vm.v_free_min to double or triple that value may help, but first let us > know if that's what is bonking your sever. > > > > On Sun, Jun 7, 2015 at 11:03 AM, Cs wrote: > >> ok, just lowered it to 1500 but please also note that it was on 1500 for 2 >> years >> >> 2015.06.07. 14:57 keltezéssel, Rick Macklem írta: >> >>> Since disabling TSO didn't help, you could try dropping to 1500mtu >>> on both interfaces. Some people run into problems when 9K jumbo clusters >>> fragment the kernel address space used to allocate mbufs. >>> >>> Good luck with it, rick >>> >>> ----- Original Message ----- >>> >>>> Hi All, >>>> >>>> It worked fine for two weeks but I had a network outage 2 days ago >>>> then >>>> today. Tried to disable rxcsum and txcsum after the first one, didn't >>>> help. Don't know what else to do it's a shame that I can't use this >>>> card >>>> with fbsd i REALLY don't want to install linux instead but my >>>> production >>>> servers outages are not welcomed by the customers.. >>>> >>>> 2015.05.26. 10:36 keltezéssel, Cs írta: >>>> >>>>> Thanks Mark, good idea. I found this thread which is exactly the >>>>> same >>>>> problem as mine: >>>>> >>>>> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ >>>>> >>>>> Will see if it helps in a couple weeks. >>>>> >>>>> Regards, >>>>> Csaba >>>>> >>>>> 2015.05.26. 10:30 keltezéssel, Mark Schouten írta: >>>>> >>>>>> Oh, didn't see your lowest remark. Then, the next thing that comes >>>>>> past here a few times per week is 'Try disabling TSO'. >>>>>> >>>>>> >>>>>> Met vriendelijke groeten, >>>>>> >>>>>> -- >>>>>> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >>>>>> Mark Schouten | Tuxis Internet Engineering >>>>>> KvK: 61527076 | http://www.tuxis.nl/ >>>>>> T: 0318 200208 | info@tuxis.nl >>>>>> >>>>>> >>>>>> >>>>>> Van: Cs >>>>>> Aan: Mark Schouten >>>>>> Cc: >>>>>> Verzonden: 25-5-2015 11:12 >>>>>> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after >>>>>> high >>>>>> traffic >>>>>> >>>>>> It was on 1500 for ~3 years :) >>>>>> Regards, >>>>>> Csaba >>>>>> On May 25, 2015, 10:30, at 10:30, Mark Schouten >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Try lowering your mtu to 1500, that worked miracles for me.. >>>>>>> >>>>>>> -- >>>>>>> Mark Schouten >>>>>>> Tuxis Internet Engineering >>>>>>> mark@tuxis.nl / 0318 200208 >>>>>>> >>>>>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>>>>>> Hi all, >>>>>>>> I have two FreeBSd 10.1-RELEASE servers connected to each >>>>>>>> other. >>>>>>>> They >>>>>>>> >>>>>>> were connected via cross link, but they are connected to a cisco >>>>>>> switch >>>>>>> now (the problem was the same with cross link too). When >>>>>>> transferring >>>>>>> huge files (50-500GB backup files) via Gigabit (it is important!) >>>>>>> the >>>>>>> network randomly dies. The backup runs every day/week and >>>>>>> sometimes the >>>>>>> connection is ok for months sometimes it happens twice a week. >>>>>>> When the >>>>>>> network dies I can log in to the server via IPMI and use the >>>>>>> console >>>>>>> everything is OK, but can't send anything out on the network. >>>>>>> ifconfig >>>>>>> em0 down/up doesn't help nor netif restart. The problem never >>>>>>> occured >>>>>>> when I used 100Mbit connection between them, but it was 3com NIC >>>>>>> (xl), >>>>>>> gigabit adapter is Intel (em0). When I limit the transfer rate >>>>>>> (rsync >>>>>>> bandwith limit or ipfw pipe) the problem is much more rare. >>>>>>> >>>>>>>> I tried to set these tuning parameters on both servers with >>>>>>>> different >>>>>>>> >>>>>>> buffer size but nothing helped: >>>>>>> >>>>>>>> # cat /etc/sysctl.conf >>>>>>>> security.bsd.see_other_uids=0 >>>>>>>> net.inet.tcp.recvspace=512000 >>>>>>>> net.route.netisr_maxqlen=2048 >>>>>>>> kern.ipc.nmbclusters=1310720 >>>>>>>> net.inet.tcp.sendbuf_max=16777216 >>>>>>>> net.inet.tcp.recvbuf_max=16777216 >>>>>>>> kern.ipc.soacceptqueue=32768 >>>>>>>> # cat /boot/loader.conf >>>>>>>> geom_mirror_load="YES" # RAID1 disk driver (see gmirror(8)) >>>>>>>> ipfw_load="YES" >>>>>>>> net.inet.ip.fw.default_to_accept=1 >>>>>>>> kern.maxusers=4096 >>>>>>>> accf_data_load="YES" >>>>>>>> The duplex settings are identical on both servers. >>>>>>>> Server A: >>>>>>>> em1: flags=8843 metric 0 >>>>>>>> mtu >>>>>>>> >>>>>>> 9000 >>>>>>> >>>>>>> options=4219b >>>>>>> >>>>>>> >>>>>>> ether 00:25:90:24:52:66 >>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>> nd6 options=29 >>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>> status: active >>>>>>>> Server B: >>>>>>>> em0: flags=8843 metric 0 >>>>>>>> mtu >>>>>>>> >>>>>>> 9000 >>>>>>> >>>>>>> options=4219b >>>>>>> >>>>>>> >>>>>>> ether 00:30:48:dd:fe:3e >>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>> nd6 options=29 >>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>> status: active >>>>>>>> Today I tried to set mtu to 9000 but in tcpdump I see that >>>>>>>> during >>>>>>>> scp >>>>>>>> >>>>>>> it is still 1500: >>>>>>> >>>>>>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee >>>>>>>> (incorrect -> >>>>>>>> >>>>>>> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS >>>>>>> val >>>>>>> 3103966325 ecr 853712893], length 0 >>>>>>> >>>>>>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags >>>>>>>> [DF], >>>>>>>> >>>>>>> proto TCP (6), length 1500) >>>>>>> >>>>>>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags >>>>>>>> [DF], >>>>>>>> >>>>>>> proto TCP (6), length 1500) >>>>>>> >>>>>>>> Any ideas? Thanks guys! >>>>>>>> _______________________________________________ >>>>>>>> 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@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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 09:59:55 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FEE0A52 for ; Fri, 12 Jun 2015 09:59:55 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1804D1C18 for ; Fri, 12 Jun 2015 09:59:54 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5C9xnoL019991; Fri, 12 Jun 2015 11:59:49 +0200 (CEST) Received: from [IPv6:2003:55:6b30:5800:6899:c861:6225:ffaa] (p200300556B3058006899C8616225FFAA.dip0.t-ipconnect.de [IPv6:2003:55:6b30:5800:6899:c861:6225:ffaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3m7HbT18DZz99lW; Fri, 12 Jun 2015 11:59:49 +0200 (CEST) Message-ID: <557AAD94.9090505@tzi.de> Date: Fri, 12 Jun 2015 11:59:48 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Karl Pielorz Subject: Re: Realtek Issues (re) on PC Engines APU1 Board... References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 12 Jun 2015 11:25:02 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 09:59:55 -0000 Hi Karl, did you already upgrade your Firmware? You get it from: http://www.pcengines.ch/apu1d4.htm (Build 9/8/2014) You install it with: flashrom --programmer internal -w apu140908.rom \ -c "MX25L1605A/MX25L1606E" That solved our realtek issues. Kind regards Julian From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 11:33:21 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB81A55E for ; Fri, 12 Jun 2015 11:33:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA7241816 for ; Fri, 12 Jun 2015 11:33:19 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t5CBXB3p090152; Fri, 12 Jun 2015 21:33:13 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 12 Jun 2015 21:33:11 +1000 (EST) From: Ian Smith To: Guido Falsi cc: John Reynolds , freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW In-Reply-To: <557A9725.7050506@madpilot.net> Message-ID: <20150612202813.K74737@sola.nimnet.asn.au> References: <557A48A2.4090805@reynoldsnet.org> <557A80F8.1070109@madpilot.net> <557A835C.1090106@madpilot.net> <20150612174047.Q74737@sola.nimnet.asn.au> <557A9725.7050506@madpilot.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 11:33:22 -0000 On Fri, 12 Jun 2015 10:24:05 +0200, Guido Falsi wrote: > On 06/12/15 10:07, Ian Smith wrote: > > On Fri, 12 Jun 2015 08:59:40 +0200, Guido Falsi wrote: > > > > > > looks correct, assuming xl0 is your internal interface (better put it in > > > > a variable and use the variable in your rules imho) > > > > > > Forgot one thing, working around this block is as easy as changing the > > > machine IP, teenager can learn this easily and it can be done in a lot > > > of ways, even if they are not root(or equivalent) on their machine, they > > > can just boot from a CD with some live OS. You could have a better block > > > by also checking the MAC address, like this: > > > > > > $cmd 021 deny log MAC any 00:aa:00:00:00:00:01 via xl0 > > > > > > (not tested) > > > > > > MAC addresses can be modified too but it's somewhat more difficult. > > > > While that's all true, blocking at layer 2 requires extra work that may > > be beyond what's needed here, to have ipfw deal with layer 2 traffic. > > > > sysctl net.link.ether.ipfw=1 must be set for ipfw to see layer 2 packets > > at all, and then you'd need to follow ipfw(8) section PACKET FLOW to > > separate the layer 2 and 3 traffic in order to look at MAC addresses on > > the appropriate one of the extra two passes through ipfw this entails. > Uhm, I forgot to check these details. Yes, layer 2 is a lot more work > anyway, I avoid it if possible. > > I also did not read carefully the example given, my fault on that too :) Those examples are so wrong on so many counts that I never know where to even start on fixing them; I've banged on often enough about these to annoy some folks so I won't go on .. except that the first rule quoted: $cmd 005 allow all from any to any via xl0 # exclude LAN traffic is crazy in the context of wanting to do NAT on packets from the LAN bound for the outside interface. No checks, anti-spoofing, nothing. Need icmp for path MTU discovery? Too bad. Need UDP frags for such as zen.spamhaus.org responses, let alone DNSSEC? Tough. Expect ntpd to work over TCP port 37, or NETBIOS on TCP ports 137,138? Good luck .. Fortunately lev@ is working (in ipfw@) on some new stateful rule actions to decouple state setting and checking to avoid needing such as twisty skipto constucts for handling stateful rules, at which point updating the handbook might also be timely; I do have a few bits half-written. Take-away: ipfw(8) is your friend, and pretty much your only friend apart from what's in rc.firewall (and even that lacks proper icmp). cheers, Ian From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 12:29:23 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EC82670 for ; Fri, 12 Jun 2015 12:29:23 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46058169D for ; Fri, 12 Jun 2015 12:29:23 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by qgf75 with SMTP id 75so10909538qgf.1 for ; Fri, 12 Jun 2015 05:29:22 -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=sl6j9LCsi6UFFvaRceeBAI46kJRIswAYAI/NCmBlhkU=; b=nMYjJjDphC7N6Ggor4qQdq5L6/j8RNgsMV+i/4yi7ifNRZfirK7KlwM3vvaTpvEpBi FaevrrWvyTUkiKRwtrynv877Z1ER+OdMwFIOTqk0Mli45pKh9mLAk6dxRqvXaUCntNdQ oBuAZUhQlu3QJYIfuARudXs1ueGCgdmYeRHrnFaRjwG9VuqDkA+9NmU6MHCSNc3g1sNH rvCQ9iK7Mex17oYGpYDPbjjMQWgiPvcGHoQ11gmj4izl+loU/fnsZ93V9mSvna3LfrXx Qn0sU/DSlzLydCDPlS4QUdqCLMS/cF0tU7WaEmsxMX2YdrDGC1BeK7AI80UPNvw6A5Fh Ztmw== MIME-Version: 1.0 X-Received: by 10.55.23.84 with SMTP id i81mr29646290qkh.90.1434112162337; Fri, 12 Jun 2015 05:29:22 -0700 (PDT) Received: by 10.96.76.104 with HTTP; Fri, 12 Jun 2015 05:29:22 -0700 (PDT) In-Reply-To: <557AB1BB.60502@field.hu> References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> Date: Fri, 12 Jun 2015 09:29:22 -0300 Message-ID: Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Christopher Forgeron To: Cs Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 12:29:23 -0000 Well, even at low speed it could drop due to memory from what I've seen. What was the last line from vmstat 5 before it locked up? I find that the em driver isn't crap, but there is a deeper problem inside of FreeBSD that is being exposed now - For me it's due to faster network connections. Are you using rsync to move the files? On Fri, Jun 12, 2015 at 7:17 AM, Cs wrote: > it seems it's not memory related. Server just died a few minutes ago > during transporting the backup (400GB) around 800Mbps speed.. > will disable remote backup, it's a shame that em driver is such a crap. > > > 2015.06.08. 5:01 keltez=C3=A9ssel, Christopher Forgeron =C3=ADrta: > >> You know what helped me: >> >> 'vmstat 5' >> >> Leave that running. If the last thing on the console after a crash/hang = is >> vmstat showing 8k of memory left, then you're in the same problem-park a= s >> me. >> >> My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in less than 5 seconds, a= nd >> then crashing/panicking/hanging. >> >> There's others with this issues if you search for it; a sysctl >> to vm.v_free_min to double or triple that value may help, but first let = us >> know if that's what is bonking your sever. >> >> >> >> On Sun, Jun 7, 2015 at 11:03 AM, Cs wrote: >> >> ok, just lowered it to 1500 but please also note that it was on 1500 fo= r >>> 2 >>> years >>> >>> 2015.06.07. 14:57 keltez=C3=A9ssel, Rick Macklem =C3=ADrta: >>> >>> Since disabling TSO didn't help, you could try dropping to 1500mtu >>>> on both interfaces. Some people run into problems when 9K jumbo cluste= rs >>>> fragment the kernel address space used to allocate mbufs. >>>> >>>> Good luck with it, rick >>>> >>>> ----- Original Message ----- >>>> >>>> Hi All, >>>>> >>>>> It worked fine for two weeks but I had a network outage 2 days ago >>>>> then >>>>> today. Tried to disable rxcsum and txcsum after the first one, didn't >>>>> help. Don't know what else to do it's a shame that I can't use this >>>>> card >>>>> with fbsd i REALLY don't want to install linux instead but my >>>>> production >>>>> servers outages are not welcomed by the customers.. >>>>> >>>>> 2015.05.26. 10:36 keltez=C3=A9ssel, Cs =C3=ADrta: >>>>> >>>>> Thanks Mark, good idea. I found this thread which is exactly the >>>>>> same >>>>>> problem as mine: >>>>>> >>>>>> >>>>>> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-ne= twork-down.49264/ >>>>>> >>>>>> Will see if it helps in a couple weeks. >>>>>> >>>>>> Regards, >>>>>> Csaba >>>>>> >>>>>> 2015.05.26. 10:30 keltez=C3=A9ssel, Mark Schouten =C3=ADrta: >>>>>> >>>>>> Oh, didn't see your lowest remark. Then, the next thing that comes >>>>>>> past here a few times per week is 'Try disabling TSO'. >>>>>>> >>>>>>> >>>>>>> Met vriendelijke groeten, >>>>>>> >>>>>>> -- >>>>>>> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >>>>>>> Mark Schouten | Tuxis Internet Engineering >>>>>>> KvK: 61527076 | http://www.tuxis.nl/ >>>>>>> T: 0318 200208 | info@tuxis.nl >>>>>>> >>>>>>> >>>>>>> >>>>>>> Van: Cs >>>>>>> Aan: Mark Schouten >>>>>>> Cc: >>>>>>> Verzonden: 25-5-2015 11:12 >>>>>>> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after >>>>>>> high >>>>>>> traffic >>>>>>> >>>>>>> It was on 1500 for ~3 years :) >>>>>>> Regards, >>>>>>> Csaba >>>>>>> On May 25, 2015, 10:30, at 10:30, Mark Schouten >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Try lowering your mtu to 1500, that worked miracles for me.. >>>>>>>> >>>>>>>> -- >>>>>>>> Mark Schouten >>>>>>>> Tuxis Internet Engineering >>>>>>>> mark@tuxis.nl / 0318 200208 >>>>>>>> >>>>>>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> I have two FreeBSd 10.1-RELEASE servers connected to each >>>>>>>>> other. >>>>>>>>> They >>>>>>>>> >>>>>>>>> were connected via cross link, but they are connected to a cisco >>>>>>>> switch >>>>>>>> now (the problem was the same with cross link too). When >>>>>>>> transferring >>>>>>>> huge files (50-500GB backup files) via Gigabit (it is important!) >>>>>>>> the >>>>>>>> network randomly dies. The backup runs every day/week and >>>>>>>> sometimes the >>>>>>>> connection is ok for months sometimes it happens twice a week. >>>>>>>> When the >>>>>>>> network dies I can log in to the server via IPMI and use the >>>>>>>> console >>>>>>>> everything is OK, but can't send anything out on the network. >>>>>>>> ifconfig >>>>>>>> em0 down/up doesn't help nor netif restart. The problem never >>>>>>>> occured >>>>>>>> when I used 100Mbit connection between them, but it was 3com NIC >>>>>>>> (xl), >>>>>>>> gigabit adapter is Intel (em0). When I limit the transfer rate >>>>>>>> (rsync >>>>>>>> bandwith limit or ipfw pipe) the problem is much more rare. >>>>>>>> >>>>>>>> I tried to set these tuning parameters on both servers with >>>>>>>>> different >>>>>>>>> >>>>>>>>> buffer size but nothing helped: >>>>>>>> >>>>>>>> # cat /etc/sysctl.conf >>>>>>>>> security.bsd.see_other_uids=3D0 >>>>>>>>> net.inet.tcp.recvspace=3D512000 >>>>>>>>> net.route.netisr_maxqlen=3D2048 >>>>>>>>> kern.ipc.nmbclusters=3D1310720 >>>>>>>>> net.inet.tcp.sendbuf_max=3D16777216 >>>>>>>>> net.inet.tcp.recvbuf_max=3D16777216 >>>>>>>>> kern.ipc.soacceptqueue=3D32768 >>>>>>>>> # cat /boot/loader.conf >>>>>>>>> geom_mirror_load=3D"YES" # RAID1 disk driver (see gmirror(8)) >>>>>>>>> ipfw_load=3D"YES" >>>>>>>>> net.inet.ip.fw.default_to_accept=3D1 >>>>>>>>> kern.maxusers=3D4096 >>>>>>>>> accf_data_load=3D"YES" >>>>>>>>> The duplex settings are identical on both servers. >>>>>>>>> Server A: >>>>>>>>> em1: flags=3D8843 metric = 0 >>>>>>>>> mtu >>>>>>>>> >>>>>>>>> 9000 >>>>>>>> >>>>>>>> >>>>>>>> options=3D4219b >>>>>>>> >>>>>>>> >>>>>>>> ether 00:25:90:24:52:66 >>>>>>>> >>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>> nd6 options=3D29 >>>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>>> status: active >>>>>>>>> Server B: >>>>>>>>> em0: flags=3D8843 metric = 0 >>>>>>>>> mtu >>>>>>>>> >>>>>>>>> 9000 >>>>>>>> >>>>>>>> >>>>>>>> options=3D4219b >>>>>>>> >>>>>>>> >>>>>>>> ether 00:30:48:dd:fe:3e >>>>>>>> >>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>> nd6 options=3D29 >>>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>>> status: active >>>>>>>>> Today I tried to set mtu to 9000 but in tcpdump I see that >>>>>>>>> during >>>>>>>>> scp >>>>>>>>> >>>>>>>>> it is still 1500: >>>>>>>> >>>>>>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee >>>>>>>>> (incorrect -> >>>>>>>>> >>>>>>>>> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS >>>>>>>> val >>>>>>>> 3103966325 ecr 853712893], length 0 >>>>>>>> >>>>>>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags >>>>>>>>> [DF], >>>>>>>>> >>>>>>>>> proto TCP (6), length 1500) >>>>>>>> >>>>>>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags >>>>>>>>> [DF], >>>>>>>>> >>>>>>>>> proto TCP (6), length 1500) >>>>>>>> >>>>>>>> Any ideas? Thanks guys! >>>>>>>>> _______________________________________________ >>>>>>>>> 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@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@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@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 Jun 12 12:31:22 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A7AA72F for ; Fri, 12 Jun 2015 12:31:22 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA5651831 for ; Fri, 12 Jun 2015 12:31:20 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id 9BC6C250A7B for ; Fri, 12 Jun 2015 14:31:17 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JuM3FQAEWw0 for ; Fri, 12 Jun 2015 14:31:12 +0200 (CEST) Received: from [10.10.10.153] (unknown [188.227.229.50]) by green.field.hu (Postfix) with ESMTPA id C19ED250A64 for ; Fri, 12 Jun 2015 14:31:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1434112272; bh=2SlvQq4Ctv+byzVAHW1OTYIRy9YnYIGHe31dlEl5EY0=; h=Date:From:To:Subject:References:In-Reply-To; b=Wy4NGFpqVH7cNi5hsvnaTz59EUZFKe9Ibb2Uuq1x7NkmergbgRhCYqb4S/70TgSCj e3gketEu0zF8Ig11EnpaPYEC4CRTwL7P7rHGpI3ybEvqAIfSKYbyKuzwDWOJcwglIO MC2dLxAKZ77SnSf1RTXedT7hACl3WKy0m5WZO5yg= Message-ID: <557AD10D.5070205@field.hu> Date: Fri, 12 Jun 2015 14:31:09 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 12:31:22 -0000 machine has been restarted before I could check the "vmstat 5" output. Yep, it's rsync. Anyway I disabled the backup transfer it'll solve, but I can't really accept this for solution. 2015.06.12. 14:29 keltezéssel, Christopher Forgeron írta: > Well, even at low speed it could drop due to memory from what I've seen. > > What was the last line from vmstat 5 before it locked up? > > I find that the em driver isn't crap, but there is a deeper problem inside > of FreeBSD that is being exposed now - For me it's due to faster network > connections. > > Are you using rsync to move the files? > > On Fri, Jun 12, 2015 at 7:17 AM, Cs wrote: > >> it seems it's not memory related. Server just died a few minutes ago >> during transporting the backup (400GB) around 800Mbps speed.. >> will disable remote backup, it's a shame that em driver is such a crap. >> >> >> 2015.06.08. 5:01 keltezéssel, Christopher Forgeron írta: >> >>> You know what helped me: >>> >>> 'vmstat 5' >>> >>> Leave that running. If the last thing on the console after a crash/hang is >>> vmstat showing 8k of memory left, then you're in the same problem-park as >>> me. >>> >>> My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in less than 5 seconds, and >>> then crashing/panicking/hanging. >>> >>> There's others with this issues if you search for it; a sysctl >>> to vm.v_free_min to double or triple that value may help, but first let us >>> know if that's what is bonking your sever. >>> >>> >>> >>> On Sun, Jun 7, 2015 at 11:03 AM, Cs wrote: >>> >>> ok, just lowered it to 1500 but please also note that it was on 1500 for >>>> 2 >>>> years >>>> >>>> 2015.06.07. 14:57 keltezéssel, Rick Macklem írta: >>>> >>>> Since disabling TSO didn't help, you could try dropping to 1500mtu >>>>> on both interfaces. Some people run into problems when 9K jumbo clusters >>>>> fragment the kernel address space used to allocate mbufs. >>>>> >>>>> Good luck with it, rick >>>>> >>>>> ----- Original Message ----- >>>>> >>>>> Hi All, >>>>>> It worked fine for two weeks but I had a network outage 2 days ago >>>>>> then >>>>>> today. Tried to disable rxcsum and txcsum after the first one, didn't >>>>>> help. Don't know what else to do it's a shame that I can't use this >>>>>> card >>>>>> with fbsd i REALLY don't want to install linux instead but my >>>>>> production >>>>>> servers outages are not welcomed by the customers.. >>>>>> >>>>>> 2015.05.26. 10:36 keltezéssel, Cs írta: >>>>>> >>>>>> Thanks Mark, good idea. I found this thread which is exactly the >>>>>>> same >>>>>>> problem as mine: >>>>>>> >>>>>>> >>>>>>> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ >>>>>>> >>>>>>> Will see if it helps in a couple weeks. >>>>>>> >>>>>>> Regards, >>>>>>> Csaba >>>>>>> >>>>>>> 2015.05.26. 10:30 keltezéssel, Mark Schouten írta: >>>>>>> >>>>>>> Oh, didn't see your lowest remark. Then, the next thing that comes >>>>>>>> past here a few times per week is 'Try disabling TSO'. >>>>>>>> >>>>>>>> >>>>>>>> Met vriendelijke groeten, >>>>>>>> >>>>>>>> -- >>>>>>>> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >>>>>>>> Mark Schouten | Tuxis Internet Engineering >>>>>>>> KvK: 61527076 | http://www.tuxis.nl/ >>>>>>>> T: 0318 200208 | info@tuxis.nl >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Van: Cs >>>>>>>> Aan: Mark Schouten >>>>>>>> Cc: >>>>>>>> Verzonden: 25-5-2015 11:12 >>>>>>>> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after >>>>>>>> high >>>>>>>> traffic >>>>>>>> >>>>>>>> It was on 1500 for ~3 years :) >>>>>>>> Regards, >>>>>>>> Csaba >>>>>>>> On May 25, 2015, 10:30, at 10:30, Mark Schouten >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Try lowering your mtu to 1500, that worked miracles for me.. >>>>>>>>> -- >>>>>>>>> Mark Schouten >>>>>>>>> Tuxis Internet Engineering >>>>>>>>> mark@tuxis.nl / 0318 200208 >>>>>>>>> >>>>>>>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> I have two FreeBSd 10.1-RELEASE servers connected to each >>>>>>>>>> other. >>>>>>>>>> They >>>>>>>>>> >>>>>>>>>> were connected via cross link, but they are connected to a cisco >>>>>>>>> switch >>>>>>>>> now (the problem was the same with cross link too). When >>>>>>>>> transferring >>>>>>>>> huge files (50-500GB backup files) via Gigabit (it is important!) >>>>>>>>> the >>>>>>>>> network randomly dies. The backup runs every day/week and >>>>>>>>> sometimes the >>>>>>>>> connection is ok for months sometimes it happens twice a week. >>>>>>>>> When the >>>>>>>>> network dies I can log in to the server via IPMI and use the >>>>>>>>> console >>>>>>>>> everything is OK, but can't send anything out on the network. >>>>>>>>> ifconfig >>>>>>>>> em0 down/up doesn't help nor netif restart. The problem never >>>>>>>>> occured >>>>>>>>> when I used 100Mbit connection between them, but it was 3com NIC >>>>>>>>> (xl), >>>>>>>>> gigabit adapter is Intel (em0). When I limit the transfer rate >>>>>>>>> (rsync >>>>>>>>> bandwith limit or ipfw pipe) the problem is much more rare. >>>>>>>>> >>>>>>>>> I tried to set these tuning parameters on both servers with >>>>>>>>>> different >>>>>>>>>> >>>>>>>>>> buffer size but nothing helped: >>>>>>>>> # cat /etc/sysctl.conf >>>>>>>>>> security.bsd.see_other_uids=0 >>>>>>>>>> net.inet.tcp.recvspace=512000 >>>>>>>>>> net.route.netisr_maxqlen=2048 >>>>>>>>>> kern.ipc.nmbclusters=1310720 >>>>>>>>>> net.inet.tcp.sendbuf_max=16777216 >>>>>>>>>> net.inet.tcp.recvbuf_max=16777216 >>>>>>>>>> kern.ipc.soacceptqueue=32768 >>>>>>>>>> # cat /boot/loader.conf >>>>>>>>>> geom_mirror_load="YES" # RAID1 disk driver (see gmirror(8)) >>>>>>>>>> ipfw_load="YES" >>>>>>>>>> net.inet.ip.fw.default_to_accept=1 >>>>>>>>>> kern.maxusers=4096 >>>>>>>>>> accf_data_load="YES" >>>>>>>>>> The duplex settings are identical on both servers. >>>>>>>>>> Server A: >>>>>>>>>> em1: flags=8843 metric 0 >>>>>>>>>> mtu >>>>>>>>>> >>>>>>>>>> 9000 >>>>>>>>> >>>>>>>>> options=4219b >>>>>>>>> >>>>>>>>> >>>>>>>>> ether 00:25:90:24:52:66 >>>>>>>>> >>>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>>> nd6 options=29 >>>>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>>>> status: active >>>>>>>>>> Server B: >>>>>>>>>> em0: flags=8843 metric 0 >>>>>>>>>> mtu >>>>>>>>>> >>>>>>>>>> 9000 >>>>>>>>> >>>>>>>>> options=4219b >>>>>>>>> >>>>>>>>> >>>>>>>>> ether 00:30:48:dd:fe:3e >>>>>>>>> >>>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>>> nd6 options=29 >>>>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>>>> status: active >>>>>>>>>> Today I tried to set mtu to 9000 but in tcpdump I see that >>>>>>>>>> during >>>>>>>>>> scp >>>>>>>>>> >>>>>>>>>> it is still 1500: >>>>>>>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee >>>>>>>>>> (incorrect -> >>>>>>>>>> >>>>>>>>>> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS >>>>>>>>> val >>>>>>>>> 3103966325 ecr 853712893], length 0 >>>>>>>>> >>>>>>>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags >>>>>>>>>> [DF], >>>>>>>>>> >>>>>>>>>> proto TCP (6), length 1500) >>>>>>>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags >>>>>>>>>> [DF], >>>>>>>>>> >>>>>>>>>> proto TCP (6), length 1500) >>>>>>>>> Any ideas? Thanks guys! >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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@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@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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 12:37:39 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ACA58EF for ; Fri, 12 Jun 2015 12:37:39 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0DFA192A for ; Fri, 12 Jun 2015 12:37:38 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by qgep100 with SMTP id p100so10962422qge.3 for ; Fri, 12 Jun 2015 05:37:37 -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=qSWTpo4NQpEbtndxvMpXK7ck5Qgl8R6weGjoRzMB3/M=; b=hy2ffIPz0BS3jvzLuWeU9tOb7cRPHgoICiASd6Fn/nDX9ZNqyHuRjUupkK4rzCT9gH sVkUFjrKbvugWGC70ZmSV3oh2YJZdH4ufsSqkYVZC//i9YnHX1XoNrPgQsxXZ9ItC0YP skW6Zmls41Nm12nBWVeFRJUwbZ1NWg9GACqzTu8RQfSXMnAvvqVSw7199aQSSWb5cp7e UffgfefAOEOru8mBMoa3s7QcYGS0McuHcfcY8KhZMJsIENiZO+JvwN4l/YUepp3cX3M+ /AKQOzTaaMfEfrnWbCQTCb+7Jtz79T2mhv27QrCt8VAtxIG4GeYiSk1H1VP14AXFinGj QLzw== MIME-Version: 1.0 X-Received: by 10.140.151.130 with SMTP id 124mr19219897qhx.18.1434112657723; Fri, 12 Jun 2015 05:37:37 -0700 (PDT) Received: by 10.96.76.104 with HTTP; Fri, 12 Jun 2015 05:37:37 -0700 (PDT) In-Reply-To: <557AD10D.5070205@field.hu> References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> <557AD10D.5070205@field.hu> Date: Fri, 12 Jun 2015 09:37:37 -0300 Message-ID: Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Christopher Forgeron To: Cs Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 12:37:39 -0000 rsycn burns memory - I'd say you have a good chance you're running out of mem before it's replenished. For vmstat 5 - Don't run it on console. Connect via a second box with ssh, and run it there - That way it's the last thing on the ssh terminal screen when the box dies, and you'll have your proof. On Fri, Jun 12, 2015 at 9:31 AM, Cs wrote: > machine has been restarted before I could check the "vmstat 5" output. > Yep, it's rsync. Anyway I disabled the backup transfer it'll solve, but I > can't really accept this for solution. > > > 2015.06.12. 14:29 keltez=C3=A9ssel, Christopher Forgeron =C3=ADrta: > >> Well, even at low speed it could drop due to memory from what I've seen. >> >> What was the last line from vmstat 5 before it locked up? >> >> I find that the em driver isn't crap, but there is a deeper problem >> inside >> of FreeBSD that is being exposed now - For me it's due to faster network >> connections. >> >> Are you using rsync to move the files? >> >> On Fri, Jun 12, 2015 at 7:17 AM, Cs wrote: >> >> it seems it's not memory related. Server just died a few minutes ago >>> during transporting the backup (400GB) around 800Mbps speed.. >>> will disable remote backup, it's a shame that em driver is such a crap. >>> >>> >>> 2015.06.08. 5:01 keltez=C3=A9ssel, Christopher Forgeron =C3=ADrta: >>> >>> You know what helped me: >>>> >>>> 'vmstat 5' >>>> >>>> Leave that running. If the last thing on the console after a crash/han= g >>>> is >>>> vmstat showing 8k of memory left, then you're in the same problem-park >>>> as >>>> me. >>>> >>>> My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in less than 5 seconds, >>>> and >>>> then crashing/panicking/hanging. >>>> >>>> There's others with this issues if you search for it; a sysctl >>>> to vm.v_free_min to double or triple that value may help, but first le= t >>>> us >>>> know if that's what is bonking your sever. >>>> >>>> >>>> >>>> On Sun, Jun 7, 2015 at 11:03 AM, Cs wrote: >>>> >>>> ok, just lowered it to 1500 but please also note that it was on 1500 >>>> for >>>> >>>>> 2 >>>>> years >>>>> >>>>> 2015.06.07. 14:57 keltez=C3=A9ssel, Rick Macklem =C3=ADrta: >>>>> >>>>> Since disabling TSO didn't help, you could try dropping to 1500mtu >>>>> >>>>>> on both interfaces. Some people run into problems when 9K jumbo >>>>>> clusters >>>>>> fragment the kernel address space used to allocate mbufs. >>>>>> >>>>>> Good luck with it, rick >>>>>> >>>>>> ----- Original Message ----- >>>>>> >>>>>> Hi All, >>>>>> >>>>>>> It worked fine for two weeks but I had a network outage 2 days ago >>>>>>> then >>>>>>> today. Tried to disable rxcsum and txcsum after the first one, didn= 't >>>>>>> help. Don't know what else to do it's a shame that I can't use this >>>>>>> card >>>>>>> with fbsd i REALLY don't want to install linux instead but my >>>>>>> production >>>>>>> servers outages are not welcomed by the customers.. >>>>>>> >>>>>>> 2015.05.26. 10:36 keltez=C3=A9ssel, Cs =C3=ADrta: >>>>>>> >>>>>>> Thanks Mark, good idea. I found this thread which is exactly the >>>>>>> >>>>>>>> same >>>>>>>> problem as mine: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-= network-down.49264/ >>>>>>>> >>>>>>>> Will see if it helps in a couple weeks. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Csaba >>>>>>>> >>>>>>>> 2015.05.26. 10:30 keltez=C3=A9ssel, Mark Schouten =C3=ADrta: >>>>>>>> >>>>>>>> Oh, didn't see your lowest remark. Then, the next thing that com= es >>>>>>>> >>>>>>>>> past here a few times per week is 'Try disabling TSO'. >>>>>>>>> >>>>>>>>> >>>>>>>>> Met vriendelijke groeten, >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >>>>>>>>> Mark Schouten | Tuxis Internet Engineering >>>>>>>>> KvK: 61527076 | http://www.tuxis.nl/ >>>>>>>>> T: 0318 200208 | info@tuxis.nl >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Van: Cs >>>>>>>>> Aan: Mark Schouten >>>>>>>>> Cc: >>>>>>>>> Verzonden: 25-5-2015 11:12 >>>>>>>>> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible aft= er >>>>>>>>> high >>>>>>>>> traffic >>>>>>>>> >>>>>>>>> It was on 1500 for ~3 years :) >>>>>>>>> Regards, >>>>>>>>> Csaba >>>>>>>>> On May 25, 2015, 10:30, at 10:30, Mark Schouten >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Try lowering your mtu to 1500, that worked miracles for me.. >>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mark Schouten >>>>>>>>>> Tuxis Internet Engineering >>>>>>>>>> mark@tuxis.nl / 0318 200208 >>>>>>>>>> >>>>>>>>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>>> I have two FreeBSd 10.1-RELEASE servers connected to each >>>>>>>>>>> other. >>>>>>>>>>> They >>>>>>>>>>> >>>>>>>>>>> were connected via cross link, but they are connected to a >>>>>>>>>>> cisco >>>>>>>>>>> >>>>>>>>>> switch >>>>>>>>>> now (the problem was the same with cross link too). When >>>>>>>>>> transferring >>>>>>>>>> huge files (50-500GB backup files) via Gigabit (it is important!= ) >>>>>>>>>> the >>>>>>>>>> network randomly dies. The backup runs every day/week and >>>>>>>>>> sometimes the >>>>>>>>>> connection is ok for months sometimes it happens twice a week. >>>>>>>>>> When the >>>>>>>>>> network dies I can log in to the server via IPMI and use the >>>>>>>>>> console >>>>>>>>>> everything is OK, but can't send anything out on the network. >>>>>>>>>> ifconfig >>>>>>>>>> em0 down/up doesn't help nor netif restart. The problem never >>>>>>>>>> occured >>>>>>>>>> when I used 100Mbit connection between them, but it was 3com NIC >>>>>>>>>> (xl), >>>>>>>>>> gigabit adapter is Intel (em0). When I limit the transfer rate >>>>>>>>>> (rsync >>>>>>>>>> bandwith limit or ipfw pipe) the problem is much more rare. >>>>>>>>>> >>>>>>>>>> I tried to set these tuning parameters on both servers wit= h >>>>>>>>>> >>>>>>>>>>> different >>>>>>>>>>> >>>>>>>>>>> buffer size but nothing helped: >>>>>>>>>>> >>>>>>>>>> # cat /etc/sysctl.conf >>>>>>>>>> >>>>>>>>>>> security.bsd.see_other_uids=3D0 >>>>>>>>>>> net.inet.tcp.recvspace=3D512000 >>>>>>>>>>> net.route.netisr_maxqlen=3D2048 >>>>>>>>>>> kern.ipc.nmbclusters=3D1310720 >>>>>>>>>>> net.inet.tcp.sendbuf_max=3D16777216 >>>>>>>>>>> net.inet.tcp.recvbuf_max=3D16777216 >>>>>>>>>>> kern.ipc.soacceptqueue=3D32768 >>>>>>>>>>> # cat /boot/loader.conf >>>>>>>>>>> geom_mirror_load=3D"YES" # RAID1 disk driver (see gmirror(8)) >>>>>>>>>>> ipfw_load=3D"YES" >>>>>>>>>>> net.inet.ip.fw.default_to_accept=3D1 >>>>>>>>>>> kern.maxusers=3D4096 >>>>>>>>>>> accf_data_load=3D"YES" >>>>>>>>>>> The duplex settings are identical on both servers. >>>>>>>>>>> Server A: >>>>>>>>>>> em1: flags=3D8843 metri= c 0 >>>>>>>>>>> mtu >>>>>>>>>>> >>>>>>>>>>> 9000 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> options=3D4219b >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ether 00:25:90:24:52:66 >>>>>>>>>> >>>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>>>> nd6 options=3D29 >>>>>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>>>>> status: active >>>>>>>>>>> Server B: >>>>>>>>>>> em0: flags=3D8843 metri= c 0 >>>>>>>>>>> mtu >>>>>>>>>>> >>>>>>>>>>> 9000 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> options=3D4219b >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ether 00:30:48:dd:fe:3e >>>>>>>>>> >>>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>>>> nd6 options=3D29 >>>>>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>>>>> status: active >>>>>>>>>>> Today I tried to set mtu to 9000 but in tcpdump I see that >>>>>>>>>>> during >>>>>>>>>>> scp >>>>>>>>>>> >>>>>>>>>>> it is still 1500: >>>>>>>>>>> >>>>>>>>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee >>>>>>>>>> >>>>>>>>>>> (incorrect -> >>>>>>>>>>> >>>>>>>>>>> 0xda6f), seq 35749, ack 113701596, win 7986, options >>>>>>>>>>> [nop,nop,TS >>>>>>>>>>> >>>>>>>>>> val >>>>>>>>>> 3103966325 ecr 853712893], length 0 >>>>>>>>>> >>>>>>>>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags >>>>>>>>>> >>>>>>>>>>> [DF], >>>>>>>>>>> >>>>>>>>>>> proto TCP (6), length 1500) >>>>>>>>>>> >>>>>>>>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags >>>>>>>>>> >>>>>>>>>>> [DF], >>>>>>>>>>> >>>>>>>>>>> proto TCP (6), length 1500) >>>>>>>>>>> >>>>>>>>>> Any ideas? Thanks guys! >>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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@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@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@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@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 Jun 12 12:39:32 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D73869B4 for ; Fri, 12 Jun 2015 12:39:32 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFB951952 for ; Fri, 12 Jun 2015 12:39:31 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id 90F13250A78; Fri, 12 Jun 2015 14:39:29 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX8DRwHmQ6sS; Fri, 12 Jun 2015 14:39:25 +0200 (CEST) Received: from [10.10.10.153] (unknown [188.227.229.50]) by green.field.hu (Postfix) with ESMTPA id 34070250A7B; Fri, 12 Jun 2015 14:39:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1434112765; bh=qocKw4h97ktnQLuPHhXioFpyc2e3Iai9RP9sd6N5mlk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Qjc59lLpQ7oJUU7EcHJIW+wM1/46N8TazVllJ4OxKfI8z/9k8CJuaoN2twBOXomTV KSWapSFveoCbbtGT0zQweUsiuhBLlmy0ydp9YAlEQpnVIylADysrT8ujBq0OGGraU4 5Bc1PKYgC7MNliMMS/3UCUuS/2Qusk31P1jpWjmA= Message-ID: <557AD2FA.103@field.hu> Date: Fri, 12 Jun 2015 14:39:22 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christopher Forgeron CC: FreeBSD Net Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> <557AD10D.5070205@field.hu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 12:39:32 -0000 but why is that machine runs fine except the network if it's memory related? swap didn't increased before the network outage. 2015.06.12. 14:37 keltezéssel, Christopher Forgeron írta: > rsycn burns memory - I'd say you have a good chance you're running out > of mem before it's replenished. > > For vmstat 5 - Don't run it on console. Connect via a second box with > ssh, and run it there - That way it's the last thing on the ssh > terminal screen when the box dies, and you'll have your proof. > > On Fri, Jun 12, 2015 at 9:31 AM, Cs > wrote: > > machine has been restarted before I could check the "vmstat 5" > output. Yep, it's rsync. Anyway I disabled the backup transfer > it'll solve, but I can't really accept this for solution. > > > 2015.06.12. 14 :29 keltezéssel, Christopher > Forgeron írta: > > Well, even at low speed it could drop due to memory from what > I've seen. > > What was the last line from vmstat 5 before it locked up? > > I find that the em driver isn't crap, but there is a deeper > problem inside > of FreeBSD that is being exposed now - For me it's due to > faster network > connections. > > Are you using rsync to move the files? > > On Fri, Jun 12, 2015 at 7:17 AM, Cs > wrote: > > it seems it's not memory related. Server just died a few > minutes ago > during transporting the backup (400GB) around 800Mbps speed.. > will disable remote backup, it's a shame that em driver is > such a crap. > > > 2015.06.08. 5:01 keltezéssel, Christopher Forgeron írta: > > You know what helped me: > > 'vmstat 5' > > Leave that running. If the last thing on the console > after a crash/hang is > vmstat showing 8k of memory left, then you're in the > same problem-park as > me. > > My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in less > than 5 seconds, and > then crashing/panicking/hanging. > > There's others with this issues if you search for it; > a sysctl > to vm.v_free_min to double or triple that value may > help, but first let us > know if that's what is bonking your sever. > > > > On Sun, Jun 7, 2015 at 11:03 AM, Cs > wrote: > > ok, just lowered it to 1500 but please also note > that it was on 1500 for > > 2 > years > > 2015.06.07. 14 :57 > keltezéssel, Rick Macklem írta: > > Since disabling TSO didn't help, you could try > dropping to 1500mtu > > on both interfaces. Some people run into > problems when 9K jumbo clusters > fragment the kernel address space used to > allocate mbufs. > > Good luck with it, rick > > ----- Original Message ----- > > Hi All, > > It worked fine for two weeks but I had a > network outage 2 days ago > then > today. Tried to disable rxcsum and txcsum > after the first one, didn't > help. Don't know what else to do it's a > shame that I can't use this > card > with fbsd i REALLY don't want to install > linux instead but my > production > servers outages are not welcomed by the > customers.. > > 2015.05.26. 10 :36 > keltezéssel, Cs írta: > > Thanks Mark, good idea. I found this > thread which is exactly the > > same > problem as mine: > > > https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ > > Will see if it helps in a couple weeks. > > Regards, > Csaba > > 2015.05.26. 10 > :30 keltezéssel, > Mark Schouten írta: > > Oh, didn't see your lowest remark. > Then, the next thing that comes > > past here a few times per week is > 'Try disabling TSO'. > > > Met vriendelijke groeten, > > -- > Kerio Operator in de Cloud? > https://www.kerioindecloud.nl/ > Mark Schouten | Tuxis Internet > Engineering > KvK: 61527076 | http://www.tuxis.nl/ > T: 0318 200208 | info@tuxis.nl > > > > > Van: Cs > > Aan: Mark Schouten > > > Cc: > > > Verzonden: 25-5-2015 11:12 > Onderwerp: Re: FreeBSD > 10.1-REL - network unaccessible after > high > traffic > > It was on 1500 for ~3 years :) > Regards, > Csaba > On May 25, 2015, 10:30, > at 10:30, Mark Schouten > > > wrote: > > Try lowering your mtu to 1500, > that worked miracles for me.. > > -- > Mark Schouten > Tuxis Internet Engineering > mark@tuxis.nl > / 0318 > 200208 > > On 25 May 2015, at 09:36, > "Cs" > wrote: > > Hi all, > I have two FreeBSd > 10.1-RELEASE servers > connected to each > other. > They > > were connected via cross > link, but they are > connected to a cisco > > switch > now (the problem was the same > with cross link too). When > transferring > huge files (50-500GB backup > files) via Gigabit (it is > important!) > the > network randomly dies. The > backup runs every day/week and > sometimes the > connection is ok for months > sometimes it happens twice a week. > When the > network dies I can log in to > the server via IPMI and use the > console > everything is OK, but can't > send anything out on the network. > ifconfig > em0 down/up doesn't help nor > netif restart. The problem never > occured > when I used 100Mbit connection > between them, but it was 3com NIC > (xl), > gigabit adapter is Intel > (em0). When I limit the > transfer rate > (rsync > bandwith limit or ipfw pipe) > the problem is much more rare. > > I tried to set these > tuning parameters on both > servers with > > different > > buffer size but nothing > helped: > > # cat /etc/sysctl.conf > > security.bsd.see_other_uids=0 > net.inet.tcp.recvspace=512000 > net.route.netisr_maxqlen=2048 > kern.ipc.nmbclusters=1310720 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > kern.ipc.soacceptqueue=32768 > # cat /boot/loader.conf > geom_mirror_load="YES" # > RAID1 disk driver (see > gmirror(8)) > ipfw_load="YES" > net.inet.ip.fw.default_to_accept=1 > kern.maxusers=4096 > accf_data_load="YES" > The duplex settings > are identical on both servers. > Server A: > em1: > flags=8843 > metric 0 > mtu > > 9000 > > > options=4219b > > > ether > 00:25:90:24:52:66 > > inet x.x.x.x > netmask 0xfffffe00 > broadcast x.x.x.x > nd6 > options=29 > media: Ethernet > autoselect (1000baseT > ) > status: active > Server B: > em0: > flags=8843 > metric 0 > mtu > > 9000 > > > options=4219b > > > ether > 00:30:48:dd:fe:3e > > inet x.x.x.x > netmask 0xfffffe00 > broadcast x.x.x.x > nd6 > options=29 > media: Ethernet > autoselect (1000baseT > ) > status: active > Today I tried to set > mtu to 9000 but in tcpdump > I see that > during > scp > > it is still 1500: > > x.x.x.x.222 > > x.x.x.x.37612: Flags [.], > cksum 0xb6ee > > (incorrect -> > > 0xda6f), seq 35749, ack > 113701596, win 7986, > options [nop,nop,TS > > val > 3103966325 > ecr > 853712893], length 0 > > 09:27:33.912354 IP (tos 0x8, > ttl 64, id 1028, offset 0, flags > > [DF], > > proto TCP (6), length 1500) > > 09:27:33.912358 IP (tos 0x8, > ttl 64, id 1029, offset 0, flags > > [DF], > > proto TCP (6), length 1500) > > Any ideas? Thanks guys! > > _______________________________________________ > 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@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@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@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@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 Jun 12 12:43:18 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE0A1AB4 for ; Fri, 12 Jun 2015 12:43:18 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C1951B79 for ; Fri, 12 Jun 2015 12:43:18 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by qcbfb9 with SMTP id fb9so1194760qcb.1 for ; Fri, 12 Jun 2015 05:43:17 -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=vF993GRfKvi+XxsPokrlglAZLs4NxgF06qXM6V74eL4=; b=rR7HlmhWLl2iJKWISrFMosGxfOL35PVgOn8TJQH2nTZ7UOunEJLHDSLK+pQIgxZaWE aOWdktAnJXQt5ZCwUKpZKbuPvaNwJj4eqVAKMtQ7cSVOHJOXr/4Vy/lKm7vGjmCdMHrD qehJxGClk6xywu+n/CDy0Ve6Dg5ctV6wiViqHJtknmNlQ3hqyItlusHUgbd82TwCjuXE PoulRzciTRfqLS0ygvGVry0jXcIdX+JmLBzDkdgEaTncuhDdinO5DMmPV1kpPMqOTdVd YlsqnSXpP1O13e9TSvWOnmLfmflyNUmd4hXhCXatnOPhdhE2wUhmslZaaGlpnaJPjsmh 7lUw== MIME-Version: 1.0 X-Received: by 10.140.151.130 with SMTP id 124mr19252317qhx.18.1434112997487; Fri, 12 Jun 2015 05:43:17 -0700 (PDT) Received: by 10.96.76.104 with HTTP; Fri, 12 Jun 2015 05:43:17 -0700 (PDT) In-Reply-To: <557AD2FA.103@field.hu> References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> <557AD10D.5070205@field.hu> <557AD2FA.103@field.hu> Date: Fri, 12 Jun 2015 09:43:17 -0300 Message-ID: Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Christopher Forgeron To: Cs Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 12:43:19 -0000 Ah, but the 'why' will come later, after we know for sure what the 'what' is in your problem. I'm just pointing out the problems that I'm having, as yours sound similar. Once the box runs out of memory, all sorts of interesting things can happen. Perhaps that's not your case, but it's quite possible. Setup a remote terminal, do the copy again, and send in the last few lines of 'vmstat 5' after it's locked up, perhaps I can help. On Fri, Jun 12, 2015 at 9:39 AM, Cs wrote: > but why is that machine runs fine except the network if it's memory > related? swap didn't increased before the network outage. > > > 2015.06.12. 14:37 keltez=C3=A9ssel, Christopher Forgeron =C3=ADrta: > > rsycn burns memory - I'd say you have a good chance you're running out of > mem before it's replenished. > > For vmstat 5 - Don't run it on console. Connect via a second box with > ssh, and run it there - That way it's the last thing on the ssh terminal > screen when the box dies, and you'll have your proof. > > On Fri, Jun 12, 2015 at 9:31 AM, Cs wrote: > >> machine has been restarted before I could check the "vmstat 5" output. >> Yep, it's rsync. Anyway I disabled the backup transfer it'll solve, but = I >> can't really accept this for solution. >> >> >> 2015.06.12. 14:29 keltez=C3=A9ssel, Christopher Forgeron =C3=ADrta: >> >>> Well, even at low speed it could drop due to memory from what I've seen= . >>> >>> What was the last line from vmstat 5 before it locked up? >>> >>> I find that the em driver isn't crap, but there is a deeper problem >>> inside >>> of FreeBSD that is being exposed now - For me it's due to faster networ= k >>> connections. >>> >>> Are you using rsync to move the files? >>> >>> On Fri, Jun 12, 2015 at 7:17 AM, Cs wrote: >>> >>> it seems it's not memory related. Server just died a few minutes ago >>>> during transporting the backup (400GB) around 800Mbps speed.. >>>> will disable remote backup, it's a shame that em driver is such a crap= . >>>> >>>> >>>> 2015.06.08. 5:01 keltez=C3=A9ssel, Christopher Forgeron =C3=ADrta: >>>> >>>> You know what helped me: >>>>> >>>>> 'vmstat 5' >>>>> >>>>> Leave that running. If the last thing on the console after a >>>>> crash/hang is >>>>> vmstat showing 8k of memory left, then you're in the same problem-par= k >>>>> as >>>>> me. >>>>> >>>>> My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in less than 5 seconds= , >>>>> and >>>>> then crashing/panicking/hanging. >>>>> >>>>> There's others with this issues if you search for it; a sysctl >>>>> to vm.v_free_min to double or triple that value may help, but first >>>>> let us >>>>> know if that's what is bonking your sever. >>>>> >>>>> >>>>> >>>>> On Sun, Jun 7, 2015 at 11:03 AM, Cs wrote: >>>>> >>>>> ok, just lowered it to 1500 but please also note that it was on 150= 0 >>>>> for >>>>> >>>>>> 2 >>>>>> years >>>>>> >>>>>> 2015.06.07. 14 <2015.06.07.%2014>:57 keltez=C3=A9ssel, Rick Macklem = =C3=ADrta: >>>>>> >>>>>> Since disabling TSO didn't help, you could try dropping to 1500mtu >>>>>> >>>>>>> on both interfaces. Some people run into problems when 9K jumbo >>>>>>> clusters >>>>>>> fragment the kernel address space used to allocate mbufs. >>>>>>> >>>>>>> Good luck with it, rick >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>>> It worked fine for two weeks but I had a network outage 2 days ago >>>>>>>> then >>>>>>>> today. Tried to disable rxcsum and txcsum after the first one, >>>>>>>> didn't >>>>>>>> help. Don't know what else to do it's a shame that I can't use thi= s >>>>>>>> card >>>>>>>> with fbsd i REALLY don't want to install linux instead but my >>>>>>>> production >>>>>>>> servers outages are not welcomed by the customers.. >>>>>>>> >>>>>>>> 2015.05.26. 10 <2015.05.26.%2010>:36 keltez=C3=A9ssel, Cs =C3=ADrt= a: >>>>>>>> >>>>>>>> Thanks Mark, good idea. I found this thread which is exactly the >>>>>>>> >>>>>>>>> same >>>>>>>>> problem as mine: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden= -network-down.49264/ >>>>>>>>> >>>>>>>>> Will see if it helps in a couple weeks. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Csaba >>>>>>>>> >>>>>>>>> 2015.05.26. 10 <2015.05.26.%2010>:30 keltez=C3=A9ssel, Mark Schou= ten >>>>>>>>> =C3=ADrta: >>>>>>>>> >>>>>>>>> Oh, didn't see your lowest remark. Then, the next thing that >>>>>>>>> comes >>>>>>>>> >>>>>>>>>> past here a few times per week is 'Try disabling TSO'. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Met vriendelijke groeten, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ >>>>>>>>>> Mark Schouten | Tuxis Internet Engineering >>>>>>>>>> KvK: 61527076 | http://www.tuxis.nl/ >>>>>>>>>> T: 0318 200208 | info@tuxis.nl >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Van: Cs >>>>>>>>>> Aan: Mark Schouten >>>>>>>>>> Cc: >>>>>>>>>> Verzonden: 25-5-2015 11:12 >>>>>>>>>> Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible >>>>>>>>>> after >>>>>>>>>> high >>>>>>>>>> traffic >>>>>>>>>> >>>>>>>>>> It was on 1500 for ~3 years :) >>>>>>>>>> Regards, >>>>>>>>>> Csaba >>>>>>>>>> On May 25, 2015, 10:30, at 10:30, Mark Schouten >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Try lowering your mtu to 1500, that worked miracles for me.. >>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Mark Schouten >>>>>>>>>>> Tuxis Internet Engineering >>>>>>>>>>> mark@tuxis.nl / 0318 200208 >>>>>>>>>>> >>>>>>>>>>> On 25 May 2015, at 09:36, "Cs" wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>>> I have two FreeBSd 10.1-RELEASE servers connected to each >>>>>>>>>>>> other. >>>>>>>>>>>> They >>>>>>>>>>>> >>>>>>>>>>>> were connected via cross link, but they are connected to a >>>>>>>>>>>> cisco >>>>>>>>>>>> >>>>>>>>>>> switch >>>>>>>>>>> now (the problem was the same with cross link too). When >>>>>>>>>>> transferring >>>>>>>>>>> huge files (50-500GB backup files) via Gigabit (it is important= !) >>>>>>>>>>> the >>>>>>>>>>> network randomly dies. The backup runs every day/week and >>>>>>>>>>> sometimes the >>>>>>>>>>> connection is ok for months sometimes it happens twice a week. >>>>>>>>>>> When the >>>>>>>>>>> network dies I can log in to the server via IPMI and use the >>>>>>>>>>> console >>>>>>>>>>> everything is OK, but can't send anything out on the network. >>>>>>>>>>> ifconfig >>>>>>>>>>> em0 down/up doesn't help nor netif restart. The problem never >>>>>>>>>>> occured >>>>>>>>>>> when I used 100Mbit connection between them, but it was 3com NI= C >>>>>>>>>>> (xl), >>>>>>>>>>> gigabit adapter is Intel (em0). When I limit the transfer rate >>>>>>>>>>> (rsync >>>>>>>>>>> bandwith limit or ipfw pipe) the problem is much more rare. >>>>>>>>>>> >>>>>>>>>>> I tried to set these tuning parameters on both servers wi= th >>>>>>>>>>> >>>>>>>>>>>> different >>>>>>>>>>>> >>>>>>>>>>>> buffer size but nothing helped: >>>>>>>>>>>> >>>>>>>>>>> # cat /etc/sysctl.conf >>>>>>>>>>> >>>>>>>>>>>> security.bsd.see_other_uids=3D0 >>>>>>>>>>>> net.inet.tcp.recvspace=3D512000 >>>>>>>>>>>> net.route.netisr_maxqlen=3D2048 >>>>>>>>>>>> kern.ipc.nmbclusters=3D1310720 >>>>>>>>>>>> net.inet.tcp.sendbuf_max=3D16777216 >>>>>>>>>>>> net.inet.tcp.recvbuf_max=3D16777216 >>>>>>>>>>>> kern.ipc.soacceptqueue=3D32768 >>>>>>>>>>>> # cat /boot/loader.conf >>>>>>>>>>>> geom_mirror_load=3D"YES" # RAID1 disk driver (see gmirror(8)) >>>>>>>>>>>> ipfw_load=3D"YES" >>>>>>>>>>>> net.inet.ip.fw.default_to_accept=3D1 >>>>>>>>>>>> kern.maxusers=3D4096 >>>>>>>>>>>> accf_data_load=3D"YES" >>>>>>>>>>>> The duplex settings are identical on both servers. >>>>>>>>>>>> Server A: >>>>>>>>>>>> em1: flags=3D8843 metr= ic 0 >>>>>>>>>>>> mtu >>>>>>>>>>>> >>>>>>>>>>>> 9000 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> options=3D4219b >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ether 00:25:90:24:52:66 >>>>>>>>>>> >>>>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>>>>> nd6 options=3D29 >>>>>>>>>>>> media: Ethernet autoselect (1000baseT = ) >>>>>>>>>>>> status: active >>>>>>>>>>>> Server B: >>>>>>>>>>>> em0: flags=3D8843 metr= ic 0 >>>>>>>>>>>> mtu >>>>>>>>>>>> >>>>>>>>>>>> 9000 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> options=3D4219b >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ether 00:30:48:dd:fe:3e >>>>>>>>>>> >>>>>>>>>>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>>>>>>>>>>> nd6 options=3D29 >>>>>>>>>>>> media: Ethernet autoselect (1000baseT = ) >>>>>>>>>>>> status: active >>>>>>>>>>>> Today I tried to set mtu to 9000 but in tcpdump I see tha= t >>>>>>>>>>>> during >>>>>>>>>>>> scp >>>>>>>>>>>> >>>>>>>>>>>> it is still 1500: >>>>>>>>>>>> >>>>>>>>>>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee >>>>>>>>>>> >>>>>>>>>>>> (incorrect -> >>>>>>>>>>>> >>>>>>>>>>>> 0xda6f), seq 35749, ack 113701596, win 7986, options >>>>>>>>>>>> [nop,nop,TS >>>>>>>>>>>> >>>>>>>>>>> val >>>>>>>>>>> 3103966325 ecr 853712893], length 0 >>>>>>>>>>> >>>>>>>>>>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags >>>>>>>>>>> >>>>>>>>>>>> [DF], >>>>>>>>>>>> >>>>>>>>>>>> proto TCP (6), length 1500) >>>>>>>>>>>> >>>>>>>>>>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags >>>>>>>>>>> >>>>>>>>>>>> [DF], >>>>>>>>>>>> >>>>>>>>>>>> proto TCP (6), length 1500) >>>>>>>>>>>> >>>>>>>>>>> Any ideas? Thanks guys! >>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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@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@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g >>>>>> " >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>> 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@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 15:17:38 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C2427CE for ; Fri, 12 Jun 2015 15:17:38 +0000 (UTC) (envelope-from bounces+68977-9857-freebsd-net=freebsd.org@email.brewster.com) Received: from o1.email.brewster.com (o1.email.brewster.com [198.21.5.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6DA68C1 for ; Fri, 12 Jun 2015 15:17:37 +0000 (UTC) (envelope-from bounces+68977-9857-freebsd-net=freebsd.org@email.brewster.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=email.brewster.com; h=from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:list-unsubscribe; s=smtpapi; bh=JXVzpA2BiJv0FDCtQeQnT7+0X4c=; b=R1I+frw0hDl86JfiDj D1TgTB7EF9/eYRNaDqphYG9hU+h1jTkqrcu/35xf642j4HUc1YLyBpjNgm83AqOz MOHKhQMFUDPsIixTE/rNmqRsmc3i2ZdSgmK6q0RRJtV4T5GN2Akk2eMWTJ/YWfMA RmjzS2ppNbTNitZavbAkFovQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=brewster.com; h=from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:list-unsubscribe; q=dns; s=smtpapi; b=N+yNnrjCnKN+/FlWqPuAWevWJtPY6PVenbyTS16+iPNT uCtiV4m/1OjrOTjn7TyDLntQWhNiMpQOaHNETtdessPeqJHoVaWeut6LZDXuRc58 /Xumis7J6v4iJLh/i2rIwhK3kQUsJ1SWeRhliuZ1sEYwcffMu0aymESaVm3w2dk= Received: by filter0469p1mdw1.sendgrid.net with SMTP id filter0469p1mdw1.2015.557AF80F15 2015-06-12 15:17:35.618860334 +0000 UTC Received: from brewster.com (unknown [198.101.132.114]) by ismtpd-051 (SG) with ESMTP id 14de858fc57.2e8f.7519d for ; Fri, 12 Jun 2015 15:17:35 +0000 (UTC) Date: Fri, 12 Jun 2015 15:17:35 +0000 From: =?UTF-8?B?QW5kcsOpIExvcGVzIHZpYSBCcmV3c3Rlcg==?= Reply-to: stay-in-touch@brewster.com To: freebsd-net@freebsd.org Message-ID: <557af80f2c2b6_622e593ba347216327@prod-rs-r15.ihost.brewster.com.mail> Subject: Re: Freebsd's contact info X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxGmH3KiRo4p/IwFNuyqPrG0GCuXMr+kksX3LU aujBf2XiosdH9H2kqRKkR/ljRz/WpGCdqmbUB0+PFs1hheV+AxShMQq5CPcsgBefHFNu3buiB7IDDT aq9ZHjX3/YacOhQ= X-SG-ID: LiHNKJS0nD4/nyvAb5F9jQ+CC9njbF2GU+zUZa77FaNZcNSzmmBjYRk6uAMwZzE7i0l2HeV5Wa4NmN V6sOQTDFQ1jszWl69rX8RSfVVyt1i2cuJZOum0X9+sjxha9c7t MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 15:17:38 -0000 André Lopes André asked us to reach out and confirm they have your latest info Here's what they have for you now: [email.png] [1]freebsd-net@freebsd.org [phone-red.png] [2]Mobile Number [3]Confirm/Update for André For your safety, this link expires in 48 hours Featured on: The New York Times Business Insider Fast Co. TechChrunch Wall Street Journal Brewster Logo Your Contacts, Synced Anywhere [4]Why did you receive this email? 11 East 4th St. #2F New York, NY 10003 [5]Unsubscribe References 1. file:///tmp/tmpTo7da4.html 2. file:///tmp/tmpTo7da4.html 3. http://email.brewster.com/wf/click?upn=5Y9vRPksPl8YR2cxJ-2FiKxdqbiLUxYd3lymLWu-2B64wsQCiTnNTtDmKH6a24P7SRQhjNydiF-2FLcYDuNgB-2BCbxcjGk9bblBCSAZhO-2Fm6ovuQ-2FWfM8yiMpL-2FuLow6-2BXSoeKi-2Fj5SWNYnHzbCT9RjtHTREHaSniTCv9-2FXoNoTqTtu72ZZpGU5xIEm2TIedPv2AkD22pdlVwyUJNr1wTknU0Wha9uoNJT4NmgmwNNZm24jWd5XEUrNqa7hE4pkcnGfiaNhYph0PrJD3UBIQVerTbrQDq16albptAIQbJZ-2BAyRwDHFDL-2BX2qRjsTBJLVZ9qENLEJFgrJt-2FP6tvmCC3eGfbnY9jOd9b4LjS6-2Fqmu1XnQCWWAI-2FZmS28E7kpjZSc2wqSfFWzSDekm1ls4SvqbpRp8aW3-2BJgkMHjbIERnEMVgXNilr6gjRBBSezzbaVnAlItZOl2ZBGQs9pOZI-2Bg8P3wvdPdYnu0wY3-2FA0uKEoQM0MuJglJQoXBRjJWWFVFtTNJAQ-2FKxaaeTatW-2F-2FXsJkUt-2BetpXYjb5p4uPeDKy1kDuD-2BL1xXjzlavAcfMtsrvI3ugPcPSxwY9x9XtGdQ-2Fn5PDuLGOU2T-2BbbDMJ-2BrJoJKmxupXmk-3D_Q1G7K8cYCrLWsp3rtsmPRqpifI81A4ObdBULrI9Uhjic-2B3dNGu1r4FpIc2EB6SARRWoRGSIjKPbfpXE9PCV1apGsbISMsR6KpzSYlPTgHEDBqFYPVsqBM7DEGBG-2FadsALMz0JH2lcjjgrgty62gSiLv-2B1hD-2FuniVTk2-2F6nb4KBuPJL0-2FIqWNkcRN7WYS424E7fjk-2BFLNZdaX8Lk4kSWItVxFj-2BC7qTR0F1eWyWg-2BGRuzLEOw-2Baxof5GIvKKHPMp5BAK0fchO0gESBSfkhwytT0cfNtuCJnc8ZRh2lqcGcLN-2F5L-2FWP6LzJYbGdUkznZ8ry7Nl9pLbvWOFWWbzZxItjQ-3D-3D 4. http://email.brewster.com/wf/click?upn=5Y9vRPksPl8YR2cxJ-2FiKxc9cD7SSE2Dbi7cQpyrmtzjyC9iIlLY5V0t6VLJCriPYTN6XBWlDs6MKZDXSBG0iexUPgRo3Fgv3V8GFks-2BGfHLB6-2B3-2FWqgW9z06DirZCQCYJd5OrGtINEhbho0XQxYqww-3D-3D_Q1G7K8cYCrLWsp3rtsmPRqpifI81A4ObdBULrI9Uhjic-2B3dNGu1r4FpIc2EB6SARRWoRGSIjKPbfpXE9PCV1avQHl1xF8JtwFodcJixr4qDvNmriUKZEOqvpZk1cG3w21LuN9kQuIgVxN39TPm0eKz5CulQR-2F9uzHHwzniomo1heyOXWyhIdX4dr-2FREWxeSeCM9JeNYD8svcv-2FyMarSbIqVjQN3kXfQP9E-2BlnWHMqqJktnLofxuyXUz3vNNgvRHoggkVyr-2Bq6SQLReyVOOkl5DzGwydUgCSzYoSALq9qJ8s7-2FZZzy-2F-2BJPdgA0nO7wh3D55HjmbnZSh0dMxFMRJs1Iw-3D-3D 5. http://email.brewster.com/wf/unsubscribe?upn=Q1G7K8cYCrLWsp3rtsmPRqpifI81A4ObdBULrI9Uhjic-2B3dNGu1r4FpIc2EB6SAR3Xy29Z1m8yU5DcbbZV3GBCKwUNHepgZNCC8kwNxcPfF0QiqdmeF-2FgUtusSbjBcbRb-2FhZx0aoq2iTJDk-2Bolu77UQcqewfw1HYR7kN5QScONrQjbGOOGa-2FiPlrD8SEL9FtZWuUOGMPXuMlyYSgGiNDYniKtSgsHuT6XZr0Pn62fpLQfZKZ2astAMshhBhJfaVed37J0kkGUbama2c5r9zZEveDjVpz410HjPO8beKWCDPw9gkVHvp6gJjDSEV9q7wCWXVlLHRlJ7VF8JxqLR-2FN5w-3D-3D From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 15:43:54 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81AA6D35; Fri, 12 Jun 2015 15:43:54 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48BCDF40; Fri, 12 Jun 2015 15:43:53 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id D2FFE19E08; Fri, 12 Jun 2015 17:43:50 +0200 (CEST) Received: by vega.codepro.be (Postfix, from userid 1001) id C2D5821DA; Fri, 12 Jun 2015 17:43:50 +0200 (CEST) Date: Fri, 12 Jun 2015 17:43:50 +0200 From: Kristof Provost To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: RFC: Dropping support for scrub fragment crop/drop-ovl Message-ID: <20150612154350.GA3135@vega.codepro.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 15:43:54 -0000 Hi all, I've recently been looking at bug 200330. I broke things while adding the reassembly support for ipv6 to pf. Those issues should be fixed now, but having looked at the fragment crop/drop-ovl code, I'm starting to think support for those options should just be removed. For context: in FreeBSD's pf scrub rules can specify different ways to handle fragments. These are 'reassemble', 'crop' and 'drop-ovl'. 'reassemble' is the default, and does full reassembly before filtering the packet. 'crop' and 'drop-ovl' do not reassemble. The man page explains it better than I can: > fragment crop > The default fragment reassembly method is expensive, hence the option > to crop is provided. In this case, pf(4) will track the fragments > and cache a small range descriptor. Duplicate fragments are dropped > and overlaps are cropped. Thus data will only occur once on the wire > with ambiguities resolving to the first occurrence. Unlike the > fragment reassemble modifier, fragments are not buffered, they are > passed as soon as they are received. The fragment crop reassembly > mechanism does not yet work with NAT. > > fragment drop-ovl > This option is similar to the fragment crop modifier except that all > overlapping or duplicate fragments will be dropped, and all further > corresponding fragments will be dropped as well. Basically, these options don't reassemble. That also implies that you get the choice between having your firewall drop fragmented packets, or allowing potentially unwanted packets through because they're fragmented. That's not explicitly mentioned in the man page and I suspect many users don't realise this and are thus led to make choices with unintended consequences. All of this applies only to IPv4. I never implemented support for crop/drop-ovl in the IPv6 reassembly code. On IPv4 any scrub is 'fragment reassembly'. The OpenBSD people removed crop/drop-ovl back in 2009. Removing crop/drop-ovl would also remove around 450 lines of fairly hairy pf code. We'd just default to fragment reassemble, even if crop or drop-ovl is specified. That'd mean a behaviour change, but it'll likely actually make many firewall configurations behave better rather than break things. In summary, unless someone comes forward to say they're using crop or drop-ovl support from them is going to go away. Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 15:53:04 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05C4BEFE for ; Fri, 12 Jun 2015 15:53:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5BDA1F9 for ; Fri, 12 Jun 2015 15:53:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbpi8 with SMTP id pi8so15362772igb.0 for ; Fri, 12 Jun 2015 08:53:03 -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=AhvpTXurwhB7pR3RxKvtqkijDkU1TC6hWNTI9iS9OOM=; b=RIe94NaO0MJ6N93BkbdOL6B35d4GS1Ez3Tw3r7GsTQNR17Ziv8DrpUhRslweqTUycT eKeqFs6qTtf+0M/zvoEQ3XqRQwbz100tynbNX7fR5gcispuHebmG5ByUqNQpNMCN8mup X/bejU1iIcFLY3D9HTAaae5zLxGAhlSsUREMpNxt9EqRBfN4NE1i7lk837z7OCa9EMn8 r3PHboM0tV1bV5GHdev5Pa+nhlGtMykSmuUdZFQUeiHkJgLBT5ue1fLqpnPScIQywSz9 TtoD9bvOmK8vHu/3+hiDJINT3aIa72vdQxDoopIsLvTNMN5UDQNrQtHadADcUIBiQj7N 1Ttg== MIME-Version: 1.0 X-Received: by 10.50.79.228 with SMTP id m4mr5256510igx.6.1434124383070; Fri, 12 Jun 2015 08:53:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Fri, 12 Jun 2015 08:53:03 -0700 (PDT) In-Reply-To: <557AAE18.1040902@tzi.de> References: <557AAE18.1040902@tzi.de> Date: Fri, 12 Jun 2015 08:53:03 -0700 X-Google-Sender-Auth: pTselXkFCqhRjkfNhd_1_BogPUE Message-ID: Subject: Re: Realtek Issues (re) on PC Engines APU1 Board... From: Adrian Chadd To: Julian Kornberger Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 15:53:04 -0000 Hi, If this works for people then we should document this somewhere and include the firmware/tool. Does flashrom come with the above firmware rom image? -a On 12 June 2015 at 03:02, Julian Kornberger wrote: > Hi Karl, > > did you already upgrade your Firmware? > > You get it from: > http://www.pcengines.ch/apu1d4.htm (Build 9/8/2014) > > You install it with: > flashrom --programmer internal -w apu140908.rom \ > -c "MX25L1605A/MX25L1606E" > > That solved our realtek issues. > > Kind regards > Julian > > _______________________________________________ > 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 Jun 12 16:06:12 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5B2F59B for ; Fri, 12 Jun 2015 16:06:12 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 769816C8 for ; Fri, 12 Jun 2015 16:06:12 +0000 (UTC) (envelope-from jim@netgate.com) Received: by iesa3 with SMTP id a3so27346933ies.2 for ; Fri, 12 Jun 2015 09:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SvFGZmyCEMlrH8yEwO5F7fLVdyGsujMUmN/mmYJt1wo=; b=L7J6bPLBK/AgpnFQ1oUP4bKDYtaRWMvuST73QD4JsNd8HitlZoTwENjmHsVhItYqaT PNREmf4jEDIq31S9599qjEIYZgtWiK5SSZlyq76s7S1ptIGIqu7klEoxEoYxRxCLXo1C o2Hy+6CyoF25Kazr/Cc0KY7Tpgn12/jfOqOds= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SvFGZmyCEMlrH8yEwO5F7fLVdyGsujMUmN/mmYJt1wo=; b=nHkPi+vFL0zSI7xMX6+B8kbM+tagGCzu7djAuy8vEqNPOmp0iKT9uHq+3/pW3uRVxv 06tQSQWF/WUhZRk5An57uQiGw4k16pERiE36djtHklQYHO5bOoQgsqS89EjRRPaJSqlG 7K07jCh6ZbmMXd+BHkZnniWFJACT87o0WBs6qSSTw1PIayAi2Dgos0hosHFQX5bwsx3e ivb9V75p/HOk1iPexPKg1HL7/eW/DEesA4hfCc9RWOgfSHwNr8xernPWp2ggdaMNYIFh lXRYGxgjDHYzckLgVcBTZwpg8rBW5v8RpqfLvAOwQQQZ98iiffx6SlTM51siyRHvYyF6 Z2fw== X-Gm-Message-State: ALoCoQlooX69Wop1hCiIeGz9uPyXE2jjkmHwgVFbqaD2RubU3qoIj4beaCXEN6yaFYpGq5TfbF3J X-Received: by 10.50.93.69 with SMTP id cs5mr5474312igb.4.1434125172007; Fri, 12 Jun 2015 09:06:12 -0700 (PDT) Received: from [10.65.212.195] ([137.122.64.42]) by mx.google.com with ESMTPSA id 196sm2742441ioe.23.2015.06.12.09.06.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 09:06:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\)) Subject: Re: Realtek Issues (re) on PC Engines APU1 Board... From: Jim Thompson In-Reply-To: Date: Fri, 12 Jun 2015 12:06:10 -0400 Cc: Julian Kornberger , FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: <50AD907B-37D1-4203-BE41-0F375512FBBB@netgate.com> References: <557AAE18.1040902@tzi.de> To: Adrian Chadd X-Mailer: Apple Mail (2.2100) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 16:06:12 -0000 Do we even know that Karl=E2=80=99s APU(s) aren=E2=80=99t running the = current version of firmware (which was released last September)? jim > On Jun 12, 2015, at 11:53 AM, Adrian Chadd wrote: >=20 > Hi, >=20 > If this works for people then we should document this somewhere and > include the firmware/tool. >=20 > Does flashrom come with the above firmware rom image? >=20 >=20 >=20 > -a >=20 >=20 > On 12 June 2015 at 03:02, Julian Kornberger wrote: >> Hi Karl, >>=20 >> did you already upgrade your Firmware? >>=20 >> You get it from: >> http://www.pcengines.ch/apu1d4.htm (Build 9/8/2014) >>=20 >> You install it with: >> flashrom --programmer internal -w apu140908.rom \ >> -c "MX25L1605A/MX25L1606E" >>=20 >> That solved our realtek issues. >>=20 >> Kind regards >> Julian >>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > 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 Jun 12 16:07:50 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07FFE644 for ; Fri, 12 Jun 2015 16:07:50 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39CD16E0 for ; Fri, 12 Jun 2015 16:07:48 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id 59DA3250A64; Fri, 12 Jun 2015 18:07:45 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndQopDY4Wf8V; Fri, 12 Jun 2015 18:07:41 +0200 (CEST) Received: from [192.168.52.11] (1F2EC6DD.catv.pool.telekom.hu [31.46.198.221]) by green.field.hu (Postfix) with ESMTPA id 03E2D250A7D; Fri, 12 Jun 2015 18:07:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1434125261; bh=nWE8IjsiCkwx8E41RFiDnL7PRPCOdfJbwB29MfNOJOI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=k3zBwzNw/EJwcdlWmVfo1GGN/n3+6eKxiVTGzjEjqw2NM6FPvuEo+6u2YJu/mb5Eu HOoEN62VuFznDjSPuICzoZoTJGVb9qNhPL6N2RDXUgWOcMAHlfQzbhETyCPx+axvjp hxaFTfzpNcrvwa4CsybNXSZHIFR0DzSJhC+sruPw= Message-ID: <557B03C9.4000509@field.hu> Date: Fri, 12 Jun 2015 18:07:37 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christopher Forgeron CC: FreeBSD Net Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> <557AD10D.5070205@field.hu> <557AD2FA.103@field.hu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 16:07:50 -0000 I'll take your advice and give it a shot, thanks :) 2015.06.12. 14:43 keltezéssel, Christopher Forgeron írta: > Ah, but the 'why' will come later, after we know for sure what the > 'what' is in your problem. > > I'm just pointing out the problems that I'm having, as yours sound > similar. Once the box runs out of memory, all sorts of interesting > things can happen. Perhaps that's not your case, but it's quite possible. > > Setup a remote terminal, do the copy again, and send in the last few > lines of 'vmstat 5' after it's locked up, perhaps I can help. > > On Fri, Jun 12, 2015 at 9:39 AM, Cs > wrote: > > but why is that machine runs fine except the network if it's > memory related? swap didn't increased before the network outage. > > > 2015.06.12. 14:37 keltezéssel, Christopher Forgeron írta: >> rsycn burns memory - I'd say you have a good chance you're >> running out of mem before it's replenished. >> >> For vmstat 5 - Don't run it on console. Connect via a second box >> with ssh, and run it there - That way it's the last thing on the >> ssh terminal screen when the box dies, and you'll have your proof. >> >> On Fri, Jun 12, 2015 at 9:31 AM, Cs > > wrote: >> >> machine has been restarted before I could check the "vmstat >> 5" output. Yep, it's rsync. Anyway I disabled the backup >> transfer it'll solve, but I can't really accept this for >> solution. >> >> >> 2015.06.12. 14 :29 keltezéssel, >> Christopher Forgeron írta: >> >> Well, even at low speed it could drop due to memory from >> what I've seen. >> >> What was the last line from vmstat 5 before it locked up? >> >> I find that the em driver isn't crap, but there is a >> deeper problem inside >> of FreeBSD that is being exposed now - For me it's due to >> faster network >> connections. >> >> Are you using rsync to move the files? >> >> On Fri, Jun 12, 2015 at 7:17 AM, Cs > > wrote: >> >> it seems it's not memory related. Server just died a >> few minutes ago >> during transporting the backup (400GB) around 800Mbps >> speed.. >> will disable remote backup, it's a shame that em >> driver is such a crap. >> >> >> 2015.06.08. 5:01 keltezéssel, Christopher Forgeron írta: >> >> You know what helped me: >> >> 'vmstat 5' >> >> Leave that running. If the last thing on the >> console after a crash/hang is >> vmstat showing 8k of memory left, then you're in >> the same problem-park as >> me. >> >> My 10.1 96GiB RAM box is chewing ~8 GiB of RAM in >> less than 5 seconds, and >> then crashing/panicking/hanging. >> >> There's others with this issues if you search for >> it; a sysctl >> to vm.v_free_min to double or triple that value >> may help, but first let us >> know if that's what is bonking your sever. >> >> >> >> On Sun, Jun 7, 2015 at 11:03 AM, Cs >> > wrote: >> >> ok, just lowered it to 1500 but please also >> note that it was on 1500 for >> >> 2 >> years >> >> 2015.06.07. 14 :57 >> keltezéssel, Rick Macklem írta: >> >> Since disabling TSO didn't help, you could >> try dropping to 1500mtu >> >> on both interfaces. Some people run into >> problems when 9K jumbo clusters >> fragment the kernel address space used to >> allocate mbufs. >> >> Good luck with it, rick >> >> ----- Original Message ----- >> >> Hi All, >> >> It worked fine for two weeks but I >> had a network outage 2 days ago >> then >> today. Tried to disable rxcsum and >> txcsum after the first one, didn't >> help. Don't know what else to do it's >> a shame that I can't use this >> card >> with fbsd i REALLY don't want to >> install linux instead but my >> production >> servers outages are not welcomed by >> the customers.. >> >> 2015.05.26. 10 >> :36 >> keltezéssel, Cs írta: >> >> Thanks Mark, good idea. I found >> this thread which is exactly the >> >> same >> problem as mine: >> >> >> https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ >> >> Will see if it helps in a couple >> weeks. >> >> Regards, >> Csaba >> >> 2015.05.26. 10 >> :30 >> keltezéssel, Mark Schouten írta: >> >> Oh, didn't see your lowest >> remark. Then, the next thing that >> comes >> >> past here a few times per >> week is 'Try disabling TSO'. >> >> >> Met vriendelijke groeten, >> >> -- >> Kerio Operator in de Cloud? >> https://www.kerioindecloud.nl/ >> Mark Schouten | Tuxis >> Internet Engineering >> KvK: 61527076 | >> http://www.tuxis.nl/ >> T: 0318 200208 | >> info@tuxis.nl >> >> >> >> >> Van: Cs >> > > >> Aan: Mark Schouten >> > > >> Cc: >> > > >> Verzonden: 25-5-2015 11:12 >> Onderwerp: Re: FreeBSD >> 10.1-REL - network >> unaccessible after >> high >> traffic >> >> It was on 1500 for ~3 years :) >> Regards, >> Csaba >> On May 25, 2015, >> 10:30, at 10:30, Mark Schouten >> > > >> wrote: >> >> Try lowering your mtu to >> 1500, that worked miracles >> for me.. >> >> -- >> Mark Schouten >> Tuxis Internet Engineering >> mark@tuxis.nl >> / >> 0318 200208 >> >> On 25 May 2015, at >> 09:36, "Cs" >> > > >> wrote: >> >> Hi all, >> I have two >> FreeBSd 10.1-RELEASE >> servers connected to each >> other. >> They >> >> were connected via >> cross link, but they >> are connected to a cisco >> >> switch >> now (the problem was the >> same with cross link >> too). When >> transferring >> huge files (50-500GB >> backup files) via Gigabit >> (it is important!) >> the >> network randomly dies. >> The backup runs every >> day/week and >> sometimes the >> connection is ok for >> months sometimes it >> happens twice a week. >> When the >> network dies I can log in >> to the server via IPMI >> and use the >> console >> everything is OK, but >> can't send anything out >> on the network. >> ifconfig >> em0 down/up doesn't help >> nor netif restart. The >> problem never >> occured >> when I used 100Mbit >> connection between them, >> but it was 3com NIC >> (xl), >> gigabit adapter is Intel >> (em0). When I limit the >> transfer rate >> (rsync >> bandwith limit or ipfw >> pipe) the problem is much >> more rare. >> >> I tried to set >> these tuning parameters >> on both servers with >> >> different >> >> buffer size but >> nothing helped: >> >> # cat /etc/sysctl.conf >> >> security.bsd.see_other_uids=0 >> net.inet.tcp.recvspace=512000 >> net.route.netisr_maxqlen=2048 >> kern.ipc.nmbclusters=1310720 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.recvbuf_max=16777216 >> kern.ipc.soacceptqueue=32768 >> # cat >> /boot/loader.conf >> geom_mirror_load="YES" # >> RAID1 disk driver >> (see gmirror(8)) >> ipfw_load="YES" >> net.inet.ip.fw.default_to_accept=1 >> kern.maxusers=4096 >> accf_data_load="YES" >> The duplex >> settings are >> identical on both >> servers. >> Server A: >> em1: >> flags=8843 >> metric 0 >> mtu >> >> 9000 >> >> >> options=4219b >> >> >> ether >> 00:25:90:24:52:66 >> >> inet >> x.x.x.x netmask >> 0xfffffe00 broadcast >> x.x.x.x >> nd6 >> options=29 >> media: >> Ethernet autoselect >> (1000baseT ) >> status: active >> Server B: >> em0: >> flags=8843 >> metric 0 >> mtu >> >> 9000 >> >> >> options=4219b >> >> >> ether >> 00:30:48:dd:fe:3e >> >> inet >> x.x.x.x netmask >> 0xfffffe00 broadcast >> x.x.x.x >> nd6 >> options=29 >> media: >> Ethernet autoselect >> (1000baseT ) >> status: active >> Today I tried to >> set mtu to 9000 but >> in tcpdump I see that >> during >> scp >> >> it is still 1500: >> >> x.x.x.x.222 > >> x.x.x.x.37612: Flags [.], >> cksum 0xb6ee >> >> (incorrect -> >> >> 0xda6f), seq 35749, >> ack 113701596, win >> 7986, options [nop,nop,TS >> >> val >> 3103966325 >> ecr >> 853712893], length 0 >> >> 09:27:33.912354 IP (tos >> 0x8, ttl 64, id 1028, >> offset 0, flags >> >> [DF], >> >> proto TCP (6), >> length 1500) >> >> 09:27:33.912358 IP (tos >> 0x8, ttl 64, id 1029, >> offset 0, flags >> >> [DF], >> >> proto TCP (6), >> length 1500) >> >> Any ideas? Thanks >> guys! >> >> _______________________________________________ >> 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@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@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@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@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 Jun 12 16:12:37 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5EC572F for ; Fri, 12 Jun 2015 16:12:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C535933 for ; Fri, 12 Jun 2015 16:12:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iesa3 with SMTP id a3so27452533ies.2 for ; Fri, 12 Jun 2015 09:12:37 -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=I+jsF5SODY4Ts+fuJzBzBmwQet0bEILNkvwra79Kdcs=; b=USemzrpqShiq9A3PSevzUrN4embYd89TXmBw6xpzuW/0BQFJj5oj+448to1mybd435 ebTFnDCFjXOm+6IJ/dNOWSiw1vDPPk2ZfY2mca24mx3ORWYx/YMFxzptSYjhffSRa9fN XDlf6T+n4jesIcPeRTr6HSXGx2Xt/CUGCYB8j3m++CubHtXTa0dmwYxW9s3iDa7VSVTz kYvWTDqiDkuKpCwBiOjXetFN2aPtkr9YySdyDHdTeWxzx7+dLBCNh6LsEPvKTrzrDdHt hOkvMGVWVlywn8sII1IF6AujBE/0qu3vRBOInZ9vEJ1lD4LE3NLM2O6FXuDRcczebC+h pM8Q== MIME-Version: 1.0 X-Received: by 10.50.79.167 with SMTP id k7mr5391807igx.32.1434125557124; Fri, 12 Jun 2015 09:12:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Fri, 12 Jun 2015 09:12:37 -0700 (PDT) In-Reply-To: References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> <557AD10D.5070205@field.hu> <557AD2FA.103@field.hu> Date: Fri, 12 Jun 2015 09:12:37 -0700 X-Google-Sender-Auth: -Jejnimp6J3yqkSPS7K2fHczxRs Message-ID: Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Adrian Chadd To: Christopher Forgeron Cc: Cs , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 16:12:37 -0000 Hi, It shouldn't "run out of memory" like this in a way that pisses off em, not unless it's leaking memory and it can't allocate mbufs. netstat -m wil list mbuf allocations and what's failed. vmstat -z will list all the memory pools and which allocations have failed. Both would be good to post. -adrian From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:24:37 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FCA8F1; Fri, 12 Jun 2015 17:24:37 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1F8C78; Fri, 12 Jun 2015 17:24:37 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by ykdx132 with SMTP id x132so3887873ykd.2; Fri, 12 Jun 2015 10:24:36 -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=czfeMivhIrE866+i04P7XL51/WXS0ZRutmTs6EUIwHs=; b=NnsluFbN+nwUCjyV9h5P5zY9CSyjWvR2BGoOyA3NgYFsDWmJmblybToVSWk+hCkV5z gLdIgqP8xC6iO80kz2W6mSMkfhZ8oywxQtPdNcnoD/jkGoCdg10yx28lIpTrDMPXysIU vf0SW+sm2zoOIfewf3WXTU8J5gbVENs6BY+ZawrToOcTmtlPdJlQfhU+xYgWW4LdxZ5m DllZPku9Y31RvZaj7jT0IHkvwj9eZpNgHuBP5mQuonlVcQk4mEA1NLFpuKtme7pNf2uE iEcr3578NnREt8yixb7H0Tj4dQr3T5nnaUCT5+zZwkRro49PrOEnusD80yDz/132j1J7 hVUw== MIME-Version: 1.0 X-Received: by 10.129.82.14 with SMTP id g14mr20352232ywb.9.1434129876032; Fri, 12 Jun 2015 10:24:36 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.129.123.137 with HTTP; Fri, 12 Jun 2015 10:24:35 -0700 (PDT) In-Reply-To: <20150612154350.GA3135@vega.codepro.be> References: <20150612154350.GA3135@vega.codepro.be> Date: Fri, 12 Jun 2015 13:24:35 -0400 X-Google-Sender-Auth: mE_nDyXSMQQapTkcToQlweL1Wd4 Message-ID: Subject: Re: RFC: Dropping support for scrub fragment crop/drop-ovl From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Kristof Provost Cc: freebsd-net , "freebsd-pf@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 17:24:37 -0000 On Fri, Jun 12, 2015 at 11:43 AM, Kristof Provost wrote: > Hi all, > > I've recently been looking at bug 200330. I broke things while adding > the reassembly support for ipv6 to pf. > > Those issues should be fixed now, but having looked at the fragment > crop/drop-ovl code, I'm starting to think support for those options > should just be removed. > Just go ahead an do that. > > For context: in FreeBSD's pf scrub rules can specify different ways to > handle fragments. These are 'reassemble', 'crop' and 'drop-ovl'. > > 'reassemble' is the default, and does full reassembly before filtering > the packet. > > 'crop' and 'drop-ovl' do not reassemble. The man page explains it better > than I can: > > > fragment crop > > The default fragment reassembly method is expensive, hence the > option > > to crop is provided. In this case, pf(4) will track the fragments > > and cache a small range descriptor. Duplicate fragments are > dropped > > and overlaps are cropped. Thus data will only occur once on the > wire > > with ambiguities resolving to the first occurrence. Unlike the > > fragment reassemble modifier, fragments are not buffered, they are > > passed as soon as they are received. The fragment crop reassembly > > mechanism does not yet work with NAT. > > > > fragment drop-ovl > > This option is similar to the fragment crop modifier except that > all > > overlapping or duplicate fragments will be dropped, and all further > > corresponding fragments will be dropped as well. > > Basically, these options don't reassemble. That also implies that you > get the choice between having your firewall drop fragmented packets, or > allowing potentially unwanted packets through because they're > fragmented. > > That's not explicitly mentioned in the man page and I suspect many > users don't realise this and are thus led to make choices with > unintended consequences. > > All of this applies only to IPv4. I never implemented support for > crop/drop-ovl in the IPv6 reassembly code. On IPv4 any scrub is > 'fragment reassembly'. > The OpenBSD people removed crop/drop-ovl back in 2009. > > Removing crop/drop-ovl would also remove around 450 lines of fairly > hairy pf code. > > We'd just default to fragment reassemble, even if crop or drop-ovl is > specified. That'd mean a behaviour change, but it'll likely actually > make many firewall configurations behave better rather than break > things. > > In summary, unless someone comes forward to say they're using crop or > drop-ovl support from them is going to go away. > > Regards, > Kristof > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 17:57:58 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C69D72B; Fri, 12 Jun 2015 17:57:58 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69B6E37E; Fri, 12 Jun 2015 17:57:58 +0000 (UTC) (envelope-from csforgeron@gmail.com) Received: by qcjl8 with SMTP id l8so12749281qcj.3; Fri, 12 Jun 2015 10:57:57 -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=bw1g5FKGOLozFitchMc98UqhUz6xgejCGsYDlzvbPNY=; b=ZXfPusRz1BtWsQDSDhE+HIBdInT/+4vCxG8w2NFSo5C/ZApMClLa6YYxH2ZGNVQqnd vgkWy6UjwJAz8hlpvXnmCg8F+j54BEC/oRqfgf/slAoKqeSZQBoSdd3nvG0r4hZHD0P3 SF4adTfxTCEQobZ4RyBaB3ffPD3lRDVpMOuxt7snRirZ9n0tXHxs3MmkOrd7bMhWYVu6 6R4hLQ+/X2zh0QvEYlJ83caLELA0hKLLrOYYLmjwOqJZFUIE1OwGmeeRRsmP72kRHIin DtxtUfnXWIunWiyOwdIwjpkRBKXnYcUN1vGLlA2agJv1JZzDyrs4gQfL4EbJbaxL8dae ivKw== MIME-Version: 1.0 X-Received: by 10.55.16.74 with SMTP id a71mr33201413qkh.15.1434131877441; Fri, 12 Jun 2015 10:57:57 -0700 (PDT) Received: by 10.96.76.104 with HTTP; Fri, 12 Jun 2015 10:57:57 -0700 (PDT) In-Reply-To: References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> <557AD10D.5070205@field.hu> <557AD2FA.103@field.hu> Date: Fri, 12 Jun 2015 14:57:57 -0300 Message-ID: Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Christopher Forgeron To: Adrian Chadd Cc: Cs , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 17:57:58 -0000 I agree it shouldn't run out of memory. Here's what mine does under network load, or rsync load: 2 0 9 1822M 1834M 0 0 0 0 14 8 0 0 22750 724 136119 0 23 77 0 0 9 1822M 1823M 0 0 0 0 0 8 0 0 44317 347 138151 0 16 84 0 0 9 1822M 1761M 0 0 0 0 17 8 0 0 23818 820 92198 0 12 88 0 0 9 1822M 1727M 0 0 0 0 14 8 0 0 40768 634 126688 0 17 83 0 0 9 1822M 8192B 0 8 0 0 15 3 3 0 9236 305 57149 0 33 67 That's with a 5 second vmstat output. After the 8KiB, the system is nearly completely brain-dead and needs a hard power-off. I've seen it go from 6 GiB free to 8KiB in 5 sec as well. Currently my large machines are set to 12 GiB free to keep them from crashing, from what I presume is just network load due to lots of iSCSI / NFS traffic on my 10GiB network. I haven't had time to type this up for the list yet, but I'm putting it here just to make sure people know it's real. On Fri, Jun 12, 2015 at 1:12 PM, Adrian Chadd wrote: > Hi, > > It shouldn't "run out of memory" like this in a way that pisses off > em, not unless it's leaking memory and it can't allocate mbufs. > > netstat -m wil list mbuf allocations and what's failed. > > vmstat -z will list all the memory pools and which allocations have failed. > > Both would be good to post. > > > > -adrian > From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 18:17:43 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9723B9F2 for ; Fri, 12 Jun 2015 18:17:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59697A1A for ; Fri, 12 Jun 2015 18:17:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iebgx4 with SMTP id gx4so29307502ieb.0 for ; Fri, 12 Jun 2015 11:17:42 -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=QQ5tWgZtiFJn8ZHOMro6X0vvG4PDhhmLmtojpBFMX0s=; b=EcwavyOB1YQjSzogyMwuvL8/JR/s5seEjV95Rfw0gGs1Ex5C5/toHnPSikyiqlFNbZ yWSTOE71rc0l+oijJpJPhkkmzcdk4ObEhOcLIR9baXOY2tIzNjHPW+DBwIqN3ompnGXJ dhiLBkk5lc4dcHXJhcSVHadc7hCrm9pnukL2nWYNuS1lltIJeGdOck62cEUVyIYoawPv eBHCuhQOzs5UGksyzaWatAYewkiWFGrwPcrGQf9wZBzDH5JZUrVxLq+zX00sbW4T5J5L rjhKXf2WlQbSKZ6pPT9HGoX5AUSyQqVVP1GTVw/NUpG7SmDemUgESR3dMXDSC4jqlYLi ftNw== MIME-Version: 1.0 X-Received: by 10.50.111.167 with SMTP id ij7mr5993308igb.49.1434133062742; Fri, 12 Jun 2015 11:17:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Fri, 12 Jun 2015 11:17:42 -0700 (PDT) In-Reply-To: References: <374339249.53058039.1433681874571.JavaMail.root@uoguelph.ca> <55744F28.5000402@field.hu> <557AB1BB.60502@field.hu> <557AD10D.5070205@field.hu> <557AD2FA.103@field.hu> Date: Fri, 12 Jun 2015 11:17:42 -0700 X-Google-Sender-Auth: _cWyBNhPIVlWGomjg2ViMsGTrKA Message-ID: Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Adrian Chadd To: Christopher Forgeron Cc: Cs , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 12 Jun 2015 18:17:43 -0000 On 12 June 2015 at 10:57, Christopher Forgeron wrote: > I agree it shouldn't run out of memory. Here's what mine does under network > load, or rsync load: > > 2 0 9 1822M 1834M 0 0 0 0 14 8 0 0 22750 724 136119 > 0 23 77 > > 0 0 9 1822M 1823M 0 0 0 0 0 8 0 0 44317 347 138151 > 0 16 84 > > 0 0 9 1822M 1761M 0 0 0 0 17 8 0 0 23818 820 92198 0 > 12 88 > > 0 0 9 1822M 1727M 0 0 0 0 14 8 0 0 40768 634 126688 > 0 17 83 > > 0 0 9 1822M 8192B 0 8 0 0 15 3 3 0 9236 305 57149 0 > 33 67 > > > That's with a 5 second vmstat output. After the 8KiB, the system is nearly > completely brain-dead and needs a hard power-off. > > > I've seen it go from 6 GiB free to 8KiB in 5 sec as well. Currently my large > machines are set to 12 GiB free to keep them from crashing, from what I > presume is just network load due to lots of iSCSI / NFS traffic on my 10GiB > network. > > > I haven't had time to type this up for the list yet, but I'm putting it here > just to make sure people know it's real. > Hi, Then something is leaking or holding onto memory when it shouldn't be. Try doing vmstat -z and vmstat -m in a one second loop, post the data just before it falls over. -adrian From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 12:36:13 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB4BEFDC; Sat, 13 Jun 2015 12:36:13 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5267D3A1; Sat, 13 Jun 2015 12:36:13 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5DCa7iJ001870; Sat, 13 Jun 2015 14:36:07 +0200 (CEST) Received: from [IPv6:2003:55:6b4e:ef01:9850:a6d8:ea0a:4bb] (p200300556B4EEF019850A6D8EA0A04BB.dip0.t-ipconnect.de [IPv6:2003:55:6b4e:ef01:9850:a6d8:ea0a:4bb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3m7z1L66g3z9905; Sat, 13 Jun 2015 14:36:06 +0200 (CEST) Message-ID: <557C23B6.3060700@tzi.de> Date: Sat, 13 Jun 2015 14:36:06 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adrian Chadd CC: FreeBSD Net Subject: Re: Realtek Issues (re) on PC Engines APU1 Board... References: <557AAE18.1040902@tzi.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Jun 2015 12:36:13 -0000 Hi, flashrom is available at FreeBSD ports. You install it with: pkg install flashrom If you have not updated your BIOS yet, you are running the most recent production BIOS from may. You need the latest beta from september. Kind regards Julian From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 17:44:13 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C48E60D for ; Sat, 13 Jun 2015 17:44:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA5277EC for ; Sat, 13 Jun 2015 17:44:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbpi8 with SMTP id pi8so29930664igb.1 for ; Sat, 13 Jun 2015 10:44:11 -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=2cDgAX6FoFvAX20vaL46X2/83jB0StZ33TpEPG8sOJI=; b=Jqs/a45/4xAnunT3c492ICsOKDXJ9bOUnu7lIYihvrGxIZtSiv3uGIWceFGLnLlsx0 Ga2o5sGWH2MxvSN9bbqYVXszp7j9dboUN1H5E+pD8K33/Ybd5vXr2z7LC0kudTtbijWv K0R6ZsYW3C79ySPkXTfM20Cs9aa9vBOH/z4BfGEtB4xPMzNB3ytM0oOjYjfpT+lUNe3P s9JdHOpQOSDoyCDUicJKoNooFX8V3Z3dWoleiOwDxpjoZZN09vjKufLLYNRnCBMsD5pX tO7kGWQbqVNpJHcAGbJEBVmpERkYovABwGxC7njUKHZTEdKRWtZ5NvKL+8L4TA/pUw8f rX0g== MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr6823464icb.22.1434217451857; Sat, 13 Jun 2015 10:44:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Sat, 13 Jun 2015 10:44:11 -0700 (PDT) In-Reply-To: <557C23B6.3060700@tzi.de> References: <557AAE18.1040902@tzi.de> <557C23B6.3060700@tzi.de> Date: Sat, 13 Jun 2015 10:44:11 -0700 X-Google-Sender-Auth: VuyH3mFWCEaWGW6cbDZa1nTZn9E Message-ID: Subject: Re: Realtek Issues (re) on PC Engines APU1 Board... From: Adrian Chadd To: Julian Kornberger Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Jun 2015 17:44:13 -0000 ok, can someone please create a wiki page on wiki.freebsd.org for this hardware platform, with these details and a copy of the firmware? This is likely going to cause others issues. -a On 13 June 2015 at 05:36, Julian Kornberger wrote: > Hi, > > flashrom is available at FreeBSD ports. You install it with: > pkg install flashrom > > If you have not updated your BIOS yet, you are running the most recent > production BIOS from may. You need the latest beta from september. > > Kind regards > Julian From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 19:39:35 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F198DBF3 for ; Sat, 13 Jun 2015 19:39:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2208343 for ; Sat, 13 Jun 2015 19:39:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5DJdZFx083916 for ; Sat, 13 Jun 2015 19:39:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200210] adding vtnet to bridge results to kernel panic Date: Sat, 13 Jun 2015 19:39:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Jun 2015 19:39:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200210 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Sat Jun 13 19:39:22 UTC 2015 New revision: 284348 URL: https://svnweb.freebsd.org/changeset/base/284348 Log: Fix panic when adding vtnet interfaces to a bridge vtnet interfaces are always in promiscuous mode (at least if the VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This confused the bridge code. Instead we now accept all enable/disable promiscuous commands (and always keep IFF_PROMISC set). There are also two issues with the if_bridge error handling. If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to disable promiscuous mode on the interface. That runs into an assert, because promiscuous mode was never set in the first place. (That's the panic reported in PR 200210.) We can only unset promiscuous mode if the interface actually is promiscuous. This goes against the reference counting done by if_promisc(), but only the first/last if_promic() calls can actually fail, so this is safe. A second issue is a double free of bif. It's already freed by bridge_delete_member(). PR: 200210 Differential Revision: https://reviews.freebsd.org/D2804 Reviewed by: philip (mentor) Changes: head/sys/dev/virtio/network/if_vtnet.c head/sys/net/if_bridge.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 19:39:58 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E437FC80 for ; Sat, 13 Jun 2015 19:39:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE7F6351 for ; Sat, 13 Jun 2015 19:39:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5DJdw4G084080 for ; Sat, 13 Jun 2015 19:39:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200323] BPF userland misuse can crash the system Date: Sat, 13 Jun 2015 19:39:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eri@pfsense.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Jun 2015 19:39:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200323 --- Comment #1 from Ermal Lu=C3=A7i --- This patch fixes the issue and the issue seems to a locked LLE which does n= ot allow BPF to sleep when it needs to. +diff --git a/sys/netinet/if_ether.c b/sys/netinet/if_ether.c +index baa9c26..f31576d 100644 +--- a/sys/netinet/if_ether.c ++++ b/sys/netinet/if_ether.c +@@ -353,6 +353,10 @@ retry: + if ((la->la_flags & LLE_VALID) && + ((la->la_flags & LLE_STATIC) || la->la_expire > time_uptime)) { + bcopy(&la->ll_addr, desten, ifp->if_addrlen); ++ if (flags & LLE_EXCLUSIVE) ++ LLE_WUNLOCK(la); ++ else ++ LLE_RUNLOCK(la); + /* + * If entry has an expiry time and it is approaching, + * see if we need to send an ARP request within this +@@ -365,8 +369,7 @@ retry: + } +=20 + *lle =3D la; +- error =3D 0; +- goto done; ++ return (0); + } +=20 + if (la->la_flags & LLE_STATIC) { /* should not happen! */ --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@FreeBSD.ORG Sat Jun 13 19:41:24 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FB2EDFD for ; Sat, 13 Jun 2015 19:41:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 799916A4 for ; Sat, 13 Jun 2015 19:41:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5DJfObF088859 for ; Sat, 13 Jun 2015 19:41:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200210] adding vtnet to bridge results to kernel panic Date: Sat, 13 Jun 2015 19:41:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 13 Jun 2015 19:41:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200210 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kristof@freebsd.org Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You are the assignee for the bug.