From owner-freebsd-net@FreeBSD.ORG Sun Apr 18 16:52:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB44D1065673 for ; Sun, 18 Apr 2010 16:52:04 +0000 (UTC) (envelope-from mailman@mimimail15.com) Received: from mimimail15.com (mimimail15.com [207.210.122.189]) by mx1.freebsd.org (Postfix) with ESMTP id B2B218FC1E for ; Sun, 18 Apr 2010 16:52:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mimi; d=madmimi.com; h=Date:From:To:Message-Id:Subject:Mime-Version:Content-Type:List-Unsubscribe; bh=uyWbT4DZbcFdLPcIxADB7Dh9FwE=; b=Wiq3Bz7DWJPzdrCjbABLg+TPtAfLeP6gvLF68UusNL3cdjsRC09AzfQEsOhQlkBE2oC0oSz8piYL LG3bsXOQRz+LGKWxzZ7zUfFSEwFbEcre4RFGWgnWMO5NTZYaxjv5gqVUjlL8Uv+9F9gGZ35lI3Rg 7pUtDqZYEhMyZp/tF8o= Received: from mimimail15.com (75.127.77.161) by mimimail15.com (PowerMTA(TM) v3.5r15) id hpcsb80t3cgp for ; Sun, 18 Apr 2010 12:32:34 -0400 (envelope-from ) Date: Sun, 18 Apr 2010 12:32:34 -0400 From: YNV Records To: freebsd-net@freebsd.org Message-Id: <4bcb34225014a_6741f52493c131367@worker3.gldl.railsmachina.com.tmail> Mime-Version: 1.0 Mimiaid: 958906196 Precendence: bulk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: Quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Ynv Records Presents X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 16:52:04 -0000 Since 2003, the latino community, along with other races, have been enjoy= ing a different type of music thanks to D.R-FLOW. The Group , which is co= mprised of 2 very talented youths , Ezequiel Rodriguez and Manuel Vasquez= , represent Dominicans, in and out of the Dominican Republic in a big way= . Ever since the very beginnings of the group, these bright and talented yo= ung men have received the love and support of, not only the latino popula= tion, but also other races all over the world . Their music reaches from = the streets of New York, to the hearts of many in South America, Europe, = and beyond!!! They are well-recieved where ever they go because of the di= versity of their music, from hip-hop to r&b, fans get the opportunity to = take away a little bit of every genre of music known today. For More info Regarding Drops, jingle Interviews Or For bookings = 413-363-4388 Moe View this email on the web here: http://mim.io/e9d53?fe=3D1&pact=3D958906196 Unsubscribe: http://go.madmimi.com/opt_out?fe=3D1&pact=3D958906196&amx=3D224343125 You can also forward to a friend: http://go.madmimi.com/forward/958906196?amx=3D224343125 YNV Records | Boston Ma 02128 From owner-freebsd-net@FreeBSD.ORG Sun Apr 18 17:09:31 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04B03106566C for ; Sun, 18 Apr 2010 17:09:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 9423A8FC14 for ; Sun, 18 Apr 2010 17:09:30 +0000 (UTC) Received: from c211-30-174-248.carlnfd1.nsw.optusnet.com.au (c211-30-174-248.carlnfd1.nsw.optusnet.com.au [211.30.174.248]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o3IH9PnX024597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2010 03:09:28 +1000 Date: Mon, 19 Apr 2010 03:09:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: sthaug@nethelp.no In-Reply-To: <20100417.145128.74659691.sthaug@nethelp.no> Message-ID: <20100419022830.M3157@delplex.bde.org> References: <20100417.145128.74659691.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: IPv4 vs. IPv6 ping -s inconsistency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 17:09:31 -0000 On Sat, 17 Apr 2010 sthaug@nethelp.no wrote: > For IPv4 I have to be root to ping with a payload larger than 56 bytes: > > sthaug@lab1% ping -s 1472 ftp.funet.fi > ping: packet size too large: 1472 > 56: Operation not permitted > > However, for IPv6 the corresponding operation works just fine: > > sthaug@lab1% ping6 -s 1452 -m ftp.funet.fi > PING6(1500=40+8+1452 bytes) 2001:8c0:8b00:1::2 --> 2001:708:10:9::20:2 > 1460 bytes from 2001:708:10:9::20:2, icmp_seq=0 hlim=57 time=15.730 ms > 1460 bytes from 2001:708:10:9::20:2, icmp_seq=1 hlim=57 time=15.770 ms > > I find this highly inconsistent. My *personal* preference would be to > remove the IPv4 check. Alternatively, the IPv6 ping should be changed > to have the same limitation as the IPv4 ping. This is bitrot in ping6. It was cloned from ping before the check was added to the latter. > I realize that the IPv4 limitation is there to make it *slightly* > more difficult to use FreeBSD boxes to perform DoS attacks and the > like. Personally I believe this is misguided, since there are plenty > of other ways to send large (interface MTU) packets. I tend to agree. The restrictions in (at least) plain ping on -i and to a lesser extent -f and -l are even sillier. On a non-slow machine you can send packets much faster than with ping -i 0.001 by using separate ping processes with -c 1, and as a side benefit to this denial of service the separate processes take more CPU too. The flood on the target is thus not limited by -i accept on slow machine. The lower hard-coded limit of 1 millisecond for root is also gratuitous. Granularly of kernel timers normally makes this limit impossible for ping to reach, but this depends on the kernel configuration. -f and -l can flood the target better than -i, so restricting them is reasonable. Note that -f doesn't actually flood. It sends packets as fast as they come back, or every 10 msec, whichever is more often. Once every 10 msec may have been a flood for 1 MBps ethernet, but it no longer is. Also, timer granularity prevents delivering a packet precisely every 10 msec. I think the imprecision was a factor of 2 with HZ = 100 and is still 10% with the excessively high default HZ of 100. In practice, the target usually responds in much less than 10 msec so the flood is limited by the target response time and local buffering and interrupt moderation delays (which can be significant). -l can actually flood, since it never waits. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 04:58:29 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57284106564A; Mon, 19 Apr 2010 04:58:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED338FC14; Mon, 19 Apr 2010 04:58:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3J4wTWZ080792; Mon, 19 Apr 2010 04:58:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3J4wTkt080788; Mon, 19 Apr 2010 04:58:29 GMT (envelope-from linimon) Date: Mon, 19 Apr 2010 04:58:29 GMT Message-Id: <201004190458.o3J4wTkt080788@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145728: [lagg] Stops working lagg between two servers. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 04:58:29 -0000 Old Synopsis: Stops working lagg between two servers. New Synopsis: [lagg] Stops working lagg between two servers. Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 04:57:52 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145728 From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 07:18:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A162106564A; Mon, 19 Apr 2010 07:18:56 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F96A8FC12; Mon, 19 Apr 2010 07:18:55 +0000 (UTC) Received: by wyf28 with SMTP id 28so997652wyf.13 for ; Mon, 19 Apr 2010 00:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=jP596AHsfN6CO6RNWXTRvEMmD1zSCM4hDuOhFkPI/Tw=; b=Z5aitRIVrBw11B3jORk4zyknJPoRnX1Hv0LKi8eCm4SgIPDhG22ecVKQrO1rGwTbKg /xxlQf9PrfvDl/H2//Jmh8JlOStYksj8esMnzBUY7Oiaj9ng3VXgOjQ/tUAznvnPULEU HLRl5GrEnOEgZQ4lVrl0FV3KpRICCV9QTgNQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tLVC+Ij4z8MsE/jWLvaRf9IiUN9zNtnF2IQu4RnwZsqN9nWX57k5qa2KnrP+U/c/CX sVY3vvBAsacuQLEaA3r2wzetT8E6pgjlbaFJKn7jdxisuoALMlNzxrEVBQx9gskieGju DKrQtV8RPY8a4glnqzVONKnp/SXGIPbs1UOCA= MIME-Version: 1.0 Received: by 10.216.13.7 with HTTP; Sun, 18 Apr 2010 23:53:38 -0700 (PDT) In-Reply-To: <4B28F841.1070900@skylinetele.com> References: <4B28F841.1070900@skylinetele.com> Date: Mon, 19 Apr 2010 09:53:38 +0300 Received: by 10.216.170.147 with SMTP id p19mr6484897wel.129.1271660019425; Sun, 18 Apr 2010 23:53:39 -0700 (PDT) Message-ID: From: Marin Atanasov To: "Prokofiev S.P." Content-Type: multipart/mixed; boundary=0016e65a1074bba2380484916b22 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Qing Li Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 07:18:56 -0000 --0016e65a1074bba2380484916b22 Content-Type: text/plain; charset=ISO-8859-1 Hi, I was setting up mpd5 from ports, but this proxy-arp issue still exists in 8.0. > uname -r 8.0-RELEASE-p2 I've attached the output from the mpd5 daemon, where you can still see that the issue is relevant. I've also tried to apply the patch, but it's no longer on that location. Something else to add - I've a dns server running on the same machine that mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp issue, but after a couple of start/stops of mpd5 the name resolving from the gateway machine is not possible, all other systems from the internal network are able to use the dns server on the gateway, but the gateway itself cannot. Restart of named, doesn't help either, so I had to completely reboot the machine, so that arp entries are flushed as well. Could you please have a look at the issue? If you need some additional information, please let me know. Regards, Marin On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. wrote: > Thank you ! > The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with > mpd5). > > Please, somebody fix the bug kern/141285... > > > Li, Qing wrote: > >> Hi, >> >> Recently there have been several reports regarding issues with ppp, mpd5 >> and proxy-arp configuration over the ppp links. I read through the >> various postings and the problems seem to be: >> >> 1. Unable to add proxy-arp entries for the remote ppp clients. >> >> 2. Log showing "ifa_add_loopback_route: insertion failed" causing some >> userland applications to fail. >> >> May I ask that you try applying patch >> >> http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff >> >> and report back if the patch fixes your problems. And if not, please >> describe what additional issues you are having. >> >> Thanks, >> >> -- Qing >> >> >> _______________________________________________ >> 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-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org --0016e65a1074bba2380484916b22 Content-Type: text/plain; charset=US-ASCII; name="mpd-daemon.txt" Content-Disposition: attachment; filename="mpd-daemon.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g86xilo30 IyAvdXNyL2xvY2FsL3NiaW4vbXBkNQ0KTXVsdGktbGluayBQUFAgZGFlbW9uIGZvciBGcmVlQlNE DQogDQpwcm9jZXNzIDIyOTUgc3RhcnRlZCwgdmVyc2lvbiA1LjUgKHJvb3RAZG9tYWluIDAyOjIx IDE3LUFwci0yMDEwKQ0KVXNhZ2U6IHNldCB1c2VyIHtuYW1lfSB7cGFzc3dvcmR9IFt7cHJpdn1d DQpDT05TT0xFOiBsaXN0ZW5pbmcgb24gMTI3LjAuMC4xIDUwMDUNCndlYjogbGlzdGVuaW5nIG9u IDAuMC4wLjAgNTAwNg0KUFBUUDogd2FpdGluZyBmb3IgY29ubmVjdGlvbiBvbiA8ZXh0ZXJuYWwt aXAtaGVyZT4gMTcyMw0KW0xdIFtMLTFdIEFjY2VwdGluZyBQUFRQIGNvbm5lY3Rpb24NCltMLTFd IExpbms6IE9QRU4gZXZlbnQNCltMLTFdIExDUDogT3BlbiBldmVudA0KW0wtMV0gTENQOiBzdGF0 ZSBjaGFuZ2UgSW5pdGlhbCAtLT4gU3RhcnRpbmcNCltMLTFdIExDUDogTGF5ZXJTdGFydA0KW0wt MV0gUFBUUDogYXR0YWNoaW5nIHRvIHBlZXIncyBvdXRnb2luZyBjYWxsDQpbTC0xXSBMaW5rOiBV UCBldmVudA0KW0wtMV0gTENQOiBVcCBldmVudA0KW0wtMV0gTENQOiBzdGF0ZSBjaGFuZ2UgU3Rh cnRpbmcgLS0+IFJlcS1TZW50DQpbTC0xXSBMQ1A6IFNlbmRDb25maWdSZXEgIzENCltMLTFdICAg QUNGQ09NUA0KW0wtMV0gICBQUk9UT0NPTVANCltMLTFdICAgTVJVIDE1MDANCltMLTFdICAgTUFH SUNOVU0gMTAyYzRkMjINCltMLTFdICAgQVVUSFBST1RPIENIQVAgTVNPRlR2Mg0KW0wtMV0gICBN UCBNUlJVIDIwNDgNCltMLTFdICAgTVAgU0hPUlRTRVENCltMLTFdICAgRU5EUE9JTlRESVNDIFs4 MDIuMV0gMDAgMTAgZGMgMTAgNTUgM2YNCltMLTFdIExDUDogcmVjJ2QgQ29uZmlndXJlIFJlamVj dCAjMSAoUmVxLVNlbnQpDQpbTC0xXSAgIE1QIE1SUlUgMjA0OA0KW0wtMV0gICBNUCBTSE9SVFNF UQ0KW0wtMV0gICBFTkRQT0lOVERJU0MgWzgwMi4xXSAwMCAxMCBkYyAxMCA1NSAzZg0KW0wtMV0g TENQOiBTZW5kQ29uZmlnUmVxICMyDQpbTC0xXSAgIEFDRkNPTVANCltMLTFdICAgUFJPVE9DT01Q DQpbTC0xXSAgIE1SVSAxNTAwDQpbTC0xXSAgIE1BR0lDTlVNIDEwMmM0ZDIyDQpbTC0xXSAgIEFV VEhQUk9UTyBDSEFQIE1TT0ZUdjINCltMLTFdIExDUDogcmVjJ2QgQ29uZmlndXJlIEFjayAjMiAo UmVxLVNlbnQpDQpbTC0xXSAgIEFDRkNPTVANCltMLTFdICAgUFJPVE9DT01QDQpbTC0xXSAgIE1S VSAxNTAwDQpbTC0xXSAgIE1BR0lDTlVNIDEwMmM0ZDIyDQpbTC0xXSAgIEFVVEhQUk9UTyBDSEFQ IE1TT0ZUdjINCltMLTFdIExDUDogc3RhdGUgY2hhbmdlIFJlcS1TZW50IC0tPiBBY2stUmN2ZA0K W0wtMV0gTENQOiByZWMnZCBDb25maWd1cmUgUmVxdWVzdCAjMSAoQWNrLVJjdmQpDQpbTC0xXSAg IE1SVSAxNDAwDQpbTC0xXSAgIE1BR0lDTlVNIDdmZTU3NDRkDQpbTC0xXSAgIFBST1RPQ09NUA0K W0wtMV0gICBBQ0ZDT01QDQpbTC0xXSAgIENBTExCQUNLIDYNCltMLTFdIExDUDogU2VuZENvbmZp Z1JlaiAjMQ0KW0wtMV0gICBDQUxMQkFDSyA2DQpbTC0xXSBMQ1A6IHJlYydkIENvbmZpZ3VyZSBS ZXF1ZXN0ICMyIChBY2stUmN2ZCkNCltMLTFdICAgTVJVIDE0MDANCltMLTFdICAgTUFHSUNOVU0g N2ZlNTc0NGQNCltMLTFdICAgUFJPVE9DT01QDQpbTC0xXSAgIEFDRkNPTVANCltMLTFdIExDUDog U2VuZENvbmZpZ0FjayAjMg0KW0wtMV0gICBNUlUgMTQwMA0KW0wtMV0gICBNQUdJQ05VTSA3ZmU1 NzQ0ZA0KW0wtMV0gICBQUk9UT0NPTVANCltMLTFdICAgQUNGQ09NUA0KW0wtMV0gTENQOiBzdGF0 ZSBjaGFuZ2UgQWNrLVJjdmQgLS0+IE9wZW5lZA0KW0wtMV0gTENQOiBhdXRoOiBwZWVyIHdhbnRz IG5vdGhpbmcsIEkgd2FudCBDSEFQDQpbTC0xXSBDSEFQOiBzZW5kaW5nIENIQUxMRU5HRSAjMSBs ZW46IDIxDQpbTC0xXSBMQ1A6IExheWVyVXANCltMLTFdIExDUDogcmVjJ2QgSWRlbnQgIzMgKE9w ZW5lZCkNCltMLTFdICAgTUVTRzogTVNSQVNWNS4xMA0KW0wtMV0gTENQOiByZWMnZCBJZGVudCAj NCAoT3BlbmVkKQ0KW0wtMV0gICBNRVNHOiBNU1JBUy0wLVRTVU5BTUkNCltMLTFdIENIQVA6IHJl YydkIFJFU1BPTlNFICMxIGxlbjogNjENCltMLTFdICAgTmFtZTogIm1yYXRlc3QiDQpbTC0xXSBB VVRIOiBUcnlpbmcgSU5URVJOQUwNCltMLTFdIEFVVEg6IElOVEVSTkFMIHJldHVybmVkOiB1bmRl ZmluZWQNCltMLTFdIENIQVA6IEF1dGggcmV0dXJuIHN0YXR1czogdW5kZWZpbmVkDQpbTC0xXSBD SEFQOiBSZXNwb25zZSBpcyB2YWxpZA0KW0wtMV0gQ0hBUDogUmVwbHkgbWVzc2FnZTogUz04QkUz MDVGMDhGQkFFQjRFODAxQjYyMDEwMzdCNEI0QUVCNzZBNzNCDQpbTC0xXSBDSEFQOiBzZW5kaW5n IFNVQ0NFU1MgIzEgbGVuOiA0Ng0KW0wtMV0gTENQOiBhdXRob3JpemF0aW9uIHN1Y2Nlc3NmdWwN CltMLTFdIExpbms6IE1hdGNoZWQgYWN0aW9uICdidW5kbGUgIkIiICIiJw0KW0wtMV0gQ3JlYXRp bmcgbmV3IGJ1bmRsZSB1c2luZyB0ZW1wbGF0ZSAiQiIuDQpbQi0xXSBCdW5kbGU6IEludGVyZmFj ZSBuZzAgY3JlYXRlZA0KW0wtMV0gTGluazogSm9pbiBidW5kbGUgIkItMSINCltCLTFdIEJ1bmRs ZTogU3RhdHVzIHVwZGF0ZTogdXAgMSBsaW5rLCB0b3RhbCBiYW5kd2lkdGggNjQwMDAgYnBzDQpb Qi0xXSBJUENQOiBPcGVuIGV2ZW50DQpbQi0xXSBJUENQOiBzdGF0ZSBjaGFuZ2UgSW5pdGlhbCAt LT4gU3RhcnRpbmcNCltCLTFdIElQQ1A6IExheWVyU3RhcnQNCltCLTFdIENDUDogT3BlbiBldmVu dA0KW0ItMV0gQ0NQOiBzdGF0ZSBjaGFuZ2UgSW5pdGlhbCAtLT4gU3RhcnRpbmcNCltCLTFdIEND UDogTGF5ZXJTdGFydA0KW0ItMV0gSVBDUDogVXAgZXZlbnQNCltCLTFdIElQQ1A6IEdvdCBJUCAx MC4xLjE2LjUwIGZyb20gcG9vbCAicG9vbDEiIGZvciBwZWVyDQpbQi0xXSBJUENQOiBzdGF0ZSBj aGFuZ2UgU3RhcnRpbmcgLS0+IFJlcS1TZW50DQpbQi0xXSBJUENQOiBTZW5kQ29uZmlnUmVxICMx DQpbQi0xXSAgIElQQUREUiA8ZXh0ZXJuYWwtaXAtaGVyZT4NCltCLTFdICAgQ09NUFBST1RPIFZK Q09NUCwgMTYgY29tcC4gY2hhbm5lbHMsIG5vIGNvbXAtY2lkDQpbQi0xXSBDQ1A6IFVwIGV2ZW50 DQpbQi0xXSBDQ1A6IHN0YXRlIGNoYW5nZSBTdGFydGluZyAtLT4gUmVxLVNlbnQNCltCLTFdIEND UDogU2VuZENvbmZpZ1JlcSAjMQ0KW0ItMV0gICBNUFBDDQpbQi0xXSAgICAgMHgwMTAwMDA2MDpN UFBFKDQwLCAxMjggYml0cyksIHN0YXRlbGVzcw0KW0ItMV0gQ0NQOiByZWMnZCBDb25maWd1cmUg UmVxdWVzdCAjNSAoUmVxLVNlbnQpDQpbQi0xXSAgIE1QUEMNCltCLTFdICAgICAweDAxMDAwMGUx Ok1QUEMsIE1QUEUoNDAsIDU2LCAxMjggYml0cyksIHN0YXRlbGVzcw0KW0ItMV0gQ0NQOiBTZW5k Q29uZmlnTmFrICM1DQpbQi0xXSAgIE1QUEMNCltCLTFdICAgICAweDAxMDAwMDQwOk1QUEUoMTI4 IGJpdHMpLCBzdGF0ZWxlc3MNCltCLTFdIElQQ1A6IHJlYydkIENvbmZpZ3VyZSBSZXF1ZXN0ICM2 IChSZXEtU2VudCkNCltCLTFdICAgSVBBRERSIDAuMC4wLjANCltCLTFdICAgICBOQUtpbmcgd2l0 aCAxMC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAwLjAuMC4wDQpbQi0xXSAgICAgTkFLaW5nIHdp dGggMTAuMS4xNi4xDQpbQi0xXSAgIFBSSU5CTlMgMC4wLjAuMA0KW0ItMV0gICBTRUNETlMgMC4w LjAuMA0KW0ItMV0gICBTRUNOQk5TIDAuMC4wLjANCltCLTFdIElQQ1A6IFNlbmRDb25maWdSZWog IzYNCltCLTFdICAgUFJJTkJOUyAwLjAuMC4wDQpbQi0xXSAgIFNFQ0ROUyAwLjAuMC4wDQpbQi0x XSAgIFNFQ05CTlMgMC4wLjAuMA0KW0ItMV0gSVBDUDogcmVjJ2QgQ29uZmlndXJlIFJlamVjdCAj MSAoUmVxLVNlbnQpDQpbQi0xXSAgIENPTVBQUk9UTyBWSkNPTVAsIDE2IGNvbXAuIGNoYW5uZWxz LCBubyBjb21wLWNpZA0KW0ItMV0gSVBDUDogU2VuZENvbmZpZ1JlcSAjMg0KW0ItMV0gICBJUEFE RFIgPGV4dGVybmFsLWlwLWhlcmU+DQpbQi0xXSBDQ1A6IHJlYydkIENvbmZpZ3VyZSBOYWsgIzEg KFJlcS1TZW50KQ0KW0ItMV0gICBNUFBDDQpbQi0xXSAgICAgMHgwMTAwMDA0MDpNUFBFKDEyOCBi aXRzKSwgc3RhdGVsZXNzDQpbQi0xXSBDQ1A6IFNlbmRDb25maWdSZXEgIzINCltCLTFdICAgTVBQ Qw0KW0ItMV0gICAgIDB4MDEwMDAwNDA6TVBQRSgxMjggYml0cyksIHN0YXRlbGVzcw0KW0ItMV0g Q0NQOiByZWMnZCBDb25maWd1cmUgUmVxdWVzdCAjNyAoUmVxLVNlbnQpDQpbQi0xXSAgIE1QUEMN CltCLTFdICAgICAweDAxMDAwMDQwOk1QUEUoMTI4IGJpdHMpLCBzdGF0ZWxlc3MNCltCLTFdIEND UDogU2VuZENvbmZpZ0FjayAjNw0KW0ItMV0gICBNUFBDDQpbQi0xXSAgICAgMHgwMTAwMDA0MDpN UFBFKDEyOCBiaXRzKSwgc3RhdGVsZXNzDQpbQi0xXSBDQ1A6IHN0YXRlIGNoYW5nZSBSZXEtU2Vu dCAtLT4gQWNrLVNlbnQNCltCLTFdIElQQ1A6IHJlYydkIENvbmZpZ3VyZSBSZXF1ZXN0ICM4IChS ZXEtU2VudCkNCltCLTFdICAgSVBBRERSIDAuMC4wLjANCltCLTFdICAgICBOQUtpbmcgd2l0aCAx MC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAwLjAuMC4wDQpbQi0xXSAgICAgTkFLaW5nIHdpdGgg MTAuMS4xNi4xDQpbQi0xXSBJUENQOiBTZW5kQ29uZmlnTmFrICM4DQpbQi0xXSAgIElQQUREUiAx MC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAxMC4xLjE2LjENCltCLTFdIElQQ1A6IHJlYydkIENv bmZpZ3VyZSBBY2sgIzIgKFJlcS1TZW50KQ0KW0ItMV0gICBJUEFERFIgPGV4dGVybmFsLWlwLWhl cmU+DQpbQi0xXSBJUENQOiBzdGF0ZSBjaGFuZ2UgUmVxLVNlbnQgLS0+IEFjay1SY3ZkDQpbQi0x XSBDQ1A6IHJlYydkIENvbmZpZ3VyZSBBY2sgIzIgKEFjay1TZW50KQ0KW0ItMV0gICBNUFBDDQpb Qi0xXSAgICAgMHgwMTAwMDA0MDpNUFBFKDEyOCBiaXRzKSwgc3RhdGVsZXNzDQpbQi0xXSBDQ1A6 IHN0YXRlIGNoYW5nZSBBY2stU2VudCAtLT4gT3BlbmVkDQpbQi0xXSBDQ1A6IExheWVyVXANCltC LTFdIENDUDogQ29tcHJlc3MgdXNpbmc6IG1wcGMgKE1QUEUoMTI4IGJpdHMpLCBzdGF0ZWxlc3Mp DQpbQi0xXSBDQ1A6IERlY29tcHJlc3MgdXNpbmc6IG1wcGMgKE1QUEUoMTI4IGJpdHMpLCBzdGF0 ZWxlc3MpDQpbQi0xXSBJUENQOiByZWMnZCBDb25maWd1cmUgUmVxdWVzdCAjOSAoQWNrLVJjdmQp DQpbQi0xXSAgIElQQUREUiAxMC4xLjE2LjUwDQpbQi0xXSAgICAgMTAuMS4xNi41MCBpcyBPSw0K W0ItMV0gICBQUklETlMgMTAuMS4xNi4xDQpbQi0xXSBJUENQOiBTZW5kQ29uZmlnQWNrICM5DQpb Qi0xXSAgIElQQUREUiAxMC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAxMC4xLjE2LjENCltCLTFd IElQQ1A6IHN0YXRlIGNoYW5nZSBBY2stUmN2ZCAtLT4gT3BlbmVkDQpbQi0xXSBJUENQOiBMYXll clVwDQpbQi0xXSAgIDxleHRlcm5hbC1pcC1oZXJlPiAtPiAxMC4xLjE2LjUwDQpbQi0xXSBzeXN0 ZW06IGNvbW1hbmQgIi91c3Ivc2Jpbi9hcnAiIHJldHVybmVkIDI1Ng0KW0ItMV0gSUZBQ0U6IFVw IGV2ZW50DQo= --0016e65a1074bba2380484916b22-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 11:07:04 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 688DB1065675 for ; Mon, 19 Apr 2010 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 563858FC15 for ; Mon, 19 Apr 2010 11:07:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3JB74ZP034168 for ; Mon, 19 Apr 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3JB73ci034166 for freebsd-net@FreeBSD.org; Mon, 19 Apr 2010 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Apr 2010 11:07:03 GMT Message-Id: <201004191107.o3JB73ci034166@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 11:07:04 -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/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system 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 kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. o kern/144494 net [ixgbe] ixgbe driver not built as module f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun 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/143595 net [wpi] [panic] Creating virtual interface over wpi0 in 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/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir 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 o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon 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 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on 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/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/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/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e 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/137317 net [tcp] logs full of syncache problems o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re 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/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/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. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/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/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/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/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 408 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 13:50:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 527E2106566C for ; Mon, 19 Apr 2010 13:50:05 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id F390A8FC0C for ; Mon, 19 Apr 2010 13:50:04 +0000 (UTC) Received: from [127.0.0.1] ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Mon, 19 Apr 2010 09:50:05 -0400 X-WatchGuard-Mail-Exception: Allow Message-ID: <4BCC5F89.3000907@greatbaysoftware.com> Date: Mon, 19 Apr 2010 09:50:01 -0400 From: Charles Owens MIME-Version: 1.0 To: freebsd-net@freebsd.org X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Seth Jeacopello Subject: attempting local merge of e1000 from RELENG_8 to RELENG_8_0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 13:50:05 -0000 Hello, We're trying to backport the latest e1000 driver from the -STABLE branch into our internal release that is based around the 8.0 security branch (RELENG_8_0). Specifically, we see some flakiness with the igb driver on one of our hardware platforms that we're hoping the new driver will address. Our initial test with this custom kernel seems not quite right, and I think a suggestion or two from someone more familiar with this code could be a big help. I merged in the driver code last Wednesday... in addition to all files in sys/dev/e1000 I also brought in changes to these files: * sys/conf/files * sys/net/if.c * sys/net/if.h * sys/net/if_var.h * sys/net80211/ieee80211_ioctl.c * sys/sys/priv.h * sys/sys/sockio.h More or less this amounts to this (admittedly simplistic) approach: bring in just enough to get it to compile. Most changes were brought in from -STABLE in full (so each affected file in our source tree now matches STABLE, as of last Wednesday). When we test the igb driver with this kernel, communication seems iffy, and we're seeing this on the console: igb0: Watchdog timeout -- resetting igb0: Queue(1) tdh = 4, hw tdt = 4 igb0: TX(1) desc avail = 1020,Next TX to Clean = 0 On the upside, link-state detection (which was messed up in the 8.0 driver) now seems to work properly. This morning I note that on Friday a number of additional "fixes" to em/igb were MFC'd. So... here are my questions: * Are the error messages likely related to the bugs fixed by these latest commits? --or-- is it more likely a problem with how we did the merge? * Should we expect to succeed at all, or are there other bits of new plumbing (changes since 8.0 was cut) that the newer driver relies on somehow, such that this is an iffy proposition? * Has the e1000 driver in -STABLE now mostly stabilized... or is additional engineering expected in the near term? Any and all assistance is greatly appreciated! Thanks, Charles -- Charles Owens Great Bay Software, Inc. From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 14:36:07 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F2FA106566B; Mon, 19 Apr 2010 14:36:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 574398FC15; Mon, 19 Apr 2010 14:36:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3JEa7xG020548; Mon, 19 Apr 2010 14:36:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3JEa72C020544; Mon, 19 Apr 2010 14:36:07 GMT (envelope-from linimon) Date: Mon, 19 Apr 2010 14:36:07 GMT Message-Id: <201004191436.o3JEa72C020544@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145825: [panic] panic: soabort: so_count X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 14:36:07 -0000 Synopsis: [panic] panic: soabort: so_count Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 14:35:30 UTC 2010 Responsible-Changed-Why: apparently involves the network stack. http://www.freebsd.org/cgi/query-pr.cgi?pr=145825 From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 14:36:41 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2E021065675; Mon, 19 Apr 2010 14:36:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8E28FC14; Mon, 19 Apr 2010 14:36:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3JEafZ4020609; Mon, 19 Apr 2010 14:36:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3JEafFc020605; Mon, 19 Apr 2010 14:36:41 GMT (envelope-from linimon) Date: Mon, 19 Apr 2010 14:36:41 GMT Message-Id: <201004191436.o3JEafFc020605@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145826: [ath] Unable to configure adhoc mode on ath0/wlan0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 14:36:41 -0000 Old Synopsis: Unable to configure adhoc mode on ath0/wlan0 New Synopsis: [ath] Unable to configure adhoc mode on ath0/wlan0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 14:36:30 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145826 From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 18:16:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0739B106566C; Mon, 19 Apr 2010 18:16:26 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 934DC8FC12; Mon, 19 Apr 2010 18:16:25 +0000 (UTC) Received: by vws18 with SMTP id 18so229642vws.13 for ; Mon, 19 Apr 2010 11:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=r5HOjLStbV87e+IF7+R9PFQ573DEr0BfkUkgSo357rI=; b=TtNC/a8aob7V/Hv3Kt21AD0QxjIU3qHSmT4kskr43LGeNp3aBuq6tStOGGWRRaU6zK ErU8lEH7zx4YSdujCzog7bwOS+HKPIcz9lpFY11AxRDbElOdwExgdVteiFboX/kEHgBA WP1z6x3WH20knl5MVIg8Ax7Fjfk0vzP/TQvEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tVJV4Z41Q/Z65sJyCAqRs9z9MSvizrcFdQb8BxNPCC3s/4jajXb926ru091q3NT3D9 MaoX2eS4hTFictwn1PoV+fFTh1UnMS3JeYpEPLLPozR/MBf2+pxqfMoAls6e1zK+HfIq unrp3t4gkcigGXLBnpgBC4xdvSN/NY9T0rQX8= MIME-Version: 1.0 Sender: tomelite82@gmail.com Received: by 10.220.76.71 with HTTP; Mon, 19 Apr 2010 10:50:07 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Mon, 19 Apr 2010 10:50:07 -0700 X-Google-Sender-Auth: 554a4fe646b39f4c Received: by 10.220.157.206 with SMTP id c14mr3771040vcx.230.1271699407439; Mon, 19 Apr 2010 10:50:07 -0700 (PDT) Message-ID: From: Qing Li To: Marin Atanasov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 18:16:26 -0000 Have you seen this thread? http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025128.html Quite a few fixes have gone into the -current and RELENG_8 branches. Please try sync-up to the latest code before applying the patch. -- Qing On Sun, Apr 18, 2010 at 11:53 PM, Marin Atanasov wrote: > Hi, > > I was setting up mpd5 from ports, but this proxy-arp issue still exists i= n > 8.0. > >> uname -r > 8.0-RELEASE-p2 > > I've attached the output from the mpd5 daemon, where you can still see th= at > the issue is relevant. > > I've also tried to apply the patch, but it's no longer on that location. > Something else to add - I've a dns server running on the same machine tha= t > mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp > issue, but after a couple of start/stops of mpd5 the name resolving from = the > gateway machine is not possible, all other systems from the internal netw= ork > are able to use the dns server on the gateway, but the gateway itself > cannot. > > Restart of named, doesn't help either, so I had to completely reboot the > machine, so that arp entries are flushed as well. > > Could you please have a look at the issue? If you need some additional > information, please let me know. > > Regards, > Marin > > On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. > wrote: >> >> Thank you ! >> The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with >> mpd5). >> >> Please, somebody =A0fix =A0the bug kern/141285... >> >> >> Li, Qing wrote: >>> >>> Hi, >>> >>> Recently there have been several reports regarding issues with ppp, mpd= 5 >>> and proxy-arp configuration over the ppp links. I read through the >>> various postings and the problems seem to be: >>> >>> 1. Unable to add proxy-arp entries for the remote ppp clients. >>> >>> 2. Log showing "ifa_add_loopback_route: insertion failed" causing =A0 = =A0some >>> userland applications to fail. >>> >>> May I ask that you try applying patch >>> >>> =A0http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff >>> >>> and report back if the patch fixes your problems. And if not, please >>> describe what additional issues you are having. >>> >>> Thanks, >>> >>> -- Qing >>> >>> >>> _______________________________________________ >>> 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-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " > > > > -- > Marin Atanasov Nikolov > dnaeon AT gmail DOT com > daemon AT unix-heaven DOT org > From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 00:43:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F171106564A for ; Tue, 20 Apr 2010 00:43:47 +0000 (UTC) (envelope-from bobbyjwalker@live.com) Received: from snt0-omc2-s34.snt0.hotmail.com (snt0-omc2-s34.snt0.hotmail.com [65.55.90.109]) by mx1.freebsd.org (Postfix) with ESMTP id 475D38FC08 for ; Tue, 20 Apr 2010 00:43:47 +0000 (UTC) Received: from SNT140-W14 ([65.55.90.72]) by snt0-omc2-s34.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Apr 2010 17:31:46 -0700 Message-ID: X-Originating-IP: [216.150.115.3] From: Bobby Walker To: Date: Mon, 19 Apr 2010 20:31:45 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2010 00:31:46.0054 (UTC) FILETIME=[DB8D8260:01CAE020] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 7.1 and ural problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:43:47 -0000 Hey list=2C I've searched and searched for a solution to this problem and I= can't find one. =20 I've got the wireless nic setup=2C its a Linksys WUSB54G v2. =20 Its picked up by the ural driver=2C but as far as I can tell that driver do= esn't work for it. =20 dmesg gives me: =20 ural0: MAC/BBP RT2570 (rev 0x05)=2C RF RT2526 ural0: WARNING: using obsoleted IFF_NEEDSGIANT flag ural0: Ethernet address: 00:18:39:03:35:3b =20 Then I get a series of messages that repeat: ural0: link state changed to UP ural0: link state changed to DOWN ural0: link state changed to UP ural0: link state changed to DOWN =20 Here's ifconfig when the device is UP: ural0: flags=3D108843 metric 0 mtu 1500 ether 00:18:39:03:35:3b inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) status: associated ssid MYNETWORK channel 6 (2437 Mgz 11g) bssid 00:25:9c:9e:e0:00 authmode WPA2/802.11i privacy ON deftxkey UNDEF txpower 50 bmiss 7 scanvalid 60 protmode CTS roaming MANUAL =20 And in my rc.conf I have this defined: ifconfig_ural0=3D"wpa DHCP" hostname=3D"my.home.server" =20 And lastly this is my wpa_supplicant.conf network=3D{ ssid=3D"MYNETWORK" key_mgmt=3DWPA-PSK psk=3D"mysecretpass" } =20 Anyone have any ideas on how I can pull down a stable connection with this = so that I can upgrade to 8.0? =20 Thanks in advance=2C Bobby =20 _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hot= mail. http://www.windowslive.com/campaign/thenewbusy?tile=3Dmultiaccount&ocid=3DP= ID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4= From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 06:00:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D67E11065670; Tue, 20 Apr 2010 06:00:59 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id E2D1A8FC08; Tue, 20 Apr 2010 06:00:58 +0000 (UTC) Received: by wwa36 with SMTP id 36so3529884wwa.13 for ; Mon, 19 Apr 2010 23:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=lBOO4L+pUE7DhyJlGUS4A/ek8bm7/hi1IlFxKKVLHE0=; b=SiIVhzp+XRiIl30Mk5ESylRnRvqoeJjXwGZ/N3pEyDCCxe84onWm+IKypWuT7xXn5C awWsy2TcLvfhhQKLg+nDXJVK85VktyxsOSFheofWdPxPVYdmBn5NHAwIZDGMZi8xDOnR 881b0hUcWCjnOsNngQlt2y1ZaVtTfMbm/lzkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vHjJf4r2lAMMkrHbvNTS8nyWwpE8eAcVHtOH2JYU0/50b/emQCbu+k3LGtvHCy2rzV G6wgoCmPn0mSnmnXU+zj96jvp7pc/Ldm6qQyjvoPGgFDl8gGj3NQEahGUCtn8x4ULePb hCTozUSfb/3GB7rqJXwsv/xAYtagqokvTM2o4= MIME-Version: 1.0 Received: by 10.216.13.7 with HTTP; Mon, 19 Apr 2010 23:00:57 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Tue, 20 Apr 2010 09:00:57 +0300 Received: by 10.216.86.67 with SMTP id v45mr832972wee.70.1271743257713; Mon, 19 Apr 2010 23:00:57 -0700 (PDT) Message-ID: From: Marin Atanasov To: Qing Li Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 06:00:59 -0000 Hello Qing, Seems I've missed that thread, thank you for pointing it out. I was using csup to track RELEN_8_0 branch. Currently I'm syncing to RELENG_8. If I understood you right, after getting the sources for RELENG_8, I need to apply the patch and then rebuild world? Thanks and regards, Marin On Mon, Apr 19, 2010 at 8:50 PM, Qing Li wrote: > Have you seen this thread? > > http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025128.html > > Quite a few fixes have gone into the -current and RELENG_8 branches. > Please try sync-up to the latest code before applying the patch. > > -- Qing > > > > On Sun, Apr 18, 2010 at 11:53 PM, Marin Atanasov wrote: > > Hi, > > > > I was setting up mpd5 from ports, but this proxy-arp issue still exists > in > > 8.0. > > > >> uname -r > > 8.0-RELEASE-p2 > > > > I've attached the output from the mpd5 daemon, where you can still see > that > > the issue is relevant. > > > > I've also tried to apply the patch, but it's no longer on that location. > > Something else to add - I've a dns server running on the same machine > that > > mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp > > issue, but after a couple of start/stops of mpd5 the name resolving from > the > > gateway machine is not possible, all other systems from the internal > network > > are able to use the dns server on the gateway, but the gateway itself > > cannot. > > > > Restart of named, doesn't help either, so I had to completely reboot the > > machine, so that arp entries are flushed as well. > > > > Could you please have a look at the issue? If you need some additional > > information, please let me know. > > > > Regards, > > Marin > > > > On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. > > wrote: > >> > >> Thank you ! > >> The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with > >> mpd5). > >> > >> Please, somebody fix the bug kern/141285... > >> > >> > >> Li, Qing wrote: > >>> > >>> Hi, > >>> > >>> Recently there have been several reports regarding issues with ppp, > mpd5 > >>> and proxy-arp configuration over the ppp links. I read through the > >>> various postings and the problems seem to be: > >>> > >>> 1. Unable to add proxy-arp entries for the remote ppp clients. > >>> > >>> 2. Log showing "ifa_add_loopback_route: insertion failed" causing > some > >>> userland applications to fail. > >>> > >>> May I ask that you try applying patch > >>> > >>> http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff > >>> > >>> and report back if the patch fixes your problems. And if not, please > >>> describe what additional issues you are having. > >>> > >>> Thanks, > >>> > >>> -- Qing > >>> > >>> > >>> _______________________________________________ > >>> 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-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to " > freebsd-stable-unsubscribe@freebsd.org" > > > > > > > > -- > > Marin Atanasov Nikolov > > dnaeon AT gmail DOT com > > daemon AT unix-heaven DOT org > > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 08:03:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 325581065672; Tue, 20 Apr 2010 08:03:34 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A72F18FC1F; Tue, 20 Apr 2010 08:03:33 +0000 (UTC) Received: by vws18 with SMTP id 18so648226vws.13 for ; Tue, 20 Apr 2010 01:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=azVqSKKjveSxlU/lmT8rzNuSjgPHeFYjk2IENmfv4PQ=; b=l/DRPQxeM3Cxu4EcfdNDzN91mQy/3TLu2Mott6qKqNFqX6gThP02NtojWZUiVXesVV UDSSu08ILB8pnaeUDFZuEzKL1kEXP8fJNk5MUvKyqYGEE7FZ/0A5VklIVKgw+uRZk0fO jpfFSLBM94I31iLjRT6tP4uQIomWnYSulxQyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Ff3C7m29erNEmsX/AUwY2qgz1gZF7hDlnqugsG09wsEsamW0/U21q0j3WFy5aGUXie GonQhXoN/npVhiEqKqLBkVkRTXkWtWera9Fd9zCcMH2j8fyvRC0A06vsxlm8IweTR6RM doZnuVcURSAWcuJkdTc8yU7BwHiIYUh2q7/J4= MIME-Version: 1.0 Sender: tomelite82@gmail.com Received: by 10.220.76.71 with HTTP; Tue, 20 Apr 2010 01:03:32 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Tue, 20 Apr 2010 01:03:32 -0700 X-Google-Sender-Auth: fa6dd5dbd164b230 Received: by 10.220.108.227 with SMTP id g35mr4380355vcp.184.1271750612811; Tue, 20 Apr 2010 01:03:32 -0700 (PDT) Message-ID: From: Qing Li To: Marin Atanasov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 08:03:34 -0000 > > I was using csup to track RELEN_8_0 branch. Currently I'm syncing to > RELENG_8. > > If I understood you right, after getting the sources for RELENG_8, I need to > apply the patch and then rebuild world? > You only need to rebuild the kernel. -- Qing From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 09:03:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 046851065675 for ; Tue, 20 Apr 2010 09:03:23 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id D946F8FC1D for ; Tue, 20 Apr 2010 09:03:22 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 3270111BAA1; Tue, 20 Apr 2010 03:44:13 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id 6S82DKM0UA2M; Tue, 20 Apr 2010 03:44:13 -0500 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Tue, 20 Apr 2010 09:44:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bobby Walker X-Mailer: Apple Mail (2.1078) Cc: freebsd-net@freebsd.org Subject: Re: 7.1 and ural problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 09:03:23 -0000 On 20 Apr 2010, at 01:31, Bobby Walker wrote: >=20 > Hey list, I've searched and searched for a solution to this problem = and I can't find one. >=20 >=20 >=20 > I've got the wireless nic setup, its a Linksys WUSB54G v2. >=20 >=20 >=20 > Its picked up by the ural driver, but as far as I can tell that driver = doesn't work for it. >=20 >=20 >=20 > dmesg gives me: >=20 >=20 >=20 > ural0: MAC/BBP RT2570 (rev 0x05), RF RT2526 >=20 > ural0: WARNING: using obsoleted IFF_NEEDSGIANT flag >=20 > ural0: Ethernet address: 00:18:39:03:35:3b >=20 >=20 >=20 > Then I get a series of messages that repeat: >=20 > ural0: link state changed to UP >=20 > ural0: link state changed to DOWN >=20 > ural0: link state changed to UP >=20 > ural0: link state changed to DOWN >=20 >=20 >=20 > Here's ifconfig when the device is UP: >=20 > ural0: flags=3D108843= metric 0 mtu 1500 >=20 > ether 00:18:39:03:35:3b >=20 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >=20 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) >=20 > status: associated >=20 > ssid MYNETWORK channel 6 (2437 Mgz 11g) bssid 00:25:9c:9e:e0:00 >=20 > authmode WPA2/802.11i privacy ON deftxkey UNDEF txpower 50 bmiss 7 >=20 > scanvalid 60 protmode CTS roaming MANUAL >=20 >=20 >=20 > And in my rc.conf I have this defined: >=20 > ifconfig_ural0=3D"wpa DHCP" >=20 > hostname=3D"my.home.server" >=20 >=20 >=20 > And lastly this is my wpa_supplicant.conf >=20 > network=3D{ >=20 > ssid=3D"MYNETWORK" >=20 > key_mgmt=3DWPA-PSK >=20 > psk=3D"mysecretpass" >=20 > } >=20 >=20 >=20 > Anyone have any ideas on how I can pull down a stable connection with = this so that I can upgrade to 8.0? You should try updating to FreeBSD-8. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 13:41:49 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94259106564A; Tue, 20 Apr 2010 13:41:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 541B88FC13; Tue, 20 Apr 2010 13:41:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DFBCB46B37; Tue, 20 Apr 2010 09:41:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CF53A8A021; Tue, 20 Apr 2010 09:41:47 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 20 Apr 2010 07:48:09 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004200748.09566.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 20 Apr 2010 09:41:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: c0re , net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 13:41:49 -0000 On Tuesday 20 April 2010 2:53:16 am c0re wrote: > Hello All! > I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to > configure gre interface and use ipfw fwd. > I'm actually does not know what was the point of failure in my > configuration. > > [ some details snipped ] > > It worked about one week and then I made some configuration changes: > added gre interface and 2 aliases: > > # cat /etc/rc.conf |grep > ifconfig_xl0="inet 192.168.0.10 netmask 255.255.255.0" > ifconfig_xl0_alias0="192.168.0.11 netmask 255.255.255.255" > ifconfig_xl0_alias1="192.168.0.12 netmask 255.255.255.255" > cloned_interfaces="gre0" > ifconfig_gre0="inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 > 192.168.200.15 netmask 255.255.255.252 link1 up" > > and > > # cat /etc/rc.local > #!/bin/sh > ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 > ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 > ipfw add allow ip from any to any > > # ifconfig gre0 > gre0: flags=b050 metric 0 mtu > 1476 > tunnel inet 192.168.0.12 --> 192.168.200.15 > inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc > > I shutted down gre interface to prevent requests via gre to buggy IP. > > The main idea of such configurations was: fwd all connections to https to > 192.168.0.1 via gre interface. > And also I made apache configurations to make it listen on 192.168.0.11 too. > > And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet to > 192.168.0.11 443 was fine too. Then I tryed to make browser https > connection to 192.168.0.11. Apache showed me certificate warning and I > accepted, then in browser nothing happened, it was trying to open page. But > server got kernel panic at that moment. > > At first time I thought that it was some power failure, I tryed 2 more times > and got same behaviour. > > So https works without kernel panic via 192.168.0.10 address but kernel > panics when I try do https via 192.168.0.11 address that source-forwarded > via gre. Looks like the TCP output path got stuck in an infinite recursion loop until it exhausted the kernel stack: > # cd /usr/obj/usr/src/sys/MYKERNEL > # kgdb kernel.debug /var/crash/vmcore.2 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > Fatal double fault: > eip = 0xc08e3ba3 > esp = 0xccf6dfc4 > ebp = 0xccf6e274 > cpuid = 0; apic id = 00 > panic: double fault > cpuid = 0 > Uptime: 7m14s > Physical memory: 235 MB > Dumping 35 MB: 20 4 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from > /boot/kernel/if_gre.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_gre.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc07f2857 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc07f2b29 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:983 > #4 0xc08e3ba3 in ipfw_chk (args=0xccf6e28c) at > /usr/src/sys/netinet/ip_fw2.c:2465 > #5 0xc08e6ce1 in ipfw_check_out (arg=0x0, m0=0xccf6e390, ifp=0xc25c5c00, > dir=2, inp=0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 > #6 0xc08a1968 in pfil_run_hooks (ph=0xc0c55240, mp=0xccf6e420, > ifp=0xc25c5c00, dir=2, inp=0xc28ba708) at /usr/src/sys/net/pfil.c:78 > #7 0xc08eb6f2 in ip_output (m=0xc2710b00, opt=0x0, ro=0xccf6e3f4, flags=0, > imo=0x0, inp=0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 > #8 0xc08f4016 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1134 > #9 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #10 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #11 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #12 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #13 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #14 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #15 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #16 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #17 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #18 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #19 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #20 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #21 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #22 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #23 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #24 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #25 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #26 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #27 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #28 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #29 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #30 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #31 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #32 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #33 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #34 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #35 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #36 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #37 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #38 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #39 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #40 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #41 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #42 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #43 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #44 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #45 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #46 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #47 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #48 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #49 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > ---Type to continue, or q to quit--- > #50 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #51 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #52 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #53 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #54 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #55 0xc08fdcf8 in tcp_usr_send (so=0xc2ac1820, flags=0, m=0xc270ed00, > nam=0x0, control=0x0, td=0xc28e2d80) at tcp_offload.h:269 > #56 0xc0850405 in sosend_generic (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, > top=0xc270ed00, control=0x0, flags=0, td=0xc28e2d80) at > /usr/src/sys/kern/uipc_socket.c:1243 > #57 0xc084bf7f in sosend (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, top=0x0, > control=0x0, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/uipc_socket.c:1285 > #58 0xc0833c5b in soo_write (fp=0xc28e84c0, uio=0xc28766c0, > active_cred=0xc28e5900, flags=0, td=0xc28e2d80) at > /usr/src/sys/kern/sys_socket.c:103 > #59 0xc082d2e7 in dofilewrite (td=0xc28e2d80, fd=24, fp=0xc28e84c0, > auio=0xc28766c0, offset=-1, flags=0) at file.h:257 > #60 0xc082d5c8 in kern_writev (td=0xc28e2d80, fd=24, auio=0xc28766c0) at > /usr/src/sys/kern/sys_generic.c:402 > #61 0xc082d816 in writev (td=0xc28e2d80, uap=0xccf6fcfc) at > /usr/src/sys/kern/sys_generic.c:388 > #62 0xc0a7f2d5 in syscall (frame=0xccf6fd38) at > /usr/src/sys/i386/i386/trap.c:1101 > #63 0xc0a636a0 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:262 > #64 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > (kgdb) quit tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: case EMSGSIZE: /* * For some reason the interface we used initially * to send segments changed to another or lowered * its MTU. * * tcp_mtudisc() will find out the new MTU and as * its last action, initiate retransmission, so it * is important to not do so here. * * If TSO was active we either got an interface * without TSO capabilits or TSO was turned off. * Disable it for this connection as too and * immediatly retry with MSS sized segments generated * by this function. */ if (tso) tp->t_flags &= ~TF_TSO; tcp_mtudisc(tp->t_inpcb, 0); return (0); But tcp_mtudisc() calls tcp_output(): tcpstat.tcps_mturesent++; tp->t_rtttime = 0; tp->snd_nxt = tp->snd_una; tcp_free_sackholes(tp); tp->snd_recover = tp->snd_max; if (tp->t_flags & TF_SACK_PERMIT) EXIT_FASTRECOVERY(tp); tcp_output_send(tp); return (inp); I'm not sure why it's not able to figure out the MTU, perhaps folks on net@ can help. However, it would seem that for the tcp_output() case, tcp_mtudisc() should probably not call tcp_output_send(), but instead tcp_output() should just loop back up to the top after calling tcp_mtudisc() and retry. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 14:17:37 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF4B1065672 for ; Tue, 20 Apr 2010 14:17:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id B25AB8FC08 for ; Tue, 20 Apr 2010 14:17:36 +0000 (UTC) Received: by bwz8 with SMTP id 8so5594600bwz.3 for ; Tue, 20 Apr 2010 07:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AnP+huBkOJHK0m9w+ovY662TEpMWEBmCZ+hrgxqnnHM=; b=eAB6TcoY8ommvWy6Y3wwNKyMSimT1vknnlIx09wvoEEB/zWiStVh6fA5BAIeik13fO 46eLRazGA99nQwggAKyZrDQxhguVk37cZRcktnoN4Wd0SgXPuuMOOzwniCnfRXfNjef1 /IW+6xTorKG+xNHT/5JEZ4oNWCQmNPs2OHqb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=feoiSU5SajZbv0kzYYNji6I38RdDGthwtvFzeGYK6fAby41BDUztoghPRtC9jsH5nz c9T90p9W5wP48oaBK4zyUoZOoNIXxwOQdw0ZjtdwEMUfDDGi2H/In6IKx31/8jNjfD4P 36Skgb85gdI9vTTZO6MDv4SEI/SUO+XYjj1+s= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Tue, 20 Apr 2010 06:51:49 -0700 (PDT) In-Reply-To: <201004200748.09566.jhb@freebsd.org> References: <201004200748.09566.jhb@freebsd.org> Date: Tue, 20 Apr 2010 17:51:49 +0400 Received: by 10.204.21.18 with SMTP id h18mr2490059bkb.177.1271771510528; Tue, 20 Apr 2010 06:51:50 -0700 (PDT) Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, c0re , net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 14:17:37 -0000 On 20 April 2010 15:48, John Baldwin wrote: > On Tuesday 20 April 2010 2:53:16 am c0re wrote: >> Hello All! >> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to >> configure gre interface and use ipfw fwd. >> I'm actually does not know what was the point of failure in my >> configuration. >> >> [ some details snipped ] >> >> It worked about one week and then I made some configuration changes: >> added gre interface and 2 aliases: >> >> # cat /etc/rc.conf |grep >> ifconfig_xl0=3D"inet 192.168.0.10 =A0netmask 255.255.255.0" >> ifconfig_xl0_alias0=3D"192.168.0.11 netmask 255.255.255.255" >> ifconfig_xl0_alias1=3D"192.168.0.12 netmask 255.255.255.255" >> cloned_interfaces=3D"gre0" >> ifconfig_gre0=3D"inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 >> 192.168.200.15 netmask 255.255.255.252 link1 up" >> >> and >> >> # cat /etc/rc.local >> #!/bin/sh >> ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 >> ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 >> ipfw add allow ip from any to any >> >> # ifconfig gre0 >> gre0: flags=3Db050 metric 0 m= tu >> 1476 >> =A0 =A0 =A0 =A0 tunnel inet 192.168.0.12 --> 192.168.200.15 >> =A0 =A0 =A0 =A0 inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc >> >> I shutted down gre interface to prevent requests via gre to buggy IP. >> >> The main idea of such configurations was: fwd all connections to https t= o >> 192.168.0.1 via gre interface. >> And also I made apache configurations to make it listen on 192.168.0.11 = too. >> >> And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet = to >> 192.168.0.11 =A0443 was fine too. Then I tryed to make browser https >> connection to 192.168.0.11. Apache showed me certificate warning and I >> accepted, then in browser nothing happened, it was trying to open page. = But >> server got kernel panic at that moment. >> >> At first time I thought that it was some power failure, I tryed 2 more t= imes >> and got same behaviour. >> >> So https works without kernel panic via 192.168.0.10 address but kernel >> panics when I try do https via 192.168.0.11 address that source-forwarde= d >> via gre. > > Looks like the TCP output path got stuck in an infinite recursion loop un= til > it exhausted the kernel stack: > >> # cd /usr/obj/usr/src/sys/MYKERNEL >> # kgdb kernel.debug /var/crash/vmcore.2 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you= are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. =A0Type "show warranty" for det= ails. >> This GDB was configured as "i386-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> >> Fatal double fault: >> eip =3D 0xc08e3ba3 >> esp =3D 0xccf6dfc4 >> ebp =3D 0xccf6e274 >> cpuid =3D 0; apic id =3D 00 >> panic: double fault >> cpuid =3D 0 >> Uptime: 7m14s >> Physical memory: 235 MB >> Dumping 35 MB: 20 4 >> >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from >> /boot/kernel/if_gre.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/if_gre.ko >> Reading symbols from /boot/kernel/linux.ko...Reading symbols from >> /boot/kernel/linux.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/linux.ko >> #0 =A0doadump () at pcpu.h:196 >> 196 =A0 =A0 =A0 =A0 =A0 =A0 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (= td)); >> (kgdb) bt >> #0 =A0doadump () at pcpu.h:196 >> #1 =A00xc07f2857 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdow= n.c:418 >> #2 =A00xc07f2b29 in panic (fmt=3DVariable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:574 >> #3 =A00xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c= :983 >> #4 =A00xc08e3ba3 in ipfw_chk (args=3D0xccf6e28c) at >> /usr/src/sys/netinet/ip_fw2.c:2465 >> #5 =A00xc08e6ce1 in ipfw_check_out (arg=3D0x0, m0=3D0xccf6e390, ifp=3D0x= c25c5c00, >> dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 >> #6 =A00xc08a1968 in pfil_run_hooks (ph=3D0xc0c55240, mp=3D0xccf6e420, >> ifp=3D0xc25c5c00, dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/net/pfil.c:= 78 >> #7 =A00xc08eb6f2 in ip_output (m=3D0xc2710b00, opt=3D0x0, ro=3D0xccf6e3f= 4, flags=3D0, >> imo=3D0x0, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 >> #8 =A00xc08f4016 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1134 >> #9 =A00xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_off= load.h:269 >> #10 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #11 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #12 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #13 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #14 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #15 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #16 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #17 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #18 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #19 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #20 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #21 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #22 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #23 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #24 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #25 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #26 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #27 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #28 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #29 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #30 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #31 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #32 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #33 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #34 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #35 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #36 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #37 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #38 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #39 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #40 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #41 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #42 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #43 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #44 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #45 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #46 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #47 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #48 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #49 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> ---Type to continue, or q to quit--- >> #50 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #51 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #52 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #53 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #54 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #55 0xc08fdcf8 in tcp_usr_send (so=3D0xc2ac1820, flags=3D0, m=3D0xc270ed= 00, >> nam=3D0x0, control=3D0x0, td=3D0xc28e2d80) at tcp_offload.h:269 >> #56 0xc0850405 in sosend_generic (so=3D0xc2ac1820, addr=3D0x0, uio=3D0xc= 28766c0, >> top=3D0xc270ed00, control=3D0x0, flags=3D0, td=3D0xc28e2d80) at >> /usr/src/sys/kern/uipc_socket.c:1243 >> #57 0xc084bf7f in sosend (so=3D0xc2ac1820, addr=3D0x0, uio=3D0xc28766c0,= top=3D0x0, >> control=3D0x0, flags=3D0, td=3D0xc28e2d80) at /usr/src/sys/kern/uipc_soc= ket.c:1285 >> #58 0xc0833c5b in soo_write (fp=3D0xc28e84c0, uio=3D0xc28766c0, >> active_cred=3D0xc28e5900, flags=3D0, td=3D0xc28e2d80) at >> /usr/src/sys/kern/sys_socket.c:103 >> #59 0xc082d2e7 in dofilewrite (td=3D0xc28e2d80, fd=3D24, fp=3D0xc28e84c0= , >> auio=3D0xc28766c0, offset=3D-1, flags=3D0) at file.h:257 >> #60 0xc082d5c8 in kern_writev (td=3D0xc28e2d80, fd=3D24, auio=3D0xc28766= c0) at >> /usr/src/sys/kern/sys_generic.c:402 >> #61 0xc082d816 in writev (td=3D0xc28e2d80, uap=3D0xccf6fcfc) at >> /usr/src/sys/kern/sys_generic.c:388 >> #62 0xc0a7f2d5 in syscall (frame=3D0xccf6fd38) at >> /usr/src/sys/i386/i386/trap.c:1101 >> #63 0xc0a636a0 in Xint0x80_syscall () at >> /usr/src/sys/i386/i386/exception.s:262 >> #64 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> (kgdb) quit > > tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case EMSGSIZE: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * For some reason the int= erface we used initially > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * to send segments change= d to another or lowered > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its MTU. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * tcp_mtudisc() will find= out the new MTU and as > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its last action, initia= te retransmission, so it > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * is important to not do = so here. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * If TSO was active we ei= ther got an interface > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * without TSO capabilits = or TSO was turned off. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Disable it for this con= nection as too and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * immediatly retry with M= SS sized segments generated > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * by this function. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tso) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tp->t_flag= s &=3D ~TF_TSO; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tcp_mtudisc(tp->t_inpcb, 0= ); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > > But tcp_mtudisc() calls tcp_output(): > > =A0 =A0 =A0 =A0tcpstat.tcps_mturesent++; > =A0 =A0 =A0 =A0tp->t_rtttime =3D 0; > =A0 =A0 =A0 =A0tp->snd_nxt =3D tp->snd_una; > =A0 =A0 =A0 =A0tcp_free_sackholes(tp); > =A0 =A0 =A0 =A0tp->snd_recover =3D tp->snd_max; > =A0 =A0 =A0 =A0if (tp->t_flags & TF_SACK_PERMIT) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EXIT_FASTRECOVERY(tp); > =A0 =A0 =A0 =A0tcp_output_send(tp); > =A0 =A0 =A0 =A0return (inp); > > I'm not sure why it's not able to figure out the MTU, perhaps folks on ne= t@ > can help. =A0However, it would seem that for the tcp_output() case, > tcp_mtudisc() should probably not call tcp_output_send(), but instead > tcp_output() should just loop back up to the top after calling tcp_mtudis= c() > and retry. > I'm afraid to be wrong but it looks similar to another report for 8.0-STABL= E (may it be a cross-major version regression somewhere around tcp_mtudisc()?= ): http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056063.html --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 17:14:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9263E106566B for ; Tue, 20 Apr 2010 17:14:10 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4876D8FC08 for ; Tue, 20 Apr 2010 17:14:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O4H1U-0004x8-IJ for freebsd-net@freebsd.org; Tue, 20 Apr 2010 19:14:08 +0200 Received: from gw2.masterhost.ru ([87.242.97.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Apr 2010 19:14:08 +0200 Received: from citrin by gw2.masterhost.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Apr 2010 19:14:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org connect(): No such file or directory From: Anton Yuzhaninov Date: Tue, 20 Apr 2010 17:13:55 +0000 (UTC) Organization: Vega Lines: 22 Sender: Message-ID: References: <005801cad03c$5f5128d0$1df37a70$@kawasaki-tn.com> <201003302120.o2ULKwTT071015@lava.sentex.ca> <20100331004822.GA49860@edoofus.dev.vega.ru> <20100414125927.GA4425@edoofus.dev.vega.ru> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: gw2.masterhost.ru X-Comment-To: "Li, Qing" User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/2.6.32-gentoo-r7 (i686)) Subject: Re: Workaround for mpd5 and 8.0 broken proxy arp? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 17:14:10 -0000 On Thu, 15 Apr 2010 10:49:08 -0700, Li, Qing wrote: >> Doesn't seem to have any effect. Please see >> http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024728.html >> on how to reproduce. >> LQ> LQ> Could you please try the patch at: LQ> LQ> http://people.freebsd.org/~qingli/ng-patch.diff LQ> Thanks, this patch help in our case. But there is still same differences between FreeBSD7 and FreeBSD8 related to ng_iface tunnels, but may be not related to ARP. Detailed test of ng_iface + proxy arp is here: http://citrin.ru/stuff/freebsd_ng_iface_and_proxy_arp.txt -- WBR, Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 17:18:10 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 531D5106566B for ; Tue, 20 Apr 2010 17:18:10 +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 1C19C8FC18 for ; Tue, 20 Apr 2010 17:18:09 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7AD6673098; Tue, 20 Apr 2010 19:28:45 +0200 (CEST) Date: Tue, 20 Apr 2010 19:28:45 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20100420172845.GA71187@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: max_linkhdr defaults to 16, too short ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 17:18:10 -0000 just noticed that sys/kern/uipc_domain.c still sets max_linkhdr=16 as a default. The value is often used to reserve head space in mbufs for the MAC header. As such, 16 is too short for systems that make use of vlans, and the effect might be that we would need additional mbuf entries or at least move stuff down as the vlan tag is added. Any objection to bumping the default to 20 ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 21:44:51 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F59D106564A for ; Tue, 20 Apr 2010 21:44:51 +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 26B438FC1D for ; Tue, 20 Apr 2010 21:44:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 51E8F730A1; Tue, 20 Apr 2010 23:55:27 +0200 (CEST) Date: Tue, 20 Apr 2010 23:55:27 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20100420215527.GA75324@onelab2.iet.unipi.it> References: <20100420172845.GA71187@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100420172845.GA71187@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: max_linkhdr defaults to 16, too short ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 21:44:51 -0000 On Tue, Apr 20, 2010 at 07:28:45PM +0200, Luigi Rizzo wrote: > just noticed that sys/kern/uipc_domain.c still sets max_linkhdr=16 > as a default. > The value is often used to reserve head space in mbufs for > the MAC header. As such, 16 is too short for systems that make > use of vlans, and the effect might be that we would need > additional mbuf entries or at least move stuff down > as the vlan tag is added. > > Any objection to bumping the default to 20 ? forgot to mention: max_linkhdr is available as a sysctl, kern.max_linkhdr , but other than that, there is no code in sys/ that sets the value, so systems are stuck at 16 unless users override the default. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 01:20:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9147106564A for ; Wed, 21 Apr 2010 01:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B86448FC17 for ; Wed, 21 Apr 2010 01:20:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3L1K46K093596 for ; Wed, 21 Apr 2010 01:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3L1K462093595; Wed, 21 Apr 2010 01:20:04 GMT (envelope-from gnats) Date: Wed, 21 Apr 2010 01:20:04 GMT Message-Id: <201004210120.o3L1K462093595@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Scheffenegger, Richard" Cc: Subject: Re: kern/140597 implement Lost Retransmission Detection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Scheffenegger, Richard" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 01:20:05 -0000 The following reply was made to PR kern/140597; it has been noted by GNATS. From: "Scheffenegger, Richard" To: , "Lawrence Stewart" Cc: "Biswas, Anumita" Subject: Re: kern/140597 implement Lost Retransmission Detection Date: Wed, 21 Apr 2010 02:16:01 +0100 I found a small oversight (bug) in my earlier simple fix. If we had sent out multiple holes already, all of which get (partially) lost in the retransmission again, the original simple patch would only work for the very first hole. So, subsequent holes would not get re-sent, unless another ACK (SACK) would be received - however, seeing more SACKs becomes less likely the more loss is expirienced. This is a updated patch diff, which accounts for that case as well - but at the cost of O(n) time, instead of O(c). (Just check all holes from the hint backwards to the head, if any already fully resent hole needs to be reset, instead of only the first one - which might go away during subsequent processing in the original patch). diff -u netinet.orig/tcp_output.c netinet/tcp_output.c --- netinet.orig/tcp_output.c 2009-10-25 02:10:29.000000000 +0100 +++ netinet/tcp_output.c 2010-04-02 16:55:14.000000000 +0200 @@ -953,6 +953,10 @@ } else { th->th_seq =3D htonl(p->rxmit); p->rxmit +=3D len; + /* lost again detection */ + if (SEQ_GEQ(p->rxmit, p->end)) { + p->rxmit =3D tp->snd_nxt; + } tp->sackhint.sack_bytes_rexmit +=3D len; } th->th_ack =3D htonl(tp->rcv_nxt); diff -u netinet.orig/tcp_sack.c netinet.simple_mod/tcp_sack.c --- netinet.orig/tcp_sack.c 2009-10-25 02:10:29.000000000 +0100 +++ netinet/tcp_sack.c 2010-04-21 00:48:23.000000000 +0200 @@ -508,7 +508,9 @@ if (SEQ_GEQ(sblkp->end, cur->end)) { /* Move end of hole backward. */ cur->end =3D sblkp->start; - cur->rxmit =3D SEQ_MIN(cur->rxmit, cur->end); + if (SEQ_GEQ(cur->rxmit, cur->end)) { + cur->rxmit =3D tp->snd_nxt; + } } else { /* * ACKs some data in middle of a hole; need @@ -524,8 +526,9 @@ - temp->start); } cur->end =3D sblkp->start; - cur->rxmit =3D = SEQ_MIN(cur->rxmit, - cur->end); + if (SEQ_GEQ(cur->rxmit, cur->end)) { + cur->rxmit =3D tp->snd_nxt; + } } } } @@ -540,6 +543,15 @@ else sblkp--; } + /* retransmission lost again - then restart */ + if ((temp =3D tp->sackhint.nexthole) !=3D NULL) { + do { + if (SEQ_GT(tp->snd_fack, temp->rxmit)) { + temp->rxmit =3D temp->start; + tp->sackhint.nexthole =3D temp; + } + } while ((temp =3D TAILQ_PREV(temp, sackhole_head, scblink)) !=3D NULL); + } } /* Richard Scheffenegger =20 From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 05:28:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F2D6106567F for ; Wed, 21 Apr 2010 05:28:54 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id D431A8FC1F for ; Wed, 21 Apr 2010 05:28:53 +0000 (UTC) Received: by bwz28 with SMTP id 28so7751781bwz.14 for ; Tue, 20 Apr 2010 22:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:organization :date:message-id:user-agent:mime-version:content-type; bh=/Faw1e7dk+OP/NN8zDTiZb/5x2jAxSb0mi9d7qeopVc=; b=bu39xmw7dxWRlF7O1vTyOC9VZirx6xBcTy334Vc8KuUG2LBJmUz2IGrmZ7oJk2YTh2 6UhO4Oz7bu0McvoRZo0w6ERcqbMSQOp7gMFoy4JeVOJZDQSpSGqxmk6bkXXuJaJB5z52 /Uv9E1Z9QjowfejlWBWjgbnZ7n7vvD004OlZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:organization:date:message-id:user-agent :mime-version:content-type; b=JC93tlYi6gDUa/bh0iZQFyjKnYhj8ATnJOIdNbReEkojHxRQWfj5zTEnYdlR2acv3W RH0F4h8FDWx3VvDc3ir2a88t6Hw8xAsFzOaL5bY8G445BzVdNxb+JoSp12L0LCnQzdRD 3LBIjobBPzXlG8qiLjjTJHQBJN97HRF/iTQIw= Received: by 10.204.138.212 with SMTP id b20mr2240929bku.63.1271827732063; Tue, 20 Apr 2010 22:28:52 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 16sm3977669bwz.1.2010.04.20.22.28.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 22:28:51 -0700 (PDT) From: Mikolaj Golub To: freebsd-net Organization: TOA Ukraine Date: Wed, 21 Apr 2010 08:28:48 +0300 Message-ID: <86fx2pfk6n.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Subject: Races on alias deletion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 05:28:54 -0000 --=-=-= Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Hi, Accidentally due to misconfiguration of our tools we ran simultaneously deletion of the same interface alias and crashed the box (FreeBSD-7.1). So I did some experiments on my 8-STABLE (I have CURRENT in virtualbox only) to investigate this running concurrently two scripts, which were adding and deleting the same address: while true; do ifconfig $IFACE alias $IP ifconfig $IFACE -alias $IP done The box crashed just after I started the second script. The crash was in in_control() on removing ia->ia_ifa from ifp->if_addrhead list, because there was no check if the address is still in the list before removing. panic: Bad link elm 0xcd2f3b00 prev->next != elm #0 doadump () at pcpu.h:246 #1 0xc04ec829 in db_fncall (dummy1=-1064461270, dummy2=0, dummy3=-1, dummy4=0xe9a737fc "\0208§é") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04ecc5f in db_command (last_cmdp=0xc0e0ab9c, cmd_table=0x0, dopager=0) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04ecd14 in db_command_script (command=0xc0e0bac4 "call doadump") at /usr/src/sys/ddb/db_command.c:516 #4 0xc04f0e50 in db_script_exec (scriptname=0xe9a73908 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available. ) at /usr/src/sys/ddb/db_script.c:302 #5 0xc04f0f37 in db_script_kdbenter (eventname=0xc0cc760a "panic") at /usr/src/sys/ddb/db_script.c:324 #6 0xc04eec18 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228 #7 0xc08d9aa6 in kdb_trap (type=3, code=0, tf=0xe9a73a44) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xc0befbeb in trap (frame=0xe9a73a44) at /usr/src/sys/i386/i386/trap.c:690 #9 0xc0bd130b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc08d9c2a in kdb_enter (why=0xc0cc760a "panic", msg=0xc0cc760a "panic") at cpufunc.h:71 #11 0xc08a95b6 in panic (fmt=0xc0c61bc0 "Bad link elm %p prev->next != elm") at /usr/src/sys/kern/kern_shutdown.c:562 #12 0xc09ba87f in in_control (so=0xcdbd519c, cmd=2149607705, data=0xcd3db120 "fxp0", ifp=0xc5b94c00, td=0xc92ddb90) at /usr/src/sys/netinet/in.c:604 #13 0xc095d400 in ifioctl (so=0xcdbd519c, cmd=2149607705, data=0xcd3db120 "fxp0", td=0xc92ddb90) at /usr/src/sys/net/if.c:2516 #14 0xc08f69d5 in soo_ioctl (fp=0xcdc90af0, cmd=2149607705, data=0xcd3db120, active_cred=0xc9d78400, td=0xc92ddb90) at /usr/src/sys/kern/sys_socket.c:212 #15 0xc08f0a2d in kern_ioctl (td=0xc92ddb90, fd=3, com=2149607705, data=0xcd3db120 "fxp0") at file.h:262 #16 0xc08f0bb4 in ioctl (td=0xc92ddb90, uap=0xe9a73cf8) at /usr/src/sys/kern/sys_generic.c:678 #17 0xc0bef320 in syscall (frame=0xe9a73d38) at /usr/src/sys/i386/i386/trap.c:1111 #18 0xc0bd13a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 12 #12 0xc09ba87f in in_control (so=0xcdbd519c, cmd=2149607705, data=0xcd3db120 "fxp0", ifp=0xc5b94c00, td=0xc92ddb90) at /usr/src/sys/netinet/in.c:604 604 TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); (kgdb) list 599 default: 600 panic("in_control: unsupported ioctl"); 601 } 602 603 IF_ADDR_LOCK(ifp); 604 TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); 605 IF_ADDR_UNLOCK(ifp); 606 ifa_free(&ia->ia_ifa); /* if_addrhead */ 607 608 IN_IFADDR_WLOCK(); The fist patch in the attachments fixed this type of crashes for me, but the box started to crash in in_lltable_prefix_free (now it was required for scripts to run a few seconds). (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc04ec829 in db_fncall (dummy1=1, dummy2=0, dummy3=-1056922880, dummy4=0xe8636760 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04ecc21 in db_command (last_cmdp=0xc0e0ac1c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04ecd7a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04eec1d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc08d9aa6 in kdb_trap (type=12, code=0, tf=0xe863694c) at /usr/src/sys/kern/subr_kdb.c:535 #6 0xc0beeedf in trap_fatal (frame=0xe863694c, eva=420) at /usr/src/sys/i386/i386/trap.c:929 #7 0xc0bef800 in trap (frame=0xe863694c) at /usr/src/sys/i386/i386/trap.c:328 #8 0xc0bd139b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #9 0xc08a6a8b in _rw_wlock_hard (rw=0xc79e1508, tid=3334964384, file=0xc0ce01e4 "/usr/src/sys/netinet/in.c", line=1370) at /usr/src/sys/kern/kern_rwlock.c:677 #10 0xc08a75d6 in _rw_wlock (rw=0xc79e1508, file=0xc0ce01e4 "/usr/src/sys/netinet/in.c", line=1370) at /usr/src/sys/kern/kern_rwlock.c:237 #11 0xc09bb17e in in_lltable_prefix_free (llt=0xc5dabc00, prefix=0xe8636a94, mask=0xe8636a84) at /usr/src/sys/netinet/in.c:1370 #12 0xc09631d1 in lltable_prefix_free (af=2, prefix=0xe8636a94, mask=0xe8636a84) at /usr/src/sys/net/if_llatbl.c:217 #13 0xc09b8d77 in in_ifscrub (ifp=0xc5b94c00, ia=0xc6ec0500) at /usr/src/sys/netinet/in.c:1197 #14 0xc09ba6dc in in_control (so=0xc79d2338, cmd=2149607705, data=0xc629b0c0 "fxp0", ifp=0xc5b94c00, td=0xc6c784a0) at /usr/src/sys/netinet/in.c:586 #15 0xc095d400 in ifioctl (so=0xc79d2338, cmd=2149607705, data=0xc629b0c0 "fxp0", td=0xc6c784a0) at /usr/src/sys/net/if.c:2516 #16 0xc08f69d5 in soo_ioctl (fp=0xc6304738, cmd=2149607705, data=0xc629b0c0, active_cred=0xc79d8d80, td=0xc6c784a0) at /usr/src/sys/kern/sys_socket.c:212 #17 0xc08f0a2d in kern_ioctl (td=0xc6c784a0, fd=3, com=2149607705, data=0xc629b0c0 "fxp0") at file.h:262 #18 0xc08f0bb4 in ioctl (td=0xc6c784a0, uap=0xe8636cf8) at /usr/src/sys/kern/sys_generic.c:678 #19 0xc0bef3b0 in syscall (frame=0xe8636d38) at /usr/src/sys/i386/i386/trap.c:1111 #20 0xc0bd1430 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 11 #11 0xc09bb17e in in_lltable_prefix_free (llt=0xc5dabc00, prefix=0xe8636a94, mask=0xe8636a84) at /usr/src/sys/netinet/in.c:1370 1370 LLE_WLOCK(lle); (kgdb) list 1365 LIST_FOREACH_SAFE(lle, &llt->lle_head[i], lle_next, next) { 1366 1367 if (IN_ARE_MASKED_ADDR_EQUAL((struct sockaddr_in *)L3_ADDR(lle), 1368 pfx, msk)) { 1369 callout_drain(&lle->la_timer); 1370 LLE_WLOCK(lle); 1371 llentry_free(lle); 1372 } 1373 } 1374 } (kgdb) p *lle $1 = {lle_next = {le_next = 0xdeadc0de, le_prev = 0xdeadc0de}, lle_lock = {lock_object = { lo_name = 0xdeadc0de
, lo_flags = 3735929054, lo_data = 3735929054, lo_witness = 0xdeadc0de}, rw_lock = 3735929054}, lle_tbl = 0xdeadc0de, lle_head = 0xdeadc0de, la_hold = 0xdeadc0de, la_expire = -559038242, la_flags = 49374, la_asked = 57005, la_preempt = 49374, ln_byhint = 57005, ln_state = -16162, ln_router = 57005, ln_ntick = -559038242, lle_refcnt = -559038242, ll_addr = {mac_aligned = 16045693110842147038, mac16 = {49374, 57005, 49374}}, lle_timer = {ln_timer_ch = { c_links = {sle = {sle_next = 0xdeadc0de}, tqe = {tqe_next = 0xdeadc0de, tqe_prev = 0xdeadc0de}}, c_time = -559038242, c_arg = 0xdeadc0de, c_func = 0xdeadc0de, c_lock = 0xdeadc0de, c_flags = -559038242, c_cpu = -559038242}, la_timer = {c_links = {sle = {sle_next = 0xdeadc0de}, tqe = { tqe_next = 0xdeadc0de, tqe_prev = 0xdeadc0de}}, c_time = -559038242, c_arg = 0xdeadc0de, c_func = 0xdeadc0de, c_lock = 0xdeadc0de, c_flags = -559038242, c_cpu = -559038242}}} (kgdb) fr 12 #12 0xc09631d1 in lltable_prefix_free (af=2, prefix=0xe8636a94, mask=0xe8636a84) at /usr/src/sys/net/if_llatbl.c:217 217 llt->llt_prefix_free(llt, prefix, mask); (kgdb) list 212 LLTABLE_RLOCK(); 213 SLIST_FOREACH(llt, &V_lltables, llt_link) { 214 if (llt->llt_af != af) 215 continue; 216 217 llt->llt_prefix_free(llt, prefix, mask); 218 } 219 LLTABLE_RUNLOCK(); 220 } 221 So lltable is RLOCKed while the entries are deleted from the table. When callout_drain() is run by one thread other thread has time to destroy lle. Is LLTABLE_RLOCK (and not LLTABLE_WLOCK) in lltable_prefix_free used intentionally? I tried the patch (the second in the attaches) with WLOCK instead of RLOCK and this fixed this type of crashes for me. After this the box was able to live some time with two test scripts running but then crashed in sysctl_iflist(), processing ifa, which is destroyed by other thread: (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc08a92fe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc08a95d2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc0beef23 in trap_fatal (frame=0xe8456a64, eva=3735929054) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc0bef113 in trap_pfault (frame=0xe8456a64, usermode=0, eva=3735929054) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc0befb05 in trap (frame=0xe8456a64) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0bd139b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc096f85e in rt_msg2 (type=12, rtinfo=0xe8456b08, cp=0x0, w=0xe8456b38) at /usr/src/sys/net/rtsock.c:1022 #8 0xc096ff7b in sysctl_rtsock (oidp=0xc0dcb900, arg1=0xe8456c18, arg2=4, req=0xe8456ba4) at /usr/src/sys/net/rtsock.c:1408 #9 0xc08b4598 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1418 #10 0xc08b475c in userland_sysctl (td=0xc636b250, name=0xe8456c10, namelen=6, old=0x0, oldlenp=0xbfbfe048, inkernel=0, new=0x0, newlen=0, retval=0xe8456c70, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1522 #11 0xc08b4b14 in __sysctl (td=0xc636b250, uap=0xe8456cf8) at /usr/src/sys/kern/kern_sysctl.c:1448 #12 0xc0bef3b0 in syscall (frame=0xe8456d38) at /usr/src/sys/i386/i386/trap.c:1111 #13 0xc0bd1430 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 8 #8 0xc096ff7b in sysctl_rtsock (oidp=0xc0dcb900, arg1=0xe8456c18, arg2=4, req=0xe8456ba4) at /usr/src/sys/net/rtsock.c:1408 1408 len = rt_msg2(RTM_NEWADDR, &info, NULL, w); (kgdb) list 1370,1410 1370 static int 1371 sysctl_iflist(int af, struct walkarg *w) 1372 { 1373 struct ifnet *ifp; 1374 struct ifaddr *ifa; 1375 struct rt_addrinfo info; 1376 int len, error = 0; 1377 1378 bzero((caddr_t)&info, sizeof(info)); 1379 IFNET_RLOCK(); 1380 TAILQ_FOREACH(ifp, &V_ifnet, if_link) { 1381 if (w->w_arg && w->w_arg != ifp->if_index) 1382 continue; 1383 ifa = ifp->if_addr; 1384 info.rti_info[RTAX_IFP] = ifa->ifa_addr; 1385 len = rt_msg2(RTM_IFINFO, &info, NULL, w); 1386 info.rti_info[RTAX_IFP] = NULL; 1387 if (w->w_req && w->w_tmem) { 1388 struct if_msghdr *ifm; 1389 1390 ifm = (struct if_msghdr *)w->w_tmem; 1391 ifm->ifm_index = ifp->if_index; 1392 ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags; 1393 ifm->ifm_data = ifp->if_data; 1394 ifm->ifm_addrs = info.rti_addrs; 1395 error = SYSCTL_OUT(w->w_req,(caddr_t)ifm, len); 1396 if (error) 1397 goto done; 1398 } 1399 while ((ifa = TAILQ_NEXT(ifa, ifa_link)) != NULL) { 1400 if (af && af != ifa->ifa_addr->sa_family) 1401 continue; 1402 if (prison_if(w->w_req->td->td_ucred, 1403 ifa->ifa_addr) != 0) 1404 continue; 1405 info.rti_info[RTAX_IFA] = ifa->ifa_addr; 1406 info.rti_info[RTAX_NETMASK] = ifa->ifa_netmask; 1407 info.rti_info[RTAX_BRD] = ifa->ifa_dstaddr; 1408 len = rt_msg2(RTM_NEWADDR, &info, NULL, w); 1409 if (w->w_req && w->w_tmem) { 1410 struct ifa_msghdr *ifam; (kgdb) fr 7 #7 0xc096f85e in rt_msg2 (type=12, rtinfo=0xe8456b08, cp=0x0, w=0xe8456b38) at /usr/src/sys/net/rtsock.c:1022 1022 rtinfo->rti_addrs |= (1 << i); (kgdb) p *rtinfo $2 = {rti_addrs = 4, rti_info = {0x0, 0x0, 0xdeadc0de, 0x0, 0x0, 0xdeadc0de, 0x0, 0xdeadc0de}, rti_flags = 0, rti_ifa = 0x0, rti_ifp = 0x0} The third patch fixed this type of crashes. But the crashes were still possible: panic: Bad link elm 0xc876ea00 prev->next != elm #0 doadump () at pcpu.h:246 #1 0xc04ec829 in db_fncall (dummy1=-1064461270, dummy2=0, dummy3=-1, dummy4=0xe880d784 "\230×\200è") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04ecc5f in db_command (last_cmdp=0xc0e0ac9c, cmd_table=0x0, dopager=0) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04ecd14 in db_command_script (command=0xc0e0bbc4 "call doadump") at /usr/src/sys/ddb/db_command.c:516 #4 0xc04f0e50 in db_script_exec (scriptname=0xe880d890 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available. ) at /usr/src/sys/ddb/db_script.c:302 #5 0xc04f0f37 in db_script_kdbenter (eventname=0xc0cc770a "panic") at /usr/src/sys/ddb/db_script.c:324 #6 0xc04eec18 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228 #7 0xc08d9aa6 in kdb_trap (type=3, code=0, tf=0xe880d9cc) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xc0befcfb in trap (frame=0xe880d9cc) at /usr/src/sys/i386/i386/trap.c:690 #9 0xc0bd141b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc08d9c2a in kdb_enter (why=0xc0cc770a "panic", msg=0xc0cc770a "panic") at cpufunc.h:71 #11 0xc08a95b6 in panic (fmt=0xc0c61cc0 "Bad link elm %p prev->next != elm") at /usr/src/sys/kern/kern_shutdown.c:562 #12 0xc09b8efc in in_ifinit (ifp=0xc5b94c00, ia=0xc876ea00, sin=0xc185fcf6, scrub=0) at /usr/src/sys/netinet/in.c:844 #13 0xc09ba58b in in_control (so=0xc7b13ce0, cmd=2151704858, data=0xc7841bc0 "fxp0", ifp=0xc5b94c00, td=0xc818db90) at /usr/src/sys/netinet/in.c:564 #14 0xc095d400 in ifioctl (so=0xc7b13ce0, cmd=2151704858, data=0xc7841bc0 "fxp0", td=0xc818db90) at /usr/src/sys/net/if.c:2516 #15 0xc08f69d5 in soo_ioctl (fp=0xc70a84d0, cmd=2151704858, data=0xc7841bc0, active_cred=0xc78dc400, td=0xc818db90) at /usr/src/sys/kern/sys_socket.c:212 #16 0xc08f0a2d in kern_ioctl (td=0xc818db90, fd=3, com=2151704858, data=0xc7841bc0 "fxp0") at file.h:262 #17 0xc08f0bb4 in ioctl (td=0xc818db90, uap=0xe880dcf8) at /usr/src/sys/kern/sys_generic.c:678 #18 0xc0bef430 in syscall (frame=0xe880dd38) at /usr/src/sys/i386/i386/trap.c:1111 #19 0xc0bd14b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 12 #12 0xc09b8efc in in_ifinit (ifp=0xc5b94c00, ia=0xc876ea00, sin=0xc185fcf6, scrub=0) at /usr/src/sys/netinet/in.c:844 844 LIST_REMOVE(ia, ia_hash); (kgdb) list in_ifinit 832 * and routing table entry. 833 */ 834 static int 835 in_ifinit(struct ifnet *ifp, struct in_ifaddr *ia, struct sockaddr_in *sin, 836 int scrub) 837 { 838 register u_long i = ntohl(sin->sin_addr.s_addr); 839 struct sockaddr_in oldaddr; 840 int s = splimp(), flags = RTF_UP, error = 0; 841 (kgdb) 842 oldaddr = ia->ia_addr; 843 if (oldaddr.sin_family == AF_INET) 844 LIST_REMOVE(ia, ia_hash); 845 ia->ia_addr = *sin; 846 if (ia->ia_addr.sin_family == AF_INET) { 847 IN_IFADDR_WLOCK(); 848 LIST_INSERT_HEAD(INADDR_HASH(ia->ia_addr.sin_addr.s_addr), 849 ia, ia_hash); 850 IN_IFADDR_WUNLOCK(); 851 } Applying the fourth patch fixed this. But it is still possible to crash the box: #0 doadump () at pcpu.h:246 #1 0xc04ec829 in db_fncall (dummy1=1, dummy2=0, dummy3=-1056922624, dummy4=0xe847c890 "") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04ecc21 in db_command (last_cmdp=0xc0e0ad1c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04ecd7a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04eec1d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc08d9aa6 in kdb_trap (type=12, code=0, tf=0xe847ca7c) at /usr/src/sys/kern/subr_kdb.c:535 #6 0xc0beefbf in trap_fatal (frame=0xe847ca7c, eva=3735929146) at /usr/src/sys/i386/i386/trap.c:929 #7 0xc0bef8e0 in trap (frame=0xe847ca7c) at /usr/src/sys/i386/i386/trap.c:328 #8 0xc0bd147b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #9 0xc09b9c24 in in_control (so=0xc6e29670, cmd=2149607705, data=0xc6246ba0 "fxp0", ifp=0xc5b94c00, td=0xc6a59940) at /usr/src/sys/netinet/in.c:331 #10 0xc095d400 in ifioctl (so=0xc6e29670, cmd=2149607705, data=0xc6246ba0 "fxp0", td=0xc6a59940) at /usr/src/sys/net/if.c:2516 #11 0xc08f69d5 in soo_ioctl (fp=0xc6374700, cmd=2149607705, data=0xc6246ba0, active_cred=0xc7131280, td=0xc6a59940) at /usr/src/sys/kern/sys_socket.c:212 #12 0xc08f0a2d in kern_ioctl (td=0xc6a59940, fd=3, com=2149607705, data=0xc6246ba0 "fxp0") at file.h:262 #13 0xc08f0bb4 in ioctl (td=0xc6a59940, uap=0xe847ccf8) at /usr/src/sys/kern/sys_generic.c:678 #14 0xc0bef490 in syscall (frame=0xe847cd38) at /usr/src/sys/i386/i386/trap.c:1111 #15 0xc0bd1510 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 9 #9 0xc09b9c24 in in_control (so=0xc6e29670, cmd=2149607705, data=0xc6246ba0 "fxp0", ifp=0xc5b94c00, td=0xc6a59940) at /usr/src/sys/netinet/in.c:331 331 if (iap->ia_ifp == ifp && (kgdb) list 326 * first one on the interface, if possible. 327 */ 328 dst = ((struct sockaddr_in *)&ifr->ifr_addr)->sin_addr; 329 IN_IFADDR_RLOCK(); 330 LIST_FOREACH(iap, INADDR_HASH(dst.s_addr), ia_hash) { 331 if (iap->ia_ifp == ifp && 332 iap->ia_addr.sin_addr.s_addr == dst.s_addr) { 333 if (td == NULL || prison_check_ip4(td->td_ucred, 334 &dst) == 0) 335 ia = iap; (kgdb) p iap $1 = (struct in_ifaddr *) 0xdeadc0de But I don't have the patch for this yet :-). Also I have noticed that after running my tests long enough (but not so long to crash the box) the error message starts to appear on every attempt to add tested alias IP (although the alias is created): ifconfig: ioctl (SIOCAIFADDR): File exists This is because the route is not deleted on alias removal (some reference leak?). After removing the route manually the error does not appear. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=in.c.in_control.patch --- sys/netinet/in.c.orig 2010-04-16 15:15:07.000000000 +0300 +++ sys/netinet/in.c 2010-04-18 17:22:57.000000000 +0300 @@ -601,8 +601,17 @@ in_control(struct socket *so, u_long cmd } IF_ADDR_LOCK(ifp); - TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); + TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { + if (&ia->ia_ifa == ifa) { + TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); + break; + } + } IF_ADDR_UNLOCK(ifp); + if (ifa == NULL) { + error = EADDRNOTAVAIL; + goto out; + } ifa_free(&ia->ia_ifa); /* if_addrhead */ IN_IFADDR_WLOCK(); --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=if_llatbl.c.lltable_prefix_free.patch --- sys/net/if_llatbl.c.orig 2010-04-18 22:38:58.000000000 +0300 +++ sys/net/if_llatbl.c 2010-04-18 22:39:13.000000000 +0300 @@ -209,14 +209,14 @@ lltable_prefix_free(int af, struct socka { struct lltable *llt; - LLTABLE_RLOCK(); + LLTABLE_WLOCK(); SLIST_FOREACH(llt, &V_lltables, llt_link) { if (llt->llt_af != af) continue; llt->llt_prefix_free(llt, prefix, mask); } - LLTABLE_RUNLOCK(); + LLTABLE_WUNLOCK(); } --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=rtsock.c.sysctl_iflist.patch --- sys/net/rtsock.c.orig 2010-04-19 08:19:48.000000000 +0300 +++ sys/net/rtsock.c 2010-04-19 08:26:02.000000000 +0300 @@ -1380,6 +1380,7 @@ sysctl_iflist(int af, struct walkarg *w) TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (w->w_arg && w->w_arg != ifp->if_index) continue; + IF_ADDR_LOCK(ifp); ifa = ifp->if_addr; info.rti_info[RTAX_IFP] = ifa->ifa_addr; len = rt_msg2(RTM_IFINFO, &info, NULL, w); @@ -1419,10 +1420,13 @@ sysctl_iflist(int af, struct walkarg *w) goto done; } } + IF_ADDR_UNLOCK(ifp); info.rti_info[RTAX_IFA] = info.rti_info[RTAX_NETMASK] = info.rti_info[RTAX_BRD] = NULL; } done: + if (ifp) + IF_ADDR_UNLOCK(ifp); IFNET_RUNLOCK(); return (error); } --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=in.c.in_ifinit.2.patch --- sys/netinet/in.c.in_control 2010-04-18 21:00:37.000000000 +0300 +++ sys/netinet/in.c 2010-04-20 13:08:41.000000000 +0300 @@ -836,19 +836,25 @@ in_ifinit(struct ifnet *ifp, struct in_i int scrub) { register u_long i = ntohl(sin->sin_addr.s_addr); + register struct in_ifaddr *iap; struct sockaddr_in oldaddr; int s = splimp(), flags = RTF_UP, error = 0; oldaddr = ia->ia_addr; - if (oldaddr.sin_family == AF_INET) - LIST_REMOVE(ia, ia_hash); + IN_IFADDR_WLOCK(); + if (oldaddr.sin_family == AF_INET) { + LIST_FOREACH(iap, INADDR_HASH(oldaddr.sin_addr.s_addr), ia_hash) { + if (iap == ia) { + LIST_REMOVE(ia, ia_hash); + break; + } + } + } ia->ia_addr = *sin; - if (ia->ia_addr.sin_family == AF_INET) { - IN_IFADDR_WLOCK(); + if (ia->ia_addr.sin_family == AF_INET) LIST_INSERT_HEAD(INADDR_HASH(ia->ia_addr.sin_addr.s_addr), ia, ia_hash); - IN_IFADDR_WUNLOCK(); - } + IN_IFADDR_WUNLOCK(); /* * Give the interface a chance to initialize * if this is its first address, --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 05:52:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9A9B106567F for ; Wed, 21 Apr 2010 05:52:45 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 85FDC8FC08 for ; Wed, 21 Apr 2010 05:52:45 +0000 (UTC) Received: (qmail 23056 invoked by uid 0); 21 Apr 2010 05:26:04 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Apr 2010 05:26:04 -0000 Date: Wed, 21 Apr 2010 01:26:03 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: 8.0 carp problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 05:52:46 -0000 Hello, I still need to gather more info when I visit the datacenter to reboot one of the problematic hosts, but I wanted to verify my basic carp config here was solid. I have two hosts that are running a recursing name server on our internal network for other servers. Since failover from multiple entries in resolv.conf is painfully slow, I decided to start using carp to deal with possible dns failure by having pairs of boxes setup with carp in arpbalance mode. Testing in vmware proved this works well... However, after about 18 hours, one of the carp hosts (with an fxp interface) paniced. Then after coming back up after that, it hard locked - no serial console response, no ping response on either internal or external interfaces. The other carp host (em interface) continues to run with no issues. My config on each box is pretty simple: carp-1: (rc.conf) ifconfig_fxp1="inet 192.168.1.107 netmask 255.255.255.0 media 100baseTX mediaopt full-duplex" # carp stuff - this sets up two vhids, required for arpbalance cloned_interfaces="carp0 carp1" ifconfig_carp0="vhid 1 pass foobar 192.168.1.254/24" ifconfig_carp1="vhid 2 advskew 100 pass foobar 192.168.1.254/24" (sysctl.conf) net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 carp-2: (rc.conf) ifconfig_em0="inet 192.168.1.121 netmask 255.255.255.0 media 1000baseTX mediaopt full-duplex" # carp stuff - this sets up two vhids, required for arpbalance cloned_interfaces="carp0 carp1" ifconfig_carp0="vhid 1 advskew 100 pass foobar 192.168.1.254/24" ifconfig_carp1="vhid 2 pass foobar 192.168.1.254/24" (sysctl.conf) net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 When the carp-1 paniced, this is what I saw in carp-2's logs: Apr 20 22:32:40 h21 kernel: carp0: link state changed to UP Apr 20 22:39:52 h21 kernel: carp0: incorrect hash Apr 20 22:39:52 h21 kernel: carp1: incorrect hash Apr 20 22:39:52 h21 kernel: arp: 00:00:5e:00:01:02 is using my IP address 192.168.1.254 on em0! Apr 20 22:39:54 h21 kernel: carp0: link state changed to DOWN Apr 20 22:40:19 h21 kernel: carp0: link state changed to UP carp-1 managed to squirt this out on the console before locking up: fxp1: discard frame w/o leading ethernet header (len 4294967294 pkt len 4294967294) I'm bringing this up here since I've seen some traffic on -stable lately regarding issues with some of the intel nics. I figure carp is probably doing some "interesting" things to create virtual macs and the like. The two nics I'm using are as follows. carp-1: fxp1: port 0xd000-0xd03f mem 0xfe9fd000-0xfe9fdfff,0xfe600000-0xfe6fffff irq 21 at device 5.0 on pci0^M miibus1: on fxp1 inphy1: PHY 1 on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:e0:81:03:b0:13 fxp1: [ITHREAD] carp-2: em0: port 0x3800-0x381f mem 0xfc220000-0xfc23ffff,0xfc200000-0xfc21ffff irq 31 at device 4.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:30:48:12:2d:60 I've not fiddled with any settings on either nic beyond forcing media and duplex - so if checksum offloading is enabled/disabled by default, that's what I'd be using. I can supply more information if needed. I need to boot the locked box, enable dumps, and get more info on the revision of the fxp nics on it. Thanks, Charles From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 05:58:25 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 232AE1065673; Wed, 21 Apr 2010 05:58:25 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF86F8FC22; Wed, 21 Apr 2010 05:58:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3L5wOMX037391; Wed, 21 Apr 2010 05:58:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3L5wOLR037387; Wed, 21 Apr 2010 05:58:24 GMT (envelope-from linimon) Date: Wed, 21 Apr 2010 05:58:24 GMT Message-Id: <201004210558.o3L5wOLR037387@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145905: [fxp] multicast packets aren't received when PROMISC mode on fxp. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 05:58:25 -0000 Old Synopsis: multicast packets aren't received when PROMISC mode on fxp. New Synopsis: [fxp] multicast packets aren't received when PROMISC mode on fxp. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 21 05:57:31 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145905 From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 07:55:09 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4873106564A; Wed, 21 Apr 2010 07:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 10B938FC13; Wed, 21 Apr 2010 07:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 1C97541C707; Wed, 21 Apr 2010 09:55:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 4fK10W4iQAFT; Wed, 21 Apr 2010 09:55:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id EBADE41C6DB; Wed, 21 Apr 2010 09:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9F81E4448EC; Wed, 21 Apr 2010 07:54:46 +0000 (UTC) Date: Wed, 21 Apr 2010 07:54:46 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: pluknet In-Reply-To: Message-ID: <20100421074959.J40281@maildrop.int.zabbadoz.net> References: <201004200748.09566.jhb@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-945982823-1271836486=:40281" Cc: freebsd-stable@freebsd.org, c0re , John Baldwin , net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:55:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-945982823-1271836486=:40281 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Apr 2010, pluknet wrote: > On 20 April 2010 15:48, John Baldwin wrote: >> On Tuesday 20 April 2010 2:53:16 am c0re wrote: >>> Hello All! >>> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to >>> configure gre interface and use ipfw fwd. >>> I'm actually does not know what was the point of failure in my >>> configuration. >>> >>> [ some details snipped ] >>> >>> It worked about one week and then I made some configuration changes: >>> added gre interface and 2 aliases: >>> >>> # cat /etc/rc.conf |grep >>> ifconfig_xl0=3D"inet 192.168.0.10 =A0netmask 255.255.255.0" >>> ifconfig_xl0_alias0=3D"192.168.0.11 netmask 255.255.255.255" >>> ifconfig_xl0_alias1=3D"192.168.0.12 netmask 255.255.255.255" >>> cloned_interfaces=3D"gre0" >>> ifconfig_gre0=3D"inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 >>> 192.168.200.15 netmask 255.255.255.252 link1 up" >>> >>> and >>> >>> # cat /etc/rc.local >>> #!/bin/sh >>> ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 >>> ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 >>> ipfw add allow ip from any to any >>> >>> # ifconfig gre0 >>> gre0: flags=3Db050 metric 0 = mtu >>> 1476 >>> =A0 =A0 =A0 =A0 tunnel inet 192.168.0.12 --> 192.168.200.15 >>> =A0 =A0 =A0 =A0 inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc >>> >>> I shutted down gre interface to prevent requests via gre to buggy IP. >>> >>> The main idea of such configurations was: fwd all connections to https = to >>> 192.168.0.1 via gre interface. >>> And also I made apache configurations to make it listen on 192.168.0.11= too. >>> >>> And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet= to >>> 192.168.0.11 =A0443 was fine too. Then I tryed to make browser https >>> connection to 192.168.0.11. Apache showed me certificate warning and I >>> accepted, then in browser nothing happened, it was trying to open page.= But >>> server got kernel panic at that moment. >>> >>> At first time I thought that it was some power failure, I tryed 2 more = times >>> and got same behaviour. >>> >>> So https works without kernel panic via 192.168.0.10 address but kernel >>> panics when I try do https via 192.168.0.11 address that source-forward= ed >>> via gre. >> >> Looks like the TCP output path got stuck in an infinite recursion loop u= ntil >> it exhausted the kernel stack: >> >>> # cd /usr/obj/usr/src/sys/MYKERNEL >>> # kgdb kernel.debug /var/crash/vmcore.2 >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and yo= u are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. =A0Type "show warranty" for de= tails. >>> This GDB was configured as "i386-marcel-freebsd"... >>> >>> Unread portion of the kernel message buffer: >>> >>> Fatal double fault: >>> eip =3D 0xc08e3ba3 >>> esp =3D 0xccf6dfc4 >>> ebp =3D 0xccf6e274 >>> cpuid =3D 0; apic id =3D 00 >>> panic: double fault >>> cpuid =3D 0 >>> Uptime: 7m14s >>> Physical memory: 235 MB >>> Dumping 35 MB: 20 4 >>> >>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >>> /boot/kernel/acpi.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/acpi.ko >>> Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from >>> /boot/kernel/if_gre.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/if_gre.ko >>> Reading symbols from /boot/kernel/linux.ko...Reading symbols from >>> /boot/kernel/linux.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/linux.ko >>> #0 =A0doadump () at pcpu.h:196 >>> 196 =A0 =A0 =A0 =A0 =A0 =A0 __asm __volatile("movl %%fs:0,%0" : "=3Dr" = (td)); >>> (kgdb) bt >>> #0 =A0doadump () at pcpu.h:196 >>> #1 =A00xc07f2857 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdo= wn.c:418 >>> #2 =A00xc07f2b29 in panic (fmt=3DVariable "fmt" is not available. >>> ) at /usr/src/sys/kern/kern_shutdown.c:574 >>> #3 =A00xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.= c:983 >>> #4 =A00xc08e3ba3 in ipfw_chk (args=3D0xccf6e28c) at >>> /usr/src/sys/netinet/ip_fw2.c:2465 >>> #5 =A00xc08e6ce1 in ipfw_check_out (arg=3D0x0, m0=3D0xccf6e390, ifp=3D0= xc25c5c00, >>> dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 >>> #6 =A00xc08a1968 in pfil_run_hooks (ph=3D0xc0c55240, mp=3D0xccf6e420, >>> ifp=3D0xc25c5c00, dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/net/pfil.c= :78 >>> #7 =A00xc08eb6f2 in ip_output (m=3D0xc2710b00, opt=3D0x0, ro=3D0xccf6e3= f4, flags=3D0, >>> imo=3D0x0, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 >>> #8 =A00xc08f4016 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1134 [twiddle] >>> #47 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> #48 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #49 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> ---Type to continue, or q to quit--- >>> #50 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #51 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> #52 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #53 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> #54 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #55 0xc08fdcf8 in tcp_usr_send (so=3D0xc2ac1820, flags=3D0, m=3D0xc270e= d00, >>> nam=3D0x0, control=3D0x0, td=3D0xc28e2d80) at tcp_offload.h:269 >>> #56 0xc0850405 in sosend_generic (so=3D0xc2ac1820, addr=3D0x0, uio=3D0x= c28766c0, >>> top=3D0xc270ed00, control=3D0x0, flags=3D0, td=3D0xc28e2d80) at >>> /usr/src/sys/kern/uipc_socket.c:1243 >>> #57 0xc084bf7f in sosend (so=3D0xc2ac1820, addr=3D0x0, uio=3D0xc28766c0= , top=3D0x0, >>> control=3D0x0, flags=3D0, td=3D0xc28e2d80) at /usr/src/sys/kern/uipc_so= cket.c:1285 >>> #58 0xc0833c5b in soo_write (fp=3D0xc28e84c0, uio=3D0xc28766c0, >>> active_cred=3D0xc28e5900, flags=3D0, td=3D0xc28e2d80) at >>> /usr/src/sys/kern/sys_socket.c:103 >>> #59 0xc082d2e7 in dofilewrite (td=3D0xc28e2d80, fd=3D24, fp=3D0xc28e84c= 0, >>> auio=3D0xc28766c0, offset=3D-1, flags=3D0) at file.h:257 >>> #60 0xc082d5c8 in kern_writev (td=3D0xc28e2d80, fd=3D24, auio=3D0xc2876= 6c0) at >>> /usr/src/sys/kern/sys_generic.c:402 >>> #61 0xc082d816 in writev (td=3D0xc28e2d80, uap=3D0xccf6fcfc) at >>> /usr/src/sys/kern/sys_generic.c:388 >>> #62 0xc0a7f2d5 in syscall (frame=3D0xccf6fd38) at >>> /usr/src/sys/i386/i386/trap.c:1101 >>> #63 0xc0a636a0 in Xint0x80_syscall () at >>> /usr/src/sys/i386/i386/exception.s:262 >>> #64 0x00000033 in ?? () >>> Previous frame inner to this frame (corrupt stack?) >>> (kgdb) >>> (kgdb) quit >> >> tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case EMSGSIZE: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * For some reason the in= terface we used initially >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * to send segments chang= ed to another or lowered >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its MTU. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * tcp_mtudisc() will fin= d out the new MTU and as >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its last action, initi= ate retransmission, so it >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * is important to not do= so here. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * If TSO was active we e= ither got an interface >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * without TSO capabilits= or TSO was turned off. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Disable it for this co= nnection as too and >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * immediatly retry with = MSS sized segments generated >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * by this function. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tso) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tp->t_fla= gs &=3D ~TF_TSO; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tcp_mtudisc(tp->t_inpcb, = 0); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); >> >> But tcp_mtudisc() calls tcp_output(): >> >> =A0 =A0 =A0 =A0tcpstat.tcps_mturesent++; >> =A0 =A0 =A0 =A0tp->t_rtttime =3D 0; >> =A0 =A0 =A0 =A0tp->snd_nxt =3D tp->snd_una; >> =A0 =A0 =A0 =A0tcp_free_sackholes(tp); >> =A0 =A0 =A0 =A0tp->snd_recover =3D tp->snd_max; >> =A0 =A0 =A0 =A0if (tp->t_flags & TF_SACK_PERMIT) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EXIT_FASTRECOVERY(tp); >> =A0 =A0 =A0 =A0tcp_output_send(tp); >> =A0 =A0 =A0 =A0return (inp); >> >> I'm not sure why it's not able to figure out the MTU, perhaps folks on n= et@ >> can help. =A0However, it would seem that for the tcp_output() case, >> tcp_mtudisc() should probably not call tcp_output_send(), but instead >> tcp_output() should just loop back up to the top after calling tcp_mtudi= sc() >> and retry. >> > > I'm afraid to be wrong but it looks similar to another report for 8.0-STA= BLE > (may it be a cross-major version regression somewhere around tcp_mtudisc(= )?): > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056063.html The backtrace indeed looks very similar. The reporter at that point had been cvs updated in the middle between two commits. Updating again seemed to have fixed it for him. None of those changes are in 7.3-RELEASE though and the endless loop indeed should no happen. Is the kernel and the core file still avail for further analyses? /bz --=20 Bjoern A. Zeeb It will not break if you know what you are doing. --0-945982823-1271836486=:40281-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 09:07:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FA6E106566C for ; Wed, 21 Apr 2010 09:07:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 9E89C8FC1A for ; Wed, 21 Apr 2010 09:07:38 +0000 (UTC) Received: by bwz28 with SMTP id 28so7925164bwz.14 for ; Wed, 21 Apr 2010 02:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sGLB1li88yVIL7vw6DduvXyTqQoSldKlWkn4ZmVNoKQ=; b=iCiO157NnbSGUY6LR5Fhy9wg2i4557YGIQUUGKHo0JIW3kdulb+KTPbo9jQiwGYYcT BKohNs22Hnpa4up58B0SRvzpmb5YkmjDJ8RXyzjJNluVNZsDeFlWX16wH8es/f37B6j9 DkzoehF2oOmhijZ2KYfzNJMSyZyWrytr/cXWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DoI0EMDs7Nk3pHvMqgtEcjqfMIj+VwbfeKYVtwweWPNZ2J2eoBtxI66rL+x7mw+JMT Wk9j503zj19O+j2XHKMOODY8xtS/DCZQECrJ5s/wfEmZPEdJdqxCWzFlMAtPt3G3rbrH BEDSh/Q5aKetVoKyP3ku7RUSvae8apYido1tI= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Wed, 21 Apr 2010 02:07:37 -0700 (PDT) In-Reply-To: <200911301620.nAUGK9U3085078@ambrisko.com> References: <200911301620.nAUGK9U3085078@ambrisko.com> Date: Wed, 21 Apr 2010 13:07:37 +0400 Received: by 10.204.133.146 with SMTP id f18mr6181360bkt.153.1271840857274; Wed, 21 Apr 2010 02:07:37 -0700 (PDT) Message-ID: From: pluknet To: Doug Ambrisko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: svn commit: r198994 - in stable/6/sys/dev: bce mii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:07:39 -0000 On 30 November 2009 20:20, Doug Ambrisko wrote: > pluknet writes: > [ Charset ISO-8859-1 unsupported, converting... ] > | 2009/11/6 Doug Ambrisko : > | > Author: ambrisko > | > Date: Fri Nov ?6 17:58:44 2009 > | > New Revision: 198994 > | > URL: http://svn.freebsd.org/changeset/base/198994 > | > > | > Log: > | > ?MFC: Merge in minimal 5709/5716 support into 6.X extracted from curr= ent. > | > ?This is not a direct merge since I tried to only extra the changes t= o > | > ?support the 5709 from all of the other changes that have happened in > | > ?head. ?This should not introduce any issues that the other changes m= ay > | > ?have caused. ?We have been running this code for months on Dell r710= 's. > | > ?It has been lightly tested on systems with 5716's. > | > > | > ?This is to allow people to run newer hardware on 6.X. > | > | Very nice. Thank you. > | > | I'm afraid not all the chunks were merged since I cannot run on 6.x > | with my BCM5709. > | > | FreeBSD 7.2 - works > | FreeBSD 6.4-stable - does not > | > | It locks up somewhere in the late stage of multiuser (usually in a > | random step of rc.d) and getty cannot take the control. > | Here it still pings via network, I can achieve ssh stage where ssh > | warns me "The authenticity of host '$HOST' can't be established." > | If I type "yes", then it stops here and no go. After return from ddb > | it stops even ping until next reboot. > | > | I use boot via NFS/PXE, so it may interfere there, since rc.d usually > | write something to disk, which is NFS-mounted here. > | So it probably could run fine if booting from a local disk (I can't > | test this setup). > > You might try to instrument the rc stuff even though you mention it > appears random. =A0Might try to make sure that it isn't re-initializing > the network or something like that. =A0I tried with a fresh checkout > of 6-stable and I PXE booted it fine. =A0A side note is that Dell's > have a bug with their uarts starting with the 2950 rev 2 in which > the TX does work with the speed that we do the reset. =A0RX works > fine so you can recover it with a {Ctrl}d since it doesn't always > fail. > > | I've attached dmesg (doesn't differs much from 7.2) and some ddb output= below. > | Looking in alltrace I see no obvious lockups, no nfs stuck. But > | sometimes sh stucks somewhere in nfsreq. > | > | The same box boots fine via NFS on different NFS setup with 7.2, > | a different (in h/w) box boots fine on these NFS setup and NFS root, > | so no mistakes in setup part. > | > | I remember that back to August I tried to boot 6.4 with what is in bce > | of RELENG_7 on this box and it booted fine and I xmitted some traffic > | with it. > | So I guess the problem is in NFS-boot. > | > | I'll try to find ways to boot the system locally and report back.. > > I didn't see anything in the logs. > > Doug A. > For archives: It tried to boot 6.4-STABLE one more time recently and all's fine. Shame on me and sorry for noise. --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 13:10:06 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FC71106566B for ; Wed, 21 Apr 2010 13:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 034DD8FC14 for ; Wed, 21 Apr 2010 13:10:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3LDA5cl040192 for ; Wed, 21 Apr 2010 13:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3LDA5kZ040191; Wed, 21 Apr 2010 13:10:05 GMT (envelope-from gnats) Date: Wed, 21 Apr 2010 13:10:05 GMT Message-Id: <201004211310.o3LDA5kZ040191@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Simonenko Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Simonenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 13:10:06 -0000 The following reply was made to PR bin/131567; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@freebsd.org Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg Date: Wed, 21 Apr 2010 16:08:13 +0300 Updated version of unix_cmsg now works correctly on FreeBSD 8.0-STABLE and 9.0-CURRENT, where data returned in groups array was changed. The "TODO" was removed from several tests, since they are passed correctly on 8.0-STABLE and 9.0-CURRENT. diff -ruNp unix_cmsg.orig/README unix_cmsg/README --- unix_cmsg.orig/README 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/README 2010-04-21 12:28:59.000000000 +0300 @@ -1,7 +1,7 @@ $FreeBSD: src/tools/regression/sockets/unix_cmsg/README,v 1.1 2006/05/29 18:40:55 maxim Exp $ About unix_cmsg -================ +=============== This program is a collection of regression tests for ancillary (control) data for PF_LOCAL sockets (local domain or Unix domain sockets). There @@ -13,8 +13,8 @@ is correct in received message. Sometim messages to Server. It is better to change the owner of unix_cmsg to some safe user -(eg. nobody:nogroup) and set SUID and SGID bits, else some tests -can give correct results for wrong implementation. +(eg. nobody:nogroup) and set SUID and SGID bits, else some tests that +check credentials can give correct results for wrong implementation. Available options ================= @@ -24,13 +24,13 @@ Available options -h Output help message and exit. --t +-t socktype Run tests only for the given socket type: "stream" or "dgram". With this option it is possible to run only particular test, not all of them. -z Do not send real control data if possible. Struct cmsghdr{} - should be followed by real control data. It is not clear if + should be followed by real control data. It is not clear whether a sender should give control data in all cases (this is not documented and an arbitrary application can choose anything). @@ -90,6 +90,13 @@ For SOCK_STREAM sockets: message with data and control message with SCM_TIMESTAMP type followed by struct timeval{}. + 6: Check LOCAL_PEERCRED socket option + + This test does not use control data for PF_LOCAL sockets, but can be + implemented here. Client connects to Server. Both Client and Server + verify that credentials of the peer are correct using LOCAL_PEERCRED + socket option. + For SOCK_DGRAM sockets: ---------------------- @@ -110,7 +117,7 @@ For SOCK_DGRAM sockets: structure should contain correct information. 3: Sending cmsgcred, receiving sockcred - + Server creates datagram socket and set socket option LOCAL_CREDS for it. Client sends one message with data and control message with SOCK_CREDS type to Server. Server should receive one message with diff -ruNp unix_cmsg.orig/unix_cmsg.c unix_cmsg/unix_cmsg.c --- unix_cmsg.orig/unix_cmsg.c 2006-05-31 11:10:34.000000000 +0300 +++ unix_cmsg/unix_cmsg.c 2010-04-21 15:23:45.000000000 +0300 @@ -27,10 +27,12 @@ #include __FBSDID("$FreeBSD: src/tools/regression/sockets/unix_cmsg/unix_cmsg.c,v 1.2 2006/05/31 08:10:34 maxim Exp $"); -#include +#include #include #include +#include #include +#include #include #include @@ -38,16 +40,15 @@ __FBSDID("$FreeBSD: src/tools/regression #include #include #include +#include #include #include -#include #include #include #include #include #include #include -#include #include /* @@ -68,7 +69,7 @@ __FBSDID("$FreeBSD: src/tools/regression * * Each function which can block, is run under TIMEOUT, if timeout * occurs, then test function returns -2 or a client process exits - * with nonzero return code. + * with non-zero return code. */ #ifndef LISTENQ @@ -76,46 +77,76 @@ __FBSDID("$FreeBSD: src/tools/regression #endif #ifndef TIMEOUT -# define TIMEOUT 60 +# define TIMEOUT 5 #endif #define EXTRA_CMSG_SPACE 512 /* Memory for not expected control data. */ -static int t_cmsgcred(void), t_sockcred_stream1(void); -static int t_sockcred_stream2(void), t_cmsgcred_sockcred(void); -static int t_sockcred_dgram(void), t_timestamp(void); +static int t_cmsgcred(void); +static int t_sockcred_stream1(void); +static int t_sockcred_stream2(void); +static int t_cmsgcred_sockcred(void); +static int t_sockcred_dgram(void); +static int t_timestamp(void); +static int t_peercred(void); struct test_func { - int (*func)(void); /* Pointer to function. */ - const char *desc; /* Test description. */ + int (*func)(void); /* Pointer to function. */ + const char *desc; /* Test description. */ }; -static struct test_func test_stream_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_stream1, " 2: Receiving sockcred (listening socket has LOCAL_CREDS)" }, - { t_sockcred_stream2, " 3: Receiving sockcred (accepted socket has LOCAL_CREDS)" }, - { t_cmsgcred_sockcred, " 4: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 5: Sending, receiving timestamp" }, - { NULL, NULL } +static const struct test_func test_stream_tbl[] = { + { .func = NULL, + .desc = "All tests" + }, + { .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { .func = t_sockcred_stream1, + .desc = "Receiving sockcred (listening socket has LOCAL_CREDS)" + }, + { .func = t_sockcred_stream2, + .desc = "Receiving sockcred (accepted socket has LOCAL_CREDS)" + }, + { .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { .func = t_timestamp, + .desc = "Sending, receiving timestamp" + }, + { .func = t_peercred, + .desc = "Check LOCAL_PEERCRED socket option" + } }; -static struct test_func test_dgram_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_dgram, " 2: Receiving sockcred" }, - { t_cmsgcred_sockcred, " 3: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 4: Sending, receiving timestamp" }, - { NULL, NULL } +#define TEST_STREAM_TBL_SIZE \ + (sizeof(test_stream_tbl) / sizeof(test_stream_tbl[0])) + +static const struct test_func test_dgram_tbl[] = { + { .func = NULL, + .desc = "All tests" + }, + { .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { .func = t_sockcred_dgram, + .desc = "Receiving sockcred" + }, + { .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { .func = t_timestamp, + .desc = "Sending, receiving timestamp" + } }; -#define TEST_STREAM_NO_MAX (sizeof(test_stream_tbl) / sizeof(struct test_func) - 2) -#define TEST_DGRAM_NO_MAX (sizeof(test_dgram_tbl) / sizeof(struct test_func) - 2) +#define TEST_DGRAM_TBL_SIZE \ + (sizeof(test_dgram_tbl) / sizeof(test_dgram_tbl[0])) -static const char *myname = "SERVER"; /* "SERVER" or "CLIENT" */ +static const char *myname; /* "SERVER" or "CLIENT" */ -static int debug = 0; /* 1, if -d. */ -static int no_control_data = 0; /* 1, if -z. */ +static int debug = 0; /* -d */ +static int no_control_data = 0; /* -z */ static u_int nfailed = 0; /* Number of failed tests. */ @@ -131,17 +162,11 @@ static char ipc_message[] = "hello"; static struct sockaddr_un servaddr; /* Server address. */ -static sigjmp_buf env_alrm; - static uid_t my_uid; static uid_t my_euid; static gid_t my_gid; static gid_t my_egid; -/* - * my_gids[0] is EGID, next items are supplementary GIDs, - * my_ngids determines valid items in my_gids array. - */ static gid_t my_gids[NGROUPS_MAX]; static int my_ngids; @@ -156,32 +181,29 @@ static void logmsg(const char *, ...) __ static void logmsgx(const char *, ...) __printflike(1, 2); static void output(const char *, ...) __printflike(1, 2); -extern char *__progname; /* The name of program. */ - /* * Output the help message (-h switch). */ static void -usage(int quick) +usage(int verbose) { - const struct test_func *test_func; + u_int i; - fprintf(stderr, "Usage: %s [-dhz] [-t ] [testno]\n", - __progname); - if (quick) + fprintf(stderr, "usage: %s [-dhz] [-t socktype] [testno]\n", + getprogname()); + if (!verbose) return; fprintf(stderr, "\n Options are:\n\ -d\t\t\tOutput debugging information\n\ -h\t\t\tOutput this help message and exit\n\ - -t \t\tRun test only for the given socket type:\n\ -\t\t\tstream or dgram\n\ + -t socktype\t\tRun test only for socket type: stream or dgram\n\ -z\t\t\tDo not send real control data if possible\n\n"); fprintf(stderr, " Available tests for stream sockets:\n"); - for (test_func = test_stream_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_STREAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_stream_tbl[i].desc); fprintf(stderr, "\n Available tests for datagram sockets:\n"); - for (test_func = test_dgram_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_DGRAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_dgram_tbl[i].desc); } /* @@ -195,7 +217,7 @@ output(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "output: vsnprintf failed"); + err(EXIT_FAILURE, "output: vsnprintf failed"); write(STDOUT_FILENO, buf, strlen(buf)); va_end(ap); } @@ -210,18 +232,16 @@ logmsg(const char *format, ...) va_list ap; int errno_save; - errno_save = errno; /* Save errno. */ - + errno_save = errno; va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsg: vsnprintf failed"); + err(EXIT_FAILURE, "logmsg: vsnprintf failed"); if (errno_save == 0) output("%s: %s\n", myname, buf); else output("%s: %s: %s\n", myname, buf, strerror(errno_save)); va_end(ap); - - errno = errno_save; /* Restore errno. */ + errno = errno_save; } /* @@ -235,33 +255,47 @@ logmsgx(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsgx: vsnprintf failed"); + err(EXIT_FAILURE, "logmsgx: vsnprintf failed"); output("%s: %s\n", myname, buf); va_end(ap); } /* - * Run tests from testno1 to testno2. + * Run tests for the given socket type. */ static int -run_tests(u_int testno1, u_int testno2) +run_tests(int type, u_int testno1) { - const struct test_func *test_func; - u_int i, nfailed1; + const struct test_func *tf; + u_int i, nfailed1, testno2; - output("Running tests for %s sockets:\n", sock_type_str); - test_func = (sock_type == SOCK_STREAM ? - test_stream_tbl : test_dgram_tbl) + testno1; + sock_type = type; + if (type == SOCK_STREAM) { + sock_type_str = "SOCK_STREAM"; + tf = test_stream_tbl; + i = TEST_STREAM_TBL_SIZE - 1; + } else { + sock_type_str = "SOCK_DGRAM"; + tf = test_dgram_tbl; + i = TEST_DGRAM_TBL_SIZE - 1; + } + if (testno1 == 0) { + testno1 = 1; + testno2 = i; + } else + testno2 = testno1; + output("Running tests for %s sockets:\n", sock_type_str); nfailed1 = 0; - for (i = testno1; i <= testno2; ++test_func, ++i) { - output(" %s\n", test_func->desc); - switch (test_func->func()) { + for (i = testno1, tf += testno1; i <= testno2; ++tf, ++i) { + output(" %u: %s\n", i, tf->desc); + switch (tf->func()) { case -1: ++nfailed1; break; case -2: - logmsgx("some system error occurred, exiting"); + logmsgx("some system error or timeout occurred, " + "exiting"); return (-1); } } @@ -284,38 +318,57 @@ run_tests(u_int testno1, u_int testno2) return (0); } -/* ARGSUSED */ +/* + * Initialize signals handlers. + */ static void -sig_alrm(int signo __unused) +sig_init(void) { - siglongjmp(env_alrm, 1); + struct sigaction sigact; + + sigact.sa_handler = SIG_IGN; + sigact.sa_flags = 0; + sigemptyset(&sigact.sa_mask); + if (sigaction(SIGPIPE, &sigact, (struct sigaction *)NULL) < 0) + err(EXIT_FAILURE, "sigaction(SIGPIPE)"); } /* - * Initialize signals handlers. + * Output this process UID, GID, groups from getgroups(), EUID and EGID. */ static void -sig_init(void) +show_my_id(void) { - struct sigaction sa; + int i; - sa.sa_handler = SIG_IGN; - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - if (sigaction(SIGPIPE, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGPIPE)"); - - sa.sa_handler = sig_alrm; - if (sigaction(SIGALRM, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGALRM)"); + if (!debug) + return; + logmsgx("UID %lu, GID %lu, groups from getgroups():", + (u_long)my_uid, (u_long)my_gid); + for (i = 0; i < my_ngids; ++i) + logmsgx(" GID %lu", (u_long)my_gids[i]); + logmsgx("EUID %lu, EGID %lu", (u_long)my_euid, (u_long)my_egid); +} + +static int +fork_client(void) +{ + client_pid = fork(); + if (client_pid == 0) + myname = "CLIENT"; + else if (client_pid == (pid_t)-1) { + logmsg("fork"); + return (-1); + } + return (0); } int main(int argc, char *argv[]) { const char *errstr; - int opt, dgramflag, streamflag; - u_int testno1, testno2; + u_int testno; + int opt, rv, dgramflag, streamflag; dgramflag = streamflag = 0; while ((opt = getopt(argc, argv, "dht:z")) != -1) @@ -324,141 +377,162 @@ main(int argc, char *argv[]) debug = 1; break; case 'h': - usage(0); - return (EX_OK); + usage(1); + return (EXIT_SUCCESS); case 't': if (strcmp(optarg, "stream") == 0) streamflag = 1; else if (strcmp(optarg, "dgram") == 0) dgramflag = 1; else - errx(EX_USAGE, "wrong socket type in -t option"); + errx(EXIT_FAILURE, "option -t: " + "wrong socket type"); break; case 'z': no_control_data = 1; break; case '?': default: - usage(1); - return (EX_USAGE); + usage(0); + return (EXIT_FAILURE); } if (optind < argc) { if (optind + 1 != argc) - errx(EX_USAGE, "too many arguments"); - testno1 = strtonum(argv[optind], 0, UINT_MAX, &errstr); + errx(EXIT_FAILURE, "too many arguments"); + testno = strtonum(argv[optind], 0, UINT_MAX, &errstr); if (errstr != NULL) - errx(EX_USAGE, "wrong test number: %s", errstr); + errx(EXIT_FAILURE, "wrong test number: %s", errstr); } else - testno1 = 0; + testno = 0; if (dgramflag == 0 && streamflag == 0) dgramflag = streamflag = 1; - if (dgramflag && streamflag && testno1 != 0) - errx(EX_USAGE, "you can use particular test, only with datagram or stream sockets"); + if (dgramflag && streamflag && testno != 0) + errx(EXIT_FAILURE, "you can use particular test, only " + "with datagram or stream sockets"); if (streamflag) { - if (testno1 > TEST_STREAM_NO_MAX) - errx(EX_USAGE, "given test %u for stream sockets does not exist", - testno1); + if (testno >= TEST_STREAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for stream " + "sockets does not exist", testno); } else { - if (testno1 > TEST_DGRAM_NO_MAX) - errx(EX_USAGE, "given test %u for datagram sockets does not exist", - testno1); + if (testno >= TEST_DGRAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for datagram " + "sockets does not exist", testno); } my_uid = getuid(); my_euid = geteuid(); my_gid = getgid(); my_egid = getegid(); - switch (my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids)) { + my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids); + switch (my_ngids) { case -1: - err(EX_SOFTWARE, "getgroups"); + err(EXIT_FAILURE, "getgroups"); /* NOTREACHED */ case 0: - errx(EX_OSERR, "getgroups returned 0 groups"); + errx(EXIT_FAILURE, "getgroups returned no groups"); } sig_init(); if (mkdtemp(tempdir) == NULL) - err(EX_OSERR, "mkdtemp"); - - if (streamflag) { - sock_type = SOCK_STREAM; - sock_type_str = "SOCK_STREAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_STREAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - testno1 = 0; - } + err(EXIT_FAILURE, "mkdtemp"); - if (dgramflag) { - sock_type = SOCK_DGRAM; - sock_type_str = "SOCK_DGRAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_DGRAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - } + myname = "SERVER"; + rv = EXIT_SUCCESS; + show_my_id(); + if (streamflag) + if (run_tests(SOCK_STREAM, testno) < 0) + rv = EXIT_FAILURE; + if (dgramflag && rv == EXIT_SUCCESS) + if (run_tests(SOCK_DGRAM, testno) < 0) + rv = EXIT_FAILURE; if (rmdir(tempdir) < 0) { logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); + rv = EXIT_FAILURE; } - return (nfailed ? EX_OSERR : EX_OK); + return (nfailed > 0 ? EXIT_FAILURE : rv); +} -failed: - if (rmdir(tempdir) < 0) - logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); +/* + * Close socket descriptor, if sock_path is not equal to NULL, + * then unlink the given path. + */ +static int +close_socket(const char *sock_path, int fd) +{ + int rv; + + if (close(fd) < 0) { + logmsg("close_socket: close"); + rv = -1; + } else + rv = 0; + if (sock_path != NULL) + if (unlink(sock_path) < 0) { + logmsg("close_socket: unlink(%s)", sock_path); + rv = -1; + } + return (rv); } /* * Create PF_LOCAL socket, if sock_path is not equal to NULL, then - * bind() it. Return socket address in addr. Return file descriptor + * bind() it. Return socket address in *un. Return file descriptor * or -1 if some error occurred. */ static int -create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *addr) +create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *un) { - int rv, fd; + struct timeval tv; + int fd; - if ((fd = socket(PF_LOCAL, sock_type, 0)) < 0) { - logmsg("create_socket: socket(PF_LOCAL, %s, 0)", sock_type_str); + fd = socket(PF_LOCAL, sock_type, 0); + if (fd < 0) { + logmsg("create_socket: socket(PF_LOCAL, %s, 0)", + sock_type_str); return (-1); } + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) < 0 || + setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv)) < 0) { + logmsg("create_socket: setsockopt(SO_RCVTIMEO/SO_SNDTIMEO)"); + goto failed; + } + if (sock_path != NULL) { - if ((rv = snprintf(sock_path, sock_path_len, "%s/%s", - tempdir, myname)) < 0) { + int rv; + + rv = snprintf(sock_path, sock_path_len, "%s/%s", tempdir, + myname); + if (rv < 0) { logmsg("create_socket: snprintf failed"); goto failed; } if ((size_t)rv >= sock_path_len) { - logmsgx("create_socket: too long path name for given buffer"); + logmsgx("create_socket: too long path name for " + "given buffer"); goto failed; } - - memset(addr, 0, sizeof(addr)); - addr->sun_family = AF_LOCAL; - if (strlen(sock_path) >= sizeof(addr->sun_path)) { - logmsgx("create_socket: too long path name (>= %lu) for local domain socket", - (u_long)sizeof(addr->sun_path)); + if (strlen(sock_path) >= sizeof(un->sun_path)) { + logmsgx("create_socket: too long path name (>= %zu) " + "for local domain socket", sizeof(un->sun_path)); goto failed; } - strcpy(addr->sun_path, sock_path); - if (bind(fd, (struct sockaddr *)addr, SUN_LEN(addr)) < 0) { + memset(un, 0, sizeof(un)); + un->sun_family = PF_LOCAL; + strcpy(un->sun_path, sock_path); + un->sun_len = SUN_LEN(un); + + if (bind(fd, (struct sockaddr *)un, un->sun_len) < 0) { logmsg("create_socket: bind(%s)", sock_path); goto failed; } @@ -473,43 +547,49 @@ failed: } /* - * Call create_socket() for server listening socket. - * Return socket descriptor or -1 if some error occurred. + * Create server socket. */ static int create_server_socket(void) { - return (create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr)); -} + int fd; -/* - * Create unbound socket. - */ -static int -create_unbound_socket(void) -{ - return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); + fd = create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr); + if (fd < 0) + return (-1); + + if (sock_type == SOCK_STREAM) { + int val; + + if (listen(fd, LISTENQ) < 0) { + logmsg("create_server_socket: listen"); + goto failed; + } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("create_server_socket: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val | O_NONBLOCK) < 0) { + logmsg("create_server_socket: fcntl(F_SETFL)"); + goto failed; + } + } + + return (fd); + +failed: + (void)close_socket(serv_sock_path, fd); + return (-1); } /* - * Close socket descriptor, if sock_path is not equal to NULL, - * then unlink the given path. + * Create client socket. */ static int -close_socket(const char *sock_path, int fd) +create_client_socket(void) { - int error = 0; - - if (close(fd) < 0) { - logmsg("close_socket: close"); - error = -1; - } - if (sock_path != NULL) - if (unlink(sock_path) < 0) { - logmsg("close_socket: unlink(%s)", sock_path); - error = -1; - } - return (error); + return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); } /* @@ -524,7 +604,7 @@ connect_server(int fd) * If PF_LOCAL listening socket's queue is full, then connect() * returns ECONNREFUSED immediately, do not need timeout. */ - if (connect(fd, (struct sockaddr *)&servaddr, sizeof(servaddr)) < 0) { + if (connect(fd, (struct sockaddr *)&servaddr, servaddr.sun_len) < 0) { logmsg("connect_server: connect(%s)", serv_sock_path); return (-1); } @@ -533,34 +613,23 @@ connect_server(int fd) } /* - * sendmsg() with timeout. + * sendmsg() wrapper. */ static int -sendmsg_timeout(int fd, struct msghdr *msg, size_t n) +send_message(int fd, const struct msghdr *msg, size_t n) { ssize_t nsent; - dbgmsg(("sending %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sendmsg_timeout: cannot send message to %s (timeout)", serv_sock_path); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("sending %zu bytes", n)); nsent = sendmsg(fd, msg, 0); - - (void)alarm(0); - if (nsent < 0) { - logmsg("sendmsg_timeout: sendmsg"); + logmsg("send_message: sendmsg"); return (-1); } - if ((size_t)nsent != n) { - logmsgx("sendmsg_timeout: sendmsg: short send: %ld of %lu bytes", - (long)nsent, (u_long)n); + logmsgx("send_message: sendmsg: short send: " + "%zd of %zu bytes", nsent, n); return (-1); } @@ -568,63 +637,73 @@ sendmsg_timeout(int fd, struct msghdr *m } /* - * accept() with timeout. + * accept() wrapper. */ static int -accept_timeout(int listenfd) +accept_connection(int listenfd) { - int fd; + fd_set rset; + struct timeval tv; + int fd, rv, val; dbgmsg(("accepting connection")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("accept_timeout: cannot accept connection (timeout)"); + FD_ZERO(&rset); + FD_SET(listenfd, &rset); + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + rv = select(listenfd + 1, &rset, (fd_set *)NULL, (fd_set *)NULL, &tv); + if (rv < 0) { + logmsg("accept_connection: select"); + return (-1); + } + if (rv == 0) { + logmsgx("accept_connection: select timeout"); return (-1); } - - (void)alarm(TIMEOUT); fd = accept(listenfd, (struct sockaddr *)NULL, (socklen_t *)NULL); - - (void)alarm(0); - if (fd < 0) { - logmsg("accept_timeout: accept"); + logmsg("accept_connection: accept"); return (-1); } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("accept_connection: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val & ~O_NONBLOCK) < 0) { + logmsg("accept_connection: fcntl(F_SETFL)"); + goto failed; + } + return (fd); + +failed: + if (close(fd) < 0) + logmsg("accept_connection: close"); + return (-1); } /* - * recvmsg() with timeout. + * recvmsg() wrapper. */ static int -recvmsg_timeout(int fd, struct msghdr *msg, size_t n) +recv_message(int fd, struct msghdr *msg, size_t n) { ssize_t nread; - dbgmsg(("receiving %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("recvmsg_timeout: cannot receive message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("receiving %zu bytes", n)); nread = recvmsg(fd, msg, MSG_WAITALL); - - (void)alarm(0); - if (nread < 0) { - logmsg("recvmsg_timeout: recvmsg"); + logmsg("recv_message: recvmsg"); return (-1); } - if ((size_t)nread != n) { - logmsgx("recvmsg_timeout: recvmsg: short read: %ld of %lu bytes", - (long)nread, (u_long)n); + logmsgx("recv_message: recvmsg: short read: " + "%zd of %zu bytes", nread, n); return (-1); } @@ -632,7 +711,7 @@ recvmsg_timeout(int fd, struct msghdr *m } /* - * Wait for synchronization message (1 byte) with timeout. + * Wait for synchronization message (1 byte). */ static int sync_recv(int fd) @@ -642,25 +721,13 @@ sync_recv(int fd) dbgmsg(("waiting for sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_recv: cannot receive sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nread = read(fd, &buf, 1); - - (void)alarm(0); - if (nread < 0) { logmsg("sync_recv: read"); return (-1); } - if (nread != 1) { - logmsgx("sync_recv: read: short read: %ld of 1 byte", - (long)nread); + logmsgx("sync_recv: read: short read: %zd of 1 byte", nread); return (-1); } @@ -668,7 +735,7 @@ sync_recv(int fd) } /* - * Send synchronization message (1 byte) with timeout. + * Send synchronization message (1 byte). */ static int sync_send(int fd) @@ -677,25 +744,13 @@ sync_send(int fd) dbgmsg(("sending sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_send: cannot send sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nsent = write(fd, "", 1); - - (void)alarm(0); - if (nsent < 0) { logmsg("sync_send: write"); return (-1); } - if (nsent != 1) { - logmsgx("sync_send: write: short write: %ld of 1 byte", - (long)nsent); + logmsgx("sync_send: write: short write: %zd of 1 byte", nsent); return (-1); } @@ -711,36 +766,29 @@ wait_client(void) int status; pid_t pid; - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("wait_client: cannot get exit status of client PID %ld (timeout)", - (long)client_pid); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("waiting for a client")); pid = waitpid(client_pid, &status, 0); - - (void)alarm(0); - if (pid == (pid_t)-1) { logmsg("wait_client: waitpid"); return (-1); } if (WIFEXITED(status)) { - if (WEXITSTATUS(status) != 0) { - logmsgx("wait_client: exit status of client PID %ld is %d", - (long)client_pid, WEXITSTATUS(status)); + if (WEXITSTATUS(status) != EXIT_SUCCESS) { + logmsgx("wait_client: exit status of client PID %ld " + "is %d", (long)client_pid, WEXITSTATUS(status)); return (-1); } } else { if (WIFSIGNALED(status)) - logmsgx("wait_client: abnormal termination of client PID %ld, signal %d%s", - (long)client_pid, WTERMSIG(status), WCOREDUMP(status) ? " (core file generated)" : ""); + logmsgx("wait_client: abnormal termination of client " + "PID %ld, signal %d%s", (long)client_pid, + WTERMSIG(status), WCOREDUMP(status) ? + " (core file generated)" : ""); else - logmsgx("wait_client: termination of client PID %ld, unknown status", - (long)client_pid); + logmsgx("wait_client: termination of client PID %ld, " + "unknown status", (long)client_pid); return (-1); } @@ -748,28 +796,27 @@ wait_client(void) } /* - * Check if n supplementary GIDs in gids are correct. (my_gids + 1) - * has (my_ngids - 1) supplementary GIDs of current process. + * Check whether n GIDs in gids are correct. */ static int check_groups(const gid_t *gids, int n) { + int i, j, rv; char match[NGROUPS_MAX] = { 0 }; - int error, i, j; - if (n != my_ngids - 1) { - logmsgx("wrong number of groups %d != %d (returned from getgroups() - 1)", - n, my_ngids - 1); - error = -1; + if (n != my_ngids) { + logmsgx("wrong number of groups %d != %d (returned from " + "getgroups())", n, my_ngids); + rv = -1; } else - error = 0; + rv = 0; for (i = 0; i < n; ++i) { - for (j = 1; j < my_ngids; ++j) { + for (j = 0; j < my_ngids; ++j) { if (gids[i] == my_gids[j]) { if (match[j]) { logmsgx("duplicated GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } else match[j] = 1; break; @@ -777,15 +824,15 @@ check_groups(const gid_t *gids, int n) } if (j == my_ngids) { logmsgx("unexpected GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } } - for (j = 1; j < my_ngids; ++j) + for (j = 0; j < my_ngids; ++j) if (match[j] == 0) { - logmsgx("did not receive supplementary GID %u", my_gids[j]); - error = -1; + logmsgx("did not receive GID %lu", (u_long)my_gids[j]); + rv = -1; } - return (error); + return (rv); } /* @@ -802,16 +849,19 @@ t_cmsgcred_client(u_int n) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; u_int i; + int fd, rv; assert(n == 1 || n == 2); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -834,20 +884,16 @@ t_cmsgcred_client(u_int n) for (i = 0; i < n; ++i) { dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; } - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); - + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd)) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -858,28 +904,27 @@ failed: static int t_cmsgcred_server(int fd1) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct cmsgcred)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct cmsgcred)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - const struct cmsgcred *cmcredptr; - socklen_t controllen; - int error, error2, fd2; + const struct cmsgcred *cmcred; u_int i; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; - error = 0; - - controllen = sizeof(control_un.control); + rv = 0; for (i = 0; i < 2; ++i) { iov[0].iov_base = buf; @@ -890,29 +935,31 @@ t_cmsgcred_server(int fd1) msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = controllen; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - controllen = CMSG_SPACE(sizeof(struct cmsgcred)); - - if (recvmsg_timeout(fd2, &msg, sizeof(buf)) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("#%u control data was truncated, MSG_CTRUNC flag is on", - i); - goto next_error; + logmsgx("#%u control data was truncated, MSG_CTRUNC " + "flag is on", i); + goto next; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, @@ -921,142 +968,120 @@ t_cmsgcred_server(int fd1) if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct cmsgcred))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(sizeof(struct cmsgcred))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct cmsgcred))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(sizeof(struct cmsgcred))", i, + (u_int)cmptr->cmsg_len, + CMSG_LEN(sizeof(struct cmsgcred))); + goto next; } - cmcredptr = (const struct cmsgcred *)CMSG_DATA(cmptr); + cmcred = (struct cmsgcred *)CMSG_DATA(cmptr); - error2 = 0; - if (cmcredptr->cmcred_pid != client_pid) { + if (cmcred->cmcred_pid != client_pid) { logmsgx("#%u cmcred_pid %ld != %ld (PID of client)", - i, (long)cmcredptr->cmcred_pid, (long)client_pid); - error2 = 1; + i, (long)cmcred->cmcred_pid, (long)client_pid); + goto next; } - if (cmcredptr->cmcred_uid != my_uid) { - logmsgx("#%u cmcred_uid %lu != %lu (UID of current process)", - i, (u_long)cmcredptr->cmcred_uid, (u_long)my_uid); - error2 = 1; - } - if (cmcredptr->cmcred_euid != my_euid) { - logmsgx("#%u cmcred_euid %lu != %lu (EUID of current process)", - i, (u_long)cmcredptr->cmcred_euid, (u_long)my_euid); - error2 = 1; - } - if (cmcredptr->cmcred_gid != my_gid) { - logmsgx("#%u cmcred_gid %lu != %lu (GID of current process)", - i, (u_long)cmcredptr->cmcred_gid, (u_long)my_gid); - error2 = 1; + if (cmcred->cmcred_uid != my_uid) { + logmsgx("#%u cmcred_uid %lu != %lu (UID of current " + "process)", i, (u_long)cmcred->cmcred_uid, + (u_long)my_uid); + goto next; + } + if (cmcred->cmcred_euid != my_euid) { + logmsgx("#%u cmcred_euid %lu != %lu (EUID of current " + "process)", i, (u_long)cmcred->cmcred_euid, + (u_long)my_euid); + goto next; + } + if (cmcred->cmcred_gid != my_gid) { + logmsgx("#%u cmcred_gid %lu != %lu (GID of current " + "process)", i, (u_long)cmcred->cmcred_gid, + (u_long)my_gid); + goto next; } - if (cmcredptr->cmcred_ngroups == 0) { + if (cmcred->cmcred_ngroups == 0) { logmsgx("#%u cmcred_ngroups = 0, this is wrong", i); - error2 = 1; - } else { - if (cmcredptr->cmcred_ngroups > NGROUPS_MAX) { - logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", - i, cmcredptr->cmcred_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (cmcredptr->cmcred_ngroups < 0) { - logmsgx("#%u cmcred_ngroups %d < 0", - i, cmcredptr->cmcred_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u cmcred_ngroups = %d", i, - cmcredptr->cmcred_ngroups)); - if (cmcredptr->cmcred_groups[0] != my_egid) { - logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of current process)", - i, (u_long)cmcredptr->cmcred_groups[0], (u_long)my_egid); - error2 = 1; - } - if (check_groups(cmcredptr->cmcred_groups + 1, cmcredptr->cmcred_ngroups - 1) < 0) { - logmsgx("#%u cmcred_groups has wrong GIDs", i); - error2 = 1; - } - } + goto next; } - - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header", i); - goto next_error; + if (cmcred->cmcred_ngroups < 0) { + logmsgx("#%u cmcred_ngroups %d < 0", + i, cmcred->cmcred_ngroups); + goto next; + } + if (cmcred->cmcred_ngroups > NGROUPS_MAX) { + logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", + i, cmcred->cmcred_ngroups, NGROUPS_MAX); + goto next; + } + + dbgmsg(("#%u cmcred_ngroups = %d", i, cmcred->cmcred_ngroups)); + if (cmcred->cmcred_groups[0] != my_egid) { + logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of " + "current process)", i, + (u_long)cmcred->cmcred_groups[0], (u_long)my_egid); + goto next; + } + if (check_groups(cmcred->cmcred_groups, + cmcred->cmcred_ngroups) < 0) { + logmsgx("#%u cmcred_groups has wrong GIDs", i); + goto next; + } + + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, " + "this is wrong", i); + goto next; } - continue; -next_error: - error = -1; +next: + rv = -1; } if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_cmsgcred(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_cmsgcred_client(2); } - if ((error = t_cmsgcred_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_cmsgcred_server(fd); if (wait_client() < 0) - goto failed; - - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1067,20 +1092,23 @@ t_sockcred_client(int type) { struct msghdr msg; struct iovec iov[1]; - int fd; u_int i; + int fd, rv; assert(type == 0 || type == 1); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; if (type == 1) if (sync_recv(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1094,19 +1122,15 @@ t_sockcred_client(int type) msg.msg_flags = 0; for (i = 0; i < 2; ++i) - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1119,232 +1143,222 @@ failed: static int t_sockcred_server(int type, int fd1, u_int n) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct sockcred *sockcred; - int error, error2, fd2, optval; u_int i; + int fd2, rv, optval; + char buf[IPC_MESSAGE_SIZE]; assert(n == 1 || n == 2); assert(type == 0 || type == 1); + rv = -2; + if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); if (type == 1) { optval = 1; - if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for accepted socket"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for accepted " + "socket"); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } if (sync_send(fd2) < 0) - goto failed; + goto done; } } else fd2 = fd1; - error = 0; + rv = 0; for (i = 0; i < n; ++i) { iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("control data was truncated, MSG_CTRUNC flag is on"); - goto next_error; + logmsgx("control data was truncated, MSG_CTRUNC flag " + "is on"); + goto next; } + dbgmsg(("#%u msg_controllen = %u", i, + (u_int)msg.msg_controllen)); + if (i != 0 && sock_type == SOCK_STREAM) { if (msg.msg_controllen != 0) { - logmsgx("second message has control data, this is wrong for stream sockets"); - goto next_error; + logmsgx("second message has control data, " + "this is wrong for stream sockets"); + goto next; } - dbgmsg(("#%u msg_controllen = %u", i, - (u_int)msg.msg_controllen)); continue; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } - dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, - (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); + dbgmsg(("#%u cmsg_len = %u", i, (u_int)cmptr->cmsg_len)); if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len < CMSG_LEN(SOCKCREDSIZE(1))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(SOCKCREDSIZE(1)))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(SOCKCREDSIZE(1))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(SOCKCREDSIZE(1)))", i, + (u_int)cmptr->cmsg_len, CMSG_LEN(SOCKCREDSIZE(1))); + goto next; } - sockcred = (const struct sockcred *)CMSG_DATA(cmptr); + sockcred = (struct sockcred *)CMSG_DATA(cmptr); - error2 = 0; if (sockcred->sc_uid != my_uid) { - logmsgx("#%u sc_uid %lu != %lu (UID of current process)", - i, (u_long)sockcred->sc_uid, (u_long)my_uid); - error2 = 1; + logmsgx("#%u sc_uid %lu != %lu (UID of current " + "process)", i, (u_long)sockcred->sc_uid, + (u_long)my_uid); + goto next; } if (sockcred->sc_euid != my_euid) { - logmsgx("#%u sc_euid %lu != %lu (EUID of current process)", - i, (u_long)sockcred->sc_euid, (u_long)my_euid); - error2 = 1; + logmsgx("#%u sc_euid %lu != %lu (EUID of current " + "process)", i, (u_long)sockcred->sc_euid, + (u_long)my_euid); + goto next; } if (sockcred->sc_gid != my_gid) { - logmsgx("#%u sc_gid %lu != %lu (GID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_gid); - error2 = 1; + logmsgx("#%u sc_gid %lu != %lu (GID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_gid); + goto next; } if (sockcred->sc_egid != my_egid) { - logmsgx("#%u sc_egid %lu != %lu (EGID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_egid); - error2 = 1; + logmsgx("#%u sc_egid %lu != %lu (EGID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_egid); + goto next; + } + if (sockcred->sc_ngroups == 0) { + logmsgx("#%u sc_ngroups %d = 0, this is wrong", + i, sockcred->sc_ngroups); + goto next; + } + if (sockcred->sc_ngroups < 0) { + logmsgx("#%u sc_ngroups %d < 0", + i, sockcred->sc_ngroups); + goto next; } if (sockcred->sc_ngroups > NGROUPS_MAX) { logmsgx("#%u sc_ngroups %d > %u (NGROUPS_MAX)", i, sockcred->sc_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (sockcred->sc_ngroups < 0) { - logmsgx("#%u sc_ngroups %d < 0", - i, sockcred->sc_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); - if (check_groups(sockcred->sc_groups, sockcred->sc_ngroups) < 0) { - logmsgx("#%u sc_groups has wrong GIDs", i); - error2 = 1; - } + goto next; } - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header, this is wrong", - i); - goto next_error; + dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); + if (check_groups(sockcred->sc_groups, + sockcred->sc_ngroups) < 0) { + logmsgx("#%u sc_groups has wrong GIDs", i); + goto next; } + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, " + "this is wrong", i); + goto next; + } continue; -next_error: - error = -1; +next: + rv = -1; } - -done_close: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: +done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_sockcred(int type) { - int error, fd, optval; + int fd, rv, optval; assert(type == 0 || type == 1); - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; if (type == 0) { optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_sockcred_client(type); } - if ((error = t_sockcred_server(type, fd, 2)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(type, fd, 2); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } static int @@ -1368,59 +1382,39 @@ t_sockcred_dgram(void) static int t_cmsgcred_sockcred(void) { - int error, fd, optval; + int fd, rv, optval; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for %s socket", sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_cmsgcred_client(1); } - if ((error = t_sockcred_server(0, fd, 1)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(0, fd, 1); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1437,13 +1431,16 @@ t_timestamp_client(void) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; + int fd, rv; + + rv = EXIT_FAILURE; - if ((fd = create_unbound_socket()) < 0) + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1454,7 +1451,7 @@ t_timestamp_client(void) msg.msg_iovlen = 1; msg.msg_control = control_un.control; msg.msg_controllen = no_control_data ? - sizeof(struct cmsghdr) :sizeof control_un.control; + sizeof(struct cmsghdr) : sizeof(control_un.control); msg.msg_flags = 0; cmptr = CMSG_FIRSTHDR(&msg); @@ -1466,19 +1463,15 @@ t_timestamp_client(void) dbgmsg(("msg_controllen = %u, cmsg_len = %u", (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1490,36 +1483,40 @@ t_timestamp_server(int fd1) { union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct timeval)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct timeval)) + + EXTRA_CMSG_SPACE]; } control_un; - char buf[IPC_MESSAGE_SIZE]; - int error, fd2; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct timeval *timeval; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control;; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + goto done; + } - error = -1; + rv = -1; if (msg.msg_flags & MSG_CTRUNC) { logmsgx("control data was truncated, MSG_CTRUNC flag is on"); @@ -1527,12 +1524,13 @@ t_timestamp_server(int fd1) } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("msg_controllen %u < %lu (sizeof(struct cmsghdr))", - (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); + logmsgx("msg_controllen %u < %zu (sizeof(struct cmsghdr))", + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); goto done; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); goto done; } @@ -1551,80 +1549,199 @@ t_timestamp_server(int fd1) } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct timeval))) { - logmsgx("cmsg_len %u != %lu (CMSG_LEN(sizeof(struct timeval))", - (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct timeval))); + logmsgx("cmsg_len %u != %zu (CMSG_LEN(sizeof(struct timeval))", + (u_int)cmptr->cmsg_len, CMSG_LEN(sizeof(struct timeval))); goto done; } - timeval = (const struct timeval *)CMSG_DATA(cmptr); + timeval = (struct timeval *)CMSG_DATA(cmptr); - dbgmsg(("timeval tv_sec %jd, tv_usec %jd", + dbgmsg(("timeval tv_sec %"PRIdMAX", tv_usec %"PRIdMAX, (intmax_t)timeval->tv_sec, (intmax_t)timeval->tv_usec)); - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("control data has extra header"); + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("control data has extra header, this is wrong"); goto done; } - error = 0; - + rv = 0; done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_timestamp(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_timestamp_client(); } - if ((error = t_timestamp_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_timestamp_server(fd); if (wait_client() < 0) + rv = -2; +done: + if (close_socket(serv_sock_path, fd) < 0) + rv = -2; + return (rv); +} + +/* + * Verify that xucred structure has correct credentials. + */ +static int +check_xucred(const struct xucred *xucred, socklen_t len) +{ + if (len != sizeof(*xucred)) { + logmsgx("option value size %zu != %zu (sizeof(struct xucred))", + (size_t)len, sizeof(*xucred)); + return (-1); + } + if (xucred->cr_version != XUCRED_VERSION) { + logmsgx("cr_version %u != %d (XUCRED_VERSION)", + xucred->cr_version, XUCRED_VERSION); + return (-1); + } + if (xucred->cr_uid != my_euid) { + logmsgx("cr_uid %lu != %lu (EUID of current process)", + (u_long)xucred->cr_uid, (u_long)my_euid); + return (-1); + } + if (xucred->cr_ngroups == 0) { + logmsgx("cr_ngroups = 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups < 0) { + logmsgx("cr_ngroups < 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups > NGROUPS_MAX) { + logmsgx("cr_ngroups %hu > %u (NGROUPS_MAX)", + xucred->cr_ngroups, NGROUPS_MAX); + return (-1); + } + if (xucred->cr_groups[0] != my_egid) { + logmsgx("cr_groups[0] %lu != %lu (EGID of current process)", + (u_long)xucred->cr_groups[0], (u_long)my_egid); + return (-1); + } + if (check_groups(xucred->cr_groups, xucred->cr_ngroups) < 0) { + logmsgx("cr_groups has wrong GIDs"); + return (-1); + } + return (0); +} + +/* + * Connect to server and set LOCAL_PEERCRED socket option for connected + * socket. Verify that credentials of the peer are correct. + */ +static void +t_peercred_client(void) +{ + struct xucred xucred; + socklen_t len; + int fd, rv; + + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); + if (connect_server(fd) < 0) + goto done; + + len = sizeof(xucred); + if (getsockopt(fd, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + goto done; } - return (error); + if (check_xucred(&xucred, len) < 0) + goto done; +done: + rv = close_socket((char *)NULL, fd) < 0 ? EXIT_FAILURE : EXIT_SUCCESS; failed: + _exit(rv); +} + +/* + * Accept connection from client and set LOCAL_PEERCRED socket option for + * connected socket. Verify that credentials of the peer are correct. + */ +static int +t_peercred_server(int fd1) +{ + struct xucred xucred; + socklen_t len; + int fd2, rv; + + fd2 = accept_connection(fd1); + if (fd2 < 0) + return (-2); + + len = sizeof(xucred); + if (getsockopt(fd2, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + rv = -2; + goto done; + } + + if (check_xucred(&xucred, len) < 0) { + rv = -1; + goto done; + } + + rv = 0; +done: + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); +} + +static int +t_peercred(void) +{ + int fd, rv; + + fd = create_server_socket(); + if (fd < 0) + return (-2); + + rv = -2; + + if (fork_client() < 0) + goto done; + + if (client_pid == 0) { + if (close_socket((char *)NULL, fd) < 0) + _exit(1); + t_peercred_client(); + } + + rv = t_peercred_server(fd); + + if (wait_client() < 0) + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } diff -ruNp unix_cmsg.orig/unix_cmsg.t unix_cmsg/unix_cmsg.t --- unix_cmsg.orig/unix_cmsg.t 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/unix_cmsg.t 2010-04-21 14:14:46.000000000 +0300 @@ -23,14 +23,15 @@ run() done } -echo "1..15" +echo "1..16" for desc in \ "Sending, receiving cmsgcred" \ - "Receiving sockcred (listening socket has LOCAL_CREDS) # TODO" \ - "Receiving sockcred (accepted socket has LOCAL_CREDS) # TODO" \ - "Sending cmsgcred, receiving sockcred # TODO" \ - "Sending, receiving timestamp" + "Receiving sockcred (listening socket has LOCAL_CREDS)" \ + "Receiving sockcred (accepted socket has LOCAL_CREDS)" \ + "Sending cmsgcred, receiving sockcred" \ + "Sending, receiving timestamp" \ + "Check LOCAL_PEERCRED socket option" do n=`expr ${n} + 1` run ${n} stream "" ${n} "STREAM ${desc}" @@ -48,10 +49,10 @@ do run ${n} dgram "" ${i} "DGRAM ${desc}" done -run 10 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" -run 11 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 12 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" +run 11 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" +run 12 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 13 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" -run 13 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" -run 14 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 15 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" +run 14 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" +run 15 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 16 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 14:29:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDAD6106566C for ; Wed, 21 Apr 2010 14:29:04 +0000 (UTC) (envelope-from murat@enderunix.org) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.150]) by mx1.freebsd.org (Postfix) with ESMTP id 78B198FC1B for ; Wed, 21 Apr 2010 14:29:03 +0000 (UTC) Received: (qmail 19660 invoked from network); 21 Apr 2010 14:01:02 -0000 Received: from unknown (HELO ?10.41.0.13?) (127.0.0.1) by 0 with SMTP; 21 Apr 2010 14:01:02 -0000 From: Murat Balaban To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Organization: EnderUNIX SDT, Turkey Date: Wed, 21 Apr 2010 17:00:59 +0300 Message-ID: <1271858459.2018.14.camel@efe> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: read mostly locks and interrupt handlers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 14:29:05 -0000 Hello net@ folks, I came across some performance problems with BPF on 10G links, and have been investigating more on this. The first thing I noticed is that, bpf_if structures are protected with a mutex. I was wondering if that has been done for a special purpose, i.e. rmlocks are not allowed to run in interrupt context or so? -- Murat From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 16:42:18 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A33751065672 for ; Wed, 21 Apr 2010 16:42:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 30F8A8FC27 for ; Wed, 21 Apr 2010 16:42:17 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id E92FFEAFAA; Wed, 21 Apr 2010 12:42:16 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 21 Apr 2010 12:42:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=RlK8Kve87uKmLVCRiiaMxXgohi8=; b=ZA/OEZEijme0PfnPnRd7ADMrh7OkEzI8hsLA+AajBstIPSOoYbw0XWV+nDLfTxSvYdbTM9zcSwm5DWlXpRKslkxTlmNS5QlZFxD3eG8GOAFkfjtiW0k8cwlXjeQSm8kVwxLNNCIZd/7KKnhaelgtqByaONCeSFmSxdgh/yw7WNc= X-Sasl-enc: /o1kBcAc/rt8qoEDPD9s2A9aNozjYPamUviYxzl6iyp3 1271868136 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 52CC347D0F; Wed, 21 Apr 2010 12:42:16 -0400 (EDT) Message-ID: <4BCF2AE7.80409@incunabulum.net> Date: Wed, 21 Apr 2010 17:42:15 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100406 Thunderbird/3.0.4 MIME-Version: 1.0 To: linimon@FreeBSD.org References: <201004210558.o3L5wOLR037387@freefall.freebsd.org> In-Reply-To: <201004210558.o3L5wOLR037387@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@FreeBSD.org Subject: Re: kern/145905: [fxp] multicast packets aren't received when PROMISC mode on fxp. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:42:18 -0000 Spooky http://en.wikipedia.org/wiki/Cisco_PIX Some Intel-based Ethernet cards for the PIX are identified at boot with the designation "mcwa". This designation denotes a multicast receive bug in the card's firmware that the designers addressed with a feature they called *M*ulti *C*ast *W*ork *A*round. ...I've seen this happen with 1 fxp card I used to have, I don't know if this was a recycled PIX part or not. Think it was 82559ED off the top of my head. From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 16:54:57 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB952106566B; Wed, 21 Apr 2010 16:54:57 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 92AE08FC0C; Wed, 21 Apr 2010 16:54:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3LGsvkJ038656; Wed, 21 Apr 2010 16:54:57 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3LGsuHj038652; Wed, 21 Apr 2010 16:54:56 GMT (envelope-from yongari) Date: Wed, 21 Apr 2010 16:54:56 GMT Message-Id: <201004211654.o3LGsuHj038652@freefall.freebsd.org> To: kimoto@soum.co.jp, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/145905: [fxp] multicast packets aren't received when PROMISC mode on fxp. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:54:57 -0000 Synopsis: [fxp] multicast packets aren't received when PROMISC mode on fxp. State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Apr 21 16:49:05 UTC 2010 State-Changed-Why: Would try the patch at the following URL? http://people.freebsd.org/~yongari/fxp/fxp.promisc.patch Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Apr 21 16:49:05 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=145905 From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 17:24:28 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C1E106566C; Wed, 21 Apr 2010 17:24:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC788FC17; Wed, 21 Apr 2010 17:24:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3LHORAr069062; Wed, 21 Apr 2010 17:24:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3LHOREO069058; Wed, 21 Apr 2010 17:24:27 GMT (envelope-from linimon) Date: Wed, 21 Apr 2010 17:24:27 GMT Message-Id: <201004211724.o3LHOREO069058@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145918: [ae] After spontaneous ae0 "watchdog timeout", "stray Tx interrupt(s)", "size mismatch" messages, interface hangs up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:24:28 -0000 Old Synopsis: After spontaneous ae0 "watchdog timeout", "stray Tx interrupt(s)", "size mismatch" messages, interface hangs up New Synopsis: [ae] After spontaneous ae0 "watchdog timeout", "stray Tx interrupt(s)", "size mismatch" messages, interface hangs up Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 21 17:24:12 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145918 From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 03:07:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CAAF106566B for ; Thu, 22 Apr 2010 03:07:27 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id A7D4B8FC14 for ; Thu, 22 Apr 2010 03:07:26 +0000 (UTC) Received: by ywh11 with SMTP id 11so4654073ywh.7 for ; Wed, 21 Apr 2010 20:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6qVhsaCRWDXOPYg6TBb8XPNpspeYPXKcimAolyQ7UNg=; b=L4d0P6tTjDCOKAgx3j6ui+LVMI6ZC5/LqByhcFnJO+Dp5t52rMt8GuTEVbKUqkDWo+ YR6wnbfkayaJ84BGNyVZtzn0eQ1sKDt+CivbL0Zh5aA31WoLZxwiKjZacKd7rLMARyNd uOZv3s8mGCXTkzjl/MjC7DZlpWTGIWN3ItYoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=c8hpgt85pnCflAB2iU2f+x6mf2BlO+6CW+83M9hlUIDYp+tMQWIq1nVLIKBiSJHutn vZ1mT3/XKlvRkwrJQypd2+4BkNGLKIdnG88osmYlMyrE2d2Kv1K4x8uhwu+EtFe/zolD bWq1cDLAvLD9ZJYCcZrBG+Rl/nHWw1EMCMZJY= MIME-Version: 1.0 Received: by 10.231.113.36 with HTTP; Wed, 21 Apr 2010 20:07:21 -0700 (PDT) In-Reply-To: References: <20100413151933.GA20976@icarus.home.lan> Date: Wed, 21 Apr 2010 22:07:21 -0500 Received: by 10.101.149.40 with SMTP id b40mr22335083ano.99.1271905642002; Wed, 21 Apr 2010 20:07:22 -0700 (PDT) Message-ID: From: Brandon Gooch To: Lin Jui-Nan Eric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, stable@freebsd.org, Jeremy Chadwick Subject: Re: pf stalls connection when using route-to X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 03:07:27 -0000 On Tue, Apr 13, 2010 at 10:53 AM, Lin Jui-Nan Eric wro= te: > On Tue, Apr 13, 2010 at 11:19 PM, Jeremy Chadwick > wrote: >> >> What FreeBSD version? =A0uname -a output please. >> > I have tried 7.2-R and 8.0-R. Both version stalls, too. > > 8.0-RELEASE: > # uname -a > FreeBSD bsd8 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #3: Wed Mar 3 > 17:15:52 CST 2010 root@bsd8:/usr/obj/usr/src/sys/KERNEL amd64 [SNIP] Jack Vogel recently committed an updated, overhauled em(4) driver to 9-CURRENT, which was MFC'd to 8-STABLE: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/e1000/ Would it be possible for you to try your configuration on one of these newer versions? -Brandon From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 08:25:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3FBE106566B for ; Thu, 22 Apr 2010 08:25:05 +0000 (UTC) (envelope-from ose11rose@gmail.com) Received: from avas8.indosat.net.id (avas8.indosat.net.id [202.155.90.9]) by mx1.freebsd.org (Postfix) with ESMTP id C50D98FC08 for ; Thu, 22 Apr 2010 08:25:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqITAE+kz0tyOjSk/2dsb2JhbACBP4UFAWAyhUADgweBD4pxYw6sFAqIJy6IUoJ6ghQEgzKJEg X-IronPort-AV: E=Sophos;i="4.52,255,1270400400"; d="scan'208,217";a="24473656" Received: from unknown (HELO BION11) ([114.58.52.164]) by avas7.indosat.net.id with ESMTP; 22 Apr 2010 15:19:46 +0700 MIME-Version: 1.0 From: "Absensi terbaik di Indonesia hanya 1,3 jt" To: freebsd-net@freebsd.org X-Mailer: SendBlaster.1.6.0 Date: Thu, 22 Apr 2010 15:25:04 +0700 Message-ID: <34646960528067728901@BION-11> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LUAR BIASA!!! ABSENSI SIDIK JARI HANYA 1, 3 JUTA => LIFETIME WARANTY X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ose11rose@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 08:25:06 -0000 =B7 ABSENSI SIDIK JARI TERBAIK DI INDONESIA =B7 Penyedia Solusi Pengamanan Sistem, Aplikasi dan Data Perusahaan Me= nggunakan Teknologi Sidik Jari Pertama di Indonesia (lebih aman daripada me= nggunakan password,unique ID,encryption,dll) Hanya 1,3JT GARANSI SPARE PART 3 TAHUN GARANSI SERVICE LIFETIME TINGGALKAN ABSENSI MANUAL ANDA BERALIHLAH MENGGUNAKAN ABSENSI SIDIK JARI Hub : Rosnita Fingerspot (021) 93229090/ (021) 62202861 Please visit us @ www.fingerspot .com PT BiomeTrik Citra Solusi From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 15:27:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F5E1065672 for ; Thu, 22 Apr 2010 15:27:16 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp5.uk.umis.net (smtp5.uk.umis.net [217.65.166.40]) by mx1.freebsd.org (Postfix) with ESMTP id 30DAA8FC0A for ; Thu, 22 Apr 2010 15:27:15 +0000 (UTC) Received: from www1.prt.org ([217.65.161.4] helo=emma.prt.org) by smtp5.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1O4xpP-0003Zh-3H for freebsd-net@freebsd.org; Thu, 22 Apr 2010 14:56:31 +0000 Message-ID: <4BD0639E.1020004@prt.org> Date: Thu, 22 Apr 2010 14:56:30 +0000 From: Paul Thornton User-Agent: Thunderbird 2.0.0.12 (X11/20080419) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Current best version for router use X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:27:16 -0000 Hi list, A bit of advice please, folks. We currently use 6.2-release + Quagga as a router on a number of boxes. These are stable but we have seen some CPU issues recently and clearly the code is all getting old now, and so I'm starting to look at updating them. Specifically, the hardware consists of a single dual-core Xeon at 2GHz with 2G RAM, containing 10x em interfaces (2x quad PCI-X cards, plus 2 onboard) . IRQ sharing is a bit of an issue and only 8 of those 1G ports can be used without re-using an interrupt. They run with polling enabled, with kern.polling.user_frac = 22 These routers run Quagga 0.99.7 doing v4 and v6 OSPF/BGP. We do use a number of vlans and a couple of gif tunnels. Total throughput varies quite a lot - from 50M to about 200M - but usually isn't high. There seem to be a lot of issues that have appeared around 8.0 and the em code, and although patches have quickly appeared, I know that a lot of the forwarding and routing code in 8 is new - so whilst I would normally have just tested this with 8 and not considered anything else, I am thinking that maybe sticking with 7 is a better plan. I'd appreciate any input from anyone who is using 8.0 in a similar environment, any advice and suggestions would be gratefully received. Thanks, Paul. From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 15:35:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFA00106566C for ; Thu, 22 Apr 2010 15:35:29 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93CFA8FC16 for ; Thu, 22 Apr 2010 15:35:29 +0000 (UTC) Received: by pwi9 with SMTP id 9so6242664pwi.13 for ; Thu, 22 Apr 2010 08:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=OGy+XuZuAouTFW5uaF4pXzVasG7M+ofXJt8Wocwb/eo=; b=dGvj8GIJVZGCoWMOoc6IXOSr8/vriKj2RUYM0dd2kRbHApAeULW3Bj7QNoO63eiqU0 n9bVGpKHikC7vijAQqKbQ2LjvMGozYZ2lSdkeG8aDRyw2WKzXddHkYdV/lAYunWOFxCQ XEsrpWQXdedOyPbItLZDfl9YTDA1IUrKOmj3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gULZ8NGk/rArjH2500nQP8uz89e0pqCs6/MujITJZEuDMf/7++8mqN0OIH3c+uvHc/ yzarlU3F5PEfH7mX/sKQjlrTYtaaz6OenaczTeHcshyg7oV0R2gKZR6DGbiNQeamDBmw yDDPE1HGBWEw6P9qcx7ptvFanG82HWhgzo/Aw= MIME-Version: 1.0 Received: by 10.231.176.4 with HTTP; Thu, 22 Apr 2010 08:35:28 -0700 (PDT) In-Reply-To: <4BD0639E.1020004@prt.org> References: <4BD0639E.1020004@prt.org> Date: Thu, 22 Apr 2010 09:35:28 -0600 Received: by 10.140.88.33 with SMTP id l33mr77479rvb.4.1271950528851; Thu, 22 Apr 2010 08:35:28 -0700 (PDT) Message-ID: From: Balaji G To: Paul Thornton Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Current best version for router use X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:35:29 -0000 Hi Paul > There seem to be a lot of issues that have appeared around 8.0 and the em code, and although patches have quickly appeared, I know that a lot of the forwarding and routing code in 8 is new - so whilst I would normally have just tested this with 8 > and not considered anything else, I am thinking that maybe sticking with 7 is a better plan. I have been using FreeBSD 8.0 and as well 7.2 but from a routing perspective i would say you could go ahead with 8.0 for the reason being 7.2 still does not support ECMP but 8.0 supports ECMP which is quite important but having said that load balancing and fast protection has got issues in 8.0 too but from a longer run 8.0 would be better choice as Qing and other few people are putting lot of fixes to flowtable and general routing infrastructure . Hope this helps Thanks, Cheers, - Balaji On 4/22/10, Paul Thornton wrote: > > Hi list, > > A bit of advice please, folks. > > We currently use 6.2-release + Quagga as a router on a number of boxes. > These are stable but we have seen some CPU issues recently and clearly the > code is all getting old now, and so I'm starting to look at updating them. > > Specifically, the hardware consists of a single dual-core Xeon at 2GHz with > 2G RAM, containing 10x em interfaces (2x quad PCI-X cards, plus 2 onboard) . > IRQ sharing is a bit of an issue and only 8 of those 1G ports can be used > without re-using an interrupt. > They run with polling enabled, with kern.polling.user_frac = 22 > These routers run Quagga 0.99.7 doing v4 and v6 OSPF/BGP. > We do use a number of vlans and a couple of gif tunnels. > Total throughput varies quite a lot - from 50M to about 200M - but usually > isn't high. > > There seem to be a lot of issues that have appeared around 8.0 and the em > code, and although patches have quickly appeared, I know that a lot of the > forwarding and routing code in 8 is new - so whilst I would normally have > just tested this with 8 and not considered anything else, I am thinking that > maybe sticking with 7 is a better plan. > > I'd appreciate any input from anyone who is using 8.0 in a similar > environment, any advice and suggestions would be gratefully received. > > Thanks, > > Paul. > > _______________________________________________ > 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 Apr 22 15:50:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF181106567A for ; Thu, 22 Apr 2010 15:50:38 +0000 (UTC) (envelope-from dcarrick@uniongas.com) Received: from spectraenergy.com (houims01.spectraenergy.com [64.95.214.232]) by mx1.freebsd.org (Postfix) with ESMTP id 53D3D8FC14 for ; Thu, 22 Apr 2010 15:50:37 +0000 (UTC) Received: from ([10.20.121.58]) by houims01.spectraenergy.com with ESMTP with TLS id 5502387.42093340; Thu, 22 Apr 2010 10:35:09 -0500 Received: from CHATEXCHANGE.gtna.gt.ds ([169.254.2.153]) by GTNACHATEX03.gtna.gt.ds ([10.20.121.58]) with mapi; Thu, 22 Apr 2010 11:35:08 -0400 From: "Carrick, David" To: "freebsd-net@freebsd.org" Date: Thu, 22 Apr 2010 11:35:07 -0400 Thread-Topic: 3-Line MLPPP DSL on BSD - MTU/MRRU/MRU?? Thread-Index: AcriMWLzlf2NkbELTF2fL7NnYb2Zcw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 3-Line MLPPP DSL on BSD - MTU/MRRU/MRU?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:50:38 -0000 Hi Guys,=0D=0A=0D=0AI have posted this question in a few different forums b= ut I have not had much luck with a response and I'm hoping someone can help= me out=2E I recently upgraded to a triple-5meg DSL service setup with MLPP= P here in Ontario Canada through a provider called Teksavvy=2E I chose Free= BSD as my o/s of choice and I'm using MPD5=2E5 to bond the connections=2E I= believe they are using Juniper equipment on their end, not sure if it matt= ers=2E=0D=0A=0D=0AI have been using Linux for 15 years, and am an AIX Infra= structure Analyst by trade, but I am not very familiar with more advanced n= etworking terms and technologies, and I am pretty new to FreeBSD=2E=0D=0A= =0D=0AI was wondering if someone could help me with the optimal values for = my mpd=2Econf file - Max Transmit units, Max recieve unit, all that stuff= =2E Here is what I've got going so far=2E=2E=2E Please note I am not on the= freebsd-net mailing list so if you could CC me on the responses that would= be great!=0D=0A=0D=0Adefault:=0D=0A=0D=0Aload DSL=0D=0A=0D=0ADSL:=0D=0Acre= ate bundle static B1=0D=0Aset iface route default=0D=0Aset ipcp ranges 0=2E= 0=2E0=2E0/0 0=2E0=2E0=2E0/0=0D=0Aset ipcp enable req-pri-dns=0D=0Aset ipcp = enable req-sec-dns=0D=0Aset ipcp disable vjcomp=0D=0A=0D=0Aset bundle disab= le round-robin=0D=0Aset bundle disable bw-manage=0D=0Aset bundle links L1 L= 2 L3=0D=0Aset iface mtu 1492=0D=0Aset iface disable on-demand=0D=0Aset ifac= e enable tcpmssfix=0D=0Acreate link static L1 pppoe=0D=0Aset auth authname = xxx@wiredhighspeed=2Ecom=0D=0Aset auth password xxx=0D=0Aset link max-redia= l 0=0D=0Aset link keep-alive 10 60=0D=0Aset pppoe iface fxp1=0D=0Aset pppoe= service "teksavvy"=0D=0Aset link enable multilink=0D=0Aset link enable sho= rtseq=0D=0Aset link disable protocomp=0D=0Aset link mrru 1500=0D=0A# set li= nk mru 1500=0D=0Aset link mtu 1492=0D=0Aset link bandwidth 5056000=0D=0Aset= link action bundle B1=0D=0Aopen=0D=0A=0D=0Acreate link static L2 pppoe=0D= =0Aset auth authname xxx@wiredhighspeed=2Ecom=0D=0Aset auth password xxx=0D= =0Aset link max-redial 0=0D=0Aset link keep-alive 10 60=0D=0Aset pppoe ifac= e fxp2=0D=0Aset pppoe service "teksavvy"=0D=0Aset link enable multilink=0D= =0Aset link enable shortseq=0D=0Aset link disable protocomp=0D=0Aset link m= rru 1500=0D=0A# set link mru 1500=0D=0Aset link mtu 1492=0D=0Aset link band= width 5056000=0D=0Aset link action bundle B1=0D=0Aopen=0D=0A=0D=0Acreate li= nk static L3 pppoe=0D=0Aset auth authname xxx@wiredhighspeed=2Ecom=0D=0Aset= auth password xxx=0D=0Aset link max-redial 0=0D=0Aset link keep-alive 10 6= 0=0D=0Aset pppoe iface fxp3=0D=0Aset pppoe service "teksavvy"=0D=0Aset link= enable multilink=0D=0Aset link enable shortseq=0D=0Aset link disable proto= comp=0D=0Aset link mrru 1500=0D=0A# set link mru 1500=0D=0Aset link mtu 149= 2=0D=0Aset link bandwidth 5056000=0D=0Aset link action bundle B1=0D=0Aopen= =0D=0A=0D=0A----=0D=0A=0D=0AI can't really recall why I commented the MRU v= alues - I think they defaulted to 1500 anyway=2E I adapted the config from = a fast 2 Line setup posted in another forum around here=2E When I tested it= as two lines, it was definitely "as fast as it could go"=2E Not as impress= ed with the 3 line setup=2E=0D=0A=0D=0AAny advice or direction on this woul= d be greatly appreciated=2E=0D=0A=0D=0AThanks=0D=0A=0D=0ADavid Carrick=0D= =0ASenior AIX Infrastructure Analyst=0D=0AAIX Services | Spectra Energy=0D= =0A519=2E436=2E4600 x2464 (desk)=0D=0A800=2E571=2E8446 x2464 (toll free)=0D= =0A519=2E437=2E7194 (cell)=0D=0Adcarrick@uniongas=2Ecom=0D=0AFor first call resolution please contact the Spectra Ener= gy Enterprise IT Help Desk @ local 4444 or toll free @ 1-866-252-8881=0D=0A= =0D=0A=0D=0A=0D=0A From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 16:12:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E6C01065675 for ; Thu, 22 Apr 2010 16:12:21 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3608FC16 for ; Thu, 22 Apr 2010 16:12:15 +0000 (UTC) Received: by wye20 with SMTP id 20so1941438wye.13 for ; Thu, 22 Apr 2010 09:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kARoeNKVCOSzLpNMNpPRQkDSaSYqzNU6p//3OGoFtFo=; b=pD6oCqTHePJd/RE9R4tGJNuk87jmO7la2jdKzIve26edDIfndh/0NrXi4L7a0R9gYY lpwihYTLGsP36hZmjPbWk9vQpZNA6V0QW/sJOUVGZdHoqGBGzPwXvHXkjELakJ03XbwK XKXJkMjy0BK9sWIaSWIm+W3vj0IlkbDGOJbdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WvITtV3ZHHfBzFLeIZFmvR/9scxUD8tUJGvLjMeLLUG7BFsS4F8uqjn/M2xBX74Uga TyLIXvyaj4n1QobQnL9PJs3sqjdzuYhU9wAn5xShyzyUAoJJGUfg6u8dL8uAdyiUc/k6 FH0OpeKGt2jl0bY3H8qMPph9mc5q35V+6g/CY= Received: by 10.216.158.3 with SMTP id p3mr457133wek.9.1271952729157; Thu, 22 Apr 2010 09:12:09 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id x14sm812354wbs.0.2010.04.22.09.12.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Apr 2010 09:12:03 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BD0754E.8020107@elischer.org> Date: Thu, 22 Apr 2010 09:11:58 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Carrick, David" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: 3-Line MLPPP DSL on BSD - MTU/MRRU/MRU?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:12:21 -0000 On 4/22/10 8:35 AM, Carrick, David wrote: > Hi Guys, > > I have posted this question in a few different forums but I have not > had much luck with a response and I'm hoping someone can help me > out. I recently upgraded to a triple-5meg DSL service setup with > MLPPP here in Ontario Canada through a provider called Teksavvy. I > chose FreeBSD as my o/s of choice and I'm using MPD5.5 to bond the > connections. I believe they are using Juniper equipment on their > end, not sure if > matters. > > I have been using Linux for 15 years, and am an AIX Infrastructure > Analyst by trade, but I am not very familiar with more advanced > networking terms and technologies, and I am pretty new to FreeBSD. > > I was wondering if someone could help me with the optimal values > for my mpd.conf file - Max Transmit units, Max recieve unit, all > that stuff. Here is what I've got going so far... Please note I am > not on the freebsd-net mailing list so if you could CC me on the > responses that would be great! Not my area of best knowledge but a couple of points.. Use 'load' to abstract away common items from the links Try not to reference things until after they are defined.. is this working? and if not, what happens? (keep list on Cc please) # How I would have structured it: # just off the top of my head.. untested and probably with errors. default: load DSL common: set link max-redial 0 set link keep-alive 10 60 set pppoe service "teksavvy" set link enable multilink set link enable shortseq set link disable protocomp set link mrru 1500 # set link mru 1500 set link mtu 1492 set link bandwidth 5056000 set link action bundle B1 L1: create link static L1 pppoe set auth authname xxx@wiredhighspeed.com set auth password xxx set pppoe iface fxp1 load common open L2: create link static L2 pppoe set auth authname xxx@wiredhighspeed.com set auth password xxx set pppoe iface fxp2 load common open L3: create link static L3 pppoe set auth authname xxx@wiredhighspeed.com set auth password xxx set pppoe iface fxp3 load common open DSL: create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipcp enable req-pri-dns set ipcp enable req-sec-dns set ipcp disable vjcomp set bundle disable round-robin set bundle disable bw-manage set iface mtu 1492 set iface disable on-demand set iface enable tcpmssfix load L1 load L2 load L3 set bundle links L1 L2 L3 From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 17:15:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E73F6106564A for ; Thu, 22 Apr 2010 17:15:15 +0000 (UTC) (envelope-from dcarrick@uniongas.com) Received: from spectraenergy.com (houims01.spectraenergy.com [64.95.214.232]) by mx1.freebsd.org (Postfix) with ESMTP id 99AD88FC1C for ; Thu, 22 Apr 2010 17:15:15 +0000 (UTC) Received: from ([10.20.121.56]) by houims01.spectraenergy.com with ESMTP with TLS id 5502387.42102229; Thu, 22 Apr 2010 12:14:47 -0500 Received: from CHATEXCHANGE.gtna.gt.ds ([169.254.2.153]) by GTNACHATEX02.gtna.gt.ds ([10.20.121.56]) with mapi; Thu, 22 Apr 2010 13:14:47 -0400 From: "Carrick, David" To: Julian Elischer Date: Thu, 22 Apr 2010 13:14:46 -0400 Thread-Topic: 3-Line MLPPP DSL on BSD - MTU/MRRU/MRU?? Thread-Index: AcriNpebszBVbadXQrGiwe9su59MLQACIBDA Message-ID: References: <4BD0754E.8020107@elischer.org> In-Reply-To: <4BD0754E.8020107@elischer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "freebsd-net@freebsd.org" Subject: RE: 3-Line MLPPP DSL on BSD - MTU/MRRU/MRU?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 17:15:16 -0000 The config works - just don't think it is optimal=2E I structured it based = on the mpd5=2Econf=2Esample and some other configurations stolen from dslre= ports=2Ecom=2E=0D=0A=0D=0AI am looking more for advised MRU/MTU, and MRRU v= alues for the links and the bundle as a whole as I do not believe my settin= gs are optimal=2E I have tested a 2link configuration with similar values a= nd obtained very, very fast speeds=2E Adding the 3rd link with the settings= below does improve the speed, but I do not feel it is as fast as it should= be=2E =0D=0A=0D=0ARepsectfully, =0D=0A=0D=0ADavid Carrick=0D=0AAIX Service= s | Spectra Energy=0D=0A519=2E436=2E4600=A0x2464 (desk)=0D=0A800=2E571=2E84= 46 x2464 (toll free) =0D=0A519=2E437=2E7194 (cell)=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: Julian Elischer [mailto:julianelischer@gmail=2Ecom= ] On Behalf Of Julian Elischer=0D=0ASent: April-22-10 12:12 PM=0D=0ATo: Car= rick, David=0D=0ACc: freebsd-net@freebsd=2Eorg=0D=0ASubject: Re: 3-Line MLP= PP DSL on BSD - MTU/MRRU/MRU??=0D=0A=0D=0AOn 4/22/10 8:35 AM, Carrick, Davi= d wrote:=0D=0A> Hi Guys,=0D=0A>=0D=0A> I have posted this question in a fe= w different forums but I have not=0D=0A> had much luck with a response and = I'm hoping someone can help me=0D=0A> out=2E I recently upgraded to a tripl= e-5meg DSL service setup with=0D=0A> MLPPP here in Ontario Canada through a= provider called Teksavvy=2E I=0D=0A> chose FreeBSD as my o/s of choice and= I'm using MPD5=2E5 to bond the=0D=0A> connections=2E I believe they are us= ing Juniper equipment on their=0D=0A> end, not sure if=0D=0A > matters=2E= =0D=0A>=0D=0A> I have been using Linux for 15 years, and am an AIX Infrastr= ucture=0D=0A> Analyst by trade, but I am not very familiar with more advanc= ed=0D=0A> networking terms and technologies, and I am pretty new to FreeBSD= =2E=0D=0A>=0D=0A> I was wondering if someone could help me with the optimal= values=0D=0A> for my mpd=2Econf file - Max Transmit units, Max recieve uni= t, all=0D=0A> that stuff=2E Here is what I've got going so far=2E=2E=2E Ple= ase note I am=0D=0A> not on the freebsd-net mailing list so if you could CC= me on the=0D=0A> responses that would be great!=0D=0A=0D=0A=0D=0ANot my ar= ea of best knowledge but a couple of points=2E=2E=0D=0AUse 'load' to abstra= ct away common items from the links=0D=0ATry not to reference things until = after they are defined=2E=2E=0D=0A=0D=0Ais this working? and if not, what h= appens?=0D=0A(keep list on Cc please)=0D=0A=0D=0A=0D=0A# How I would have s= tructured it:=0D=0A# just off the top of my head=2E=2E untested and probabl= y with errors=2E=0D=0A=0D=0A=0D=0Adefault:=0D=0A load DSL=0D=0A=0D=0Acommon= :=0D=0A set link max-redial 0=0D=0A set link keep-alive 10 60=0D=0A set ppp= oe service "teksavvy"=0D=0A set link enable multilink=0D=0A set link enable= shortseq=0D=0A set link disable protocomp=0D=0A set link mrru 1500=0D=0A# = set link mru 1500=0D=0A set link mtu 1492=0D=0A set link bandwidth 5056000= =0D=0A set link action bundle B1=0D=0A=0D=0AL1:=0D=0A create link static L1= pppoe=0D=0A set auth authname xxx@wiredhighspeed=2Ecom=0D=0A set auth pass= word xxx=0D=0A set pppoe iface fxp1=0D=0A load common=0D=0A open=0D=0A=0D= =0AL2:=0D=0A create link static L2 pppoe=0D=0A set auth authname xxx@wiredh= ighspeed=2Ecom=0D=0A set auth password xxx=0D=0A set pppoe iface fxp2=0D=0A= load common=0D=0A open=0D=0A=0D=0AL3:=0D=0A create link static L3 pppoe=0D= =0A set auth authname xxx@wiredhighspeed=2Ecom=0D=0A set auth password xxx= =0D=0A set pppoe iface fxp3=0D=0A load common=0D=0A open=0D=0A=0D=0ADSL:=0D= =0A create bundle static B1=0D=0A set iface route default=0D=0A set ipcp ra= nges 0=2E0=2E0=2E0/0 0=2E0=2E0=2E0/0=0D=0A set ipcp enable req-pri-dns=0D= =0A set ipcp enable req-sec-dns=0D=0A set ipcp disable vjcomp=0D=0A set bun= dle disable round-robin=0D=0A set bundle disable bw-manage=0D=0A set iface = mtu 1492=0D=0A set iface disable on-demand=0D=0A set iface enable tcpmssfix= =0D=0A load L1=0D=0A load L2=0D=0A load L3=0D=0A set bundle links L1 L2 L3= =0D=0A From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 18:44:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22FB61065675; Thu, 22 Apr 2010 18:44:00 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 319B78FC19; Thu, 22 Apr 2010 18:43:58 +0000 (UTC) Received: by wye20 with SMTP id 20so2057491wye.13 for ; Thu, 22 Apr 2010 11:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=U3GI3nd9oezAIzWVnwhAvY2mfjiZ5C+8+naD1NhFLtw=; b=uhFOLRi6647EDHveCz4+AjIwisS+5Wi+4V0gN5Ve5W9K9fof4MFd6uqsatvT+UxaXG f87I/O7BvsOIjYHJRUJCcbE4GqJyywbwSlXxV0EC86c4uiZVXmzgIpsN4/SHbaDyLWwS fZlPvUvElRIp0flns4FoseKadOSVfr86t9iu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PJRjM9cMpHKgGOlf0wys1GiWuhldzvJMfKmfrqL46qow+eCj9m6uuR3ypADu5uZHwS RJ64EhXS/qR8CJ5YN6xpCcc3fitGnOngYB6jRPFYF+gmgn5bY9D1HsxKpFR6oLtM+LDm kogfrV40B7RryiWRQztmMg40++j35OHCTt7Bw= MIME-Version: 1.0 Received: by 10.216.13.7 with HTTP; Thu, 22 Apr 2010 11:43:57 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Thu, 22 Apr 2010 21:43:57 +0300 Received: by 10.216.91.6 with SMTP id g6mr690090wef.37.1271961837824; Thu, 22 Apr 2010 11:43:57 -0700 (PDT) Message-ID: From: Marin Atanasov To: Qing Li Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 18:44:00 -0000 Hello, Thanks a lot for the patch, Qing! It works fine. However I've noticed one thing, after I start mpd5 and connect to my home network: kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() Not very sure if this is something to worry about or not? Regards, Marin On Tue, Apr 20, 2010 at 11:03 AM, Qing Li wrote: > > > > I was using csup to track RELEN_8_0 branch. Currently I'm syncing to > > RELENG_8. > > > > If I understood you right, after getting the sources for RELENG_8, I need > to > > apply the patch and then rebuild world? > > > > You only need to rebuild the kernel. > > -- Qing > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 19:09:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A35031065677 for ; Thu, 22 Apr 2010 19:09:02 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6F5808FC1C for ; Thu, 22 Apr 2010 19:09:02 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 7F35DEC296 for ; Thu, 22 Apr 2010 15:08:58 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 22 Apr 2010 15:08:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=6Kenr6VsInWE+VrktTmeDXZQ24s=; b=kF3TcZLH0r+TUnJwy0cxDiefy7IY4qyKvxuOSnwi3pauuVj3H0V3K+h5Hp52aJMaHb23VNY59++CYcP9NkSSvbQHU/fVjI6uYtRCxlIOcX0I7GGfXTByjtSz8aklLu5cOBLU/WVC5Xcoe7lrP88YyjPgwrXD68yAiMmZJecQFRo= X-Sasl-enc: dJ9dKLPjmf2MJGJtJ4i24PP38k0o1bbuYRDYirC6Tpnx 1271963334 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A57C64B5A8E for ; Thu, 22 Apr 2010 15:08:54 -0400 (EDT) Message-ID: <4BD09EC5.9000507@incunabulum.net> Date: Thu, 22 Apr 2010 20:08:53 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100406 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4BD0754E.8020107@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 3-Line MLPPP DSL on BSD - MTU/MRRU/MRU?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:09:02 -0000 On 04/22/10 18:14, Carrick, David wrote: > The config works - just don't think it is optimal. I structured it based on the mpd5.conf.sample and some other configurations stolen from dslreports.com. > > I am looking more for advised MRU/MTU, and MRRU values for the links and the bundle as a whole as I do not believe my settings are optimal. I have tested a 2link configuration with similar values and obtained very, very fast speeds. Adding the 3rd link with the settings below does improve the speed, but I do not feel it is as fast as it should be. > Tried using hping or other tools to manually discover path MTU in both directions? Yes many DSLAMs clip it below 1500 due to ATM and PPPoA framing overhead. From owner-freebsd-net@FreeBSD.ORG Fri Apr 23 14:50:04 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD1D0106564A for ; Fri, 23 Apr 2010 14:50:04 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id EDD498FC29 for ; Fri, 23 Apr 2010 14:50:02 +0000 (UTC) Received: by bwz27 with SMTP id 27so1096190bwz.13 for ; Fri, 23 Apr 2010 07:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=G76LVv3hON+tqgxSitw8Tk0fMCvnCznVAYDoxSr4LyU=; b=j6iDPla9xVhTVg2zfeFxOZcLK9mWdul0raIcccEo2YjPJy6xMQUUgX3S4wddIWMTmG 1FaGwWg/wEj/aXh/L8rMXQFauaRQ7xOFCLsappPpe1YovhrEZmPyFUqZot2fHGQixox5 Etn6opTPuFDduEQNmadhkDIQhv2sD1/UhU5wQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W7Dckn/recNO3N+0a4/1qSo3TNrsHL9hviodwqLpfWAX3Tga6QztLxjpBXzBsA51mV UXzi/ONhpMgICXYLMt1D6iBIAjb9PLIvGjJKEDbw/hBJgKoEtomr8jycv5t1w8/Cb+oE lodDZMcVjQRaYhStrGgtzjlUqDsbRBcVAp9Fk= MIME-Version: 1.0 Received: by 10.87.62.28 with SMTP id p28mr525583fgk.16.1272032499666; Fri, 23 Apr 2010 07:21:39 -0700 (PDT) Received: by 10.86.84.6 with HTTP; Fri, 23 Apr 2010 07:21:39 -0700 (PDT) In-Reply-To: <20100421074959.J40281@maildrop.int.zabbadoz.net> References: <201004200748.09566.jhb@freebsd.org> <20100421074959.J40281@maildrop.int.zabbadoz.net> Date: Fri, 23 Apr 2010 18:21:39 +0400 Message-ID: From: c0re To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 14:50:04 -0000 I tryed RELENG_7_3, RELENG_7, RELENG_8_0, RELENG_8 - results are same - kernel panic. This is backtrace of RELENG_8 host# kgdb kernel.debug /var/crash/vmcore.7 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc0933a38 esp = 0xe460bfd8 ebp = 0xe460c068 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 4m42s Physical memory: 1011 MB Dumping 68 MB: 53 37 21 5 Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from /boot/kernel/if_gre.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_gre.ko #0 doadump () at pcpu.h:246 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0891997 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc0891c89 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc0b4525b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:971 #4 0xc0933a38 in flowtable_lookup (ft=0xc4478000, ssa=0xe460c108, dsa=0xe460c088, fibnum=0, flags=2050) at /usr/src/sys/net/flowtable.c:1115 #5 0xc093428c in flowtable_lookup_mbuf (ft=0xc4478000, m=0xc4470e00, af=2) at /usr/src/sys/net/flowtable.c:607 #6 0xc09b141f in ip_output (m=0xc4470e00, opt=0x0, ro=0x0, flags=0, imo=0x0, inp=0xc4c5d44c) at /usr/src/sys/netinet/ip_output.c:164 #7 0xc09baba6 in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1187 #8 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #9 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #10 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #11 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #12 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #13 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #14 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #15 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #16 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #17 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #18 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #19 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #20 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #21 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #22 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #23 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #24 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #25 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #26 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #27 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #28 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #29 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #30 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #31 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #32 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #33 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #34 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #35 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #36 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #37 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #38 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #39 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #40 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #41 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #42 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #43 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #44 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #45 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #46 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #47 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #48 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #49 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 ---Type to continue, or q to quit--- #50 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #51 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #52 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #53 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #54 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #55 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #56 0xc09b78e5 in tcp_do_segment (m=0xc4a83800, th=0xc4aa4024, so=0xc4a2480c, tp=0xc4c5f768, drop_hdrlen=52, tlen=0, iptos=0 '\0', ti_locked=3) at /usr/src/sys/netinet/tcp_input.c:2684 #57 0xc09b8b7d in tcp_input (m=0xc4a83800, off0=20) at /usr/src/sys/netinet/tcp_input.c:1020 #58 0xc09af671 in ip_input (m=0xc4a83800) at /usr/src/sys/netinet/ip_input.c:804 #59 0xc0946a09 in netisr_dispatch_src (proto=1, source=0, m=0xc4a83800) at /usr/src/sys/net/netisr.c:917 #60 0xc0946ca0 in netisr_dispatch (proto=1, m=0xc4a83800) at /usr/src/sys/net/netisr.c:1004 #61 0xc093d2aa in ether_demux (ifp=0xc42d7000, m=0xc4a83800) at /usr/src/sys/net/if_ethersubr.c:901 #62 0xc093d82f in ether_input (ifp=0xc42d7000, m=0xc4a83800) at /usr/src/sys/net/if_ethersubr.c:760 #63 0xc0623c4a in lem_handle_rxtx (context=0xc42ea000, pending=1) at /usr/src/sys/dev/e1000/if_lem.c:3616 #64 0xc08cb282 in taskqueue_run (queue=0xc42c9c80) at /usr/src/sys/kern/subr_taskqueue.c:239 #65 0xc08cb48d in taskqueue_thread_loop (arg=0xc42ee5a8) at /usr/src/sys/kern/subr_taskqueue.c:360 #66 0xc0868831 in fork_exit (callout=0xc08cb3d0 , arg=0xc42ee5a8, frame=0xe460dd38) at /usr/src/sys/kern/kern_fork.c:843 #67 0xc0b28c10 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) 2010/4/21 Bjoern A. Zeeb > On Tue, 20 Apr 2010, pluknet wrote: > > On 20 April 2010 15:48, John Baldwin wrote: >> >>> On Tuesday 20 April 2010 2:53:16 am c0re wrote: >>> >>>> Hello All! >>>> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to >>>> configure gre interface and use ipfw fwd. >>>> I'm actually does not know what was the point of failure in my >>>> configuration. >>>> >>>> [ some details snipped ] >>>> >>>> It worked about one week and then I made some configuration changes: >>>> added gre interface and 2 aliases: >>>> >>>> # cat /etc/rc.conf |grep >>>> ifconfig_xl0="inet 192.168.0.10 netmask 255.255.255.0" >>>> ifconfig_xl0_alias0="192.168.0.11 netmask 255.255.255.255" >>>> ifconfig_xl0_alias1="192.168.0.12 netmask 255.255.255.255" >>>> cloned_interfaces="gre0" >>>> ifconfig_gre0="inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 >>>> 192.168.200.15 netmask 255.255.255.252 link1 up" >>>> >>>> and >>>> >>>> # cat /etc/rc.local >>>> #!/bin/sh >>>> ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 >>>> ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 >>>> ipfw add allow ip from any to any >>>> >>>> # ifconfig gre0 >>>> gre0: flags=b050 metric 0 mtu >>>> 1476 >>>> tunnel inet 192.168.0.12 --> 192.168.200.15 >>>> inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc >>>> >>>> I shutted down gre interface to prevent requests via gre to buggy IP. >>>> >>>> The main idea of such configurations was: fwd all connections to https >>>> to >>>> 192.168.0.1 via gre interface. >>>> And also I made apache configurations to make it listen on 192.168.0.11 >>>> too. >>>> >>>> And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet >>>> to >>>> 192.168.0.11 443 was fine too. Then I tryed to make browser https >>>> connection to 192.168.0.11. Apache showed me certificate warning and I >>>> accepted, then in browser nothing happened, it was trying to open page. >>>> But >>>> server got kernel panic at that moment. >>>> >>>> At first time I thought that it was some power failure, I tryed 2 more >>>> times >>>> and got same behaviour. >>>> >>>> So https works without kernel panic via 192.168.0.10 address but kernel >>>> panics when I try do https via 192.168.0.11 address that >>>> source-forwarded >>>> via gre. >>>> >>> >>> Looks like the TCP output path got stuck in an infinite recursion loop >>> until >>> it exhausted the kernel stack: >>> >>> # cd /usr/obj/usr/src/sys/MYKERNEL >>>> # kgdb kernel.debug /var/crash/vmcore.2 >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and you >>>> are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" for >>>> details. >>>> This GDB was configured as "i386-marcel-freebsd"... >>>> >>>> Unread portion of the kernel message buffer: >>>> >>>> Fatal double fault: >>>> eip = 0xc08e3ba3 >>>> esp = 0xccf6dfc4 >>>> ebp = 0xccf6e274 >>>> cpuid = 0; apic id = 00 >>>> panic: double fault >>>> cpuid = 0 >>>> Uptime: 7m14s >>>> Physical memory: 235 MB >>>> Dumping 35 MB: 20 4 >>>> >>>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >>>> /boot/kernel/acpi.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/acpi.ko >>>> Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from >>>> /boot/kernel/if_gre.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/if_gre.ko >>>> Reading symbols from /boot/kernel/linux.ko...Reading symbols from >>>> /boot/kernel/linux.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/linux.ko >>>> #0 doadump () at pcpu.h:196 >>>> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >>>> (kgdb) bt >>>> #0 doadump () at pcpu.h:196 >>>> #1 0xc07f2857 in boot (howto=260) at >>>> /usr/src/sys/kern/kern_shutdown.c:418 >>>> #2 0xc07f2b29 in panic (fmt=Variable "fmt" is not available. >>>> ) at /usr/src/sys/kern/kern_shutdown.c:574 >>>> #3 0xc0a7ea2b in dblfault_handler () at >>>> /usr/src/sys/i386/i386/trap.c:983 >>>> #4 0xc08e3ba3 in ipfw_chk (args=0xccf6e28c) at >>>> /usr/src/sys/netinet/ip_fw2.c:2465 >>>> #5 0xc08e6ce1 in ipfw_check_out (arg=0x0, m0=0xccf6e390, >>>> ifp=0xc25c5c00, >>>> dir=2, inp=0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 >>>> #6 0xc08a1968 in pfil_run_hooks (ph=0xc0c55240, mp=0xccf6e420, >>>> ifp=0xc25c5c00, dir=2, inp=0xc28ba708) at /usr/src/sys/net/pfil.c:78 >>>> #7 0xc08eb6f2 in ip_output (m=0xc2710b00, opt=0x0, ro=0xccf6e3f4, >>>> flags=0, >>>> imo=0x0, inp=0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 >>>> #8 0xc08f4016 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1134 >>>> >>> > [twiddle] > > > #47 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> #48 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #49 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> ---Type to continue, or q to quit--- >>>> #50 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #51 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> #52 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #53 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> #54 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #55 0xc08fdcf8 in tcp_usr_send (so=0xc2ac1820, flags=0, m=0xc270ed00, >>>> nam=0x0, control=0x0, td=0xc28e2d80) at tcp_offload.h:269 >>>> #56 0xc0850405 in sosend_generic (so=0xc2ac1820, addr=0x0, >>>> uio=0xc28766c0, >>>> top=0xc270ed00, control=0x0, flags=0, td=0xc28e2d80) at >>>> /usr/src/sys/kern/uipc_socket.c:1243 >>>> #57 0xc084bf7f in sosend (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, >>>> top=0x0, >>>> control=0x0, flags=0, td=0xc28e2d80) at >>>> /usr/src/sys/kern/uipc_socket.c:1285 >>>> #58 0xc0833c5b in soo_write (fp=0xc28e84c0, uio=0xc28766c0, >>>> active_cred=0xc28e5900, flags=0, td=0xc28e2d80) at >>>> /usr/src/sys/kern/sys_socket.c:103 >>>> #59 0xc082d2e7 in dofilewrite (td=0xc28e2d80, fd=24, fp=0xc28e84c0, >>>> auio=0xc28766c0, offset=-1, flags=0) at file.h:257 >>>> #60 0xc082d5c8 in kern_writev (td=0xc28e2d80, fd=24, auio=0xc28766c0) at >>>> /usr/src/sys/kern/sys_generic.c:402 >>>> #61 0xc082d816 in writev (td=0xc28e2d80, uap=0xccf6fcfc) at >>>> /usr/src/sys/kern/sys_generic.c:388 >>>> #62 0xc0a7f2d5 in syscall (frame=0xccf6fd38) at >>>> /usr/src/sys/i386/i386/trap.c:1101 >>>> #63 0xc0a636a0 in Xint0x80_syscall () at >>>> /usr/src/sys/i386/i386/exception.s:262 >>>> #64 0x00000033 in ?? () >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) >>>> (kgdb) quit >>>> >>> >>> tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: >>> >>> case EMSGSIZE: >>> /* >>> * For some reason the interface we used initially >>> * to send segments changed to another or lowered >>> * its MTU. >>> * >>> * tcp_mtudisc() will find out the new MTU and as >>> * its last action, initiate retransmission, so it >>> * is important to not do so here. >>> * >>> * If TSO was active we either got an interface >>> * without TSO capabilits or TSO was turned off. >>> * Disable it for this connection as too and >>> * immediatly retry with MSS sized segments >>> generated >>> * by this function. >>> */ >>> if (tso) >>> tp->t_flags &= ~TF_TSO; >>> tcp_mtudisc(tp->t_inpcb, 0); >>> return (0); >>> >>> But tcp_mtudisc() calls tcp_output(): >>> >>> tcpstat.tcps_mturesent++; >>> tp->t_rtttime = 0; >>> tp->snd_nxt = tp->snd_una; >>> tcp_free_sackholes(tp); >>> tp->snd_recover = tp->snd_max; >>> if (tp->t_flags & TF_SACK_PERMIT) >>> EXIT_FASTRECOVERY(tp); >>> tcp_output_send(tp); >>> return (inp); >>> >>> I'm not sure why it's not able to figure out the MTU, perhaps folks on >>> net@ >>> can help. However, it would seem that for the tcp_output() case, >>> tcp_mtudisc() should probably not call tcp_output_send(), but instead >>> tcp_output() should just loop back up to the top after calling >>> tcp_mtudisc() >>> and retry. >>> >>> >> I'm afraid to be wrong but it looks similar to another report for >> 8.0-STABLE >> (may it be a cross-major version regression somewhere around >> tcp_mtudisc()?): >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056063.html >> > > The backtrace indeed looks very similar. The reporter at that point > had been cvs updated in the middle between two commits. Updating > again seemed to have fixed it for him. > > None of those changes are in 7.3-RELEASE though and the endless loop > indeed should no happen. > > > Is the kernel and the core file still avail for further analyses? > > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Fri Apr 23 19:05:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1F3A106564A for ; Fri, 23 Apr 2010 19:05:11 +0000 (UTC) (envelope-from tad1214@aol.com) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by mx1.freebsd.org (Postfix) with ESMTP id B2FC88FC20 for ; Fri, 23 Apr 2010 19:05:11 +0000 (UTC) Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o3NIslTm025035 for ; Fri, 23 Apr 2010 14:54:47 -0400 Received: from osprey.cptxoffice.net (ng1.cptxoffice.net [208.74.121.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 52D6BE000099 for ; Fri, 23 Apr 2010 14:54:47 -0400 (EDT) Message-ID: <4BD1ECD5.5040002@aol.com> Date: Fri, 23 Apr 2010 13:54:13 -0500 From: Thomas Donnelly User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100224 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:384482304:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29434bd1ecf763fa X-AOL-IP: 208.74.121.102 Subject: Fresh Build Not Taking IPv6 RA's? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 19:05:12 -0000 Hi, I have a few servers on a vlan which have all happily auto configured via RA, both FreeBSD and CentOS boxes. However, I freshly installed a FreeBSD 7 box, brought it to stable, and it wont auto configure. I'm kind of at a loss at what could be the issue. Anyone have ideas on where to start? Thanks -=Tom # sysctl net.inet6.ip6.accept_rtadv net.inet6.ip6.accept_rtadv: 1 # uname -v FreeBSD 7.3-STABLE #1: Thu Apr 15 23:59:49 CDT 2010 # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:ce:9f:78 inet6 fe80::230:48ff:fece:9f78%em0 prefixlen 64 scopeid 0x1 inet X.X.X.X netmask 0xfffffff0 broadcast X.X.X.X inet X.X.X.X netmask 0xffffffff broadcast X.X.X.X media: Ethernet autoselect (1000baseTX ) status: active tcpdump ip6 shows: 13:48:18.256983 IP6 fe80::6616:8dff:fe85:884a > ff02::1: ICMP6, router advertisement, length 64 so it is hearing the RA # /etc/rc.d/network_ipv6 start route: writing to routing socket: File exists add net ::ffff:0.0.0.0: gateway ::1: route already in table route: writing to routing socket: File exists add net ::0.0.0.0: gateway ::1: route already in table net.inet6.ip6.forwarding: 0 -> 0 net.inet6.ip6.accept_rtadv: 1 -> 1 route: writing to routing socket: File exists add net fe80::: gateway ::1: route already in table route: writing to routing socket: File exists add net ff02::: gateway ::1: route already in table IPv4 mapped IPv6 address support=NO From owner-freebsd-net@FreeBSD.ORG Fri Apr 23 19:10:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C241065673 for ; Fri, 23 Apr 2010 19:10:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 57C2C8FC12 for ; Fri, 23 Apr 2010 19:10:21 +0000 (UTC) Received: (qmail 5592 invoked by uid 399); 23 Apr 2010 19:10:20 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Apr 2010 19:10:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BD1F09B.9070207@FreeBSD.org> Date: Fri, 23 Apr 2010 12:10:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Thomas Donnelly References: <4BD1ECD5.5040002@aol.com> In-Reply-To: <4BD1ECD5.5040002@aol.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Fresh Build Not Taking IPv6 RA's? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 19:10:21 -0000 On 04/23/10 11:54, Thomas Donnelly wrote: > Hi, > > I have a few servers on a vlan which have all happily auto configured > via RA, both FreeBSD and CentOS boxes. However, I freshly installed a > FreeBSD 7 box, brought it to stable, and it wont auto configure. What are the versions of the FreeBSD boxes you have which are working? Did you run mergemaster, or similarly update /etc when you upgraded? What is different in the configuration between the working systems and the non-working? What version of FreeBSD are you installing? Does it work when you first install it before upgrading the OS? There is no inherent reason that it should not work, so you have more investigating to do. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Fri Apr 23 19:34:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54525106564A for ; Fri, 23 Apr 2010 19:34:03 +0000 (UTC) (envelope-from jake@stnlabs.com) Received: from server514.appriver.com (server514f.exghost.com [72.32.253.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9E08FC0A for ; Fri, 23 Apr 2010 19:34:02 +0000 (UTC) X-Policy: GLOBAL - stnlabs.com X-Primary: jake@stnlabs.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: jake@stnlabs.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.253.140 X-Note-Reverse-DNS: fe01.exg4.exghost.com X-Note-WHTLIST: jake@stnlabs.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G179 G180 G181 G182 G186 G187 G198 G285 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [72.32.253.140] (HELO FE01.exg4.exghost.com) by server514.appriver.com (CommuniGate Pro SMTP 5.3.2) with ESMTP id 101779735 for freebsd-net@freebsd.org; Fri, 23 Apr 2010 14:34:09 -0500 Received: from be18.exg4.exghost.com ([72.32.253.175]) by FE01.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Apr 2010 14:34:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Apr 2010 14:33:45 -0500 Message-ID: <0D51275610C0C04588FA911C811B687E02A51E50@be18.exg4.exghost.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Traverse Solos 4-port ADSL card Thread-Index: AcrjG+OpC/gpvdhFRrafui4S/NryHA== From: "Jake Baillie" To: X-OriginalArrivalTime: 23 Apr 2010 19:34:02.0586 (UTC) FILETIME=[EDBF9BA0:01CAE31B] Subject: Traverse Solos 4-port ADSL card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 19:34:03 -0000 Hi, I've recently come across this product: http://www.traverse.com.au/productview.php Which has an open source Linux driver hosted on SourceForge. From the README file contained in that driver package: The Solos PCI multiport ADSL2+ modem has been designed by Traverse Technologies. Each ADSL port is controlled by a Conexant Solos D ADSL2+ chipset, which interfaces to the PCI bus through an FPGA. I have two questions: 1. Is this device supported on FreeBSD? A read of the 8.0R hardware document and a few searches of the web turned up nothing. 2. If it is not currently supported, would it be a difficult port to FreeBSD? Ideally, I would like to put four of these in a box for a very specific application. I want to use pf, and therefore, would prefer to use FreeBSD. Cheers, -- jake From owner-freebsd-net@FreeBSD.ORG Fri Apr 23 20:36:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1440B106564A for ; Fri, 23 Apr 2010 20:36:11 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-pz0-f172.google.com (mail-pz0-f172.google.com [209.85.222.172]) by mx1.freebsd.org (Postfix) with ESMTP id D654D8FC15 for ; Fri, 23 Apr 2010 20:36:10 +0000 (UTC) Received: by pzk2 with SMTP id 2so6816193pzk.27 for ; Fri, 23 Apr 2010 13:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=///UM+CSpgM5f+oLjOG2Pymn+a9WvtPtcxI2yWaiw7M=; b=gbycGo9dUuNBDr0e5N5o+VZwKk+W5GoPEequCRthMwVKHXHS4dFD5K1IFGnLk3Ai/+ 4fGmkU5KJTjMgOUOcGZ/dDfYAPXTABwakDtkcjKfPdl4ZzhMZ28hXSceNabzIPcLkZgG oDU1+StBYfcGi2NDI6nVfwUrVmaJdummZhHug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dU2BXyoU07pJ7sbVFwuWUv1CijE8Di3HYRUyMJ+2E0ew2PUnlrP5ODMi+uHl5R3QyB +4apWrlEoWYFRs8yDjNR1Z4wdVwx9zbz0f1bAys3G4+4dfTus9FFTn4KnJyzMjlOS/rZ Ysb2daimFf/EIS0uoNmeh7lYzvUGZhbFxj0DQ= Received: by 10.114.236.2 with SMTP id j2mr883428wah.110.1272054970126; Fri, 23 Apr 2010 13:36:10 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id f11sm6318391wai.11.2010.04.23.13.36.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 13:36:09 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BD204B6.6050307@elischer.org> Date: Fri, 23 Apr 2010 13:36:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jake Baillie References: <0D51275610C0C04588FA911C811B687E02A51E50@be18.exg4.exghost.com> In-Reply-To: <0D51275610C0C04588FA911C811B687E02A51E50@be18.exg4.exghost.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Traverse Solos 4-port ADSL card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 20:36:11 -0000 On 4/23/10 12:33 PM, Jake Baillie wrote: > Hi, > > I've recently come across this product: > > http://www.traverse.com.au/productview.php > > Which has an open source Linux driver hosted on SourceForge. From the > README file contained in that driver package: > > The Solos PCI multiport ADSL2+ modem has been designed by Traverse > Technologies. Each ADSL port is controlled by a Conexant Solos D ADSL2+ > chipset, which interfaces to the PCI bus through an FPGA. > > I have two questions: > > 1. Is this device supported on FreeBSD? A read of the 8.0R hardware > document and a few searches of the web turned up nothing. I believe not > > 2. If it is not currently supported, would it be a difficult port to > FreeBSD? Ideally, I would like to put four of these in a box for a very > specific application. I want to use pf, and therefore, would prefer to > use FreeBSD. The code (I looked at it just now) would take someone who was familiar with both systems to rewrite it. It has to interruact with the pci subsystem which is different, and the device top layer whuch is different, and all the module linkage stuff would have to be rewritten. The ioread and iowrite calls and the logic as to what is done when would remain pretty much the same. (ioread and iowrite would be changed to macros to DTRT for freeBSD. It also hooks into the Linux ATM framework and I have NO IDEA how different that is however it only uses a couple of the methods read/write/opemn/close so I'm pretty sure our framework would have equivalent methods of some sort. you could probably do it yourself if you were willing to spend a couple of weeks learning this e sunsystems on each system :-) > > Cheers, > -- jake > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 11:35:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64E571065738 for ; Sat, 24 Apr 2010 11:35:05 +0000 (UTC) (envelope-from ozbilgin@hotmail.com) Received: from bay0-omc2-s21.bay0.hotmail.com (bay0-omc2-s21.bay0.hotmail.com [65.54.190.96]) by mx1.freebsd.org (Postfix) with ESMTP id 517C78FC22 for ; Sat, 24 Apr 2010 11:35:05 +0000 (UTC) Received: from BAY145-W49 ([65.54.190.125]) by bay0-omc2-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Apr 2010 04:23:05 -0700 Message-ID: X-Originating-IP: [78.160.42.128] From: =?windows-1254?B?eXVzdWYg9npiaWxnaW4=?= To: Date: Sat, 24 Apr 2010 14:23:04 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2010 11:23:05.0213 (UTC) FILETIME=[8232F2D0:01CAE3A0] Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw - natd problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 11:35:05 -0000 Hi, I am trying to use 2 internet lines for load balance. outgoing interfaces are: em0 and xl0 --Local Interface ( rl0 / 192.168.0.1 ) -- | Freebsd 7.2 | --ISP 1 ---interface ( em0 ) IP: 192.168.3.1 --ISP 2 ---interface ( xl0 ) IP: 192.168.4.1 Default Gateway: 192.168.3.2 ISP2 Gateway: 192.168.4.2 Below rules is working well. 00030 prob 0.500000 skipto 60 ip from any to any in recv rl0 00031 skipto 40 ip from any to any out xmit rl0 tagged 1 00032 skipto 60 ip from any to any out xmit rl0 tagged 2 00033 skipto 198 tag 1 ip from any to any in recv em0 00034 skipto 200 tag 2 ip from any to any in recv xl0 00040 setfib 0 ip from any to any via rl0 keep-state 00050 allow ip from any to any via rl0 00060 setfib 1 ip from any to any via rl0 keep-state 00070 allow ip from any to any via rl0 00198 nat 1 ip from any to any via em0 00200 nat 2 ip from any to any via xl0 10220 allow ip from any to any 65534 deny ip from any to any 65535 allow ip from any to any But I want to use natd. I deleted the rules 198 then I added ipfw add 198 divert 8668 ip from any to any via em0 Still works well but after deleted rule 200 and I added below rule ipfw add 200 divert 8669 ip from any to any via xl0 Only it uses default interface. What can be the problem? Second natd working and natd conf files are below. /sbin/natd -f /etc/nat1.conf /sbin/natd -f /etc/nat2.conf ------------------ nat1.conf ------------------ interface em0 dynamic yes same_ports yes use_sockets yes port 8668 unregistered_only yes log yes punch_fw 1000:999 ------------------ nat2.conf ------------------ interface xl0 port 8669 dynamic yes same_ports yes use_sockets yes unregistered_only yes log yes punch_fw 1000:999 Thanks. Yusuf