From owner-freebsd-net@FreeBSD.ORG Sun Jul 7 01:29:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53128B89 for ; Sun, 7 Jul 2013 01:29:22 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) by mx1.freebsd.org (Postfix) with ESMTP id 349151C0F for ; Sun, 7 Jul 2013 01:29:22 +0000 (UTC) Received: from chombo.houseloki.net (montesse-2-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:19b9::2]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 1D5EAE606E; Sat, 6 Jul 2013 18:29:21 -0700 (PDT) Received: from [IPv6:fc00:970::e8c0:c3d5:508d:b926] (unknown [IPv6:fc00:970::e8c0:c3d5:508d:b926]) by chombo.houseloki.net (Postfix) with ESMTPSA id 424FD9B; Sat, 6 Jul 2013 18:29:19 -0700 (PDT) Message-ID: <51D8C472.9050103@bluerosetech.com> Date: Sat, 06 Jul 2013 18:29:22 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sami Halabi Subject: Re: DNAT in freebsd References: <20130629002959.GB20376@nat.myhome> <51D006F6.6060809@grosbein.net> <51D04FA8.8080900@grosbein.net> <51D14930.1060502@grosbein.net> <51D15D06.9030300@grosbein.net> <51D390CA.5020803@freebsd.org> <51D3A1A0.8090904@freebsd.org> <51D3A35C.8070305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 01:29:22 -0000 On 7/3/2013 4:06 AM, Sami Halabi wrote: > Hi Julian, > > I appreciate your willing to help me. > > My Situation in short is: > > ----------- [a] ------------------------- [b] ------------- > internet B |---BGP---|84.xx.yy.1 192.168.0.1|-----|192.168.0.2/24 > 193.xx.yy.2| |Aem1 Cem3 D em0| | | neighbour > ----------- ------------------------- | -------------- > | | | > [Q] | | > your networks private network > > I Have control only over the middle machine, so i cant establish a tunnel. > So I want it to act as MAN IN THE MIDDLE/ proxy. > every packet comes from private network to 192.168.0.1 ie: > packet hdr: src: 192.168.0.2 dst 192.168.0.1 > should be translated as: > packet hdr: src: 84.xx.yy.1 dst 193.xx.yy.2 > ports and data untouched. > > and every packet from 193.xx.yy.2 (incoming/setup...) as: > packet hdr: src: 193.xx.yy.2 dst: 84.xx.yy.1 > to be translated as: > packet hdr: src: 192.168.0.1 dst 192.168.0.2 > > btw: any other packet from src other than 193.xx.yy.2 to dst 84.xx.yy.1 > should be dropped. I believe this will work: binat on em1 from 193.xx.yy.2 to 84.xx.yy.1 -> 192.168.0.1 \ static-port tag netA binat on em0 from 192.168.0.2 to 192.168.0.1 -> 84.xx.yy.1 \ static-port tag netB redir from any to 84.xx.yy.1 -> 192.168.0.2 tagged netA redir from any to 192.168.0.1 -> 193.xx.yy.2 tagged netB From owner-freebsd-net@FreeBSD.ORG Mon Jul 8 00:56:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A68A24ED for ; Mon, 8 Jul 2013 00:56:52 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2EC1E1E for ; Mon, 8 Jul 2013 00:56:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=smycEXdn15Av9ks7z6kToGVVW2EQt8Xnv4HojZ3KpOk=; b=CZJj0x0rd1W6BlOYqJApuyTo45NL2Ovp5bT/E9X4zVfiYir9JC5y5HgDv8jK93ZDIX4W48BKJy3i9KV9T1GZMPFIg8tazBU72JMl0Oea3lykjQRLNNmxJgQJWf6hmC5cURzjbL+0WDeUfUJlRmpYM4L3ljouDgRdmFphQXVZ7BA=; Received: from [39.210.114.110] (port=28206 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uvzl3-003G9A-L7 for freebsd-net@freebsd.org; Sun, 07 Jul 2013 18:56:51 -0600 Date: Mon, 8 Jul 2013 08:56:42 +0800 From: Erich Dollansky To: FreeBSD Net Subject: Lagg hangs machine at boot time Message-ID: <20130708085642.022221f1@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 00:56:52 -0000 Hi, after upgrading to: 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: Wed Jul 3 08:45:23 CIT 2013 I have got the problem that lagg hangs the machine on start-up. What I found out was that iwn associates to the access point but stops then. Lagg seems to wait then foreever. Turning off wireless on the hardware side or using a cable solves the problem. I will download now the latest sources to report about the status of iwn. Erich From owner-freebsd-net@FreeBSD.ORG Mon Jul 8 01:19:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 549F3A7F for ; Mon, 8 Jul 2013 01:19:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7871ED8 for ; Mon, 8 Jul 2013 01:19:14 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id nd7so2000976qeb.5 for ; Sun, 07 Jul 2013 18:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3/6Anly7aqqK61MQa63Y7/KoVzZIlIT+I8/IlfoC0fo=; b=nJOusH3TMa/LSCu2gsJwVtRnSGWQi8EDzNJ/b8HyO3IpkcM3WR4iIfuKO9/bKgV+/Z q/8Sa6gSRxpOONSxYqQyyxanyGJUalxNU/B6FT8coPiVsOKYvAU5QWGPIPYXAXa+xYuy PadTikY1RjvlRJvkF1qOFGuLR6sNSBQid14G1tT2Cf40w52uICESAYhePhNVHGG9wkD7 yF/1qgn58rxQZJ2cO6VJC1VOwxvC9HlefriNwZ703h7PjWTfk8fgXRykaZV3SDHCjxwY VkuFybEYs8ad9pVy8/zJTxuKJ/SKTtUAfPq+UiyfEU8fphLx0m0RsiCgrKJ/wZs+YYw6 6s/g== MIME-Version: 1.0 X-Received: by 10.224.13.19 with SMTP id z19mr16602022qaz.12.1373246353659; Sun, 07 Jul 2013 18:19:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Sun, 7 Jul 2013 18:19:13 -0700 (PDT) In-Reply-To: <20130708085642.022221f1@X220.ovitrap.com> References: <20130708085642.022221f1@X220.ovitrap.com> Date: Sun, 7 Jul 2013 18:19:13 -0700 X-Google-Sender-Auth: lHwSgkhaeQc7ZKZJODmIPcZ8AoQ Message-ID: Subject: Re: Lagg hangs machine at boot time From: Adrian Chadd To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 01:19:14 -0000 Hi, Please try wifi without the lagg config. Thanks, -adrian On 7 July 2013 17:56, Erich Dollansky wrote: > Hi, > > after upgrading to: > > 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: > Wed Jul 3 08:45:23 CIT 2013 > > I have got the problem that lagg hangs the machine on start-up. > > What I found out was that iwn associates to the access point but stops > then. Lagg seems to wait then foreever. Turning off wireless on the > hardware side or using a cable solves the problem. > > I will download now the latest sources to report about the status of > iwn. > > Erich > _______________________________________________ > 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 Jul 8 01:32:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F097E5C for ; Mon, 8 Jul 2013 01:32:25 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gg0-x236.google.com (mail-gg0-x236.google.com [IPv6:2607:f8b0:4002:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 3A01D1F53 for ; Mon, 8 Jul 2013 01:32:25 +0000 (UTC) Received: by mail-gg0-f182.google.com with SMTP id f1so1475275ggn.13 for ; Sun, 07 Jul 2013 18:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=RWFNZuRv+U758K/6JYM1++5kL/8CMsjJ2QXh04+esk8=; b=OzRcblCRPnRIENoaBGaa61E8639qf3Ig/6pix5xuNjcYWFMkQzTcbsEqgAHFfoGIQr B6ZDphcFDGaE3d54JfP4Q27qKKvL4hXzI7EqB8/2FuUJFdYLBNkaYEWb52+2Jmi4Rde6 bOum/yVmkr+b8HUXRvInYO3JrizeNpbr3kFXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=RWFNZuRv+U758K/6JYM1++5kL/8CMsjJ2QXh04+esk8=; b=nobe3vy1ODTYkiHFvY0aRM4tPtglw616WnnucKkI48irOweVC/X5KCI22NBi48itvG p/7n1vC6SdenhS9kUe78KOMneIJ98DVEa8iXAj49xBTyW0357VcwslNQu9mkgOsuhH2O VrhamMJS+mtxeVeyIBYk2eMoDqhx5W0cd2fGbFXDeOH+G23tfa4IzTeHIprUxkuNZVSm oxpykHCDOrA6I2voVDHKFkygxKzwd60bcFxsZMfkEnNyT4eMTIyYqDpq9K9xu9/MndhL UUBEYQw6JkWq81akeaAj4V9Dt6CH7OrmAhQ0+JsAuXqJmBNDyuPmzMgZ8laX9zDJz4GH ZFLg== X-Received: by 10.236.120.230 with SMTP id p66mr6441003yhh.111.1373247144687; Sun, 07 Jul 2013 18:32:24 -0700 (PDT) Received: from [192.168.31.77] (68-188-148-148.dhcp.aldl.mi.charter.com. [68.188.148.148]) by mx.google.com with ESMTPSA id w12sm33429991yhj.19.2013.07.07.18.32.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 18:32:23 -0700 (PDT) References: <20130708085642.022221f1@X220.ovitrap.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B35381D6-291A-4674-A852-2EA13F965708; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Jason Hellenthal Subject: Re: Lagg hangs machine at boot time Date: Sun, 7 Jul 2013 21:32:17 -0400 To: Adrian Chadd X-Gm-Message-State: ALoCoQn6Z2mMklLTEQ3VYf56H6vo9MvN7Ley74+WVxYDkGUdKU1+qjYNr20b0+WxKypepzca6ERd X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Erich Dollansky X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 01:32:25 -0000 --Apple-Mail-B35381D6-291A-4674-A852-2EA13F965708 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Was thinking that same thing. Agg before the adapter is actually ready. Simple test might be to bring up the wifi links in the rc and wait till a po= int where rc.local can be used to setup the aggregation later in the boot pr= ocess. --=20 Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jul 7, 2013, at 21:19, Adrian Chadd wrote: > Hi, >=20 > Please try wifi without the lagg config. >=20 > Thanks, >=20 >=20 > -adrian >=20 > On 7 July 2013 17:56, Erich Dollansky wrote:= >> Hi, >>=20 >> after upgrading to: >>=20 >> 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: >> Wed Jul 3 08:45:23 CIT 2013 >>=20 >> I have got the problem that lagg hangs the machine on start-up. >>=20 >> What I found out was that iwn associates to the access point but stops >> then. Lagg seems to wait then foreever. Turning off wireless on the >> hardware side or using a cable solves the problem. >>=20 >> I will download now the latest sources to report about the status of >> iwn. >>=20 >> Erich >> _______________________________________________ >> 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" --Apple-Mail-B35381D6-291A-4674-A852-2EA13F965708 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGNDCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYxggNvMIIDawIBATCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wCQYFKw4DAhoFAKCCAa8wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNzA4MDEzMjIzWjAjBgkqhkiG 9w0BCQQxFgQUFVIczSwBvjrlGQKLVdDxAuJ1Rx0wgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaijjANBgkqhkiG9w0BAQEFAASCAQBVUAJcU+x1HkQpNgPj jU8epT8G+ajIUA2PbWllE4yR+xcbINXWRP4n0uQFHlJGL7TkDLnKK/LQNFa6Of2yHhh0PGhofC4Y YCqKAXTZksodYgQYMAmc2rLq5G9MN+tANQ4EMiofiGnbSx3Dnx0Arct4rakwqxKeab3U102eeFCu odHZpF34+aYeskDjcjRFw2u6n0AK0RxaCakpWvUNGPVjhDw+pkelmb2nJ233L1RonORZlo6HIg4M g8B2uG6C00DTF7+v6VAPMalpiFs1LpX66INef16lTIDHQHuvPk4htPXdmnLZbve5nuOJVpI5n3W3 X6r3qytUGEJF+AkutcIfAAAAAAAA --Apple-Mail-B35381D6-291A-4674-A852-2EA13F965708-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 8 03:07:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3059F202; Mon, 8 Jul 2013 03:07:21 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id E1CFC1347; Mon, 8 Jul 2013 03:07:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=knkMl2MSYOU3ZlxHoqQK+AGoCpbv8Cl9E+Ud2xmvxEY=; b=PNLZqKEizDCvq+W7vdRBCNAJSGIaNCXrHjM2/QHmWby8sGS2a+4sQzlH2vet8rOt5+zydPv2yGqfyWnJGzCIN2O2n1pXy+/VStqpzpEwozpoM1PbyYWcmiPkoqKX8y1LTQgJ3hqIyRl0JErGu7b7g5c3kdmXQWRwf4DxNWpHepU=; Received: from [39.210.114.110] (port=14154 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uw1nI-003pmO-Ui; Sun, 07 Jul 2013 21:07:19 -0600 Date: Mon, 8 Jul 2013 11:07:09 +0800 From: Erich Dollansky To: Adrian Chadd Subject: Re: Lagg hangs machine at boot time Message-ID: <20130708110709.537ec96f@X220.ovitrap.com> In-Reply-To: References: <20130708085642.022221f1@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 03:07:21 -0000 On Sun, 7 Jul 2013 18:19:13 -0700 Adrian Chadd wrote: Hi, > Please try wifi without the lagg config. this is what I did already. iwn associates but stops there: iwn0: flags=8802 metric 0 mtu 2290 ether 10:0b:a9:a3:6e:f0 nd6 options=23 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated The light indicating wireless connect does not even flicker. DMESG also does not show anything from iwn. while em gives this result: em0: flags=8843 metric 0 mtu 1500 options=4219b ether f0:de:f1:cd:10:3a inet 192.168.0.112 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::f2de:f1ff:fecd:103a%em0 prefixlen 64 scopeid 0x1 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active I noticed the difference in the mtu. My cheap switch/access point does not allow me to use anything above 1500 when connecting via it to the Internet. I am just compiling the latest release. Please give me time to report the new results. Erich > Thanks, > > > -adrian > > On 7 July 2013 17:56, Erich Dollansky > wrote: > > Hi, > > > > after upgrading to: > > > > 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: > > Wed Jul 3 08:45:23 CIT 2013 > > > > I have got the problem that lagg hangs the machine on start-up. > > > > What I found out was that iwn associates to the access point but > > stops then. Lagg seems to wait then foreever. Turning off wireless > > on the hardware side or using a cable solves the problem. > > > > I will download now the latest sources to report about the status of > > iwn. > > > > Erich > > _______________________________________________ > > 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 Jul 8 03:11:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0AE4C300; Mon, 8 Jul 2013 03:11:45 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id CB38D1384; Mon, 8 Jul 2013 03:11:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=//4OXJlr3QC/8gsyW5DbgDJ3VJ1IEZI71NVlkCxmqEo=; b=DQYQOqZHSaboywQO8acAV/hNmWEsjfW8bZih5tT4JgpbtX4cK3BtiLXj0mZ3wg70hn8iS7lHnpqFfWZ4f6teffhNQ7sRGeKm5e0i67qyS0ISktAyFc0v8nrFPReKTgO/iiauU+mlX+4TQKVEGaPo1coPz2rV1N84MB8AwGvaEoc=; Received: from [39.210.114.110] (port=45010 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uw1rZ-003qhA-MS; Sun, 07 Jul 2013 21:11:43 -0600 Date: Mon, 8 Jul 2013 11:11:35 +0800 From: Erich Dollansky To: Jason Hellenthal Subject: Re: Lagg hangs machine at boot time Message-ID: <20130708111135.5c04ccb4@X220.ovitrap.com> In-Reply-To: References: <20130708085642.022221f1@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Net , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 03:11:45 -0000 Hi, On Sun, 7 Jul 2013 21:32:17 -0400 Jason Hellenthal wrote: > Was thinking that same thing. Agg before the adapter is actually > ready. it worked before. > > Simple test might be to bring up the wifi links in the rc and wait > till a point where rc.local can be used to setup the aggregation > later in the boot process. > I have tested already with plain iwn but iwn never comes up. Erich > > From owner-freebsd-net@FreeBSD.ORG Mon Jul 8 07:22:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8853C1FC for ; Mon, 8 Jul 2013 07:22:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E42A61CB8 for ; Mon, 8 Jul 2013 07:22:33 +0000 (UTC) Received: (qmail 61171 invoked from network); 8 Jul 2013 08:13:43 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jul 2013 08:13:43 -0000 Message-ID: <51DA68B8.6070201@freebsd.org> Date: Mon, 08 Jul 2013 09:22:32 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Improved SYN Cookies: Looking for testers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 07:22:34 -0000 We have a SYN cookie implementation for quite some time now but it has some limitations with current realities for window scaling and SACK encoding the in the few available bits. This patch updates and improves SYN cookies mainly by: a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN (initial sequence number) without the use of timestamp bits. b) switching to the very fast and cryptographically strong SipHash-2-4 hash MAC algorithm to protect the SYN cookie against forgery. The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). Please find it here for testing: http://people.freebsd.org/~andre/syncookie-20130708.diff Please enable TCP logdebug to see connection status reporting by the changes. Detailed discussion: The purpose of SYN cookies is to encode all necessary session state in the 32 bits of our initial sequence number to avoid storing any information locally in memory. This is especially important when under heavy spoofed SYN attacks where we would either run out of memory or the syncache would fill with bogus connection attempts swamping out legitimate connections. The 32 bits of the ISN are a very limited space because we also have to store a cryptographically strong enough hash MAC in it to prevent spoofing of valid SYN cookies. The result is that 24 bits have to be dedicated to the MAC hash and only 8 bits remain available for the session state. The common parameters used on TCP sessions have changed quite a bit since SYN cookies very invented some 17 years ago. Today we a lot more bandwidth making the use window scaling almost mandatory. Also SACK has become standard as it makes recovering from packet loss much more efficient. The original SYN cookies method only stored an indexed MSS values in the cookie. This obviously isn't sufficient anymore and breaks in the presence of WSCALE. WSCALE information is only exchanged during SYN and SYN-ACK. If we can't keep track of it then we severely under- estimate the available send or receive window compounded with the fact that with large window scaling the window size information on the TCP segment header would be even lower numerically. A number of years back I extended SYN cookies to store the additional state in the TCP timestamp fields, if available on a connection. It has been adapted by Linux as well. While timestamps are common among the BSD, Linux and other *nix systems Windows never enabled them by default and thus are not present for the vast majority of clients seen on the Internet. The new improvement in this patch moves all necessary information into the ISN again removing the need for timestamps. Both the MSS and send WSCALE are stored in 3 bit indexed form together with a single bit for SACK. While we can't represent all possible MSS and WSCALE values, both are 16 bit fields in the TCP header, in only 3 bits each this, it turns out, isn't actually necessary. The MSS depends on the MTU of the path and with the dominance of ethernet the main value seen is around 1460 bytes. Encapsulations for DSL lines and some other overheads reduce it by a few more bytes for many connections seen. Based on large traffic surveys I've selected the most common values that perfectly, or with only a small down rounding difference, represent essentially 99.99% of all connections seen in real life. Rounding down to the next lower value isn't a problem as we only would send slightly more packets for the same amount of data. The send WSCALE is bit more tricky as rounding down would let us under- estimate the available send space available towards the remote host. Again it turns out that a small number of values dominates all connections and is thus carefully selected again. The receive WSCALE isn't encoded at all but recalculated based on the local receive socket buffer size when a valid SYN cookie returns. The socket buffer size most likely didn't change in the mean time on a listen socket. If it did we'd have a discrepancy for those SYN cookies in flight at the time of the change. These improvements allow one to run with SYN cookies only on Internet facing servers. However while SYN cookies are calculated and sent all the time, they're only used when the syn cache overflows due to attacks or overload. In that cause though you can rest assured that no significant degradation in TCP connection setup happens anymore and that even Windows clients can make use of window scaling and SACK. In addition the hash MAC to protect the SYN cookies is changed from MD5 to SipHash-2-4, a much faster and cryptographically secure algorithm recently developed by Jean-Philippe Aumasson and Daniel J. Bernstein. Ministat makes the MAC hash calculation speed difference even more obvious: x md5 + siphash +------------------------------------------------------------+ | + | ~ . .. ~ | + xx | |++ xx | |++ xx | |++ xx | |++ + xx | |++ + xx | |++ ++ xx | |++ ++ xxx | |++ ++ xxx | |++ ++ xxx xx x| | |_A_| | | MA | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 84 23467 28845 23955 23920.714 746.57003 + 84 8311 9777 8800 8840.6786 323.69754 Difference at 95.0% confidence -15080 +/- 174.018 -63.0417% +/- 0.727477% (Student's t, pooled s = 575.39) Happy testing. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jul 8 11:41:12 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9361E594 for ; Mon, 8 Jul 2013 11:41:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8562215DC for ; Mon, 8 Jul 2013 11:41:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r68BeXgu053981 for ; Mon, 8 Jul 2013 11:41:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r68B6dOg046167 for freebsd-net@FreeBSD.org; Mon, 8 Jul 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jul 2013 11:06:39 GMT Message-Id: <201307081106.r68B6dOg046167@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:41:12 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179999 net [ofed] [patch] Bug assigning HCA from IB to ETH p kern/179975 net [igb] igb(4) fails to do polling(4) o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179901 net [netinet] [patch] Multicast SO_REUSEADDR handled incor o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 452 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 8 11:47:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A4CA6D4; Mon, 8 Jul 2013 11:47:01 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id AEE821842; Mon, 8 Jul 2013 11:47:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=GO4q5CXR5h2gDj50aJ0Cy8dD3Kq2Pmoastarv1M7bbo=; b=Sb8RJOPKkhIYQFpvknVjWbDjTtaOzgCLwnjlMPPAa0uqM6x2Wl8yloKyeKn7Ebf4s1mO82YOfbeKmj2kZNGbbZiRwdPcneyuaFtuzxJFpb0iEpIKYCM5Mv2XAwAPkE+N3fXxBTwQtfUmLASiijnZGmncDBMNdxwurqoDLBCGa4E=; Received: from [39.210.114.110] (port=17679 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uw6uM-000wyV-Do; Mon, 08 Jul 2013 02:34:56 -0600 Date: Mon, 8 Jul 2013 16:34:46 +0800 From: Erich Dollansky To: Adrian Chadd Subject: Re: Lagg hangs machine at boot time Message-ID: <20130708163446.096870a0@X220.ovitrap.com> In-Reply-To: References: <20130708085642.022221f1@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:47:01 -0000 Hi, as said, I have upgraded to FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r253016M: Mon Jul 8 11:32:01 CIT 2013 erich@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 with the result that lagg does not hang the machine while iwn still behaves like before. Now X stopped working. I will do some research on this first. I am back now to the old kernel. Erich On Sun, 7 Jul 2013 18:19:13 -0700 Adrian Chadd wrote: > Hi, > > Please try wifi without the lagg config. > > Thanks, > > > -adrian > > On 7 July 2013 17:56, Erich Dollansky > wrote: > > Hi, > > > > after upgrading to: > > > > 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: > > Wed Jul 3 08:45:23 CIT 2013 > > > > I have got the problem that lagg hangs the machine on start-up. > > > > What I found out was that iwn associates to the access point but > > stops then. Lagg seems to wait then foreever. Turning off wireless > > on the hardware side or using a cable solves the problem. > > > > I will download now the latest sources to report about the status of > > iwn. > > > > Erich > > _______________________________________________ > > 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 Jul 8 21:25:47 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AFE16671; Mon, 8 Jul 2013 21:25:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8902E1A00; Mon, 8 Jul 2013 21:25:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r68LPlwL069785; Mon, 8 Jul 2013 21:25:47 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r68LPlqW069784; Mon, 8 Jul 2013 21:25:47 GMT (envelope-from jhb) Date: Mon, 8 Jul 2013 21:25:47 GMT Message-Id: <201307082125.r68LPlqW069784@freefall.freebsd.org> To: shahark@mellanox.com, jhb@FreeBSD.org, freebsd-net@FreeBSD.org, jhb@FreeBSD.org From: jhb@FreeBSD.org Subject: Re: kern/179999: [ofed] [patch] Bug assigning HCA from IB to ETH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:25:47 -0000 Synopsis: [ofed] [patch] Bug assigning HCA from IB to ETH State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Mon Jul 8 21:25:21 UTC 2013 State-Changed-Why: Fix applied to HEAD. Thanks! Responsible-Changed-From-To: freebsd-net->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Mon Jul 8 21:25:21 UTC 2013 Responsible-Changed-Why: Fix applied to HEAD. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=179999 From owner-freebsd-net@FreeBSD.ORG Tue Jul 9 04:37:43 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C84B3B7; Tue, 9 Jul 2013 04:37:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 565AE16FE; Tue, 9 Jul 2013 04:37:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r694bhOO057398; Tue, 9 Jul 2013 04:37:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r694bhFx057397; Tue, 9 Jul 2013 04:37:43 GMT (envelope-from linimon) Date: Tue, 9 Jul 2013 04:37:43 GMT Message-Id: <201307090437.r694bhFx057397@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/180382: [ae] kernel: ae0: watchdog timeout - resetting. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 04:37:43 -0000 Old Synopsis: kernel: ae0: watchdog timeout - resetting. New Synopsis: [ae] kernel: ae0: watchdog timeout - resetting. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jul 9 04:37:27 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180382 From owner-freebsd-net@FreeBSD.ORG Tue Jul 9 06:22:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BF6771C; Tue, 9 Jul 2013 06:22:00 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 56F681A70; Tue, 9 Jul 2013 06:22:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Pt5xUM5TcLO3SzDACyBNYdPYJZQ7ZyEn4W0ssa9RXxc=; b=jquwHyz0ZolPGC28W9wAXeuE0u64lpcQymXRu0g8salBq+2Fi7WfyGaQI4CQx92TRjv2YPzDdTPGbaFVvqF9xpBKTEkoGXuX3r1vRsXBBBlr4xvWuPe68fGK2OQ11B1sJAehOXrCcQb7I2K7U3AuGj+TW3uoVukdMB27ik0mPtw=; Received: from [39.216.39.205] (port=63607 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UwRJA-003LJ3-6P; Tue, 09 Jul 2013 00:21:54 -0600 Date: Tue, 9 Jul 2013 14:21:43 +0800 From: Erich Dollansky To: Adrian Chadd Subject: Re: Lagg hangs machine at boot time Message-ID: <20130709142143.1d382a8c@X220.ovitrap.com> In-Reply-To: References: <20130708085642.022221f1@X220.ovitrap.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 06:22:00 -0000 Hi, On Sun, 7 Jul 2013 18:19:13 -0700 Adrian Chadd wrote: I upgraded today to FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r253048M: Tue Jul 9 11:21:48 CIT 2013 erich@X220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 and wireless was working again. Lagg worked since yesterday even with iwn failing. Good work! Erich > Hi, > > Please try wifi without the lagg config. > > Thanks, > > > -adrian > > On 7 July 2013 17:56, Erich Dollansky > wrote: > > Hi, > > > > after upgrading to: > > > > 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r252491M: > > Wed Jul 3 08:45:23 CIT 2013 > > > > I have got the problem that lagg hangs the machine on start-up. > > > > What I found out was that iwn associates to the access point but > > stops then. Lagg seems to wait then foreever. Turning off wireless > > on the hardware side or using a cable solves the problem. > > > > I will download now the latest sources to report about the status of > > iwn. > > > > Erich > > _______________________________________________ > > 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 Tue Jul 9 11:22:10 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 424794B2; Tue, 9 Jul 2013 11:22:10 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5121997; Tue, 9 Jul 2013 11:22:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r69BM9V1053002; Tue, 9 Jul 2013 11:22:09 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r69BM9Ev053001; Tue, 9 Jul 2013 11:22:09 GMT (envelope-from yongari) Date: Tue, 9 Jul 2013 11:22:09 GMT Message-Id: <201307091122.r69BM9Ev053001@freefall.freebsd.org> To: claudiu.vasadi@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Subject: Re: kern/180382: [ae] kernel: ae0: watchdog timeout - resetting. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 11:22:10 -0000 Synopsis: [ae] kernel: ae0: watchdog timeout - resetting. State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jul 9 11:21:13 UTC 2013 State-Changed-Why: Would you try patch at the following URL? http://freefall.freebsd.org/~yongari/ae.diff Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 9 11:21:13 UTC 2013 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=180382 From owner-freebsd-net@FreeBSD.ORG Tue Jul 9 13:52:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 301E03E3 for ; Tue, 9 Jul 2013 13:52:34 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id E93201139 for ; Tue, 9 Jul 2013 13:52:33 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 9A6735CA77 for ; Tue, 9 Jul 2013 15:52:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id BK_H_6MySKd8 for ; Tue, 9 Jul 2013 15:52:25 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id E28F35CA56 for ; Tue, 9 Jul 2013 15:52:25 +0200 (CEST) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id DA1E750886 for ; Tue, 9 Jul 2013 15:52:25 +0200 (CEST) Message-ID: <51DC1599.8040805@incore.de> Date: Tue, 09 Jul 2013 15:52:25 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: sis(4) flow control Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:52:34 -0000 Some of my soekris boxes run with sis interfaces. Because I need ethernet flow control on these boxes I use the following patch (against 8-Stable) for some years: --- if_sis.c.orig 2013-05-15 20:01:16.000000000 +0200 +++ if_sis.c 2013-06-24 15:58:05.000000000 +0200 @@ -1965,6 +1965,18 @@ } #endif + if (sc->sis_type == SIS_TYPE_83815 && sc->sis_srr >= NS_SRR_16A) { + if (ifp->if_flags & IFF_LINK0) { + /* + * Configure Ethernet flow control for outgoing frames. + * Enable reception of 802.3x multicast pause frames. + */ + SIS_SETBIT(sc, NS_PCR, NS_PCR_PAUSE ); + } else { + SIS_CLRBIT(sc, NS_PCR, NS_PCR_PAUSE ); + } + } + mii = device_get_softc(sc->sis_miibus); /* Set MAC address */ Other network drivers (eg. vr) have this functionality inside, it would be fine if sis learns flow control too. --- Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Tue Jul 9 20:29:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 464DE653 for ; Tue, 9 Jul 2013 20:29:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 0972F1A82 for ; Tue, 9 Jul 2013 20:29:10 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3bqZqz0gThzFTh6 for ; Tue, 9 Jul 2013 22:29:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G0YO5lAyZ9y for ; Tue, 9 Jul 2013 22:29:01 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA for ; Tue, 9 Jul 2013 22:28:59 +0200 (CEST) Message-ID: <51DC726D.6040601@madpilot.net> Date: Tue, 09 Jul 2013 22:28:29 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: re0 not working at boot on -CURRENT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:29:11 -0000 Hi, I have a PC with an integrate re ethernet interface, pciconf identifies it like this: re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 hdr=0x00 I'm running FreeBSD current r252261. As stated in the subject after boot the interface does not work correctly. Using tcpdump on another host I noticed that packets (ICMP echo requests for example) do get sent, and replies generated by the other host, but the kernel does not seem to see them. Except that every now and then some packet does get to the system. I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on from a ping which has been running for some time. Just about one every twenty. Some pattern is showing up. this is the output of ifconfig re0 after boot: re0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:19:99:f8:d3:0b inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active If I just touch any interface flag with ifconfig, anyone, tso, -txcsum -rxcsum, it starts working flawlessly. It keeps working also if I perform the opposite operation with ifconfig afterwards, so it is not the flag itself fixing it. This is an ifconfig after performing this exercise(it's the same, since I disabled txcsum and reactivated it in this instance): re0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:19:99:f8:d3:0b inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active I don't know much about FreeBSD network drivers so i can't make theories about this. I hope someone has an idea what the problem could be. I'm available for any further information needed, test, experiment and so on. Thanks in advance! -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Wed Jul 10 02:35:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E80049D6 for ; Wed, 10 Jul 2013 02:35:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id C3D811CC7 for ; Wed, 10 Jul 2013 02:35:20 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj3so6220963pad.0 for ; Tue, 09 Jul 2013 19:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=EsZkKECbNRjnfTF7+4BF0riusX0GT8AbUdc5P9hElMQ=; b=VH0zWGtc7BDyq2xwBsk6DVRwTrrUVD/uGnnKSv7pJmHfaUObM7J0gbusdW0STs4A+R 089tMvRY14yVvnZEu+nXp168nPcwcNJ1rgtdJtKE0pgv5AZw5CENj9mR267vTl2i5mfN 3U7omEhdg/KC724kRmYQCV+mH77a3iPSx2RqaoQ3z8Qnvd3dGC+S7GD+IFVxmKq6MuTs TLynX8csFIeX4UOpP+yjDS0uhfxSqZtvda3GtAgnONyKZUM8EqV/QF7YevP7t7wBU8Nk dzmQFSWN22MFRoChU0UjQVBT2fsCIZeUK3YOdfpaJZ+7zeTMEPdjPPzS5tB8PsxAPC1C WKvw== X-Received: by 10.68.239.164 with SMTP id vt4mr19322101pbc.115.1373423720581; Tue, 09 Jul 2013 19:35:20 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id dg3sm31112996pbc.24.2013.07.09.19.35.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 19:35:19 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Jul 2013 11:35:12 +0900 From: Yonghyeon PYUN Date: Wed, 10 Jul 2013 11:35:12 +0900 To: Andreas Longwitz Subject: Re: sis(4) flow control Message-ID: <20130710023512.GB2753@michelle.cdnetworks.com> References: <51DC1599.8040805@incore.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: <51DC1599.8040805@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 02:35:21 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 09, 2013 at 03:52:25PM +0200, Andreas Longwitz wrote: > Some of my soekris boxes run with sis interfaces. Because I need > ethernet flow control on these boxes I use the following patch (against > 8-Stable) for some years: > > --- if_sis.c.orig 2013-05-15 20:01:16.000000000 +0200 > +++ if_sis.c 2013-06-24 15:58:05.000000000 +0200 > @@ -1965,6 +1965,18 @@ > } > #endif > > + if (sc->sis_type == SIS_TYPE_83815 && sc->sis_srr >= NS_SRR_16A) { > + if (ifp->if_flags & IFF_LINK0) { > + /* > + * Configure Ethernet flow control for outgoing frames. > + * Enable reception of 802.3x multicast pause frames. > + */ > + SIS_SETBIT(sc, NS_PCR, NS_PCR_PAUSE ); > + } else { > + SIS_CLRBIT(sc, NS_PCR, NS_PCR_PAUSE ); > + } > + } > + > mii = device_get_softc(sc->sis_miibus); > > /* Set MAC address */ > > Other network drivers (eg. vr) have this functionality inside, it would > be fine if sis learns flow control too. > Hmm, does the change really make flow-control work? I believe flow-control should be negotiated with remote link partner so you have to announce flow-control capability to link partner. In addition, it seems DP83815/DP83816 does not support TX flow-control so it just honors RX pause frames. Try attached patch and let me know how it works. --1UWUbFP1cBYEclgG Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sis.flow.diff" Index: sys/dev/sis/if_sis.c =================================================================== --- sys/dev/sis/if_sis.c (revision 253125) +++ sys/dev/sis/if_sis.c (working copy) @@ -619,10 +619,22 @@ sis_miibus_statchg(device_t dev) SIS_SETBIT(sc, SIS_TX_CFG, (SIS_TXCFG_IGN_HBEAT | SIS_TXCFG_IGN_CARR)); SIS_SETBIT(sc, SIS_RX_CFG, SIS_RXCFG_RX_TXPKTS); + if (sc->sis_type == SIS_TYPE_83815) { + if ((IFM_OPTIONS(mii->mii_media_active) & + IFM_ETH_RXPAUSE) != 0) + SIS_SETBIT(sc, NS_PCR, NS_PCR_PAUSE_DA | + NS_PCR_PAUSE_MCAST | NS_PCR_PAUSE_ENABLE); + else + SIS_CLRBIT(sc, NS_PCR, NS_PCR_PAUSE_DA | + NS_PCR_PAUSE_MCAST | NS_PCR_PAUSE_ENABLE); + } } else { SIS_CLRBIT(sc, SIS_TX_CFG, (SIS_TXCFG_IGN_HBEAT | SIS_TXCFG_IGN_CARR)); SIS_CLRBIT(sc, SIS_RX_CFG, SIS_RXCFG_RX_TXPKTS); + if (sc->sis_type == SIS_TYPE_83815) + SIS_CLRBIT(sc, NS_PCR, NS_PCR_PAUSE_DA | + NS_PCR_PAUSE_MCAST | NS_PCR_PAUSE_ENABLE); } if (sc->sis_type == SIS_TYPE_83815 && sc->sis_srr >= NS_SRR_16A) { @@ -1074,7 +1086,8 @@ sis_attach(device_t dev) * Do MII setup. */ error = mii_attach(dev, &sc->sis_miibus, ifp, sis_ifmedia_upd, - sis_ifmedia_sts, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0); + sis_ifmedia_sts, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, + sc->sis_type == SIS_TYPE_83815 ? MIIF_DOPAUSE : 0); if (error != 0) { device_printf(dev, "attaching PHYs failed\n"); goto fail; Index: sys/dev/sis/if_sisreg.h =================================================================== --- sys/dev/sis/if_sisreg.h (revision 253125) +++ sys/dev/sis/if_sisreg.h (working copy) @@ -78,6 +78,7 @@ #define NS_IHR 0x1C #define NS_CLKRUN 0x3C #define NS_WCSR 0x40 +#define NS_PCR 0x44 #define NS_SRR 0x58 #define NS_BMCR 0x80 #define NS_BMSR 0x84 @@ -123,6 +124,15 @@ #define NS_WCSR_DET_PATTERN3 0x40000000 #define NS_WCSR_DET_MAGIC 0x80000000 +#define NS_PCR_PAUSE_CNT_MASK 0x0000FFFF +#define NS_PCR_MLD_ENABLE 0x00010000 +#define NS_PCR_PAUSE_NEG 0x00200000 +#define NS_PCR_PAUSE_RCVD 0x00400000 +#define NS_PCR_PAUSE_ACT 0x00800000 +#define NS_PCR_PAUSE_DA 0x20000000 +#define NS_PCR_PAUSE_MCAST 0x40000000 +#define NS_PCR_PAUSE_ENABLE 0x80000000 + /* NS silicon revisions */ #define NS_SRR_15C 0x302 #define NS_SRR_15D 0x403 --1UWUbFP1cBYEclgG-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 10 07:04:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 20213565 for ; Wed, 10 Jul 2013 07:04:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id F1F231853 for ; Wed, 10 Jul 2013 07:04:40 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id 4so6011517pdd.20 for ; Wed, 10 Jul 2013 00:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0voHMhJ7bmjBxf72SJkBzcxgSljFTh1Eo5uPwGeA1Dk=; b=uMcIpX8oMjg5fvbpRcUHMOoKQ+S0a6+sIsWhut36FuHYNG2fXb86T8gUnQBT/lopw3 yO4ya3tUREgyN/7q0ZXn0M1u2NhOFi6jUtCbrc/RjnvVtp8inb1viVGtvT2q9UE44HtW C2p0qqzJ8aLra0BHfJFHwhYD2dc9mJGZXjjeu/3LtLS+ao96GrIZJHiBAF/354lUcA/N by/t0URbNr8xlpMlS2agUpoAUKzdJGX1yOgZsLsWSTJ2WPGx509HPwUIbOotYJy/koVG 5FMnIQRLOiTDJcpPbpESZQ/QxFd2l56T0jYHPXDdyPPzlNNuKjNVZQogdRHQF8WJ0a0K d3sw== X-Received: by 10.68.60.132 with SMTP id h4mr30099905pbr.177.1373439879244; Wed, 10 Jul 2013 00:04:39 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id y6sm32357200pbl.23.2013.07.10.00.04.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 00:04:38 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Jul 2013 16:04:31 +0900 From: Yonghyeon PYUN Date: Wed, 10 Jul 2013 16:04:31 +0900 To: Guido Falsi Subject: Re: re0 not working at boot on -CURRENT Message-ID: <20130710070431.GE2753@michelle.cdnetworks.com> References: <51DC726D.6040601@madpilot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51DC726D.6040601@madpilot.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 07:04:41 -0000 On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: > Hi, > > I have a PC with an integrate re ethernet interface, pciconf identifies > it like this: > > re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 > hdr=0x00 > > I'm running FreeBSD current r252261. > > As stated in the subject after boot the interface does not work correctly. > > Using tcpdump on another host I noticed that packets (ICMP echo requests > for example) do get sent, and replies generated by the other host, but > the kernel does not seem to see them. Except that every now and then > some packet does get to the system. > > I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on > from a ping which has been running for some time. Just about one every > twenty. Some pattern is showing up. > > this is the output of ifconfig re0 after boot: > > re0: flags=8843 metric 0 mtu 1500 > > options=8209b > ether 00:19:99:f8:d3:0b > inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 > inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > If I just touch any interface flag with ifconfig, anyone, tso, -txcsum > -rxcsum, it starts working flawlessly. It keeps working also if I > perform the opposite operation with ifconfig afterwards, so it is not > the flag itself fixing it. > > This is an ifconfig after performing this exercise(it's the same, since > I disabled txcsum and reactivated it in this instance): > > re0: flags=8843 metric 0 mtu 1500 > > options=8209b > ether 00:19:99:f8:d3:0b > inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 > inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > I don't know much about FreeBSD network drivers so i can't make theories > about this. I hope someone has an idea what the problem could be. > > I'm available for any further information needed, test, experiment and > so on. Could you show me dmesg output(re(4) and rgephy(4) only)? Did it ever work or you see the issue only on CURRENT? From owner-freebsd-net@FreeBSD.ORG Wed Jul 10 08:32:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B4A66F3E for ; Wed, 10 Jul 2013 08:32:29 +0000 (UTC) (envelope-from melifaro@yandex-team.ru) Received: from forward-corp1f.mail.yandex.net (forward-corp1f.mail.yandex.net [IPv6:2a02:6b8:0:801::10]) by mx1.freebsd.org (Postfix) with ESMTP id 44BA41BCD for ; Wed, 10 Jul 2013 08:32:29 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1f.mail.yandex.net (Yandex) with ESMTP id E20FD24200D5; Wed, 10 Jul 2013 12:32:26 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id C87492C0248; Wed, 10 Jul 2013 12:32:26 +0400 (MSK) Received: from dhcp170-36-red.yandex.net (dhcp170-36-red.yandex.net [95.108.170.36]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id iNunliI0zu-WQImEUcu; Wed, 10 Jul 2013 12:32:26 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1373445146; bh=SkrVDUTTlO3jh90d+JM8x8Nx0O4IWIpYVNID2c6HGb0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type:Content-Transfer-Encoding; b=U3/6gNdCx4c9B2D9C7glufa/Pqtkbl21tiGyTx2Ufd9QxG8sqaVmQ2jceSRQr/25M DybVXAHUtO7Vs0lKC0EUwrFClVHDlOFWUf1F+zHE5T4MxKrGQtzhQQtRJ9freFjZ4k zAvjy2Y2QtVAEkn3Lkcia49gaqJBlu0LzxhsnmVM= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <51DD1C09.4060606@yandex-team.ru> Date: Wed, 10 Jul 2013 12:32:09 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130418 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: netmap receiver crashes driver on exit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 08:32:29 -0000 Hello list! It seems there are still some rough edges with netmap api. I'm currently experimenting with netmap receiver on fresh -current (r252470) and ixgbe. Every time the receiver is killed/coredumped/or ^C'd (stock pkt-gen with -f rx can act as such receiver), after some random pause (10-300 seconds) the crash comes: kgdb) bt #0 doadump (textdump=) at pcpu.h:236 #1 0xffffffff8083ed70 in kern_reboot (howto=260) at /home/melifaro/netmap_10/sys/kern/kern_shutdown.c:447 #2 0xffffffff8083f135 in panic (fmt=) at /home/melifaro/netmap_10/sys/kern/kern_shutdown.c:754 #3 0xffffffff80bbb1b5 in trap_fatal (frame=, eva=) at /home/melifaro/netmap_10/sys/amd64/amd64/trap.c:873 #4 0xffffffff80bbb48b in trap_pfault (frame=0x0, usermode=0) at /home/melifaro/netmap_10/sys/amd64/amd64/trap.c:699 #5 0xffffffff80bbac55 in trap (frame=0xffffff9046d52810) at /home/melifaro/netmap_10/sys/amd64/amd64/trap.c:463 #6 0xffffffff80ba4ff2 in calltrap () at exception.S:232 #7 0xffffffff81a22051 in ixgbe_rxeof (que=0xfffffe0e1f6ce000) at /home/melifaro/netmap_10/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4484 #8 0xffffffff81a22e55 in ixgbe_msix_que (arg=0xfffffe0e1f6ce000) at /home/melifaro/netmap_10/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:1515 #9 0xffffffff80812f28 in intr_event_execute_handlers (p=, ie=0xfffffe012083f300) at /home/melifaro/netmap_10/sys/kern/kern_intr.c:1263 #10 0xffffffff808133f8 in ithread_loop (arg=0xfffffe0120849820) at /home/melifaro/netmap_10/sys/kern/kern_intr.c:1276 #11 0xffffffff80810bea in fork_exit (callout=0xffffffff808132d0 , arg=0xfffffe0120849820, frame=0xffffff9046d52ac0) at /home/melifaro/netmap_10/sys/kern/kern_fork.c:991 #12 0xffffffff80ba552e in fork_trampoline () at exception.S:606 #13 0x0000000000000000 in ?? () (kgdb) up 7 #7 0xffffffff81a22051 in ixgbe_rxeof (que=0xfffffe0e1f6ce000) at /home/melifaro/netmap_10/sys/modules/ixgbe/../../dev/ixgbe/ixgbe.c:4484 4484 mp->m_len = len; (kgdb) p mp $1 = (struct mbuf *) 0x0 (kgdb) p i $2 = 279 (kgdb) p *rxr $3 = {adapter = 0xffffff8001245000, rx_mtx = {lock_object = {lo_name = 0xfffffe0d52a7f0ae "ix0:rx(0)", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 18446741879526785024}, me = 0, rx_base = 0xffffff9046d43000, rxdma = {dma_paddr = 4822675456, dma_vaddr = 0xffffff9046d43000 "", dma_tag = 0xfffffe01301d8e00, dma_map = 0xffffffff812bbf08, dma_seg = {ds_addr = 0, ds_len = 0}, dma_size = 16384, dma_nseg = 0}, lro = {ifp = 0x0, lro_queued = 0, lro_flushed = 0, lro_bad_csum = 0, lro_cnt = 0, lro_active = {slh_first = 0x0}, lro_free = {slh_first = 0x0}}, lro_enabled = false, hw_rsc = false, discard = false, vtag_strip = false, next_to_refresh = 277, next_to_check = 279, num_desc = 1024, mbuf_sz = 2048, process_limit = 65535, mtx_name = "ix0:rx(0)\000\000\000\000\000\000", rx_buffers = 0xffffff81cb9e5000, ptag = 0xfffffe01301d8300, bytes = 174, packets = 0, rx_irq = 0, rx_copies = 522, rx_packets = 3631, rx_bytes = 196720, rx_discarded = 0, rsc_num = 0, flm = 0} (kgdb) p rbuf $4 = (struct ixgbe_rx_buf *) 0xffffff81cb9e7b98 (kgdb) p *rbuf $5 = {buf = 0x0, fmp = 0x0, pmap = 0x0, flags = 0, addr = 6467809280} More specifically: small traffic rate (~180 packets/s) was constantly flowing on ix0 (so each interrupt grabs 1 packet) ix0 was opened by netmap for several seconds. After that, netmap program was killed Panic usually follows after ~30 seconds ix configuration: 4q, ring length: 1024 some more investigation (from other similar dump): define list_ring set $rxr = (struct rx_ring *)$arg0 set $i = 0 while $i < $rxr->num_desc set $rbuf = &$rxr->rx_buffers[$i] if $rbuf->buf == 0 p $i p *$rbuf end set $i = $i + 1 end p $i end (kgdb) p ifindex_table[3]->ife_ifnet->if_xname $553 = "ix0", '\0' (kgdb) p ifindex_table[4]->ife_ifnet->if_xname $554 = "ix1", '\0' kgdb) p &((struct adapter *)ifindex_table[3]->ife_ifnet->if_softc)->rx_rings[0] $529 = (struct rx_ring *) 0xfffffe0120846800 (kgdb) p &((struct adapter *)ifindex_table[3]->ife_ifnet->if_softc)->rx_rings[1] $530 = (struct rx_ring *) 0xfffffe0120846910 (kgdb) p &((struct adapter *)ifindex_table[3]->ife_ifnet->if_softc)->rx_rings[2] $531 = (struct rx_ring *) 0xfffffe0120846a20 (kgdb) p &((struct adapter *)ifindex_table[3]->ife_ifnet->if_softc)->rx_rings[3] $532 = (struct rx_ring *) 0xfffffe0120846b30 (kgdb) list_ring $529 $533 = 1024 (kgdb) list_ring $530 $534 = 591 $535 = {buf = 0x0, fmp = 0x0, pmap = 0x0, flags = 0, addr = 0} $536 = 1024 (kgdb) list_ring $531 $537 = 274 $538 = {buf = 0x0, fmp = 0x0, pmap = 0x0, flags = 0, addr = 0} $539 = 276 $540 = {buf = 0x0, fmp = 0x0, pmap = 0x0, flags = 0, addr = 0} $541 = 1024 (kgdb) list_ring $532 $542 = 592 $543 = {buf = 0x0, fmp = 0x0, pmap = 0x0, flags = 0, addr = 6021709824} $544 = 1024 (kgdb) p &((struct adapter *)ifindex_table[4]->ife_ifnet->if_softc)->rx_rings[0] $545 = (struct rx_ring *) 0xfffffe0120845000 (kgdb) p &((struct adapter *)ifindex_table[4]->ife_ifnet->if_softc)->rx_rings[1] $546 = (struct rx_ring *) 0xfffffe0120845110 (kgdb) p &((struct adapter *)ifindex_table[4]->ife_ifnet->if_softc)->rx_rings[2] $547 = (struct rx_ring *) 0xfffffe0120845220 (kgdb) p &((struct adapter *)ifindex_table[4]->ife_ifnet->if_softc)->rx_rings[3] $548 = (struct rx_ring *) 0xfffffe0120845330 (kgdb) list_ring $545 $549 = 1024 (kgdb) list_ring $546 $550 = 1024 (kgdb) list_ring $547 $551 = 1024 (kgdb) list_ring $548 $552 = 1024 What can I do to further debug/fix this issue? From owner-freebsd-net@FreeBSD.ORG Wed Jul 10 10:59:42 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B652708; Wed, 10 Jul 2013 10:59:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 73CC2138E; Wed, 10 Jul 2013 10:59:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6AAxg4l073348; Wed, 10 Jul 2013 10:59:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6AAxgjI073347; Wed, 10 Jul 2013 10:59:42 GMT (envelope-from linimon) Date: Wed, 10 Jul 2013 10:59:42 GMT Message-Id: <201307101059.r6AAxgjI073347@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 10:59:42 -0000 Old Synopsis: Bad UDP checksum calc for fragmented packets New Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 10 10:59:03 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180430 From owner-freebsd-net@FreeBSD.ORG Wed Jul 10 13:18:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FDC89F9; Wed, 10 Jul 2013 13:18:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by mx1.freebsd.org (Postfix) with ESMTP id 03C7B1CB2; Wed, 10 Jul 2013 13:18:34 +0000 (UTC) Received: from [78.35.164.14] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UwuHk-0000H8-QS; Wed, 10 Jul 2013 15:18:20 +0200 Date: Wed, 10 Jul 2013 15:18:22 +0200 From: Fabian Keil To: Andre Oppermann Subject: Re: Improved SYN Cookies: Looking for testers Message-ID: <20130710151821.5a8cf38a@fabiankeil.de> In-Reply-To: <51DA68B8.6070201@freebsd.org> References: <51DA68B8.6070201@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/bEiWjWD8oQNb.ag.VQbG9gv"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 13:18:35 -0000 --Sig_/bEiWjWD8oQNb.ag.VQbG9gv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > We have a SYN cookie implementation for quite some time now but it > has some limitations with current realities for window scaling and > SACK encoding the in the few available bits. >=20 > This patch updates and improves SYN cookies mainly by: >=20 > a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN > (initial sequence number) without the use of timestamp bits. >=20 > b) switching to the very fast and cryptographically strong SipHash-2-4 > hash MAC algorithm to protect the SYN cookie against forgery. >=20 > The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). >=20 > Please find it here for testing: >=20 > http://people.freebsd.org/~andre/syncookie-20130708.diff I've been using the patch for a couple of days and didn't notice any issues so far. Privoxy's regression tests continue to work as expected as well. BTW, I think kern/173309 could be closed. Fabian --Sig_/bEiWjWD8oQNb.ag.VQbG9gv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHdXx4ACgkQBYqIVf93VJ2/hwCgtKxRfpacubgmb4uvcQWAhKCW 8HAAnj6vE4HccN9hmWSFsBOE7+VMtXPB =gv2W -----END PGP SIGNATURE----- --Sig_/bEiWjWD8oQNb.ag.VQbG9gv-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 10 17:47:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39266526 for ; Wed, 10 Jul 2013 17:47:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id B63DC108A for ; Wed, 10 Jul 2013 17:47:10 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3br7Bh2MVCzFTxx; Wed, 10 Jul 2013 19:47:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB-M3x_6kOXj; Wed, 10 Jul 2013 19:47:06 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA; Wed, 10 Jul 2013 19:47:06 +0200 (CEST) Message-ID: <51DD9E15.7070609@madpilot.net> Date: Wed, 10 Jul 2013 19:47:01 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: re0 not working at boot on -CURRENT References: <51DC726D.6040601@madpilot.net> <20130710070431.GE2753@michelle.cdnetworks.com> In-Reply-To: <20130710070431.GE2753@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 17:47:11 -0000 On 07/10/13 09:04, Yonghyeon PYUN wrote: > On Tue, Jul 09, 2013 at 10:28:29PM +0200, Guido Falsi wrote: >> Hi, >> >> I have a PC with an integrate re ethernet interface, pciconf identifies >> it like this: >> >> re0@pci0:3:0:0: class=0x020000 card=0x11c01734 chip=0x816810ec rev=0x07 >> hdr=0x00 >> >> I'm running FreeBSD current r252261. >> >> As stated in the subject after boot the interface does not work correctly. >> >> Using tcpdump on another host I noticed that packets (ICMP echo requests >> for example) do get sent, and replies generated by the other host, but >> the kernel does not seem to see them. Except that every now and then >> some packet does get to the system. >> >> I'm seeing packet 7, 27, 47, 66, 86, 106, 125, 144, 164, 183 and so on >> from a ping which has been running for some time. Just about one every >> twenty. Some pattern is showing up. >> >> this is the output of ifconfig re0 after boot: >> >> re0: flags=8843 metric 0 mtu 1500 >> >> options=8209b >> ether 00:19:99:f8:d3:0b >> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >> nd6 options=29 >> media: Ethernet autoselect (100baseTX ) >> status: active >> >> If I just touch any interface flag with ifconfig, anyone, tso, -txcsum >> -rxcsum, it starts working flawlessly. It keeps working also if I >> perform the opposite operation with ifconfig afterwards, so it is not >> the flag itself fixing it. >> >> This is an ifconfig after performing this exercise(it's the same, since >> I disabled txcsum and reactivated it in this instance): >> >> re0: flags=8843 metric 0 mtu 1500 >> >> options=8209b >> ether 00:19:99:f8:d3:0b >> inet 172.24.42.13 netmask 0xffffff00 broadcast 172.24.42.255 >> inet6 fe80::219:99ff:fef8:d30b%re0 prefixlen 64 scopeid 0x2 >> nd6 options=29 >> media: Ethernet autoselect (100baseTX ) >> status: active >> >> I don't know much about FreeBSD network drivers so i can't make theories >> about this. I hope someone has an idea what the problem could be. >> >> I'm available for any further information needed, test, experiment and >> so on. > > Could you show me dmesg output(re(4) and rgephy(4) only)? re0: port 0xd000-0xd0ff mem 0xf2104000-0xf2104fff,0xf2100000-0xf2103fff irq 17 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 re0: Ethernet address: 00:19:99:f8:d3:0b 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 Also, I'm loading this as a module, but, for as much as I know, this should not make any difference. > Did it ever work or you see the issue only on CURRENT? Never worked on this machine (I own it since the last days of February). I only installed current on it. If needed I can find time to test a recent 9.x snapshot on it. I worked around the problem till now using an USB ethernet adapter, always wanted to report this problem, but I've been lazy :) -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Wed Jul 10 22:18:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 19C7A8CC for ; Wed, 10 Jul 2013 22:18:29 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D16681EB4 for ; Wed, 10 Jul 2013 22:18:28 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 56C0B5CB1F; Thu, 11 Jul 2013 00:18:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 3s7a5T0LO2LT; Thu, 11 Jul 2013 00:18:20 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 975DD5C7CA; Thu, 11 Jul 2013 00:18:20 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 41BAB50881; Thu, 11 Jul 2013 00:18:20 +0200 (CEST) Message-ID: <51DDDDAB.6070100@incore.de> Date: Thu, 11 Jul 2013 00:18:19 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: sis(4) flow control References: <51DC1599.8040805@incore.de> <20130710023512.GB2753@michelle.cdnetworks.com> In-Reply-To: <20130710023512.GB2753@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:18:29 -0000 Yonghyeon PYUN wrote: > Hmm, does the change really make flow-control work? > I believe flow-control should be negotiated with remote link > partner so you have to announce flow-control capability to link > partner. In addition, it seems DP83815/DP83816 does not support > TX flow-control so it just honors RX pause frames. Excuse me, the comment in my patch was wrong. Better would be /* Enable reception of 802.3x pause frames. */. My soekris boxes are connected to a slow so called "Ethernet Connect" line (2 Mbit/s). The line works correct and stable if I respect incoming RX pause frames from the line. I do not need TX flow-control. > Try attached patch and let me know how it works. Thanks for your patch. I will test it on next update of my soekris boxes with sis interfaces. Because they are all remote far away this will need some time. -- Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 00:26:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA25C260 for ; Thu, 11 Jul 2013 00:26:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id B694112EC for ; Thu, 11 Jul 2013 00:26:05 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id r10so6891410pdi.13 for ; Wed, 10 Jul 2013 17:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nJz7OKZ5US3HHkCMukDJM541PnHte0RhNc4oartzOHE=; b=UrNQg/46NOmKjQkT2x1TGyiRFJCfCULEYJYQ/gJO6YsSRIMqbKabxlRbfykKIgFyIQ no7sPV2XHjY/iO1XRQUJYwdSAPk/zm6OAVdGXzh18JTtQI/FZoCJDK11KYGD3yXumxky 81ExcL/NDsK/C2f3swhQxPO8XgT0FyCvEt0U87b/8TuvFFOYBS3RUbRmTV4+e4HR9HFW tmn2d+yVgmmS8MgG1GauIz2+VWiVu5OHMnWg5R2aCIFQ3q/FSs5QNCDQZVjWKKHFPNcQ eDeWxoDmqlv+2ePT6MAWII1I/rz1QZKDxJ2XZT3ia0Qg7bdFUU+DlMH+HLqdAxKUhohV e0iw== X-Received: by 10.66.179.17 with SMTP id dc17mr23106038pac.85.1373502365464; Wed, 10 Jul 2013 17:26:05 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id 4sm36348919pbw.32.2013.07.10.17.26.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 17:26:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Jul 2013 09:25:57 +0900 From: Yonghyeon PYUN Date: Thu, 11 Jul 2013 09:25:57 +0900 To: Andreas Longwitz Subject: Re: sis(4) flow control Message-ID: <20130711002557.GA6697@michelle.cdnetworks.com> References: <51DC1599.8040805@incore.de> <20130710023512.GB2753@michelle.cdnetworks.com> <51DDDDAB.6070100@incore.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51DDDDAB.6070100@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 00:26:05 -0000 On Thu, Jul 11, 2013 at 12:18:19AM +0200, Andreas Longwitz wrote: > Yonghyeon PYUN wrote: > > > Hmm, does the change really make flow-control work? > > I believe flow-control should be negotiated with remote link > > partner so you have to announce flow-control capability to link > > partner. In addition, it seems DP83815/DP83816 does not support > > TX flow-control so it just honors RX pause frames. > > Excuse me, the comment in my patch was wrong. Better would be > /* Enable reception of 802.3x pause frames. */. > My soekris boxes are connected to a slow so called "Ethernet Connect" > line (2 Mbit/s). The line works correct and stable if I respect incoming > RX pause frames from the line. I do not need TX flow-control. > > > Try attached patch and let me know how it works. > > Thanks for your patch. I will test it on next update of my soekris boxes > with sis interfaces. Because they are all remote far away this will need > some time. Ok. Make sure to check established link before testing flow-control. 'ifconfig sis0' will show current media and you should have something like the following. ... media: Ethernet autoselect (100baseTX ) If you don't see 'rxpause', re-negotiate flow-control with 'ifconfig sis0 mediaopt flow'. From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 07:06:07 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9FEB23F1 for ; Thu, 11 Jul 2013 07:06:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E85011671 for ; Thu, 11 Jul 2013 07:06:06 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA27344 for ; Thu, 11 Jul 2013 10:05:59 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxAww-000MSa-PA for freebsd-net@freebsd.org; Thu, 11 Jul 2013 10:05:58 +0300 Message-ID: <51DE591E.7040405@FreeBSD.org> Date: Thu, 11 Jul 2013 10:05:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: Listen queue overflow: N already in queue awaiting acceptance X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:06:07 -0000 kernel: sonewconn: pcb 0xfffffe0047db3930: Listen queue overflow: 193 already in queue awaiting acceptance last message repeated 113 times last message repeated 518 times last message repeated 2413 times last message repeated 2041 times last message repeated 1741 times last message repeated 1543 times last message repeated 1283 times last message repeated 1178 times last message repeated 1020 times ... What does this messages mean? Is it really that important to be printed? Finally, why is it not throttled? Thank you. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 07:19:46 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8CE4CE0 for ; Thu, 11 Jul 2013 07:19:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 61B5B1734 for ; Thu, 11 Jul 2013 07:19:45 +0000 (UTC) Received: (qmail 87560 invoked from network); 11 Jul 2013 08:10:22 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 08:10:22 -0000 Message-ID: <51DE5C8C.3090404@freebsd.org> Date: Thu, 11 Jul 2013 09:19:40 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Listen queue overflow: N already in queue awaiting acceptance References: <51DE591E.7040405@FreeBSD.org> In-Reply-To: <51DE591E.7040405@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:19:47 -0000 On 11.07.2013 09:05, Andriy Gapon wrote: > kernel: sonewconn: pcb 0xfffffe0047db3930: Listen queue overflow: 193 already in > queue awaiting acceptance > last message repeated 113 times > last message repeated 518 times > last message repeated 2413 times > last message repeated 2041 times > last message repeated 1741 times > last message repeated 1543 times > last message repeated 1283 times > last message repeated 1178 times > last message repeated 1020 times > ... > > What does this messages mean? That your server process lagging behind in accepting new connections and a quite a number of them get aborted due to a backlogged listen queue. Making the accept queue longer doesn't help, it's user-space that can't keep up with the rate of new incoming connections. You can either reduce the rate of new incoming connections, optimize your server process to accept more connections in the same time, or get a beefier machine. > Is it really that important to be printed? The log messages are at DEBUG level. People probably want to know about their server not keeping up and throwing incoming connection attempts away. > Finally, why is it not throttled? The frequency it happens with is important to determine if this is only a temporary spike (micro-burst) or persistent condition. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 08:36:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8DBC44C1 for ; Thu, 11 Jul 2013 08:36:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id F30ED1ACF for ; Thu, 11 Jul 2013 08:36:27 +0000 (UTC) Received: (qmail 87857 invoked from network); 11 Jul 2013 09:27:04 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 09:27:04 -0000 Message-ID: <51DE6E86.6080707@freebsd.org> Date: Thu, 11 Jul 2013 10:36:22 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fabian Keil Subject: Re: Improved SYN Cookies: Looking for testers References: <51DA68B8.6070201@freebsd.org> <20130710151821.5a8cf38a@fabiankeil.de> In-Reply-To: <20130710151821.5a8cf38a@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:36:28 -0000 On 10.07.2013 15:18, Fabian Keil wrote: > Andre Oppermann wrote: > >> We have a SYN cookie implementation for quite some time now but it >> has some limitations with current realities for window scaling and >> SACK encoding the in the few available bits. >> >> This patch updates and improves SYN cookies mainly by: >> >> a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN >> (initial sequence number) without the use of timestamp bits. >> >> b) switching to the very fast and cryptographically strong SipHash-2-4 >> hash MAC algorithm to protect the SYN cookie against forgery. >> >> The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). >> >> Please find it here for testing: >> >> http://people.freebsd.org/~andre/syncookie-20130708.diff > > I've been using the patch for a couple of days and didn't notice any > issues so far. Privoxy's regression tests continue to work as expected > as well. Thanks for testing and reporting back. Could you test with net.inet.tcp.log_debug and net.inet.tcp.syncookies_only=1 as well to bypass the syn cache entirely? It will give a bit of debug log output which is it telling you mostly about rounding to the next nearest index value. You can send the output privately to me to spot unexpected outliers, if any. > BTW, I think kern/173309 could be closed. OK. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 13:35:07 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 047AAA2A; Thu, 11 Jul 2013 13:35:07 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 836051E19; Thu, 11 Jul 2013 13:35:05 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r6BDZ4VH008721; Thu, 11 Jul 2013 17:35:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r6BDZ4Ta008720; Thu, 11 Jul 2013 17:35:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 11 Jul 2013 17:35:04 +0400 From: Gleb Smirnoff To: Andre Oppermann Subject: Re: Listen queue overflow: N already in queue awaiting acceptance Message-ID: <20130711133504.GB67810@FreeBSD.org> References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <51DE5C8C.3090404@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:35:07 -0000 On Thu, Jul 11, 2013 at 09:19:40AM +0200, Andre Oppermann wrote: A> On 11.07.2013 09:05, Andriy Gapon wrote: A> > kernel: sonewconn: pcb 0xfffffe0047db3930: Listen queue overflow: 193 already in A> > queue awaiting acceptance A> > last message repeated 113 times A> > last message repeated 518 times A> > last message repeated 2413 times A> > last message repeated 2041 times A> > last message repeated 1741 times A> > last message repeated 1543 times A> > last message repeated 1283 times A> > last message repeated 1178 times A> > last message repeated 1020 times A> > ... A> > A> > What does this messages mean? A> A> That your server process lagging behind in accepting new connections and a A> quite a number of them get aborted due to a backlogged listen queue. A> A> Making the accept queue longer doesn't help, it's user-space that can't keep A> up with the rate of new incoming connections. A> A> You can either reduce the rate of new incoming connections, optimize your A> server process to accept more connections in the same time, or get a beefier A> machine. A> A> > Is it really that important to be printed? A> A> The log messages are at DEBUG level. People probably want to know about A> their server not keeping up and throwing incoming connection attempts away. A> A> > Finally, why is it not throttled? A> A> The frequency it happens with is important to determine if this is only A> a temporary spike (micro-burst) or persistent condition. IMO, this should be a single counter accessible via sysctl, with no printf(). Those, who need details on whether this is micro-burst or persistent condition, can run monitoring software that draws plots. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 14:28:34 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71A4431D for ; Thu, 11 Jul 2013 14:28:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C36CF1063 for ; Thu, 11 Jul 2013 14:28:33 +0000 (UTC) Received: (qmail 89438 invoked from network); 11 Jul 2013 15:19:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 15:19:07 -0000 Message-ID: <51DEC10B.3080409@freebsd.org> Date: Thu, 11 Jul 2013 16:28:27 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Listen queue overflow: N already in queue awaiting acceptance References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> In-Reply-To: <20130711133504.GB67810@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:28:34 -0000 On 11.07.2013 15:35, Gleb Smirnoff wrote: > On Thu, Jul 11, 2013 at 09:19:40AM +0200, Andre Oppermann wrote: > A> On 11.07.2013 09:05, Andriy Gapon wrote: > A> > kernel: sonewconn: pcb 0xfffffe0047db3930: Listen queue overflow: 193 already in > A> > queue awaiting acceptance > A> > last message repeated 113 times > A> > last message repeated 518 times > A> > last message repeated 2413 times > A> > last message repeated 2041 times > A> > last message repeated 1741 times > A> > last message repeated 1543 times > A> > last message repeated 1283 times > A> > last message repeated 1178 times > A> > last message repeated 1020 times > A> > ... > A> > > A> > What does this messages mean? > A> > A> That your server process lagging behind in accepting new connections and a > A> quite a number of them get aborted due to a backlogged listen queue. > A> > A> Making the accept queue longer doesn't help, it's user-space that can't keep > A> up with the rate of new incoming connections. > A> > A> You can either reduce the rate of new incoming connections, optimize your > A> server process to accept more connections in the same time, or get a beefier > A> machine. > A> > A> > Is it really that important to be printed? > A> > A> The log messages are at DEBUG level. People probably want to know about > A> their server not keeping up and throwing incoming connection attempts away. > A> > A> > Finally, why is it not throttled? > A> > A> The frequency it happens with is important to determine if this is only > A> a temporary spike (micro-burst) or persistent condition. > > IMO, this should be a single counter accessible via sysctl, with no > printf(). Those, who need details on whether this is micro-burst or > persistent condition, can run monitoring software that draws plots. The single counter wouldn't tell you anything because it misses which socket/accept queue is affected by the overflow. The inpcb pointer can be cross-refrenced with netstat -a. Andriy for example would never have found out about this problem other than receiving vague user complaints about aborted connection attempts. Maybe after spending many hours searching for the cause he may have interfered from endless scrolling in Wireshark that something wasn't right and blame syncache first. Only later it would emerge that he's either receiving too many connections or his application is too slow dealing with incoming connections. If you can recommend a suitable and general sysadmin friendly monitoring software that will point out this problem I'm all ears. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 14:49:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 123738C9; Thu, 11 Jul 2013 14:49:28 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id ED5F71179; Thu, 11 Jul 2013 14:49:26 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id fr10so6887336lab.4 for ; Thu, 11 Jul 2013 07:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Bt4bgwyEs4LlKMxnrPl8Av4A+QUE62vScN/kdtmfrtI=; b=m2uFCFNicGzG465mZVwjQJKx/xMKsCNrZsTC8xI9pstxQ/0dgirwtF6el0DnimK4BS xkCpWvXzYPpOZfDszkRwn5V+1NdyYawEpbf9ynTRwOCJ2qFvU1rLWFY5ul0DAaqMlFfn TwfxLIygTpQCSfkoWb9lBUA97bX9xMeznaY39kdd2PxlblMarwDb2dA7kpKbcoOf1NnY VhO9B1PdcvCE47E4C4TtrrOEFle/rtcmWsJumPnNf9T8JSb38qiT5AuwG8wPK75WnwJn 7qrKcdy+JEVuih+oJOVrlOBR6iCSUYUgtIx6IZTcViWRxfzQEQ8iz8wV8jTof5Qu7dcY +t1g== MIME-Version: 1.0 X-Received: by 10.112.29.17 with SMTP id f17mr17500087lbh.20.1373554165762; Thu, 11 Jul 2013 07:49:25 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.15 with HTTP; Thu, 11 Jul 2013 07:49:25 -0700 (PDT) In-Reply-To: <51DEC10B.3080409@freebsd.org> References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> Date: Thu, 11 Jul 2013 16:49:25 +0200 X-Google-Sender-Auth: C2_Kf5Xba1-tFFRQqhwvaczRJUs Message-ID: Subject: Re: Listen queue overflow: N already in queue awaiting acceptance From: Luigi Rizzo To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:49:28 -0000 On Thu, Jul 11, 2013 at 4:28 PM, Andre Oppermann wrote: > On 11.07.2013 15:35, Gleb Smirnoff wrote: >> >> On Thu, Jul 11, 2013 at 09:19:40AM +0200, Andre Oppermann wrote: >> A> On 11.07.2013 09:05, Andriy Gapon wrote: >> A> > kernel: sonewconn: pcb 0xfffffe0047db3930: Listen queue overflow: 193 >> already in >> A> > queue awaiting acceptance >> A> > last message repeated 113 times >> A> > last message repeated 518 times >> A> > last message repeated 2413 times >> A> > last message repeated 2041 times >> A> > last message repeated 1741 times >> A> > last message repeated 1543 times >> A> > last message repeated 1283 times >> A> > last message repeated 1178 times >> A> > last message repeated 1020 times >> A> > ... >> A> > >> A> > What does this messages mean? >> A> >> A> That your server process lagging behind in accepting new connections >> and a >> A> quite a number of them get aborted due to a backlogged listen queue. >> A> >> A> Making the accept queue longer doesn't help, it's user-space that can't >> keep >> A> up with the rate of new incoming connections. >> A> >> A> You can either reduce the rate of new incoming connections, optimize >> your >> A> server process to accept more connections in the same time, or get a >> beefier >> A> machine. >> A> >> A> > Is it really that important to be printed? >> A> >> A> The log messages are at DEBUG level. People probably want to know >> about >> A> their server not keeping up and throwing incoming connection attempts >> away. >> A> >> A> > Finally, why is it not throttled? >> A> >> A> The frequency it happens with is important to determine if this is only >> A> a temporary spike (micro-burst) or persistent condition. >> >> IMO, this should be a single counter accessible via sysctl, with no >> printf(). Those, who need details on whether this is micro-burst or >> persistent condition, can run monitoring software that draws plots. > > > The single counter wouldn't tell you anything because it misses which > socket/accept queue is affected by the overflow. The inpcb pointer > can be cross-refrenced with netstat -a. > > Andriy for example would never have found out about this problem other > than receiving vague user complaints about aborted connection attempts. > Maybe after spending many hours searching for the cause he may have > interfered from endless scrolling in Wireshark that something wasn't > right and blame syncache first. Only later it would emerge that he's > either receiving too many connections or his application is too slow > dealing with incoming connections. > > If you can recommend a suitable and general sysadmin friendly monitoring > software that will point out this problem I'm all ears. the problem with these non-throttled messages is that they often cause thrashing -- you become slighly slow, messages start being generated and your system becomes a lot slower, making it hard to recover. What i usually do is throttle (in the kernel) and count the number of message suppressed. Something like this (in a macro): static int ctr, last_tick; if (ticks - last_tick > suppression_delay) { printf("got this error ... (%d times)\n", ... , ctr); ctr = 0; last_tick = tick; } else { ctr++; } the errors may not be exactly the same, the counter is race_prone (you can make it atomic if you really feel like) but the whole point is to get the idea that something is very wrong, not the exact count or pointer cheers luigi > -- > Andre > > > _______________________________________________ > 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" -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 14:52:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A031EAD1; Thu, 11 Jul 2013 14:52:31 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0E45011C1; Thu, 11 Jul 2013 14:52:30 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r6BEqT8J009058; Thu, 11 Jul 2013 18:52:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r6BEqTQl009057; Thu, 11 Jul 2013 18:52:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 11 Jul 2013 18:52:29 +0400 From: Gleb Smirnoff To: Luigi Rizzo Subject: Re: Listen queue overflow: N already in queue awaiting acceptance Message-ID: <20130711145229.GB8839@glebius.int.ru> References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, Andre Oppermann , Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:52:31 -0000 On Thu, Jul 11, 2013 at 04:49:25PM +0200, Luigi Rizzo wrote: L> >> IMO, this should be a single counter accessible via sysctl, with no L> >> printf(). Those, who need details on whether this is micro-burst or L> >> persistent condition, can run monitoring software that draws plots. L> > L> > L> > The single counter wouldn't tell you anything because it misses which L> > socket/accept queue is affected by the overflow. The inpcb pointer L> > can be cross-refrenced with netstat -a. L> > L> > Andriy for example would never have found out about this problem other L> > than receiving vague user complaints about aborted connection attempts. L> > Maybe after spending many hours searching for the cause he may have L> > interfered from endless scrolling in Wireshark that something wasn't L> > right and blame syncache first. Only later it would emerge that he's L> > either receiving too many connections or his application is too slow L> > dealing with incoming connections. L> > L> > If you can recommend a suitable and general sysadmin friendly monitoring L> > software that will point out this problem I'm all ears. L> L> the problem with these non-throttled messages is that they often L> cause thrashing -- you become slighly slow, messages start being L> generated and your system becomes a lot slower, making it hard L> to recover. L> L> What i usually do is throttle (in the kernel) and count the number of L> message suppressed. Something like this (in a macro): L> L> static int ctr, last_tick; L> if (ticks - last_tick > suppression_delay) { L> printf("got this error ... (%d times)\n", ... , ctr); L> ctr = 0; L> last_tick = tick; L> } else { L> ctr++; L> } L> L> the errors may not be exactly the same, the counter is race_prone L> (you can make it atomic if you really feel like) but the whole point is L> to get the idea that something is very wrong, not the exact count L> or pointer btw, there is ready function for that: ppsratecheck(), already utilized for suppressing some error messages. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 15:05:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4C2422F; Thu, 11 Jul 2013 15:05:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A747912C7; Thu, 11 Jul 2013 15:05:48 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA08475; Thu, 11 Jul 2013 18:05:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxIRG-000N76-Nc; Thu, 11 Jul 2013 18:05:46 +0300 Message-ID: <51DEC992.2040902@FreeBSD.org> Date: Thu, 11 Jul 2013 18:04:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: Listen queue overflow: N already in queue awaiting acceptance References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> In-Reply-To: <51DEC10B.3080409@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:05:49 -0000 on 11/07/2013 17:28 Andre Oppermann said the following: > Andriy for example would never have found out about this problem other > than receiving vague user complaints about aborted connection attempts. > Maybe after spending many hours searching for the cause he may have > interfered from endless scrolling in Wireshark that something wasn't > right and blame syncache first. Only later it would emerge that he's > either receiving too many connections or his application is too slow > dealing with incoming connections. That's true, but OTOH there are many interesting network conditions like excessive packet loss that we don't shout about. The stats are quietly gathered and can be examined with netstat. If a system is properly monitored then such counters are graphed and can trigger alarms. If the system just misbehaves then an administrator can use netstat for inspection. Spamming logs in the case of e.g. DDoS attack is not very helpful, IMO. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 15:06:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 014002D2; Thu, 11 Jul 2013 15:06:13 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by mx1.freebsd.org (Postfix) with ESMTP id DD06D12D7; Thu, 11 Jul 2013 15:06:11 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id 10so6675597lbf.22 for ; Thu, 11 Jul 2013 08:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UPhmRwOHn19shYskv07juhQotEq/qPW+eTBYTZJdRWg=; b=sxW6B6MQ17uHs3S6T/8SAwT69DuaXJG7YuMWJj80/hedMHKfYNUB0+N6ibblaEtIyU N+wfRbIIJlKKhISSvqOdYQSYwrQYYF+smdHq6r6TAX/Upzq5CI+wcwuRQdQYfq+qQAbK gozehMxMUcbmYxraZ+O0UyOsGUUo/sb5pEOHtdHzIXT0CH6to6DEzyxtlxpY+GyhMK+I DQV7G+64/1TO0rtfK829taj9bYRoBzrDBFx74h58AQ/nicI00UgYCr8MJJpDhvGp9skf Ubpm4GT/1ITABBDzBcdNguHzaaLgD6QvrZBKMQX1xGITeZPfEHlqzF6LgnJeEFHGLE+D FvMw== MIME-Version: 1.0 X-Received: by 10.112.144.97 with SMTP id sl1mr17303342lbb.56.1373555170197; Thu, 11 Jul 2013 08:06:10 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.15 with HTTP; Thu, 11 Jul 2013 08:06:10 -0700 (PDT) In-Reply-To: <20130711145229.GB8839@glebius.int.ru> References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> <20130711145229.GB8839@glebius.int.ru> Date: Thu, 11 Jul 2013 17:06:10 +0200 X-Google-Sender-Auth: Kbaw26zWDcGRNthlxgwLwwpVWnE Message-ID: Subject: Re: Listen queue overflow: N already in queue awaiting acceptance From: Luigi Rizzo To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Andre Oppermann , Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:06:13 -0000 On Thu, Jul 11, 2013 at 4:52 PM, Gleb Smirnoff wrote: > On Thu, Jul 11, 2013 at 04:49:25PM +0200, Luigi Rizzo wrote: > L> >> IMO, this should be a single counter accessible via sysctl, with no > L> >> printf(). Those, who need details on whether this is micro-burst or > L> >> persistent condition, can run monitoring software that draws plots. > L> > > L> > > L> > The single counter wouldn't tell you anything because it misses which > L> > socket/accept queue is affected by the overflow. The inpcb pointer > L> > can be cross-refrenced with netstat -a. > L> > > L> > Andriy for example would never have found out about this problem other > L> > than receiving vague user complaints about aborted connection attempts. > L> > Maybe after spending many hours searching for the cause he may have > L> > interfered from endless scrolling in Wireshark that something wasn't > L> > right and blame syncache first. Only later it would emerge that he's > L> > either receiving too many connections or his application is too slow > L> > dealing with incoming connections. > L> > > L> > If you can recommend a suitable and general sysadmin friendly monitoring > L> > software that will point out this problem I'm all ears. > L> > L> the problem with these non-throttled messages is that they often > L> cause thrashing -- you become slighly slow, messages start being > L> generated and your system becomes a lot slower, making it hard > L> to recover. > L> > L> What i usually do is throttle (in the kernel) and count the number of > L> message suppressed. Something like this (in a macro): > L> > L> static int ctr, last_tick; > L> if (ticks - last_tick > suppression_delay) { > L> printf("got this error ... (%d times)\n", ... , ctr); > L> ctr = 0; > L> last_tick = tick; > L> } else { > L> ctr++; > L> } > L> > L> the errors may not be exactly the same, the counter is race_prone > L> (you can make it atomic if you really feel like) but the whole point is > L> to get the idea that something is very wrong, not the exact count > L> or pointer > > btw, there is ready function for that: ppsratecheck(), already utilized > for suppressing some error messages. yes, i think i saw it before. To me, the convenience of the macro is that it can also wrap the declaration of the static variables and the printf. I basically have macros like this (see sys/dev/netmap/netmap_kern.h) RD(max_pps, "printf format ", arguments....) // rate-limited printf ND(same arguments as above) // compiles to no-op so i can quickly add the messages or disable them by simply changing the macro name FWIW the macro in netmap_kern.h does not have the counter of suppressed messages (I just thought about it , but i should probably add it as a feature) cheers luigi > -- > Totus tuus, Glebius. -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 15:43:16 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 229FB847 for ; Thu, 11 Jul 2013 15:43:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7DC1668 for ; Thu, 11 Jul 2013 15:43:15 +0000 (UTC) Received: (qmail 89780 invoked from network); 11 Jul 2013 16:33:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 16:33:48 -0000 Message-ID: <51DED28D.80502@freebsd.org> Date: Thu, 11 Jul 2013 17:43:09 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Listen queue overflow: N already in queue awaiting acceptance References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> <51DEC992.2040902@FreeBSD.org> In-Reply-To: <51DEC992.2040902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:43:16 -0000 On 11.07.2013 17:04, Andriy Gapon wrote: > on 11/07/2013 17:28 Andre Oppermann said the following: >> Andriy for example would never have found out about this problem other >> than receiving vague user complaints about aborted connection attempts. >> Maybe after spending many hours searching for the cause he may have >> interfered from endless scrolling in Wireshark that something wasn't >> right and blame syncache first. Only later it would emerge that he's >> either receiving too many connections or his application is too slow >> dealing with incoming connections. > > That's true, but OTOH there are many interesting network conditions like > excessive packet loss that we don't shout about. The stats are quietly gathered > and can be examined with netstat. If a system is properly monitored then such > counters are graphed and can trigger alarms. If the system just misbehaves then > an administrator can use netstat for inspection. > Spamming logs in the case of e.g. DDoS attack is not very helpful, IMO. I agree with that. I try to make the system behavior more transparent so that even "hidden" problems can be detected easily. This includes adding more of them, like excessive packet loss. This makes FreeBSD a more friendly platform for sysadmins whereas previously people may have quietly move on to some other OS due to such unspecific complications. Most of the TCP related debugging it is protected by net.inet.tcp.log_debug. In this case it's more complicated because the socket code where this happens is protocol agnostic and I can't bond it with TCP. I'm currently looking into a) applying a rate limiter to the message (as suggested by Luigi); and b) add a per-socket accept queue overflow statistic that is visible via netstat. I'll post patches for testing when done. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 15:47:52 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 40633B84; Thu, 11 Jul 2013 15:47:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD4716AB; Thu, 11 Jul 2013 15:47:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6BFlpTu017478; Thu, 11 Jul 2013 15:47:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6BFlpld017477; Thu, 11 Jul 2013 15:47:51 GMT (envelope-from linimon) Date: Thu, 11 Jul 2013 15:47:51 GMT Message-Id: <201307111547.r6BFlpld017477@freefall.freebsd.org> To: nicholas@nicholaswilson.me.uk, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/180468: [request] LOCAL_PEERCRED support for PF_INET X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:47:52 -0000 Old Synopsis: LOCAL_PEERCRED support for PF_INET New Synopsis: [request] LOCAL_PEERCRED support for PF_INET State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Thu Jul 11 15:47:12 UTC 2013 State-Changed-Why: Feature request. Mark as suspended awaiting someone to create patches. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 11 15:47:12 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=180468 From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 15:50:30 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18194DB8; Thu, 11 Jul 2013 15:50:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E628E16D6; Thu, 11 Jul 2013 15:50:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA09231; Thu, 11 Jul 2013 18:50:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxJ8V-000NBP-3e; Thu, 11 Jul 2013 18:50:27 +0300 Message-ID: <51DED40B.5050707@FreeBSD.org> Date: Thu, 11 Jul 2013 18:49:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: Listen queue overflow: N already in queue awaiting acceptance References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> <51DEC992.2040902@FreeBSD.org> <51DED28D.80502@freebsd.org> In-Reply-To: <51DED28D.80502@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:50:30 -0000 on 11/07/2013 18:43 Andre Oppermann said the following: > I'm currently looking into a) applying a rate limiter to the message (as suggested > by Luigi); and b) add a per-socket accept queue overflow statistic that is visible > via netstat. I'll post patches for testing when done. Thank you very much! -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 17:41:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C1808C5 for ; Thu, 11 Jul 2013 17:41:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4601C30 for ; Thu, 11 Jul 2013 17:41:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BA133B983 for ; Thu, 11 Jul 2013 13:41:32 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets Date: Thu, 11 Jul 2013 13:30:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201307101059.r6AAxgjI073347@freefall.freebsd.org> In-Reply-To: <201307101059.r6AAxgjI073347@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307111330.06608.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 11 Jul 2013 13:41:32 -0400 (EDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:41:33 -0000 On Wednesday, July 10, 2013 6:59:42 am linimon@freebsd.org wrote: > Old Synopsis: Bad UDP checksum calc for fragmented packets > New Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Jul 10 10:59:03 UTC 2013 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=180430 Is the problem that the hardware checksum overwrites arbitrary data in the packet (at the location where the UDP header would be)? Also, I've looked at other drivers, and they all look at the CSUM_* flags to determine the right settings. IP fragments will not have CSUM_UDP or CSUM_TCP set, so I think the more correct fix is this: Index: en_tx.c =================================================================== --- en_tx.c (revision 253202) +++ en_tx.c (working copy) @@ -780,8 +780,12 @@ retry: tx_desc->ctrl.srcrb_flags = cpu_to_be32(MLX4_WQE_CTRL_CQ_UPDATE | MLX4_WQE_CTRL_SOLICITED); if (mb->m_pkthdr.csum_flags & (CSUM_IP|CSUM_TCP|CSUM_UDP)) { - tx_desc->ctrl.srcrb_flags |= cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM | - MLX4_WQE_CTRL_TCP_UDP_CSUM); + if (mb->m_pkthdr.csum_flags & CSUM_IP) + tx_desc->ctrl.srcrb_flags |= + cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM); + if (mb->m_pkthdr.csum_flags & (CSUM_TCP|CSUM_UDP)) { + tx_desc->ctrl.srcrb_flags |= + cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM); priv->port_stats.tx_chksum_offload++; } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 17:55:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E2EE7E97 for ; Thu, 11 Jul 2013 17:55:44 +0000 (UTC) (envelope-from mline@ukr.net) Received: from ffe17.ukr.net (ffe17.ukr.net [195.214.192.83]) by mx1.freebsd.org (Postfix) with ESMTP id 9F87B1CD6 for ; Thu, 11 Jul 2013 17:55:43 +0000 (UTC) Received: from mail by ffe17.ukr.net with local ID 1UxKj9-000Bh1-Bd for freebsd-net@freebsd.org; Thu, 11 Jul 2013 20:32:23 +0300 MIME-Version: 1.0 Subject: FreeBSD router problems To: freebsd-net@freebsd.org From: "isp" X-Mailer: freemail.ukr.net 4.0 Message-Id: <16706.1373563943.8842093075575209984@ffe17.ukr.net> Date: Thu, 11 Jul 2013 20:32:23 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:55:45 -0000 Hi! I have a problem with my FreeBSD router, I can't get more than 1 Gbps throught it, but I have 2 Gbps LAGG on it. There are only 27 IPFW rules (NAT+Shaping). IPoE only. lagg0 (VLAN's + shaping) - two 'igb' adapters lagg1 (NAT, tso if off) - two 'em' adapters I tried to switch off dummynet, but it doesn't helps. # uname -a [code]FreeBSD router 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Tue Apr 30 20:02:00 EEST 2013 root@south:/usr/obj/usr/src/sys/ROUTER amd64 # top -aSPHI last pid: 91712; load averages: 2.18, 2.06, 1.97 up 20+22:28:36 17:40:22 120 processes: 7 running, 87 sleeping, 26 waiting CPU 0: 0.0% user, 0.0% nice, 1.6% system, 38.6% interrupt, 59.8% idle CPU 1: 0.0% user, 0.0% nice, 7.1% system, 37.0% interrupt, 55.9% idle CPU 2: 0.0% user, 0.0% nice, 3.9% system, 38.6% interrupt, 57.5% idle CPU 3: 0.0% user, 0.0% nice, 15.7% system, 26.8% interrupt, 57.5% idle Mem: 59M Active, 1102M Inact, 942M Wired, 800M Buf, 5529M Free Swap: 16G Total, 16G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -72 - 0K 448K RUN 1 153:39 72.22% [intr{swi1: netisr 0}] 11 root 155 ki31 0K 64K RUN 1 494.2H 65.19% [idle{idle: cpu1}] 11 root 155 ki31 0K 64K CPU2 2 494.3H 64.65% [idle{idle: cpu2}] 11 root 155 ki31 0K 64K RUN 0 493.3H 63.38% [idle{idle: cpu0}] 11 root 155 ki31 0K 64K CPU3 3 496.4H 62.55% [idle{idle: cpu3}] 12 root -92 - 0K 448K WAIT 2 58:49 9.38% [intr{irq266: igb0:que}] 12 root -92 - 0K 448K WAIT 2 59:32 9.03% [intr{irq271: igb1:que}] 12 root -92 - 0K 448K CPU1 1 59:09 8.94% [intr{irq265: igb0:que}] 12 root -92 - 0K 448K WAIT 3 57:52 8.01% [intr{irq272: igb1:que}] 12 root -92 - 0K 448K WAIT 1 59:32 7.96% [intr{irq270: igb1:que}] 12 root -92 - 0K 448K WAIT 3 55:47 7.81% [intr{irq267: igb0:que}] 12 root -92 - 0K 448K WAIT 0 55:24 7.23% [intr{irq264: igb0:que}] 12 root -92 - 0K 448K WAIT 0 56:57 6.69% [intr{irq269: igb1:que}] 12 root -92 - 0K 448K WAIT 3 203:34 4.74% [intr{irq275: em1:rx 0}] 0 root -92 0 0K 336K - 2 427:03 2.64% [kernel{dummynet}] 0 root -92 0 0K 336K - 3 206:57 2.54% [kernel{em0 que}] 86278 root 20 0 33348K 8588K select 0 8:35 0.54% /usr/local/sbin/snmpd -p /var/run/net_snmpd.pid -r 12 root -92 - 0K 448K WAIT 2 7:56 0.20% [intr{irq276: em1:tx 0}] # cat /etc/sysctl.conf dev.igb.0.rx_processing_limit=4096 dev.igb.1.rx_processing_limit=4096 dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.0.rx_abs_int_delay=4000 dev.em.0.tx_abs_int_delay=4000 dev.em.0.rx_processing_limit=4096 dev.em.1.rx_int_delay=200 dev.em.1.tx_int_delay=200 dev.em.1.rx_abs_int_delay=4000 dev.em.1.tx_abs_int_delay=4000 dev.em.1.rx_processing_limit=4096 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=0 net.inet.ip.redirect=0 net.inet.tcp.delayed_ack=0 net.inet.tcp.recvbuf_max=4194304 net.inet.tcp.sendbuf_max=4194304 net.inet.tcp.sack.enable=0 net.inet.tcp.drop_synfin=1 net.inet.tcp.nolocaltimewait=1 net.inet.ip.ttl=255 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.udp.recvspace=64080 net.inet.ip.rtmaxcache=1024 net.inet.ip.intr_queue_maxlen=5120 kern.ipc.nmbclusters=824288 kern.ipc.maxsockbuf=83886080 kern.ipc.maxsockets=102400 net.inet.tcp.recvspace=95536 net.inet.tcp.sendspace=95536 net.local.stream.recvspace=32768 net.local.stream.sendspace=32768 kern.ipc.somaxconn=32768 net.inet.tcp.maxtcptw=65535 net.inet.ip.fw.one_pass=1 net.inet.ip.fw.dyn_max=65535 net.inet.ip.fw.dyn_buckets=2048 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.ip.fw.dyn_ack_lifetime=120 net.inet.ip.fw.verbose=0 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=65536 net.inet.ip.dummynet.pipe_slot_limit=1000 net.inet.icmp.icmplim=3000 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=0 net.inet.icmp.bmcastecho=0 net.inet.icmp.maskrepl=0 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.point_to_point=0 kern.random.sys.harvest.interrupt=0 net.inet.raw.maxdgram=16384 net.inet.raw.recvspace=16384 net.route.netisr_maxqlen=8192 net.inet.ip.intr_queue_maxlen=10240 net.isr.dispatch=deferred # cat /boot/loader.conf loader_logo="beastie" autoboot_delay=3 geom_mirror_load="YES" hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.rx_process_limit=4096 hw.igb.max_interrupt_rate=32000 hw.igb.num_queues=4 hw.igb.fc_setting=0 hw.igb.lro=0 hw.em.rxd=4096 hw.em.txd=4096 hw.em.rx_process_limit=4096 hw.em.fc_setting=0 dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.0.rx_abs_int_delay=4000 dev.em.0.tx_abs_int_delay=4000 dev.em.1.rx_int_delay=200 dev.em.1.tx_int_delay=200 dev.em.1.rx_abs_int_delay=4000 dev.em.1.tx_abs_int_delay=4000 net.isr.maxthreads=4 net.isr.bindthreads=0 net.inet.tcp.tcbhashsize=32000 net.link.ifqmaxlen=10240 net.isr.defaultqlimit=8192 # vmstat -i interrupt total rate irq20: ehci1 4171628 2 irq21: atapci0 1561194 0 irq22: ehci0+ 2713150 1 cpu0:timer 14622957598 8082 irq264: igb0:que 0 515616328 284 irq265: igb0:que 1 738456087 408 irq266: igb0:que 2 711371660 393 irq267: igb0:que 3 462738813 255 irq268: igb0:link 3 0 irq269: igb1:que 0 656044816 362 irq270: igb1:que 1 546931002 302 irq271: igb1:que 2 617173223 341 irq272: igb1:que 3 644295672 356 irq273: igb1:link 4 0 irq274: em0 557400132 308 irq275: em1:rx 0 424252744 234 irq276: em1:tx 0 708469817 391 irq277: em1:link 2 0 cpu3:timer 678408141 374 cpu1:timer 674674076 372 cpu2:timer 621495291 343 Total 23188731381 12816 # netstat -w1 input (Total) output packets errs idrops bytes packets errs bytes colls 442k 0 0 304M 457k 0 393M 0 449k 0 0 308M 463k 0 395M 0 445k 0 0 304M 461k 0 393M 0 439k 0 0 303M 456k 0 393M 0 434k 0 0 297M 450k 0 387M 0 440k 0 0 301M 456k 0 392M 0 438k 0 0 300M 455k 0 391M 0 # ifconfig lagg0 (internal, 500 VLAN's) lagg0: flags=8843 metric 0 mtu 1500 options=401bb ether a0:36:9f:16:d0:9c media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: igb1 flags=1c laggport: igb0 flags=1c # ifconfig lagg1 - (external, NAT) lagg1: flags=8843 metric 0 mtu 1500 options=4209b ether 00:1e:67:59:ea:89 inet ХХХ.ХХХ.ХХХ.14 netmask 0xffffffe0 broadcast ХХХ.ХХХ.ХХХ.31 inet ХХХ.ХХХ.ХХХ.70 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.70 inet ХХХ.ХХХ.ХХХ.71 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.71 inet ХХХ.ХХХ.ХХХ.72 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.72 inet ХХХ.ХХХ.ХХХ.73 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.73 inet ХХХ.ХХХ.ХХХ.74 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.74 inet ХХХ.ХХХ.ХХХ.75 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.75 inet ХХХ.ХХХ.ХХХ.76 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.76 inet ХХХ.ХХХ.ХХХ.77 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.77 inet ХХХ.ХХХ.ХХХ.78 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.78 inet ХХХ.ХХХ.ХХХ.79 netmask 0xffffffff broadcast ХХХ.ХХХ.ХХХ.79 inet ХХХ.ХХХ.ХХХ.33 netmask 0xfffffff0 broadcast ХХХ.ХХХ.ХХХ.47 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: em1 flags=1c laggport: em0 flags=1c # netstat -w1 -I em0 input (em0) output packets errs idrops bytes packets errs bytes colls 101k 0 0 111M 36k 0 13M 0 101k 0 0 112M 36k 0 13M 0 100k 0 0 112M 37k 0 13M 0 # netstat -w1 -I em1 [code] input (em1) output packets errs idrops bytes packets errs bytes colls 100k 0 0 111M 37k 0 9.1M 0 102k 0 0 113M 39k 0 10M 0 91k 0 0 101M 38k 0 9.7M 0 # netstat -w1 -I igb0 input (igb0) output packets errs idrops bytes packets errs bytes colls 39k 0 0 9.1M 51k 0 57M 0 38k 0 0 9.1M 49k 0 54M 0 39k 0 0 9.4M 51k 0 56M 0 # netstat -w1 -I igb1 input (igb1) output packets errs idrops bytes packets errs bytes colls 36k 0 0 14M 48k 0 56M 0 35k 0 0 14M 50k 0 59M 0 34k 0 0 13M 48k 0 57M 0 # netstat -w1 -I lagg0 input (lagg0) output packets errs idrops bytes packets errs bytes colls 75k 0 0 23M 98k 0 113M 0 73k 0 0 21M 98k 0 113M 0 73k 0 0 23M 98k 0 112M 0 # netstat -w1 -I lagg1 input (lagg1) output packets errs idrops bytes packets errs bytes colls 100k 0 0 112M 74k 0 24M 0 101k 0 0 113M 73k 0 24M 0 102k 0 0 114M 74k 0 24M 0 > From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 18:00:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C94D410E for ; Thu, 11 Jul 2013 18:00:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 909A11D13 for ; Thu, 11 Jul 2013 18:00:31 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id u12so4451090qcx.26 for ; Thu, 11 Jul 2013 11:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hTyoVqIJU78DxwIT24HDLeei1wRlu3Pe/0lgMeUHp5Q=; b=rqGDvTzhekfww0tDkH404r8BsVaMf76PwAT7VlJeSz8y/jDT7vUb3+sjzA6kY55RP5 tbku8lD4BBLZkX1LnvZgzyYTrNJm5XVxTkjL85AzQ1wY7GsLdVsQz1/5asqD6O9Q6I1g opbkXJSzHFVrEQH6vl56r6HDSIwFvjPh6tbMOmKRdK8JkmPUSLSwwk9AX75aVeYA9AaK cUcoEQR67Lj8syvuF4320jdvEGWgcBtpPshcyPUXCnZihhKYE4BH8q1MV+VM0Xbd3F66 B3cMYR44mWFpBn7igYnuEMUsEvyfd4queDtBV088bLJ6Qi0gY1J0LEptk2lo8OgVzszt O9Rg== MIME-Version: 1.0 X-Received: by 10.224.30.74 with SMTP id t10mr25640793qac.2.1373565631116; Thu, 11 Jul 2013 11:00:31 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.49.37.226 with HTTP; Thu, 11 Jul 2013 11:00:31 -0700 (PDT) In-Reply-To: <16706.1373563943.8842093075575209984@ffe17.ukr.net> References: <16706.1373563943.8842093075575209984@ffe17.ukr.net> Date: Thu, 11 Jul 2013 12:00:31 -0600 X-Google-Sender-Auth: OoKzNi79l6rwJxkxINFwhDu0vok Message-ID: Subject: Re: FreeBSD router problems From: Alan Somers To: isp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 18:00:31 -0000 How are you benchmarking it? Each TCP connection only uses one member of a lagg port. So if you want to see > 1 Gbps, you'll need to benchmark with multiple TCP connections. You may also need multiple systems; I don't know the full details of LACP. On Thu, Jul 11, 2013 at 11:32 AM, isp wrote: > > > > Hi! I have a problem with my FreeBSD router, I can't get more than 1 Gbps > throught it, but I have 2 Gbps LAGG on it. There are only 27 IPFW rules > (NAT+Shaping). IPoE only. > lagg0 (VLAN's + shaping) - two 'igb' adapters > lagg1 (NAT, tso if off) - two 'em' adapters > > I tried to switch off dummynet, but it doesn't helps. > > # uname -a > [code]FreeBSD router 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Tue Apr 30 > 20:02:00 EEST 2013 root@south:/usr/obj/usr/src/sys/ROUTER amd64 > > # top -aSPHI > last pid: 91712; load averages: 2.18, 2.06, > 1.97 > up 20+22:28:36 17:40:22 > 120 processes: 7 running, 87 sleeping, 26 waiting > CPU 0: 0.0% user, 0.0% nice, 1.6% system, 38.6% interrupt, 59.8% idle > CPU 1: 0.0% user, 0.0% nice, 7.1% system, 37.0% interrupt, 55.9% idle > CPU 2: 0.0% user, 0.0% nice, 3.9% system, 38.6% interrupt, 57.5% idle > CPU 3: 0.0% user, 0.0% nice, 15.7% system, 26.8% interrupt, 57.5% idle > Mem: 59M Active, 1102M Inact, 942M Wired, 800M Buf, 5529M Free > Swap: 16G Total, 16G Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root -72 - 0K 448K RUN 1 153:39 72.22% [intr{swi1: > netisr 0}] > 11 root 155 ki31 0K 64K RUN 1 494.2H 65.19% [idle{idle: > cpu1}] > 11 root 155 ki31 0K 64K CPU2 2 494.3H 64.65% [idle{idle: > cpu2}] > 11 root 155 ki31 0K 64K RUN 0 493.3H 63.38% [idle{idle: > cpu0}] > 11 root 155 ki31 0K 64K CPU3 3 496.4H 62.55% [idle{idle: > cpu3}] > 12 root -92 - 0K 448K WAIT 2 58:49 9.38% [intr{irq266: > igb0:que}] > 12 root -92 - 0K 448K WAIT 2 59:32 9.03% [intr{irq271: > igb1:que}] > 12 root -92 - 0K 448K CPU1 1 59:09 8.94% [intr{irq265: > igb0:que}] > 12 root -92 - 0K 448K WAIT 3 57:52 8.01% [intr{irq272: > igb1:que}] > 12 root -92 - 0K 448K WAIT 1 59:32 7.96% [intr{irq270: > igb1:que}] > 12 root -92 - 0K 448K WAIT 3 55:47 7.81% [intr{irq267: > igb0:que}] > 12 root -92 - 0K 448K WAIT 0 55:24 7.23% [intr{irq264: > igb0:que}] > 12 root -92 - 0K 448K WAIT 0 56:57 6.69% [intr{irq269: > igb1:que}] > 12 root -92 - 0K 448K WAIT 3 203:34 4.74% [intr{irq275: > em1:rx 0}] > 0 root -92 0 0K 336K - 2 427:03 2.64% > [kernel{dummynet}] > 0 root -92 0 0K 336K - 3 206:57 2.54% [kernel{em0 > que}] > 86278 root 20 0 33348K 8588K select 0 8:35 0.54% > /usr/local/sbin/snmpd -p /var/run/net_snmpd.pid -r > 12 root -92 - 0K 448K WAIT 2 7:56 0.20% [intr{irq276: > em1:tx 0}] > > # cat /etc/sysctl.conf > dev.igb.0.rx_processing_limit=3D4096 > dev.igb.1.rx_processing_limit=3D4096 > dev.em.0.rx_int_delay=3D200 > dev.em.0.tx_int_delay=3D200 > dev.em.0.rx_abs_int_delay=3D4000 > dev.em.0.tx_abs_int_delay=3D4000 > dev.em.0.rx_processing_limit=3D4096 > dev.em.1.rx_int_delay=3D200 > dev.em.1.tx_int_delay=3D200 > dev.em.1.rx_abs_int_delay=3D4000 > dev.em.1.tx_abs_int_delay=3D4000 > dev.em.1.rx_processing_limit=3D4096 > net.inet.ip.forwarding=3D1 > net.inet.ip.fastforwarding=3D1 > net.inet.tcp.blackhole=3D2 > net.inet.udp.blackhole=3D0 > net.inet.ip.redirect=3D0 > net.inet.tcp.delayed_ack=3D0 > net.inet.tcp.recvbuf_max=3D4194304 > net.inet.tcp.sendbuf_max=3D4194304 > net.inet.tcp.sack.enable=3D0 > net.inet.tcp.drop_synfin=3D1 > net.inet.tcp.nolocaltimewait=3D1 > net.inet.ip.ttl=3D255 > net.inet.ip.sourceroute=3D0 > net.inet.ip.accept_sourceroute=3D0 > net.inet.udp.recvspace=3D64080 > net.inet.ip.rtmaxcache=3D1024 > net.inet.ip.intr_queue_maxlen=3D5120 > kern.ipc.nmbclusters=3D824288 > kern.ipc.maxsockbuf=3D83886080 > kern.ipc.maxsockets=3D102400 > net.inet.tcp.recvspace=3D95536 > net.inet.tcp.sendspace=3D95536 > net.local.stream.recvspace=3D32768 > net.local.stream.sendspace=3D32768 > kern.ipc.somaxconn=3D32768 > net.inet.tcp.maxtcptw=3D65535 > net.inet.ip.fw.one_pass=3D1 > net.inet.ip.fw.dyn_max=3D65535 > net.inet.ip.fw.dyn_buckets=3D2048 > net.inet.ip.fw.dyn_syn_lifetime=3D10 > net.inet.ip.fw.dyn_ack_lifetime=3D120 > net.inet.ip.fw.verbose=3D0 > net.inet.ip.dummynet.io_fast=3D1 > net.inet.ip.dummynet.hash_size=3D65536 > net.inet.ip.dummynet.pipe_slot_limit=3D1000 > net.inet.icmp.icmplim=3D3000 > net.inet.icmp.drop_redirect=3D1 > net.inet.icmp.log_redirect=3D0 > net.inet.icmp.bmcastecho=3D0 > net.inet.icmp.maskrepl=3D0 > kern.random.sys.harvest.ethernet=3D0 > kern.random.sys.harvest.point_to_point=3D0 > kern.random.sys.harvest.interrupt=3D0 > net.inet.raw.maxdgram=3D16384 > net.inet.raw.recvspace=3D16384 > net.route.netisr_maxqlen=3D8192 > net.inet.ip.intr_queue_maxlen=3D10240 > net.isr.dispatch=3Ddeferred > > # cat /boot/loader.conf > loader_logo=3D"beastie" > autoboot_delay=3D3 > geom_mirror_load=3D"YES" > hw.igb.rxd=3D4096 > hw.igb.txd=3D4096 > hw.igb.rx_process_limit=3D4096 > hw.igb.max_interrupt_rate=3D32000 > hw.igb.num_queues=3D4 > hw.igb.fc_setting=3D0 > hw.igb.lro=3D0 > hw.em.rxd=3D4096 > hw.em.txd=3D4096 > hw.em.rx_process_limit=3D4096 > hw.em.fc_setting=3D0 > dev.em.0.rx_int_delay=3D200 > dev.em.0.tx_int_delay=3D200 > dev.em.0.rx_abs_int_delay=3D4000 > dev.em.0.tx_abs_int_delay=3D4000 > dev.em.1.rx_int_delay=3D200 > dev.em.1.tx_int_delay=3D200 > dev.em.1.rx_abs_int_delay=3D4000 > dev.em.1.tx_abs_int_delay=3D4000 > net.isr.maxthreads=3D4 > net.isr.bindthreads=3D0 > net.inet.tcp.tcbhashsize=3D32000 > net.link.ifqmaxlen=3D10240 > net.isr.defaultqlimit=3D8192 > > # vmstat -i > interrupt total rate > irq20: ehci1 4171628 2 > irq21: atapci0 1561194 0 > irq22: ehci0+ 2713150 1 > cpu0:timer 14622957598 8082 > irq264: igb0:que 0 515616328 284 > irq265: igb0:que 1 738456087 408 > irq266: igb0:que 2 711371660 393 > irq267: igb0:que 3 462738813 255 > irq268: igb0:link 3 0 > irq269: igb1:que 0 656044816 362 > irq270: igb1:que 1 546931002 302 > irq271: igb1:que 2 617173223 341 > irq272: igb1:que 3 644295672 356 > irq273: igb1:link 4 0 > irq274: em0 557400132 308 > irq275: em1:rx 0 424252744 234 > irq276: em1:tx 0 708469817 391 > irq277: em1:link 2 0 > cpu3:timer 678408141 374 > cpu1:timer 674674076 372 > cpu2:timer 621495291 343 > Total 23188731381 12816 > > # netstat -w1 > input (Total) output > packets errs idrops bytes packets errs bytes colls > 442k 0 0 304M 457k 0 393M 0 > 449k 0 0 308M 463k 0 395M 0 > 445k 0 0 304M 461k 0 393M 0 > 439k 0 0 303M 456k 0 393M 0 > 434k 0 0 297M 450k 0 387M 0 > 440k 0 0 301M 456k 0 392M 0 > 438k 0 0 300M 455k 0 391M 0 > > # ifconfig lagg0 (internal, 500 VLAN's) > lagg0: flags=3D8843 metric 0 mtu > 1500 > options=3D401bb > ether a0:36:9f:16:d0:9c > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: igb1 flags=3D1c > laggport: igb0 flags=3D1c > > # ifconfig lagg1 - (external, NAT) > lagg1: flags=3D8843 metric 0 mtu > 1500 > options=3D4209b > ether 00:1e:67:59:ea:89 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.14 netmask = 0xffffffe0 broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.31 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.70 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.70 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.71 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.71 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.72 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.72 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.73 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.73 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.74 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.74 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.75 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.75 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.76 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.76 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.77 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.77 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.78 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.78 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.79 netmask = 0xffffffff broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.79 > inet =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.33 netmask = 0xfffffff0 broadcast > =D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.=D0=A5=D0=A5=D0=A5.47 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: em1 flags=3D1c > laggport: em0 flags=3D1c > > # netstat -w1 -I em0 > input (em0) output > packets errs idrops bytes packets errs bytes colls > 101k 0 0 111M 36k 0 13M 0 > 101k 0 0 112M 36k 0 13M 0 > 100k 0 0 112M 37k 0 13M 0 > > # netstat -w1 -I em1 > [code] input (em1) output > packets errs idrops bytes packets errs bytes colls > 100k 0 0 111M 37k 0 9.1M 0 > 102k 0 0 113M 39k 0 10M 0 > 91k 0 0 101M 38k 0 9.7M 0 > > # netstat -w1 -I igb0 > input (igb0) output > packets errs idrops bytes packets errs bytes colls > 39k 0 0 9.1M 51k 0 57M 0 > 38k 0 0 9.1M 49k 0 54M 0 > 39k 0 0 9.4M 51k 0 56M 0 > > # netstat -w1 -I igb1 > input (igb1) output > packets errs idrops bytes packets errs bytes colls > 36k 0 0 14M 48k 0 56M 0 > 35k 0 0 14M 50k 0 59M 0 > 34k 0 0 13M 48k 0 57M 0 > > # netstat -w1 -I lagg0 > input (lagg0) output > packets errs idrops bytes packets errs bytes colls > 75k 0 0 23M 98k 0 113M 0 > 73k 0 0 21M 98k 0 113M 0 > 73k 0 0 23M 98k 0 112M 0 > > # netstat -w1 -I lagg1 > input (lagg1) output > packets errs idrops bytes packets errs bytes colls > 100k 0 0 112M 74k 0 24M 0 > 101k 0 0 113M 73k 0 24M 0 > 102k 0 0 114M 74k 0 24M 0 > >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 18:35:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB9295F6; Thu, 11 Jul 2013 18:35:07 +0000 (UTC) (envelope-from mline@ukr.net) Received: from ffe15.ukr.net (ffe15.ukr.net [195.214.192.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9391B1E88; Thu, 11 Jul 2013 18:35:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=4JCDHTH2EnYE+ovlXvsx81sw37z23AoTTBTsXliy/7c=; b=joHRuhbrjDgKpc0c2Q8HZ1SvZqZQqu0kCts6WqfHZkEXe4b6rAiX23haw0fGyTsV497R9nHJ9tD96lVdUKaBOVLYsnj5SO/Zm1TEiAqZeaI1mhXc7rqRTKdgPnZlsthCpsI9eACBdAYgMUjwIIvNBO96C9HkJDmUQyMiQrD0alM=; Received: from mail by ffe15.ukr.net with local ID 1UxLLB-0001TA-5v ; Thu, 11 Jul 2013 21:11:41 +0300 MIME-Version: 1.0 Subject: Re[2]: FreeBSD router problems In-Reply-To: References: <16706.1373563943.8842093075575209984@ffe17.ukr.net> To: "Alan Somers" From: "isp" X-Mailer: freemail.ukr.net 4.0 Message-Id: <3798.1373566301.16193856550018220032@ffe15.ukr.net> Date: Thu, 11 Jul 2013 21:11:41 +0300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 18:35:07 -0000 I have a real network with more than 4 000 users. In normal case, when I have two 1Gbps routers, and I split VLAN's between them total bandwidth if growing up to 1.7 Gbps. --- Incoming mail --- From: "Alan Somers" Date: 11 July 2013, 21:00:41 How are you benchmarking it? Each TCP connection only uses one member of a lagg port. So if you want to see > 1 Gbps, you'll need to benchmark with multiple TCP connections. You may also need multiple systems; I don't know the full details of LACP. On Thu, Jul 11, 2013 at 11:32 AM, isp < mline@ukr.net > wrote: > > > > Hi! I have a problem with my FreeBSD router, I can't get more than 1 Gbps > throught it, but I have 2 Gbps LAGG on it. There are only 27 IPFW rules > (NAT+Shaping). IPoE only. > lagg0 (VLAN's + shaping) - two 'igb' adapters > lagg1 (NAT, tso if off) - two 'em' adapters > > I tried to switch off dummynet, but it doesn't helps. > > # uname -a > [code]FreeBSD router 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Tue Apr 30 > 20:02:00 EEST 2013 root@south:/usr/obj/usr/src/sys/ROUTER amd64 > > # top -aSPHI > last pid: 91712; load averages: 2.18, 2.06, > 1.97 > up 20+22:28:36 17:40:22 > 120 processes: 7 running, 87 sleeping, 26 waiting > CPU 0: 0.0% user, 0.0% nice, 1.6% system, 38.6% interrupt, 59.8% idle > CPU 1: 0.0% user, 0.0% nice, 7.1% system, 37.0% interrupt, 55.9% idle > CPU 2: 0.0% user, 0.0% nice, 3.9% system, 38.6% interrupt, 57.5% idle > CPU 3: 0.0% user, 0.0% nice, 15.7% system, 26.8% interrupt, 57.5% idle > Mem: 59M Active, 1102M Inact, 942M Wired, 800M Buf, 5529M Free > Swap: 16G Total, 16G Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root -72 - 0K 448K RUN 1 153:39 72.22% [intr{swi1: > netisr 0}] > 11 root 155 ki31 0K 64K RUN 1 494.2H 65.19% [idle{idle: > cpu1}] > 11 root 155 ki31 0K 64K CPU2 2 494.3H 64.65% [idle{idle: > cpu2}] > 11 root 155 ki31 0K 64K RUN 0 493.3H 63.38% [idle{idle: > cpu0}] > 11 root 155 ki31 0K 64K CPU3 3 496.4H 62.55% [idle{idle: > cpu3}] > 12 root -92 - 0K 448K WAIT 2 58:49 9.38% [intr{irq266: > igb0:que}] > 12 root -92 - 0K 448K WAIT 2 59:32 9.03% [intr{irq271: > igb1:que}] > 12 root -92 - 0K 448K CPU1 1 59:09 8.94% [intr{irq265: > igb0:que}] > 12 root -92 - 0K 448K WAIT 3 57:52 8.01% [intr{irq272: > igb1:que}] > 12 root -92 - 0K 448K WAIT 1 59:32 7.96% [intr{irq270: > igb1:que}] > 12 root -92 - 0K 448K WAIT 3 55:47 7.81% [intr{irq267: > igb0:que}] > 12 root -92 - 0K 448K WAIT 0 55:24 7.23% [intr{irq264: > igb0:que}] > 12 root -92 - 0K 448K WAIT 0 56:57 6.69% [intr{irq269: > igb1:que}] > 12 root -92 - 0K 448K WAIT 3 203:34 4.74% [intr{irq275: > em1:rx 0}] > 0 root -92 0 0K 336K - 2 427:03 2.64% > [kernel{dummynet}] > 0 root -92 0 0K 336K - 3 206:57 2.54% [kernel{em0 > que}] > 86278 root 20 0 33348K 8588K select 0 8:35 0.54% > /usr/local/sbin/snmpd -p /var/run/net_snmpd.pid -r > 12 root -92 - 0K 448K WAIT 2 7:56 0.20% [intr{irq276: > em1:tx 0}] > > # cat /etc/sysctl.conf > dev.igb.0.rx_processing_limit=4096 > dev.igb.1.rx_processing_limit=4096 > dev.em.0.rx_int_delay=200 > dev.em.0.tx_int_delay=200 > dev.em.0.rx_abs_int_delay=4000 > dev.em.0.tx_abs_int_delay=4000 > dev.em.0.rx_processing_limit=4096 > dev.em.1.rx_int_delay=200 > dev.em.1.tx_int_delay=200 > dev.em.1.rx_abs_int_delay=4000 > dev.em.1.tx_abs_int_delay=4000 > dev.em.1.rx_processing_limit=4096 > net.inet.ip.forwarding=1 > net.inet.ip.fastforwarding=1 > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=0 > net.inet.ip.redirect=0 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.recvbuf_max=4194304 > net.inet.tcp.sendbuf_max=4194304 > net.inet.tcp.sack.enable=0 > net.inet.tcp.drop_synfin=1 > net.inet.tcp.nolocaltimewait=1 > net.inet.ip.ttl=255 > net.inet.ip.sourceroute=0 > net.inet.ip.accept_sourceroute=0 > net.inet.udp.recvspace=64080 > net.inet.ip.rtmaxcache=1024 > net.inet.ip.intr_queue_maxlen=5120 > kern.ipc.nmbclusters=824288 > kern.ipc.maxsockbuf=83886080 > kern.ipc.maxsockets=102400 > net.inet.tcp.recvspace=95536 > net.inet.tcp.sendspace=95536 > net.local.stream.recvspace=32768 > net.local.stream.sendspace=32768 > kern.ipc.somaxconn=32768 > net.inet.tcp.maxtcptw=65535 > net.inet.ip.fw.one_pass=1 > net.inet.ip.fw.dyn_max=65535 > net.inet.ip.fw.dyn_buckets=2048 > net.inet.ip.fw.dyn_syn_lifetime=10 > net.inet.ip.fw.dyn_ack_lifetime=120 > net.inet.ip.fw.verbose=0 > net.inet.ip.dummynet.io_fast=1 > net.inet.ip.dummynet.hash_size=65536 > net.inet.ip.dummynet.pipe_slot_limit=1000 > net.inet.icmp.icmplim=3000 > net.inet.icmp.drop_redirect=1 > net.inet.icmp.log_redirect=0 > net.inet.icmp.bmcastecho=0 > net.inet.icmp.maskrepl=0 > kern.random.sys.harvest.ethernet=0 > kern.random.sys.harvest.point_to_point=0 > kern.random.sys.harvest.interrupt=0 > net.inet.raw.maxdgram=16384 > net.inet.raw.recvspace=16384 > net.route.netisr_maxqlen=8192 > net.inet.ip.intr_queue_maxlen=10240 > net.isr.dispatch=deferred > > # cat /boot/loader.conf > loader_logo="beastie" > autoboot_delay=3 > geom_mirror_load="YES" > hw.igb.rxd=4096 > hw.igb.txd=4096 > hw.igb.rx_process_limit=4096 > hw.igb.max_interrupt_rate=32000 > hw.igb.num_queues=4 > hw.igb.fc_setting=0 > hw.igb.lro=0 > hw.em.rxd=4096 > hw.em.txd=4096 > hw.em.rx_process_limit=4096 > hw.em.fc_setting=0 > dev.em.0.rx_int_delay=200 > dev.em.0.tx_int_delay=200 > dev.em.0.rx_abs_int_delay=4000 > dev.em.0.tx_abs_int_delay=4000 > dev.em.1.rx_int_delay=200 > dev.em.1.tx_int_delay=200 > dev.em.1.rx_abs_int_delay=4000 > dev.em.1.tx_abs_int_delay=4000 > net.isr.maxthreads=4 > net.isr.bindthreads=0 > net.inet.tcp.tcbhashsize=32000 > net.link.ifqmaxlen=10240 > net.isr.defaultqlimit=8192 > > # vmstat -i > interrupt total rate > irq20: ehci1 4171628 2 > irq21: atapci0 1561194 0 > irq22: ehci0+ 2713150 1 > cpu0:timer 14622957598 8082 > irq264: igb0:que 0 515616328 284 > irq265: igb0:que 1 738456087 408 > irq266: igb0:que 2 711371660 393 > irq267: igb0:que 3 462738813 255 > irq268: igb0:link 3 0 > irq269: igb1:que 0 656044816 362 > irq270: igb1:que 1 546931002 302 > irq271: igb1:que 2 617173223 341 > irq272: igb1:que 3 644295672 356 > irq273: igb1:link 4 0 > irq274: em0 557400132 308 > irq275: em1:rx 0 424252744 234 > irq276: em1:tx 0 708469817 391 > irq277: em1:link 2 0 > cpu3:timer 678408141 374 > cpu1:timer 674674076 372 > cpu2:timer 621495291 343 > Total 23188731381 12816 > > # netstat -w1 > input (Total) output > packets errs idrops bytes packets errs bytes colls > 442k 0 0 304M 457k 0 393M 0 > 449k 0 0 308M 463k 0 395M 0 > 445k 0 0 304M 461k 0 393M 0 > 439k 0 0 303M 456k 0 393M 0 > 434k 0 0 297M 450k 0 387M 0 > 440k 0 0 301M 456k 0 392M 0 > 438k 0 0 300M 455k 0 391M 0 > > # ifconfig lagg0 (internal, 500 VLAN's) > lagg0: flags=8843 metric 0 mtu > 1500 > options=401bb > ether a0:36:9f:16:d0:9c > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: igb1 flags=1c > laggport: igb0 flags=1c > > # ifconfig lagg1 - (external, NAT) > lagg1: flags=8843 metric 0 mtu > 1500 > options=4209b > ether 00:1e:67:59:ea:89 > inet ХХХ.ХХХ.ХХХ.14 netmask 0xffffffe0 broadcast > ХХХ.ХХХ.ХХХ.31 > inet ХХХ.ХХХ.ХХХ.70 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.70 > inet ХХХ.ХХХ.ХХХ.71 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.71 > inet ХХХ.ХХХ.ХХХ.72 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.72 > inet ХХХ.ХХХ.ХХХ.73 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.73 > inet ХХХ.ХХХ.ХХХ.74 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.74 > inet ХХХ.ХХХ.ХХХ.75 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.75 > inet ХХХ.ХХХ.ХХХ.76 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.76 > inet ХХХ.ХХХ.ХХХ.77 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.77 > inet ХХХ.ХХХ.ХХХ.78 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.78 > inet ХХХ.ХХХ.ХХХ.79 netmask 0xffffffff broadcast > ХХХ.ХХХ.ХХХ.79 > inet ХХХ.ХХХ.ХХХ.33 netmask 0xfffffff0 broadcast > ХХХ.ХХХ.ХХХ.47 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: em1 flags=1c > laggport: em0 flags=1c > > # netstat -w1 -I em0 > input (em0) output > packets errs idrops bytes packets errs bytes colls > 101k 0 0 111M 36k 0 13M 0 > 101k 0 0 112M 36k 0 13M 0 > 100k 0 0 112M 37k 0 13M 0 > > # netstat -w1 -I em1 > [code] input (em1) output > packets errs idrops bytes packets errs bytes colls > 100k 0 0 111M 37k 0 9.1M 0 > 102k 0 0 113M 39k 0 10M 0 > 91k 0 0 101M 38k 0 9.7M 0 > > # netstat -w1 -I igb0 > input (igb0) output > packets errs idrops bytes packets errs bytes colls > 39k 0 0 9.1M 51k 0 57M 0 > 38k 0 0 9.1M 49k 0 54M 0 > 39k 0 0 9.4M 51k 0 56M 0 > > # netstat -w1 -I igb1 > input (igb1) output > packets errs idrops bytes packets errs bytes colls > 36k 0 0 14M 48k 0 56M 0 > 35k 0 0 14M 50k 0 59M 0 > 34k 0 0 13M 48k 0 57M 0 > > # netstat -w1 -I lagg0 > input (lagg0) output > packets errs idrops bytes packets errs bytes colls > 75k 0 0 23M 98k 0 113M 0 > 73k 0 0 21M 98k 0 113M 0 > 73k 0 0 23M 98k 0 112M 0 > > # netstat -w1 -I lagg1 > input (lagg1) output > packets errs idrops bytes packets errs bytes colls > 100k 0 0 112M 74k 0 24M 0 > 101k 0 0 113M 73k 0 24M 0 > 102k 0 0 114M 74k 0 24M 0 > >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _______________________________________________ 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 Jul 12 08:25:31 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2DA85EB3; Fri, 12 Jul 2013 08:25:31 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE8013B7; Fri, 12 Jul 2013 08:25:29 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r6C8PR7r013421; Fri, 12 Jul 2013 12:25:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r6C8PR9T013420; Fri, 12 Jul 2013 12:25:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 12 Jul 2013 12:25:27 +0400 From: Gleb Smirnoff To: Andre Oppermann Subject: Re: Listen queue overflow: N already in queue awaiting acceptance Message-ID: <20130712082527.GC8839@glebius.int.ru> References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> <51DEC992.2040902@FreeBSD.org> <51DED28D.80502@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <51DED28D.80502@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:25:31 -0000 On Thu, Jul 11, 2013 at 05:43:09PM +0200, Andre Oppermann wrote: A> >> Andriy for example would never have found out about this problem other A> >> than receiving vague user complaints about aborted connection attempts. A> >> Maybe after spending many hours searching for the cause he may have A> >> interfered from endless scrolling in Wireshark that something wasn't A> >> right and blame syncache first. Only later it would emerge that he's A> >> either receiving too many connections or his application is too slow A> >> dealing with incoming connections. A> > A> > That's true, but OTOH there are many interesting network conditions like A> > excessive packet loss that we don't shout about. The stats are quietly gathered A> > and can be examined with netstat. If a system is properly monitored then such A> > counters are graphed and can trigger alarms. If the system just misbehaves then A> > an administrator can use netstat for inspection. A> > Spamming logs in the case of e.g. DDoS attack is not very helpful, IMO. A> A> I agree with that. A> A> I try to make the system behavior more transparent so that even "hidden" problems A> can be detected easily. This includes adding more of them, like excessive packet A> loss. This makes FreeBSD a more friendly platform for sysadmins whereas previously A> people may have quietly move on to some other OS due to such unspecific complications. A> A> Most of the TCP related debugging it is protected by net.inet.tcp.log_debug. In this A> case it's more complicated because the socket code where this happens is protocol A> agnostic and I can't bond it with TCP. A> A> I'm currently looking into a) applying a rate limiter to the message (as suggested A> by Luigi); and b) add a per-socket accept queue overflow statistic that is visible A> via netstat. I'll post patches for testing when done. What about the following generic idea: syslogd periodically queries the kernel about various error counters, and remembers the values. Those, that increased since previous query are logged. This can be implemented in different ways, either syslogd knows all the sysctls, or kernel "pushes" a list of values to syslogd. These are details to be discussed. What do you think about the plan itself? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jul 12 09:42:43 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8B43329 for ; Fri, 12 Jul 2013 09:42:43 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA851A1C for ; Fri, 12 Jul 2013 09:42:43 +0000 (UTC) Received: (qmail 95885 invoked from network); 12 Jul 2013 10:33:06 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Jul 2013 10:33:06 -0000 Message-ID: <51DFCF8A.8090303@freebsd.org> Date: Fri, 12 Jul 2013 11:42:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Listen queue overflow: N already in queue awaiting acceptance References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> <51DEC992.2040902@FreeBSD.org> <51DED28D.80502@freebsd.org> <20130712082527.GC8839@glebius.int.ru> In-Reply-To: <20130712082527.GC8839@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:42:43 -0000 On 12.07.2013 10:25, Gleb Smirnoff wrote: > On Thu, Jul 11, 2013 at 05:43:09PM +0200, Andre Oppermann wrote: > A> >> Andriy for example would never have found out about this problem other > A> >> than receiving vague user complaints about aborted connection attempts. > A> >> Maybe after spending many hours searching for the cause he may have > A> >> interfered from endless scrolling in Wireshark that something wasn't > A> >> right and blame syncache first. Only later it would emerge that he's > A> >> either receiving too many connections or his application is too slow > A> >> dealing with incoming connections. > A> > > A> > That's true, but OTOH there are many interesting network conditions like > A> > excessive packet loss that we don't shout about. The stats are quietly gathered > A> > and can be examined with netstat. If a system is properly monitored then such > A> > counters are graphed and can trigger alarms. If the system just misbehaves then > A> > an administrator can use netstat for inspection. > A> > Spamming logs in the case of e.g. DDoS attack is not very helpful, IMO. > A> > A> I agree with that. > A> > A> I try to make the system behavior more transparent so that even "hidden" problems > A> can be detected easily. This includes adding more of them, like excessive packet > A> loss. This makes FreeBSD a more friendly platform for sysadmins whereas previously > A> people may have quietly move on to some other OS due to such unspecific complications. > A> > A> Most of the TCP related debugging it is protected by net.inet.tcp.log_debug. In this > A> case it's more complicated because the socket code where this happens is protocol > A> agnostic and I can't bond it with TCP. > A> > A> I'm currently looking into a) applying a rate limiter to the message (as suggested > A> by Luigi); and b) add a per-socket accept queue overflow statistic that is visible > A> via netstat. I'll post patches for testing when done. > > What about the following generic idea: syslogd periodically queries the kernel > about various error counters, and remembers the values. Those, that increased since > previous query are logged. > > This can be implemented in different ways, either syslogd knows all the sysctls, > or kernel "pushes" a list of values to syslogd. These are details to be discussed. > > What do you think about the plan itself? I think it generally makes a lot of sense. It would be really good to have a generic way of tracking the history of the various counters, not only error counters, over longer periods with sufficient fine granularity. Tracking individual socket statistics is probably not feasible due the large amount of churn by connections coming and going all the time. In telco equipment we have the ITU G.826/828 "performance" counters which cover a longer period with varying granularity, like 1hr intervals over 7 days, 15 minute intervals over 24 hours, 5 minutes intervals over 4hrs, and 5 second intervals over 15 minutes. In reality not all intervals may be available on all systems but a base set is. I've been dreaming of this ever since I worked a lot with telco equipment in the late 90s and early 2000s. It made debugging persistent and intermittent link and line problems so much easier because we could pinpoint what problem happened at which point in time. The G.826/828 are mostly about link impairments due to errors, with cascading counters for errored, severely errored, and unavailable seconds based on various failure cases. Taking your plan further I suggest the following: a) Adding a new daemon that in various periodic intervals polls all static kernel and interface counters and saves it in a human readable format. For each configurable interval it calculates the delta between start and end showing only the increases. For specific configurable error counters it sends a notice to syslog. b) We extend the interface counters by the standard RMON and other statistics counters as found in the ieee802.1-3 documentation and supported by all (ethernet) NICs for a long time already. With the upcoming ifnet work I'm doing the stack-side foundations will be prepared with the updates to the drivers being done individually. c) For interfaces we introduce the notion of "availability" in the sense of G.826/828 with the severity cascade. These calculations can be made by the new time-series daemon. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jul 12 09:57:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C504548; Fri, 12 Jul 2013 09:57:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D32741AD1; Fri, 12 Jul 2013 09:57:54 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7D9167300A; Fri, 12 Jul 2013 11:53:22 +0200 (CEST) Date: Fri, 12 Jul 2013 11:53:22 +0200 From: Luigi Rizzo To: Gleb Smirnoff Subject: Re: Listen queue overflow: N already in queue awaiting acceptance Message-ID: <20130712095322.GA94049@onelab2.iet.unipi.it> References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> <51DEC992.2040902@FreeBSD.org> <51DED28D.80502@freebsd.org> <20130712082527.GC8839@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130712082527.GC8839@glebius.int.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, Andre Oppermann , Andriy Gapon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:57:55 -0000 On Fri, Jul 12, 2013 at 12:25:27PM +0400, Gleb Smirnoff wrote: > On Thu, Jul 11, 2013 at 05:43:09PM +0200, Andre Oppermann wrote: ... > A> I'm currently looking into a) applying a rate limiter to the message (as suggested > A> by Luigi); and b) add a per-socket accept queue overflow statistic that is visible > A> via netstat. I'll post patches for testing when done. > > What about the following generic idea: syslogd periodically queries the kernel > about various error counters, and remembers the values. Those, that increased since > previous query are logged. > > This can be implemented in different ways, either syslogd knows all the sysctls, > or kernel "pushes" a list of values to syslogd. These are details to be discussed. > > What do you think about the plan itself? good idea in principle as it enables global throttling of messages and reduces the overhead ih the error path. However sounds complex in practice, as counters can be created dynamically (sysctl_add*() and friends), and are spread all over the place and with different methods. So the "pull" model (sysctl performs a scan to request values) will perform poorly. Just think of how expensive is to try and pull all the unchanged counters. Gleb, what is your intended goal ? global throttling ? this can probably be implemented still using the push model, with a variations of the macros I proposed (and some machinery to make sure that messages do not starve because someone else is taking up all the space; that is basically a trivial scheduler) delegating the sprintf to sysctl ? that is harder i believe, because you'd need some way to store the values used to build the message. cheers luigi > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jul 12 19:00:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87648DD2 for ; Fri, 12 Jul 2013 19:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7990A1927 for ; Fri, 12 Jul 2013 19:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6CJ018a073912 for ; Fri, 12 Jul 2013 19:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6CJ01hm073911; Fri, 12 Jul 2013 19:00:01 GMT (envelope-from gnats) Date: Fri, 12 Jul 2013 19:00:01 GMT Message-Id: <201307121900.r6CJ01hm073911@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/179901: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 19:00:01 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/179901: commit references a PR Date: Fri, 12 Jul 2013 18:54:56 +0000 (UTC) Author: trociny Date: Fri Jul 12 18:54:47 2013 New Revision: 253281 URL: http://svnweb.freebsd.org/changeset/base/253281 Log: MFC r252710: In r227207, to fix the issue with possible NULL inp_socket pointer dereferencing, when checking for SO_REUSEPORT option (and SO_REUSEADDR for multicast), INP_REUSEPORT flag was introduced to cache the socket option. It was decided then that one flag would be enough to cache both SO_REUSEPORT and SO_REUSEADDR: when processing SO_REUSEADDR setsockopt(2), it was checked if it was called for a multicast address and INP_REUSEPORT was set accordingly. Unfortunately that approach does not work when setsockopt(2) is called before binding to a multicast address: the multicast check fails and INP_REUSEPORT is not set. Fix this by adding INP_REUSEADDR flag to unconditionally cache SO_REUSEADDR. PR: 179901 Submitted by: Michael Gmelin freebsd grem.de (initial version) Reviewed by: rwatson Approved by: re (kib) Modified: stable/9/sys/netinet/in_pcb.c stable/9/sys/netinet/in_pcb.h stable/9/sys/netinet/ip_output.c stable/9/sys/netinet6/in6_pcb.c stable/9/sys/netinet6/ip6_output.c Directory Properties: stable/9/sys/ (props changed) Modified: stable/9/sys/netinet/in_pcb.c ============================================================================== --- stable/9/sys/netinet/in_pcb.c Fri Jul 12 18:52:33 2013 (r253280) +++ stable/9/sys/netinet/in_pcb.c Fri Jul 12 18:54:47 2013 (r253281) @@ -466,6 +466,23 @@ in_pcb_lport(struct inpcb *inp, struct i return (0); } + +/* + * Return cached socket options. + */ +short +inp_so_options(const struct inpcb *inp) +{ + short so_options; + + so_options = 0; + + if ((inp->inp_flags2 & INP_REUSEPORT) != 0) + so_options |= SO_REUSEPORT; + if ((inp->inp_flags2 & INP_REUSEADDR) != 0) + so_options |= SO_REUSEADDR; + return (so_options); +} #endif /* INET || INET6 */ #ifdef INET @@ -594,8 +611,7 @@ in_pcbbind_setup(struct inpcb *inp, stru if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0)) { + } else if (t && (reuseport & inp_so_options(t)) == 0) { #ifdef INET6 if (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || Modified: stable/9/sys/netinet/in_pcb.h ============================================================================== --- stable/9/sys/netinet/in_pcb.h Fri Jul 12 18:52:33 2013 (r253280) +++ stable/9/sys/netinet/in_pcb.h Fri Jul 12 18:54:47 2013 (r253281) @@ -442,6 +442,7 @@ struct tcpcb * inp_inpcbtotcpcb(struct inpcb *inp); void inp_4tuple_get(struct inpcb *inp, uint32_t *laddr, uint16_t *lp, uint32_t *faddr, uint16_t *fp); +short inp_so_options(const struct inpcb *inp); #endif /* _KERNEL */ @@ -543,6 +544,7 @@ void inp_4tuple_get(struct inpcb *inp, #define INP_PCBGROUPWILD 0x00000004 /* in pcbgroup wildcard list */ #define INP_REUSEPORT 0x00000008 /* SO_REUSEPORT option is set */ #define INP_FREED 0x00000010 /* inp itself is not valid */ +#define INP_REUSEADDR 0x00000020 /* SO_REUSEADDR option is set */ /* * Flags passed to in_pcblookup*() functions. Modified: stable/9/sys/netinet/ip_output.c ============================================================================== --- stable/9/sys/netinet/ip_output.c Fri Jul 12 18:52:33 2013 (r253280) +++ stable/9/sys/netinet/ip_output.c Fri Jul 12 18:54:47 2013 (r253281) @@ -899,13 +899,10 @@ ip_ctloutput(struct socket *so, struct s switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(inp); - if (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - inp->inp_flags2 |= INP_REUSEPORT; - else - inp->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + inp->inp_flags2 |= INP_REUSEADDR; + else + inp->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(inp); error = 0; break; Modified: stable/9/sys/netinet6/in6_pcb.c ============================================================================== --- stable/9/sys/netinet6/in6_pcb.c Fri Jul 12 18:52:33 2013 (r253280) +++ stable/9/sys/netinet6/in6_pcb.c Fri Jul 12 18:54:47 2013 (r253281) @@ -245,8 +245,7 @@ in6_pcbbind(register struct inpcb *inp, if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0)) { + } else if (t && (reuseport & inp_so_options(t)) == 0) { return (EADDRINUSE); } #ifdef INET @@ -267,8 +266,8 @@ in6_pcbbind(register struct inpcb *inp, INP_IPV6PROTO) == (t->inp_vflag & INP_IPV6PROTO)))) return (EADDRINUSE); - } else if (t && (reuseport == 0 || - (t->inp_flags2 & INP_REUSEPORT) == 0) && + } else if (t && + (reuseport & inp_so_options(t)) == 0 && (ntohl(t->inp_laddr.s_addr) != INADDR_ANY || (t->inp_vflag & INP_IPV6PROTO) != 0)) return (EADDRINUSE); Modified: stable/9/sys/netinet6/ip6_output.c ============================================================================== --- stable/9/sys/netinet6/ip6_output.c Fri Jul 12 18:52:33 2013 (r253280) +++ stable/9/sys/netinet6/ip6_output.c Fri Jul 12 18:54:47 2013 (r253281) @@ -1491,13 +1491,10 @@ ip6_ctloutput(struct socket *so, struct switch (sopt->sopt_name) { case SO_REUSEADDR: INP_WLOCK(in6p); - if (IN_MULTICAST(ntohl(in6p->inp_laddr.s_addr))) { - if ((so->so_options & - (SO_REUSEADDR | SO_REUSEPORT)) != 0) - in6p->inp_flags2 |= INP_REUSEPORT; - else - in6p->inp_flags2 &= ~INP_REUSEPORT; - } + if ((so->so_options & SO_REUSEADDR) != 0) + in6p->inp_flags2 |= INP_REUSEADDR; + else + in6p->inp_flags2 &= ~INP_REUSEADDR; INP_WUNLOCK(in6p); error = 0; break; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jul 12 19:10:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94EAE188 for ; Fri, 12 Jul 2013 19:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6D61E19C4 for ; Fri, 12 Jul 2013 19:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6CJA1UV075891 for ; Fri, 12 Jul 2013 19:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6CJA1fA075890; Fri, 12 Jul 2013 19:10:01 GMT (envelope-from gnats) Date: Fri, 12 Jul 2013 19:10:01 GMT Message-Id: <201307121910.r6CJA1fA075890@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/179901: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 19:10:01 -0000 The following reply was made to PR kern/179901; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/179901: commit references a PR Date: Fri, 12 Jul 2013 19:08:41 +0000 (UTC) Author: trociny Date: Fri Jul 12 19:08:33 2013 New Revision: 253282 URL: http://svnweb.freebsd.org/changeset/base/253282 Log: A complete duplication of binding should be allowed if on both new and duplicated sockets a multicast address is bound and either SO_REUSEPORT or SO_REUSEADDR is set. But actually it works for the following combinations: * SO_REUSEPORT is set for the fist socket and SO_REUSEPORT for the new; * SO_REUSEADDR is set for the fist socket and SO_REUSEADDR for the new; * SO_REUSEPORT is set for the fist socket and SO_REUSEADDR for the new; and fails for this: * SO_REUSEADDR is set for the fist socket and SO_REUSEPORT for the new. Fix the last case. PR: 179901 MFC after: 1 month Modified: head/sys/netinet/in_pcb.c head/sys/netinet6/in6_pcb.c Modified: head/sys/netinet/in_pcb.c ============================================================================== --- head/sys/netinet/in_pcb.c Fri Jul 12 18:54:47 2013 (r253281) +++ head/sys/netinet/in_pcb.c Fri Jul 12 19:08:33 2013 (r253282) @@ -554,7 +554,7 @@ in_pcbbind_setup(struct inpcb *inp, stru * and a multicast address is bound on both * new and duplicated sockets. */ - if (so->so_options & SO_REUSEADDR) + if ((so->so_options & (SO_REUSEADDR|SO_REUSEPORT)) != 0) reuseport = SO_REUSEADDR|SO_REUSEPORT; } else if (sin->sin_addr.s_addr != INADDR_ANY) { sin->sin_port = 0; /* yech... */ Modified: head/sys/netinet6/in6_pcb.c ============================================================================== --- head/sys/netinet6/in6_pcb.c Fri Jul 12 18:54:47 2013 (r253281) +++ head/sys/netinet6/in6_pcb.c Fri Jul 12 19:08:33 2013 (r253282) @@ -156,7 +156,7 @@ in6_pcbbind(register struct inpcb *inp, * and a multicast address is bound on both * new and duplicated sockets. */ - if (so->so_options & SO_REUSEADDR) + if ((so->so_options & (SO_REUSEADDR|SO_REUSEPORT)) != 0) reuseport = SO_REUSEADDR|SO_REUSEPORT; } else if (!IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr)) { struct ifaddr *ifa; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jul 13 05:18:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 86B376CF for ; Sat, 13 Jul 2013 05:18:29 +0000 (UTC) (envelope-from trafdev@mail.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id 40C651148 for ; Sat, 13 Jul 2013 05:18:28 +0000 (UTC) Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id CD66C2243CCE for ; Sat, 13 Jul 2013 09:16:41 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=zrjz5Q+QteNa2LVnZo8mtNw4FtK28IEiMEBu9E7pO3I=; b=h8nxY3NLOaxpOOb0otjRhB26KMaQIO0R4/O88MNukrL15IIvKaPt6o/BDxmHVW/4NqNOYcDckxWbuuUbnX66LCKXZRPQvWawV1F2RuQaO1r+vyeofFEPDcnin2YMYWL5ye3fuChrSezekZQP/a9OaQbovMxj2weuheoPRgrkkHk=; Received: from [50.156.108.197] (port=15916 helo=[192.168.1.116]) by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1UxsCA-0001wy-Eu for freebsd-net@freebsd.org; Sat, 13 Jul 2013 09:16:34 +0400 Message-ID: <51E0E2AF.7090404@mail.ru> Date: Fri, 12 Jul 2013 22:16:31 -0700 From: trafdev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: SO_REUSEPORT: strange kernel balancer behaviour Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 05:18:29 -0000 Hello. Could someone help with following problem of SO_REUSEPORT. Created server: int sockd_acceptor_; ... if ((sockd_acceptor_ = socket(PF_INET, SOCK_STREAM, 0)) == -1) { LOG4CXX_ERROR_ERRNO(kLogger, "socket"); return false; } struct sockaddr_in sa_in; memset(&sa_in, 0, sizeof(sa_in)); sa_in.sin_family = AF_INET; sa_in.sin_port = htons(port); sa_in.sin_addr.s_addr = htonl(INADDR_ANY); int yes = 1; if (setsockopt(sockd_acceptor_, SOL_SOCKET, SO_REUSEPORT, &yes, sizeof (yes)) == -1) { LOG4CXX_ERROR_ERRNO(kLogger, "setsockopt"); return false; } if (bind(sockd_acceptor_, (const struct sockaddr*)&sa_in, sizeof(sa_in)) == -1) { LOG4CXX_ERROR_ERRNO(kLogger, "bind"); return false; } if (listen(sockd_acceptor_, listen_backlog) == -1) { LOG4CXX_ERROR_ERRNO(kLogger, "socket listen"); return false; } if (!fcntl_set(sockd_acceptor_, O_NONBLOCK)) return false; Then libev is used as async dispatcher. Server process 1 started, server process 2 started. Everything is good so far, no bind errors. Client started. Server process 1 starts to reply, process 2 gets no requests yet. This happens until process 1 is killed. Immediately after that process 2 starts to respond (gets requests from client). So it looks like there is a deque of processes sharing same port (SO_REUSEPORT) and only one process may respond. Is this an expected behavior? From owner-freebsd-net@FreeBSD.ORG Sat Jul 13 20:30:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF25784A for ; Sat, 13 Jul 2013 20:30:49 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id A14421EED for ; Sat, 13 Jul 2013 20:30:49 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id A9D2C5CDE2; Sat, 13 Jul 2013 22:30:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id lyAkIEvQ7YJA; Sat, 13 Jul 2013 22:30:41 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id C53D95CDDD; Sat, 13 Jul 2013 22:30:41 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 5F20850861; Sat, 13 Jul 2013 22:30:41 +0200 (CEST) Message-ID: <51E1B8F0.5030100@incore.de> Date: Sat, 13 Jul 2013 22:30:40 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: sis(4) flow control References: <51DC1599.8040805@incore.de> <20130710023512.GB2753@michelle.cdnetworks.com> <51DDDDAB.6070100@incore.de> <20130711002557.GA6697@michelle.cdnetworks.com> In-Reply-To: <20130711002557.GA6697@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 20:30:49 -0000 Yonghyeon PYUN wrote: >>> Try attached patch and let me know how it works. >> Thanks for your patch. I will test it on next update of my soekris boxes >> with sis interfaces. Because they are all remote far away this will need >> some time. > > Ok. Make sure to check established link before testing > flow-control. 'ifconfig sis0' will show current media and you > should have something like the following. > ... > media: Ethernet autoselect (100baseTX ) > > If you don't see 'rxpause', re-negotiate flow-control with > 'ifconfig sis0 mediaopt flow'. Because sis(4) (soekris 4801) is not available for me at the moment, I tried with vr(4) (soekris 5501). In production I run both types of boxes with FreeBSD 6 and a simple SETBIT patch to honor RX pause frames. Now I want to go with FreeBSD 8 Stable and eliminate my patch. "ifconfig vr0" gives media: Ethernet autoselect (100baseTX ), therefore I tried (using serial console) "ifconfig vr0 flow" and now "ifconfig vr0" as expected gives media: Ethernet autoselect (100baseTX ), but the interface vr0 hangs. Outgoing packets are ok, but all incoming packets are blocked. In this situation I can give "ifconfig vr0 -mediaopt flowcontrol" and see after "ifconfig vr0" media: Ethernet autoselect (none) status: no carrier and one second later media: Ethernet autoselect (100baseTX ) status: active and interface works correct again. >From console: vr0: port 0xe100-0xe1ff mem 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 vr0: Quirks: 0x2 vr0: Revision: 0x96 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow vr0: Ethernet address: 00:00:24:cb:1e:34 vr0: [ITHREAD] My switch is D-Link DGS-1008D green Ethernet (has support for IEEE 802.3x Flow-Control). On the same switch I have connected two other machines using msk driver (88E8050 and 88E8055) and "ifconfig msk0" gives always media: Ethernet autoselect (1000baseT ) Maybe there is a bug in vr(4) that generates the hang, but why is negotiation of flowcontrol on vr(4) not done at boot time as shown for msk(4) ? If you need more information about the hang let me know. -- Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Sat Jul 13 21:12:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BB30F79 for ; Sat, 13 Jul 2013 21:12:12 +0000 (UTC) (envelope-from support@webmaster.com) Received: from mail129c7.megamailservers.com (mail129c7.megamailservers.com [69.49.98.229]) by mx1.freebsd.org (Postfix) with ESMTP id 10365103A for ; Sat, 13 Jul 2013 21:12:11 +0000 (UTC) X-Authenticated-User: phsorganics.sasktel.net Received: from ADMIN-TOSH (iburst-41-56-198-114.iburst.co.za [41.56.198.114] (may be forged)) (authenticated bits=0) by mail129c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id r6DKvsN0007338 for ; Sat, 13 Jul 2013 17:12:03 -0400 From: "Support" Subject: Update Your Account freebsd-net@freebsd.org To: freebsd-net@freebsd.org MIME-Version: 1.0 Date: Sat, 13 Jul 2013 22:12:03 +0100 Message-ID: <123521600284771471@smtp.sasktel.net> X-CSC: 0 X-CHA: v=1.1 cv=96XV35rJY2WQY5OxKRhqEsdDtyhg8ZjzesoDnFOi/AY= c=1 sm=1 a=kNrzsIpfPgYA:10 a=hJRiTVC464EA:10 a=8nJEP1OIZ-IA:10 a=/qNUHj2ILW+w8qy6N6ODBA==:17 a=6I5d2MoRAAAA:8 a=tAix9fhXAAAA:20 a=HH0FNKo1L8QdWU5EtB0A:9 a=wPNLvfGTeEIA:10 a=3-Yqvn_HVjQA:10 a=SV7veod9ZcQA:10 a=IemxFXisFOkA:10 a=FuB3y5mZK5sA:10 a=jjr//+d8++h3idp61RL+V+rVJvg=:19 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=w0iBcjBkzchDPto8:21 a=/qNUHj2ILW+w8qy6N6ODBA==:117 X-CTCH-Spam: Suspect X-CTCH-RefID: str=0001.0A020208.51E1C2A4.01CA, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=0 Content-Type: text/plain ; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 21:12:12 -0000 Dear User ( freebsd-net@freebsd.org <> ),=20 =20 We are deleting all unused Mail account to create space for new accoun= ts. In order not to be suspended, you will have to update your account= =2E To update your account please: =20 Click here to update your Account information =20= =20 If you fail to update your account this account will be disable and yo= u will not be able to access your email. Thanks for your understanding. Regards, Technica Support.