From owner-freebsd-net@FreeBSD.ORG Sun May 16 06:20:50 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 0F953106566B for ; Sun, 16 May 2010 06:20:50 +0000 (UTC) (envelope-from uwe@laverenz.de) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by mx1.freebsd.org (Postfix) with ESMTP id 819B58FC08 for ; Sun, 16 May 2010 06:20:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1273990845; l=170; s=domk; d=laverenz.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=89gIRvHtrsOSCpHCKegdAvcMKRI=; b=fy5dGl656Y4s9CaZ8ku9UJaD6PzXNjAitZIj884rMBT4nLHkv1zep9JIjU9UAYRUHir YA801DjzCTh51+jM2G02iV9HC8X9YI/L4dYiPJNFe8Y1FFxgiubK3J4W5OwrZfAjvZaep UfJPIBTz1XYn+iRXEf3yEZSTyyXB0BHKG9A= X-RZG-AUTH: :LWgJfE6Id/4Sm/WkdV0gEbKL+/p/UjmosA/b4BPR0oc5Ok8I9ajctAll X-RZG-CLASS-ID: mo00 Received: from athena.laverenz.de (91-67-34-210-dynip.superkabel.de [91.67.34.210]) by post.strato.de (mrclete mo12) (RZmta 23.0) with ESMTP id N006c8m4G5tP0f for ; Sun, 16 May 2010 08:09:43 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by athena.laverenz.de (Postfix) with ESMTP id 34C9F73EC6 for ; Sun, 16 May 2010 11:51:43 +0200 (CEST) Received: from athena.laverenz.de ([127.0.0.1]) by localhost (athena [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23325-03 for ; Sun, 16 May 2010 11:51:42 +0200 (CEST) Received: from [192.168.23.142] (unknown [192.168.23.142]) by athena.laverenz.de (Postfix) with ESMTP id B9CC773E68 for ; Sun, 16 May 2010 11:51:42 +0200 (CEST) Message-ID: <4BEF8C24.2080404@laverenz.de> Date: Sun, 16 May 2010 08:09:40 +0200 From: Uwe Laverenz Organization: private site User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Which is faster: iSCSI to Freebsd box over 1Gb or local SATA storage with intel ICH9? 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, 16 May 2010 06:20:50 -0000 Am 15.05.2010 19:41, schrieb justino garcia: > Which is faster: iSCSI to Freebsd box over 1Gb or local SATA storage with > intel ICH9? Local SATA is faster. Uwe From owner-freebsd-net@FreeBSD.ORG Sun May 16 06:37:37 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 36F8C106564A for ; Sun, 16 May 2010 06:37:37 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 27D868FC1B for ; Sun, 16 May 2010 06:37:36 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 541421A4203; Sat, 15 May 2010 23:22:11 -0700 (PDT) Date: Sat, 15 May 2010 23:22:11 -0700 From: Alfred Perlstein To: freebsd-net@freebsd.org Message-ID: <20100516062211.GC6175@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Patch for ip6_sprintf(), please review 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, 16 May 2010 06:37:37 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, The following patch seems appropriate to apply to fix the kernel ip6_sprintf() function. What it is doing is ensuring that when we abbreviate addresses that the longest string of zeros is shortend, not the first run of zeros. Our internal commit log is: problem: Unification of IPv6 address representation fix: recommended format of text representing an IPv6 address is summarized as follows. 1. omit leading zeros 2. "::" used to their maximum extent whenever possible 3. "::" used where shortens address the most 4. "::" used in the former part in case of a tie breaker 5. do not shorten one 16 bit 0 field 6. use lower case Present code in ip6_sprintf() is following rules 1,2,5,6. Adding fix for following other rules also.For following rules 3 and 4, finding out the index where to replace zero's with '::' and using that index. References: http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04.html Diff is attached in text format. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer --YiEDa0DAkWCtVeE4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="in6.diff" Index: in6.c =================================================================== --- in6.c (revision 207329) +++ in6.c (working copy) @@ -61,7 +61,7 @@ */ #include -__FBSDID("$FreeBSD$"); +__FBSDID("$FreeBSD: head/sys/netinet6/in6.c 207268 2010-04-27 09:47:14Z kib $"); #include "opt_compat.h" #include "opt_inet.h" @@ -1898,7 +1898,7 @@ char * ip6_sprintf(char *ip6buf, const struct in6_addr *addr) { - int i; + int i, cnt = 0, maxcnt = 0, idx = 0, index = 0; char *cp; const u_int16_t *a = (const u_int16_t *)addr; const u_int8_t *d; @@ -1907,6 +1907,23 @@ cp = ip6buf; for (i = 0; i < 8; i++) { + if (*(a + i) == 0) { + cnt++; + if (cnt == 1) + idx = i; + } + else if (maxcnt < cnt) { + maxcnt = cnt; + index = idx; + cnt = 0; + } + } + if (maxcnt < cnt) { + maxcnt = cnt; + index = idx; + } + + for (i = 0; i < 8; i++) { if (dcolon == 1) { if (*a == 0) { if (i == 7) @@ -1917,7 +1934,7 @@ dcolon = 2; } if (*a == 0) { - if (dcolon == 0 && *(a + 1) == 0) { + if (dcolon == 0 && *(a + 1) == 0 && i == index) { if (i == 0) *cp++ = ':'; *cp++ = ':'; --YiEDa0DAkWCtVeE4-- From owner-freebsd-net@FreeBSD.ORG Sun May 16 19:05:03 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 06A251065670; Sun, 16 May 2010 19:05:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D07498FC0A; Sun, 16 May 2010 19:05:02 +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 o4GJ52D3054277; Sun, 16 May 2010 19:05:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4GJ52GG054273; Sun, 16 May 2010 19:05:02 GMT (envelope-from linimon) Date: Sun, 16 May 2010 19:05:02 GMT Message-Id: <201005161905.o4GJ52GG054273@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146628: [tcp] [patch] TCP does not clear DF when MTU is below a threshold 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, 16 May 2010 19:05:03 -0000 Old Synopsis: [patch] TCP does not clear DF when MTU is below a threshold New Synopsis: [tcp] [patch] TCP does not clear DF when MTU is below a threshold Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 16 19:04:46 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146628 From owner-freebsd-net@FreeBSD.ORG Sun May 16 19:21:49 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 EAD2D1065672 for ; Sun, 16 May 2010 19:21:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 957A68FC1B for ; Sun, 16 May 2010 19:21:49 +0000 (UTC) Received: (qmail 30610 invoked by uid 399); 16 May 2010 19:21:47 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 May 2010 19:21:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BF045C9.1040906@FreeBSD.org> Date: Sun, 16 May 2010 12:21:45 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alfred Perlstein References: <20100516062211.GC6175@elvis.mu.org> In-Reply-To: <20100516062211.GC6175@elvis.mu.org> 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: Patch for ip6_sprintf(), please review 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, 16 May 2010 19:21:50 -0000 Someone at work has been reading http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation :) This change follows the rules in that draft which will become and RFC as soon as it finishes winding its way through the process, so I am supportive of the change you are proposing. Doug On 5/15/2010 11:22 PM, Alfred Perlstein wrote: > Hello, > > The following patch seems appropriate to apply > to fix the kernel ip6_sprintf() function. > > What it is doing is ensuring that when we > abbreviate addresses that the longest string > of zeros is shortend, not the first run of > zeros. > > Our internal commit log is: > problem: > Unification of IPv6 address representation > fix: > recommended format of text representing an IPv6 address > is summarized as follows. > > 1. omit leading zeros > > 2. "::" used to their maximum extent whenever possible > > 3. "::" used where shortens address the most > > 4. "::" used in the former part in case of a tie breaker > > 5. do not shorten one 16 bit 0 field > > 6. use lower case > > Present code in ip6_sprintf() is following rules 1,2,5,6. > Adding fix for following other rules also.For following > rules 3 and 4, finding out the index where to replace zero's > with '::' and using that index. > References: > http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04.html > > > Diff is attached in text format. > > > > > _______________________________________________ > 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" -- ... 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 Sun May 16 19:59: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 947141065670 for ; Sun, 16 May 2010 19:59:06 +0000 (UTC) (envelope-from dejamuse@yahoo.com) Received: from web62505.mail.re1.yahoo.com (web62505.mail.re1.yahoo.com [69.147.75.97]) by mx1.freebsd.org (Postfix) with SMTP id 313A28FC12 for ; Sun, 16 May 2010 19:59:05 +0000 (UTC) Received: (qmail 59519 invoked by uid 60001); 16 May 2010 19:32:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1274038344; bh=b4ah8yVOcUO871QnI2F74VxO22FiEowgzal8GMA4UpI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=XbnxUoPdQllyCKtOCIy52Srob6/nVsZXG2Ta7hSgtETazfCaA79mRZSBWqarMoZCXEHaCg2IzzXDdqX0iFEjt8BskjA4dalxli47nMj0C4hmviJmFIjVKxD/Ss8VHMyZLDqhcY3MFVZOg4Lf8QYmcuoZVq55T6TrNdda7tChh98= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=DMeQ2N/0e48pT1VLrvmjZpfmvz72fMbTOAlX2s36kIwWZiF02qkq4s45kAC1OzS//SZJDK2ov92b4Y24RAbUadNb8e/O5ZBT2cQi8Osivo2t6XIx55CHHmfossVwU+GWlISQsxKfaolmbTphklRe+ilh3Fr6qGHPgvGrwvwYyaE=; Message-ID: <755761.58686.qm@web62505.mail.re1.yahoo.com> X-YMail-OSG: 0oj5dDIVM1mSCaflcdd_l0NRcVpORhW0dPO3gsPcbVP3dQe z6R3Q6vDYRAdP_BkkA1gnUyst941HPh5E5JL7LXGRjtqWeXQn3XwxrKpb6.Z KuG9Y4150gSuRikryEJtvEgdNezp45h2pQtzwC_99mQPV9gxNUtN9e.gpHTQ kQmuOVpTA2JyoHIx9Ripj1H1YHaB9fRDa3aeN5eLTdnMFNN0AwpvJTz.VXe9 5Z1OdvrF8kNcQ.DKya.chdCf8RFqk9X0mV6wQ2c2Zz.UCvqipB0oqyJuqiGi tmHaY0aWU_0b4_G_hs3lFSQ6qaXggptlQOdb2DyxOBwqoJpqkEM3bai1J81r 2beAY2akAtikdy_ruLoARATLlYbtE2.9IjocfdtVatNXQ3DlWhXc- Received: from [71.235.64.239] by web62505.mail.re1.yahoo.com via HTTP; Sun, 16 May 2010 12:32:24 PDT X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 Date: Sun, 16 May 2010 12:32:24 -0700 (PDT) From: Jeff To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Net problem with server running in jail 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, 16 May 2010 19:59:06 -0000 I have been running PCBSD 8 (FreeBSD 8.0) with no problems until recently. I have an Apache server running in a jail (created by The Warden PBI) with = PHP, MySQL, and Drupal.=A0 I also run Firefox on the same machine to access= the internet and the local server for development.=A0 I've never had a pro= blem accessing the server until recently when I moved to a new location and= tried to set up the new network on a new router and internet connection.= =A0 I switched the NIC card to a static IP from DHCP and then access to the= server got really slow, like 15 seconds delay from 2 seconds before.=A0 Al= so, Drupal can no longer access the net to check for module updates and suc= h. I asked for advice at PCBSD and reconfigured some things that fixed the pro= blem for a while, but now nothing works, so they advised me to ask here.=A0= I don't know what precipitated this problem or exactly what's wrong. Originally, both the NIC and the jail IPs were assigned to the lagg0 device= .=A0 I have another machine with the same setup that has none of these prob= lems, but it's using PCBSD=A0 7.1.1. which has no lagg interface, just the = NIC itself. If I manually assign the static IP (192.168.1.10) to the NIC, re0, and leav= e the jail (192.168.1.12) assigned to lagg0, the latency problems disappear= but Drupal still cannot talk to the outside world.=A0 I shut down the fire= wall but it had no effect. I assigned both the jail and the NIC to re0, and disabled lagg0 but that di= dn't work. The router gateway is 192.168.1.2 Here is the current state: # ifconfig re0: flags=3D8843 metric 0 mtu 1500 =A0=A0=A0=A0=A0=A0=A0 options=3D389b =A0=A0=A0=A0=A0=A0=A0 ether 00:24:8c:a1:b3:f7 =A0=A0=A0=A0=A0=A0=A0 inet6 fe80::224:8cff:fea1:b3f7%re0 prefixlen 64 scope= id 0x1 =A0=A0=A0=A0=A0=A0=A0 media: Ethernet autoselect (100baseTX ) =A0=A0=A0=A0=A0=A0=A0 status: active lo0: flags=3D8049 metric 0 mtu 16384 =A0=A0=A0=A0=A0=A0=A0 options=3D3 =A0=A0=A0=A0=A0=A0=A0 inet6 ::1 prefixlen 128 =A0=A0=A0=A0=A0=A0=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 =A0=A0=A0=A0=A0=A0=A0 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=3D0<> metric 0 mtu 33152 pfsync0: flags=3D0<> metric 0 mtu 1460 =A0=A0=A0=A0=A0=A0=A0 syncpeer: 224.0.0.240 maxupd: 128 lo1: flags=3D8048 metric 0 mtu 16384 =A0=A0=A0=A0=A0=A0=A0 options=3D3 lagg0: flags=3D8843 metric 0 mtu 15= 00 =A0=A0=A0=A0=A0=A0=A0 options=3D389b =A0=A0=A0=A0=A0=A0=A0 ether 00:24:8c:a1:b3:f7 =A0=A0=A0=A0=A0=A0=A0 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.16= 8.1.255 =A0=A0=A0=A0=A0=A0=A0 inet6 fe80::224:8cff:fea1:b3f7%lagg0 prefixlen 64 sco= peid 0x5 =A0=A0=A0=A0=A0=A0=A0 inet 192.168.1.12 netmask 0xffffffff broadcast 192.16= 8.1.12 =A0=A0=A0=A0=A0=A0=A0 media: Ethernet autoselect =A0=A0=A0=A0=A0=A0=A0 status: active =A0=A0=A0=A0=A0=A0=A0 laggproto failover =A0=A0=A0=A0=A0=A0=A0 laggport: re0 flags=3D5 -------------------------------------- # netstat -rn Routing tables Internet: Destination=A0=A0=A0=A0=A0=A0=A0 Gateway=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 F= lags=A0=A0=A0 Refs=A0=A0=A0=A0=A0 Use=A0 Netif=A0=A0=A0 Expire default=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0=A0 =A0 192.168.1.2=A0=A0=A0=A0=A0= =A0=A0 UGS=A0=A0=A0=A0=A0=A0=A0 12=A0=A0=A0=A0=A0 266 =A0=A0 lagg0 127.0.0.1=A0=A0=A0=A0=A0=A0=A0 =A0 =A0=A0 link#2=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0 =A0=A0 UH=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0 0=A0=A0=A0=A0=A0=A0=A0 0=A0= =A0 =A0 lo0 192.168.1.0/24=A0=A0=A0=A0 link#5=A0=A0=A0=A0=A0=A0=A0 =A0=A0 =A0=A0=A0 U= =A0=A0=A0=A0=A0 =A0 =A0 =A0=A0=A0 3=A0=A0=A0=A0=A0=A0 52 =A0 =A0 lagg0 192.168.1.10=A0=A0=A0=A0 =A0=A0 link#5=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0 =A0= =A0 UHS=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0 =A0=A0 lo0 192.168.1.12=A0=A0=A0=A0 =A0=A0 link#5=A0=A0=A0=A0=A0=A0=A0 =A0=A0 =A0=A0= =A0 UHS=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 29=A0 =A0=A0 lo0 =3D> 192.168.1.12/32 =A0 link#5=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 U=A0=A0=A0= =A0=A0=A0 =A0 =A0 =A0=A0 0=A0=A0=A0=A0=A0=A0=A0 0 =A0 =A0=A0 lagg0 AppleTalk: Destination=A0=A0=A0=A0=A0=A0=A0 Gateway=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 F= lags=A0=A0=A0 Netif Expire Internet6: Destination=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Gateway=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Flags=A0=A0=A0=A0=A0 Netif Expire ::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 ::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 UH=A0=A0=A0=A0=A0=A0=A0=A0=A0 lo0 fe80::%re0/64=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 l= ink#1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = U=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 re0 fe80::224:8cff:fea1:b3f7%re0=A0=A0=A0=A0=A0 link#1=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UHS=A0=A0=A0=A0=A0=A0=A0=A0 l= o0 fe80::%lo0/64=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 l= ink#2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = U=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lo0 fe80::1%lo0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 link#2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 UHS=A0=A0=A0=A0=A0=A0=A0=A0 lo0 fe80::%lagg0/64=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 link#= 5=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 U=A0= =A0=A0=A0=A0=A0=A0=A0 lagg0 fe80::224:8cff:fea1:b3f7%lagg0=A0=A0=A0 link#5=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UHS=A0=A0=A0=A0=A0=A0=A0=A0 lo0 ff01:1::/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 fe80::224:8cff:fea1:b3f7%re0=A0 U=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 re0 ff01:2::/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 U=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lo0 ff01:5::/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 fe80::224:8cff:fea1:b3f7%lagg0 U=A0=A0=A0=A0=A0=A0=A0=A0 lagg0 ff02::%re0/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 f= e80::224:8cff:fea1:b3f7%re0=A0 U=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 re0 ff02::%lo0/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 := :1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 U=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lo0 ff02::%lagg0/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fe80:= :224:8cff:fea1:b3f7%lagg0 U=A0=A0=A0=A0=A0=A0=A0=A0 lagg0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D On the older machine with PCBSD 7.1.1 where the same jail setup with the se= rver running Drupal has none of these problems, the setup is as follows (19= 2.168.1.11 is the machine's static IP, the jail is also on 192.168.1.12 but= I never run both servers at the same time) Not sure why but the jail IP do= esn't show up here: # ifconfig bge0: flags=3D8843=0A metric 0 mtu = 1500 =A0=A0=A0=A0=A0=A0=A0 options=3D9b =A0=A0=A0=A0=A0=A0=A0=0A ether 00:11:11:c3:7a:e2 =A0=A0=A0=A0=A0=A0=A0 inet 192.168.1.11 netmask 0xffffff00=0A broadcast 192= .168.1.255 =0A=A0=A0=A0=A0=A0=A0=A0 media: Ethernet autoselect (100baseTX ) =A0=A0=A0=A0=A0=A0=A0=0A status: active plip0: flags=3D108810=0A metric 0= mtu 1500 lo0: flags=3D8049=0A metric 0 mtu 16384 =0A=A0=A0=A0=A0=A0=A0=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 =A0=A0=A0=A0=A0=A0=A0 inet6 ::1 =0Aprefixlen 128 =A0=A0=A0=A0=A0=A0=A0 inet 127.0.0.1 netmask 0xff000000 pfsync0: =0Aflags=3D0<> metric 0 mtu 1460 =A0=A0=A0=A0=A0=A0=A0 syncpeer: 224.0.0.240 =0Amaxupd: 128 =0Apflog0: flags=3D0<> metric 0 mtu 33204 ---------------------------------- #=0A netstat -rn Routing tables Internet: Destination=A0=A0=A0=A0 =A0=A0=A0 =0AGateway=A0=A0=A0=A0=A0=A0=A0=A0 =A0 = =A0 =A0 =A0=A0 Flags=A0=A0=A0=A0=A0=A0 Refs=A0=A0=A0=A0 Use =A0=A0 Netif=A0= =A0 Expire default=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0 =A0 =A0=0A 192.168.1.2=A0=A0=A0=A0= =A0 =A0 =A0=A0 =A0 UGS=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0 =A0 =A0 3323=A0=A0= =A0=A0 bge0 =0A127.0.0.1=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 127.0.0.1=A0=A0=A0=A0=A0 =A0 =A0 = =A0 =A0 =A0 UH=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 0=A0=A0=A0=A0=A0=A0 22=A0=A0 = =A0 =A0=A0 lo0 192.168.1.0/24=A0=A0=A0=A0 =0Alink#1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 = =A0 =A0=A0 UC=A0=A0=A0=A0=A0=A0 =A0=A0 =A0 0=A0=A0=A0=A0=A0=A0 0=A0 =A0 =A0= =A0 =A0 bge0 192.168.1.2=A0=A0=A0=A0=A0=A0 =A0=A0 =0A00:21:29:e4:34:e4=A0 UHLW=A0=A0=A0= =A0=A0=A0 2=A0=A0=A0=A0=A0 447 =A0 =A0 =A0 bge0=A0=A0 1176 =0A192.168.1.255=A0=A0=A0=A0=A0 ff:ff:ff:ff:ff:ff =A0 =A0 =A0 =A0 =A0 =A0= =A0 UHLWb=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 59=A0 =A0 =A0 =A0=A0 bge0 Internet6: Destination=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=0A Gateway=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Flags=A0=A0=A0=A0=A0 Netif Expire ::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=0A ::1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UHL=A0=A0=A0=A0=A0=A0=A0=A0 lo0 =0Afe80::%lo0/64=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 fe80::1%lo0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =0AU= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lo0 fe80::1%lo0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =0Alink#3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 UHL=A0=A0=A0=A0=A0=A0=A0=A0 lo0 ff01:3::/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=0A fe80::1%lo0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UC= =A0=A0=A0=A0=A0=A0=A0=A0=A0 lo0 =0Aff02::%lo0/32=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 fe80::1%lo0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =0AUC= =A0=A0=A0=A0=A0=A0=A0=A0=A0 lo0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What could cause the server latency to be so high, and why can't Drupal acc= ess the internet?=A0 I have had this problem on and off for years, going ba= ck to FBSD 6, but have never figured out the problem or how I got out of it= .=A0 This time nothing is working. Thanks, Jeff =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Sun May 16 20:20:08 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 304BC106564A for ; Sun, 16 May 2010 20:20: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 9B1178FC18 for ; Sun, 16 May 2010 20:20:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7801F41C840; Sun, 16 May 2010 22:20:06 +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 DXUS1+LdbHM8; Sun, 16 May 2010 22:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E3ECE41C83F; Sun, 16 May 2010 22:20: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 9E8F84448EC; Sun, 16 May 2010 20:17:34 +0000 (UTC) Date: Sun, 16 May 2010 20:17:34 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jeff In-Reply-To: <755761.58686.qm@web62505.mail.re1.yahoo.com> Message-ID: <20100516201540.V23815@maildrop.int.zabbadoz.net> References: <755761.58686.qm@web62505.mail.re1.yahoo.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1790818726-1274041054=:23815" Cc: freebsd-net@freebsd.org Subject: Re: Net problem with server running in jail 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, 16 May 2010 20:20:08 -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-1790818726-1274041054=:23815 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 16 May 2010, Jeff wrote: > I have been running PCBSD 8 (FreeBSD 8.0) with no problems until recently= =2E > > I have an Apache server running in a jail (created by The Warden PBI) wit= h PHP, MySQL, and Drupal.=A0 I also run Firefox on the same machine to acce= ss the internet and the local server for development.=A0 I've never had a p= roblem accessing the server until recently when I moved to a new location a= nd tried to set up the new network on a new router and internet connection.= =A0 I switched the NIC card to a static IP from DHCP and then access to the= server got really slow, like 15 seconds delay from 2 seconds before.=A0 Al= so, Drupal can no longer access the net to check for module updates and suc= h. > > I asked for advice at PCBSD and reconfigured some things that fixed the p= roblem for a while, but now nothing works, so they advised me to ask here.= =A0 I don't know what precipitated this problem or exactly what's wrong. > > Originally, both the NIC and the jail IPs were assigned to the lagg0 devi= ce.=A0 I have another machine with the same setup that has none of these pr= oblems, but it's using PCBSD=A0 7.1.1. which has no lagg interface, just th= e NIC itself. > > If I manually assign the static IP (192.168.1.10) to the NIC, re0, and le= ave the jail (192.168.1.12) assigned to lagg0, the latency problems disappe= ar but Drupal still cannot talk to the outside world.=A0 I shut down the fi= rewall but it had no effect. > > I assigned both the jail and the NIC to re0, and disabled lagg0 but that = didn't work. > > The router gateway is 192.168.1.2 > > Here is the current state: =2E.. > What could cause the server latency to be so high, and why can't Drupal a= ccess the internet?=A0 I have had this problem on and off for years, going = back to FBSD 6, but have never figured out the problem or how I got out of = it.=A0 This time nothing is working. it's a bit hard to say and I admit I haven't read all the output I am not quoting. I'd suggest you'd check your resolv.conf inside the jail as DHCP wouldn't update that one and as you moved, things might have changed? /bz --=20 Bjoern A. Zeeb (from 21) Micky Rosa: But as we've all said, this game is about the past and the future, and tonight we forget about the past. We just focus on the future. --0-1790818726-1274041054=:23815-- From owner-freebsd-net@FreeBSD.ORG Sun May 16 22:09:48 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 333A5106566B for ; Sun, 16 May 2010 22:09:48 +0000 (UTC) (envelope-from cristclark@comcast.net) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6F18FC1A for ; Sun, 16 May 2010 22:09:48 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta04.emeryville.ca.mail.comcast.net with comcast id JM9K1e0041GXsucA4MweCZ; Sun, 16 May 2010 21:56:38 +0000 Received: from goku.i.pumpky.net ([24.6.184.50]) by omta07.emeryville.ca.mail.comcast.net with comcast id JMwc1e00G15fSwQ8UMwe7A; Sun, 16 May 2010 21:56:38 +0000 Date: Sun, 16 May 2010 14:58:00 -0700 From: "Crist J. Clark" To: net@freebsd.org Message-ID: <20100516215759.GA53824@goku.i.pumpky.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: MPD Just Stopped Working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 22:09:48 -0000 I'm running mpd5 on 7.2-RELEASE-p5. I just use it to tunnel from a Windows XP machine to the MPD server over an insecure (wireless) network. It "just stopped working" Friday. The MPD configuration hasn't been touched. As far as I know, nothing on the Windows box has changed. I'd suspect something stealthily changed on the Windoze box by Windows Update or the AV (Norton) software, but the more I look at the problem, it looks like the MPD side. The connection comes up, I see the two machines talk over the network with the XP machine the last to talk to the MPD side. Then the MPD side seems to try to figure some things out with itself for a few seconds before failing and closing down the connection. Here's what a packet capture looks like, 14:48:12.322112 IP 192.168.128.253.2255 > 192.168.128.254.1723: S 2131756225:2131756225(0) win 16384 14:48:12.322310 IP 192.168.128.254.1723 > 192.168.128.253.2255: S 4093488321:4093488321(0) ack 2131756226 win 65535 14:48:12.325435 IP 192.168.128.253.2255 > 192.168.128.254.1723: P 1:157(156) ack 1 win 17640: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) [|pptp] 14:48:12.326120 IP 192.168.128.254.1723 > 192.168.128.253.2255: P 1:157(156) ack 157 win 65535: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(257) [|pptp] 14:48:12.326863 IP 192.168.128.253.2255 > 192.168.128.254.1723: P 157:325(168) ack 157 win 17484: pptp CTRL_MSGTYPE=OCRQ CALL_ID(49152) CALL_SER_NUM(62587) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) [|pptp] 14:48:12.329535 IP 192.168.128.254.1723 > 192.168.128.253.2255: P 157:189(32) ack 325 win 65535: pptp CTRL_MSGTYPE=OCRP CALL_ID(64971) PEER_CALL_ID(49152) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(64000) RECV_WIN(16) PROC_DELAY(1) PHY_CHAN_ID(0) 14:48:12.337938 IP 192.168.128.253.2255 > 192.168.128.254.1723: P 325:349(24) ack 189 win 17452: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(64971) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff) 14:48:12.437639 IP 192.168.128.254.1723 > 192.168.128.253.2255: . ack 349 win 65535 14:48:29.343757 IP 192.168.128.254.1723 > 192.168.128.253.2255: P 189:337(148) ack 349 win 65535: pptp CTRL_MSGTYPE=CDN CALL_ID(64971) RESULT_CODE(3) ERR_CODE(0) CAUSE_CODE(0) [|pptp] 14:48:29.345175 IP 192.168.128.253.2255 > 192.168.128.254.1723: P 349:365(16) ack 337 win 17304: pptp CTRL_MSGTYPE=StopCCRQ REASON(1) 14:48:29.345629 IP 192.168.128.254.1723 > 192.168.128.253.2255: P 337:353(16) ack 365 win 65535: pptp CTRL_MSGTYPE=StopCCRP RESULT_CODE(1) ERR_CODE(0) 14:48:29.345763 IP 192.168.128.254.1723 > 192.168.128.253.2255: F 353:353(0) ack 365 win 65535 14:48:29.346531 IP 192.168.128.253.2255 > 192.168.128.254.1723: F 365:365(0) ack 354 win 17288 14:48:29.346637 IP 192.168.128.254.1723 > 192.168.128.253.2255: . ack 366 win 65534 And here is are the logs from MPD that correspond to this connection. Note all of the MPD activity between the hole in the packet capture from 14:48:12 to 14:48:29. It seems the server is having problems negotiating with itself? May 16 14:48:12 net5501 mpd: [L-1] Link: OPEN event May 16 14:48:12 net5501 mpd: [L-1] LCP: Open event May 16 14:48:12 net5501 mpd: [L-1] LCP: state change Initial --> Starting May 16 14:48:12 net5501 mpd: [L-1] LCP: LayerStart May 16 14:48:12 net5501 mpd: [L-1] PPTP: attaching to peer's outgoing call May 16 14:48:12 net5501 mpd: [L-1] Link: UP event May 16 14:48:12 net5501 mpd: [L-1] Link: origination is remote May 16 14:48:12 net5501 mpd: [L-1] LCP: Up event May 16 14:48:12 net5501 mpd: [L-1] LCP: state change Starting --> Req-Sent May 16 14:48:12 net5501 mpd: [L-1] LCP: SendConfigReq #1 May 16 14:48:12 net5501 mpd: [L-1] ACFCOMP May 16 14:48:12 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:12 net5501 mpd: [L-1] MRU 1500 May 16 14:48:12 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:12 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:12 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:12 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:12 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:12 net5501 mpd: [L-1] LCP: rec'd Configure Request #0 (Req-Sent) May 16 14:48:12 net5501 mpd: [L-1] MRU 1400 May 16 14:48:12 net5501 mpd: [L-1] MAGICNUM 5e8514f4 May 16 14:48:12 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:12 net5501 mpd: [L-1] ACFCOMP May 16 14:48:12 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:12 net5501 mpd: [L-1] LCP: SendConfigRej #0 May 16 14:48:12 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:14 net5501 mpd: [L-1] LCP: SendConfigReq #2 May 16 14:48:14 net5501 mpd: [L-1] ACFCOMP May 16 14:48:14 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:14 net5501 mpd: [L-1] MRU 1500 May 16 14:48:14 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:14 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:14 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:14 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:14 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:14 net5501 mpd: [L-1] LCP: rec'd Configure Request #1 (Req-Sent) May 16 14:48:14 net5501 mpd: [L-1] MRU 1400 May 16 14:48:14 net5501 mpd: [L-1] MAGICNUM 5e8514f4 May 16 14:48:14 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:14 net5501 mpd: [L-1] ACFCOMP May 16 14:48:14 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:14 net5501 mpd: [L-1] LCP: SendConfigRej #1 May 16 14:48:14 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:16 net5501 mpd: [L-1] LCP: SendConfigReq #3 May 16 14:48:16 net5501 mpd: [L-1] ACFCOMP May 16 14:48:16 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:16 net5501 mpd: [L-1] MRU 1500 May 16 14:48:16 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:16 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:16 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:16 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:16 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:17 net5501 mpd: [L-1] LCP: rec'd Configure Request #2 (Req-Sent) May 16 14:48:17 net5501 mpd: [L-1] MRU 1400 May 16 14:48:17 net5501 mpd: [L-1] MAGICNUM 5e8514f4 May 16 14:48:17 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:17 net5501 mpd: [L-1] ACFCOMP May 16 14:48:17 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:17 net5501 mpd: [L-1] LCP: SendConfigRej #2 May 16 14:48:17 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:18 net5501 mpd: [L-1] LCP: SendConfigReq #4 May 16 14:48:18 net5501 mpd: [L-1] ACFCOMP May 16 14:48:18 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:18 net5501 mpd: [L-1] MRU 1500 May 16 14:48:18 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:18 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:18 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:18 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:18 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:20 net5501 mpd: [L-1] LCP: SendConfigReq #5 May 16 14:48:20 net5501 mpd: [L-1] ACFCOMP May 16 14:48:20 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:20 net5501 mpd: [L-1] MRU 1500 May 16 14:48:20 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:20 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:20 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:20 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:20 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:21 net5501 mpd: [L-1] LCP: rec'd Configure Request #3 (Req-Sent) May 16 14:48:21 net5501 mpd: [L-1] MRU 1400 May 16 14:48:21 net5501 mpd: [L-1] MAGICNUM 5e8514f4 May 16 14:48:21 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:21 net5501 mpd: [L-1] ACFCOMP May 16 14:48:21 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:21 net5501 mpd: [L-1] LCP: SendConfigRej #3 May 16 14:48:21 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:22 net5501 mpd: [L-1] LCP: SendConfigReq #6 May 16 14:48:22 net5501 mpd: [L-1] ACFCOMP May 16 14:48:22 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:22 net5501 mpd: [L-1] MRU 1500 May 16 14:48:22 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:22 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:22 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:22 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:22 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:24 net5501 mpd: [L-1] LCP: SendConfigReq #7 May 16 14:48:24 net5501 mpd: [L-1] ACFCOMP May 16 14:48:24 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:24 net5501 mpd: [L-1] MRU 1500 May 16 14:48:24 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:24 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:24 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:24 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:24 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:25 net5501 mpd: [L-1] LCP: rec'd Configure Request #4 (Req-Sent) May 16 14:48:25 net5501 mpd: [L-1] MRU 1400 May 16 14:48:25 net5501 mpd: [L-1] MAGICNUM 5e8514f4 May 16 14:48:25 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:25 net5501 mpd: [L-1] ACFCOMP May 16 14:48:25 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:25 net5501 mpd: [L-1] LCP: SendConfigRej #4 May 16 14:48:25 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:26 net5501 mpd: [L-1] LCP: SendConfigReq #8 May 16 14:48:26 net5501 mpd: [L-1] ACFCOMP May 16 14:48:26 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:26 net5501 mpd: [L-1] MRU 1500 May 16 14:48:26 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:26 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:26 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:26 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:26 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:28 net5501 mpd: [L-1] LCP: SendConfigReq #9 May 16 14:48:28 net5501 mpd: [L-1] ACFCOMP May 16 14:48:28 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:28 net5501 mpd: [L-1] MRU 1500 May 16 14:48:28 net5501 mpd: [L-1] MAGICNUM 5ae3249c May 16 14:48:28 net5501 mpd: [L-1] AUTHPROTO CHAP MSOFTv2 May 16 14:48:28 net5501 mpd: [L-1] MP MRRU 2048 May 16 14:48:28 net5501 mpd: [L-1] MP SHORTSEQ May 16 14:48:28 net5501 mpd: [L-1] ENDPOINTDISC [802.1] 00 00 24 ca 91 b4 May 16 14:48:29 net5501 mpd: [L-1] LCP: rec'd Configure Request #5 (Req-Sent) May 16 14:48:29 net5501 mpd: [L-1] MRU 1400 May 16 14:48:29 net5501 mpd: [L-1] MAGICNUM 5e8514f4 May 16 14:48:29 net5501 mpd: [L-1] PROTOCOMP May 16 14:48:29 net5501 mpd: [L-1] ACFCOMP May 16 14:48:29 net5501 mpd: [L-1] CALLBACK 6 May 16 14:48:29 net5501 mpd: [L-1] LCP: not converging May 16 14:48:29 net5501 mpd: [L-1] LCP: parameter negotiation failed May 16 14:48:29 net5501 mpd: [L-1] LCP: state change Req-Sent --> Stopped May 16 14:48:29 net5501 mpd: [L-1] LCP: LayerFinish May 16 14:48:29 net5501 mpd: [L-1] PPTP call terminated May 16 14:48:29 net5501 mpd: [L-1] Link: DOWN event May 16 14:48:29 net5501 mpd: [L-1] LCP: Close event May 16 14:48:29 net5501 mpd: [L-1] LCP: state change Stopped --> Closed May 16 14:48:29 net5501 mpd: [L-1] LCP: Down event May 16 14:48:29 net5501 mpd: [L-1] LCP: state change Closed --> Initial May 16 14:48:29 net5501 mpd: [L-1] Link: SHUTDOWN event May 16 14:48:29 net5501 mpd: [L-1] Link: Shutdown -- Crist J. Clark | cjclark@alum.mit.edu From owner-freebsd-net@FreeBSD.ORG Mon May 17 03:44: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 CB0661065675 for ; Mon, 17 May 2010 03:44:03 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id A50A88FC1B for ; Mon, 17 May 2010 03:44:03 +0000 (UTC) Received: by pxi7 with SMTP id 7so1003787pxi.13 for ; Sun, 16 May 2010 20:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ValF/50r1P2fMaZgWcyTPA3rhPnP1IdjmiJcdHIVWzM=; b=Tik0M7yrr0o82JJk3N560uPiNW07VSwxaRpFPbm1jWaDvACvfm4C16DePXtk3TfZNy XZgg5Xv1/7oBXmA3qN8c+OQ3uMKUAtXupWlqbs34PX/UjmHqvgcGj5Zrj5bCTnq6quSN vokGnI9k5ALRr658IVPgMMn+rATffzRakwDSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i0BenVEWx6OziK+O1Wp0fBndiI6qWTCVo0EJDDBEY9iiRz4Y58/cgDKmj8SKFbztST kDOrUBCWluM7Ps14NaV/tUMj4ffn4q19A48dtSoXcB/D/dFR+skhOJQWIxln8c8NTDPt 4KulTpXgGCPsxon6xNKyhOQePhqaLA8qmmfqA= MIME-Version: 1.0 Received: by 10.141.15.21 with SMTP id s21mr3172942rvi.192.1274066483167; Sun, 16 May 2010 20:21:23 -0700 (PDT) Received: by 10.140.125.6 with HTTP; Sun, 16 May 2010 20:21:23 -0700 (PDT) Date: Mon, 17 May 2010 11:21:23 +0800 Message-ID: From: dave jones To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Questions about NFS and NTFS 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, 17 May 2010 03:44:03 -0000 Hi, I mount ntfs partition(/dev/ad4s3) using fuse-ntfs on FreeBSD and want to export it via NFS with no luck: # mount_ntfs-3g /dev/ad4s3 /wxp # cat /etc/exports /wxp -alldirs -maproot=root -network 192.168.1/24 # mount_nfs 192.168.1.1:/wxp /mnt [tcp] 192.168.1.1:/wxp: Permission denined Any idea how to solve it? Thanks! Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Mon May 17 11:07: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 C80941065674 for ; Mon, 17 May 2010 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B4E988FC24 for ; Mon, 17 May 2010 11:07:03 +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 o4HB73f1015809 for ; Mon, 17 May 2010 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4HB73WI015807 for freebsd-net@FreeBSD.org; Mon, 17 May 2010 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 May 2010 11:07:03 GMT Message-Id: <201005171107.o4HB73WI015807@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, 17 May 2010 11:07:03 -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/146628 net [tcp] [patch] TCP does not clear DF when MTU is below o kern/146539 net [arp] arp pub not working properly o kern/146534 net [icmp6] wrong source address in echo reply f kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145918 net [ae] After spontaneous ae0 "watchdog timeout", "stray o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count 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. 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/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 424 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 17 16:35: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 D0919106564A; Mon, 17 May 2010 16:35:00 +0000 (UTC) (envelope-from ysarumaru@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 73EF58FC0C; Mon, 17 May 2010 16:35:00 +0000 (UTC) Received: by vws17 with SMTP id 17so2006596vws.13 for ; Mon, 17 May 2010 09:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=JJX6Y4SYMORxExvVvdTYWNnqEgrXVgGnNc13SoQwY8c=; b=MezZMntbaBrmNEYrNZXEzlba6NURjbumys+vrVfVGWKsVPqkvzGZlGNv0YcM09/G08 sLfF9YM5sweezJ7Inj8STAWjB8bwMHgQZxfNNPMUi+T9FdQgs7MrLl6FGMlLjXWvcnad 1lRAFMageW+vfuTkbcOOCtz2EaaBM27f/mF1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Be386rrBDKKPCEuJ1KSU6oZHyTOA16VchAWaD+ZTY+/QLgSs/dPajNxci82um6izQJ wovt3GoFbax69tEILTFnL3QymCe+nplkVwqTc3sHV43mvTjoXbcVT/OhmPD2rcZvkgO1 R5omlAXX+9hXl0QUlsAsQI9Axd1G6GeS02lDg= MIME-Version: 1.0 Received: by 10.220.63.10 with SMTP id z10mr2709937vch.70.1274112530645; Mon, 17 May 2010 09:08:50 -0700 (PDT) Received: by 10.220.92.129 with HTTP; Mon, 17 May 2010 09:08:50 -0700 (PDT) Date: Tue, 18 May 2010 01:08:50 +0900 Message-ID: From: Yoshihiko Sarumaru To: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: odd behavior on select() after shutdown() 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, 17 May 2010 16:35:01 -0000 Hi all, Select(2) has three arguments to get socket status for read, write and except. After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) returns with the status exceptfds is set. It means out-of-bound data can be read from the socket, but recv() with OOB flag returns ECONNRESET, and no packets with urgent flag was observed by tcpdump. It seems strange for me, but is it an intentional change on 8.x ? This behavior breaks net/stone on 8.0-RELEASE. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/141103 The continuous recv() error on PR might lead by incorrectly setted exceptfds on every recv() and it should be fixed, but it doesn't matter if above behavior of select() doesn't occur. You can reproduce this by following example: #include #include #include #include #include #include int main() { int ret; int s; s = socket(PF_INET, SOCK_STREAM, 0); struct sockaddr_in sa; sa.sin_family = AF_INET; sa.sin_addr.s_addr = inet_addr("127.0.0.1"); sa.sin_port = htons(22); ret = connect(s, (struct sockaddr*)&sa, sizeof(sa)); if (ret) perror("connect"); /* get OpenSSH greetings */ char buf[BUFSIZ]; memset(buf, 0, sizeof(buf) / sizeof(buf[0])); ret = recv(s, buf, sizeof(buf), 0); if (ret < 0) perror("recv"); printf("recv: %s\n", buf); /* send something incorrect */ printf("send: \\r\\n\n"); ret = send(s, "\r\n", 2, 0); if (ret < 0) perror("send"); /* receive "Protocol mismatch" */ memset(buf, 0, sizeof(buf) / sizeof(buf[0])); ret = recv(s, buf, sizeof(buf), 0); if (ret < 0) perror("recv"); printf("recv: %s\n", buf); /* shutdown */ ret = shutdown(s, SHUT_WR); /* SHUT_RD doesn't make problem. */ if (ret) perror("shutdown"); /* select */ fd_set readfds, exceptfds; FD_ZERO(&readfds); FD_ZERO(&exceptfds); FD_SET(s, &readfds); FD_SET(s, &exceptfds); ret = select(s+1, &readfds, NULL, &exceptfds, NULL); if (ret < 1) perror("select"); printf("select: read:%d except:%d\n", FD_ISSET(s, &readfds), FD_ISSET(s, &exceptfds)); if (FD_ISSET(s, &exceptfds)) { printf("read OOB data\n"); memset(buf, 0, sizeof(buf) / sizeof(buf[0])); ret = recv(s, buf, sizeof(buf), MSG_OOB); if (ret < 0) perror("recv"); printf("recv(OOB): %s\n", buf); } FD_ZERO(&readfds); FD_SET(s, &readfds); ret = select(s+1, &readfds, NULL, NULL, NULL); if (ret < 1) perror("select"); printf("select: read:%d\n", FD_ISSET(s, &readfds)); memset(buf, 0, sizeof(buf) / sizeof(buf[0])); ret = recv(s, buf, sizeof(buf), 0); if (ret < 0) perror("recv"); printf("recv: %s\n", buf); close(s); } Thanks in advance - Yoshihiko From owner-freebsd-net@FreeBSD.ORG Mon May 17 17:08:37 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 C3335106564A for ; Mon, 17 May 2010 17:08:37 +0000 (UTC) (envelope-from peter@kieser.ca) Received: from mail.pfak.org (unknown [IPv6:2001:470:b:14::d813:b29a]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8538FC19 for ; Mon, 17 May 2010 17:08:37 +0000 (UTC) Received: from mail.pfak.org (localhost.pfak.org [127.0.0.1]) by mail.pfak.org (Postfix) with ESMTP id 1AAE440CF for ; Mon, 17 May 2010 10:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=kieser.ca; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=fp4naiR8VCRb9s8AWzzgfyrrm ho=; b=s98Fvk06/g6iH5uz/XNeaF/ZTIcu1atsgj4oIB/hf7Dfvmc+tGpmXK0CC IG092x9X2P1Hcz025Dt+guVIJbTVkNj8CAEX6Al1+Kw8tEhfBpvr3c9uilNRQZys zaJ55XI0kuKokLeuprCR4icQX6aZEvvlFJEu6RKjy/YDlY8RZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=kieser.ca; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=oQACo8FGFToiq5M1vMm tZR7nI3JQj6vtPGZQWsVP/WRDcrUh46wPKYLj9vPRYS1lkikxAF2Qm1VRbngTFRw 0z5c/aEaAkopSz8uuiX+I9O/kddcJpgOuQY1CPVGaCRjLWuB0ibznTvBueWLrs/S x1xnBib+we/gSNeKxX5GBem8= Received: from [192.168.100.16] (216-19-178-131.stc.novuscom.net [216.19.178.131]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter@kieser.ca) by mail.pfak.org (Postfix) with ESMTPSA id 06431405A for ; Mon, 17 May 2010 10:08:37 -0700 (PDT) Message-ID: <4BF17814.50707@kieser.ca> Date: Mon, 17 May 2010 10:08:36 -0700 From: Peter Kieser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Bringing VLANs created with rc.conf vlans_ 'up' on boot? 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, 17 May 2010 17:08:37 -0000 Hello, I am experimenting with FreeBSD vlan's using the vlans option in rc.conf, my configuration is as follows: ifconfig_em1="up" vlans_em1="100 101 102 103 104 105 106 107 108 109 110" autobridge_interfaces="bridge0" autobridge_bridge0="em0 em1.*" ifconfig_bridge0="up" rc script create em1.100 - em1.110 but doesn't bring the interfaces up on boot, I have to issue 'ifconfig em1.100 up', etc. to bring them online. I also cannot use 'ifconfig_em1.100="up"' because the rc scripts don't support periods in the variable names. Is there a way to accomplish this? In the mean time, I have had to resort to the following which is very messy (and error prone): ifconfig_em1="up" cloned_interfaces="bridge0 vlan100 vlan101 vlan102 vlan103 vlan104 vlan105 vlan106 vlan107 vlan108 vlan109 vlan110" ifconfig_vlan100="up vlan 100 vlandev em1" ifconfig_vlan101="up vlan 101 vlandev em1" ifconfig_vlan102="up vlan 102 vlandev em1" ifconfig_vlan103="up vlan 103 vlandev em1" ifconfig_vlan104="up vlan 104 vlandev em1" ifconfig_vlan105="up vlan 105 vlandev em1" ifconfig_vlan106="up vlan 106 vlandev em1" ifconfig_vlan107="up vlan 107 vlandev em1" ifconfig_vlan108="up vlan 108 vlandev em1" ifconfig_vlan109="up vlan 109 vlandev em1" ifconfig_vlan110="up vlan 110 vlandev em1" ifconfig_bridge0="up addm em0 addm vlan100 addm vlan101 addm vlan102 addm vlan103 addm vlan104 addm vlan105 addm vlan106 addm vlan107 addm vlan108 addm vlan109 addm vlan110" Any hints? Suggestions? I was trying to avoid using the method listed directly above as it is very messy and error prone. Thanks, -Peter From owner-freebsd-net@FreeBSD.ORG Mon May 17 17:33: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 E0171106566C for ; Mon, 17 May 2010 17:33:17 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC9A28FC16 for ; Mon, 17 May 2010 17:33:17 +0000 (UTC) Received: by pxi7 with SMTP id 7so1364500pxi.13 for ; Mon, 17 May 2010 10:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=/W9i/oPnZYla6nTn55Ik9ey/Yg3nUSpa4tHE/eToLu8=; b=BkN9AOi5VeMQs8P+Ed8sFNUqA4a+r9/nHDS0LVmtfT1Vmx7zJjzkir12b9G4tDtYwU oQPTvaHP+vgzG2hGBblJSB+Mdu4hwLnIC4SVzCxSAaabdZL2yCSI8H6FNRyL4KTOwOU3 yqGjwcWKhuMluhfmoLTD3MkXxrjucg7J/t9ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=hXxA5ewl2LY/YSK11vftbqNKDb9KcVv50NaYIyHsm5xRVS9khcyzqwvo6Ep559BO8m fcE+zuxnGj9pvkiUTmGvDitONGADbk5zzwz15Wlq+bQG7L/blqL2jyhquhyyj+SdoBwG AcA+8YW02C2mo6Y4kqvD/9DkOuGWuhMbtr2rI= Received: by 10.140.88.33 with SMTP id l33mr3935688rvb.4.1274117595531; Mon, 17 May 2010 10:33:15 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id b12sm4372774rvn.22.2010.05.17.10.33.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 May 2010 10:33:13 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 17 May 2010 10:32:03 -0700 From: Pyun YongHyeon Date: Mon, 17 May 2010 10:32:03 -0700 To: list@cykotix.com Message-ID: <20100517173203.GA1413@michelle.cdnetworks.com> References: <20100514145612.14566x4tj40yhyos@webmail.lahni.com> <20100514192239.GC24686@michelle.cdnetworks.com> <20100514155638.21116k5xymc7cb8c@webmail.lahni.com> <20100514210342.GD24686@michelle.cdnetworks.com> <20100514172725.1937468ajpjekhog@webmail.lahni.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100514172725.1937468ajpjekhog@webmail.lahni.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Packet Loss on FW1 but not FW2 (CARP + PF on FBSD8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 17:33:18 -0000 On Fri, May 14, 2010 at 05:27:25PM -0400, list@cykotix.com wrote: > Quoting Pyun YongHyeon : > >>>Show me the output of "sysctl dev.vr.0.stats=1" and "netstat -ndI vr0". > >> > >>soekris1# sysctl dev.vr.0.stats=1 > >>dev.vr.0.stats: -1 -> -1 > >> > > > >Please check the output of console. It would have printed some MAC > >counters maintained in driver. > > >>soekris1# netstat -ndI vr0 > >>Name Mtu Network Address Ipkts Ierrs Opkts > >>Oerrs Coll Drop > >>vr0 1500 00:00:24:cc:cb:94 17491 0 14993 > >> 0 0 0 > >>vr0 1500 98.xxx.xxx.56 98.xxx.xxx.59 992 - 9374 > >> - - - > >> > > FW1: > vr0 statistics: > Outbound good frames : 14992 > Inbound good frames : 17486 > Outbound errors : 0 > Inbound errors : 0 > Inbound no buffers : 0 > Inbound no mbuf clusters: 0 > Inbound FIFO overflows : 0 > Inbound CRC errors : 0 > Inbound frame alignment errors : 0 > Inbound giant frames : 0 > Inbound runt frames : 0 > Outbound aborted with excessive collisions : 0 > Outbound collisions : 0 > Outbound late collisions : 0 > Outbound underrun : 0 > PCI bus errors : 0 > driver restarted due to Rx/Tx shutdown failure : 0 > I thought it could be a bug in vr(4) but it seems vr(4) had zero dropped packets. Let pf(4) log dropped packet with pflog(4) and see why pf(4) dropped packets. > > >No Ierrs, so MAC counters would be more helpful here. > > >>soekris2# sysctl dev.vr.0.stats=1 > >>dev.vr.0.stats: -1 -> -1 > >> > >>soekris2# netstat -ndI vr0 > >>Name Mtu Network Address Ipkts Ierrs Opkts > >>Oerrs Coll Drop > >>vr0 1500 00:00:24:ca:40:60 575909 0 588703 > >> 0 0 0 > >>vr0 1500 98.xxx.xxx.56 98.xxx.xxx.60 10029 - 53106 > >> - - - > > FW2: > vr0 statistics: > Outbound good frames : 588054 > Inbound good frames : 575353 > Outbound errors : 0 > Inbound errors : 0 > Inbound no buffers : 0 > Inbound no mbuf clusters: 0 > Inbound FIFO overflows : 0 > Inbound CRC errors : 0 > Inbound frame alignment errors : 0 > Inbound giant frames : 0 > Inbound runt frames : 0 > Outbound aborted with excessive collisions : 0 > Outbound collisions : 0 > Outbound late collisions : 0 > Outbound underrun : 0 > PCI bus errors : 0 > driver restarted due to Rx/Tx shutdown failure : 0 > > Patrick From owner-freebsd-net@FreeBSD.ORG Mon May 17 18:35:40 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 D0EEE106566B for ; Mon, 17 May 2010 18:35:40 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 90D648FC0C for ; Mon, 17 May 2010 18:35:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 8F73BFEF6; Tue, 18 May 2010 06:35:39 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YX3JcTSg166; Tue, 18 May 2010 06:35:33 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 18 May 2010 06:35:33 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 4F92E11420; Tue, 18 May 2010 06:35:33 +1200 (NZST) Date: Tue, 18 May 2010 06:35:33 +1200 From: Andrew Thompson To: Peter Kieser Message-ID: <20100517183533.GA50109@citylink.fud.org.nz> References: <4BF17814.50707@kieser.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF17814.50707@kieser.ca> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: Bringing VLANs created with rc.conf vlans_ 'up' on boot? 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, 17 May 2010 18:35:40 -0000 On Mon, May 17, 2010 at 10:08:36AM -0700, Peter Kieser wrote: > Hello, > > I am experimenting with FreeBSD vlan's using the vlans option in > rc.conf, my configuration is as follows: > > ifconfig_em1="up" > vlans_em1="100 101 102 103 104 105 106 107 108 109 110" > autobridge_interfaces="bridge0" > autobridge_bridge0="em0 em1.*" > ifconfig_bridge0="up" > > rc script create em1.100 - em1.110 but doesn't bring the interfaces up on > boot, I have to issue 'ifconfig em1.100 up', etc. to bring them online. I > also cannot use 'ifconfig_em1.100="up"' because the rc scripts don't > support periods in the variable names. Is there a way to accomplish this? Use an underscore where the period should be, the rc.d scripts support this. ifconfig_em1.100="up" --> ifconfig_em1_100="up" cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Mon May 17 18:46:48 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 79E01106566C for ; Mon, 17 May 2010 18:46:48 +0000 (UTC) (envelope-from peter@kieser.ca) Received: from mail.pfak.org (unknown [IPv6:2001:470:b:14::d813:b29a]) by mx1.freebsd.org (Postfix) with ESMTP id 513018FC0A for ; Mon, 17 May 2010 18:46:48 +0000 (UTC) Received: from mail.pfak.org (localhost.pfak.org [127.0.0.1]) by mail.pfak.org (Postfix) with ESMTP id 8953340E3 for ; Mon, 17 May 2010 11:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=kieser.ca; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=DR5WvP8QrWAP 8M9kAhFpNRap9lY=; b=I2UF9QQVWt+W+x6xeGGJMLgicrqfUE7GDozPRVOdURW4 NbpEUS6BExsLJmms1MN7bRm+7nvfcjBq7j7sdoFhPYXCpXWbbrdF9kdtSre43Y26 6VverDr9a6vRvilpteCor8K7HzTPnM81s5d5wpizcfIhw8Ix2CWafvyHY+lj7UI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=kieser.ca; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=qZBlHR ydOjfTrlnTAtaQbpYbw9rofggMm5hkU77HyDjC82Cmw8EAUwXQZ9qEBF2hDMHK1m CWvwhssj0ngv6cCKR3oUWmEm0uqGHiSZt/QQLfVohdR2KLX7HoScqowVImvV9qSs yJvPqOhFs2RtXwmw+M1QGCT109Nw20oW1EpUA= Received: from [192.168.100.16] (216-19-178-131.stc.novuscom.net [216.19.178.131]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter@kieser.ca) by mail.pfak.org (Postfix) with ESMTPSA id 7384F40D3 for ; Mon, 17 May 2010 11:46:47 -0700 (PDT) Message-ID: <4BF18F17.2060708@kieser.ca> Date: Mon, 17 May 2010 11:46:47 -0700 From: Peter Kieser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4BF17814.50707@kieser.ca> <20100517183533.GA50109@citylink.fud.org.nz> In-Reply-To: <20100517183533.GA50109@citylink.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Bringing VLANs created with rc.conf vlans_ 'up' on boot? 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, 17 May 2010 18:46:48 -0000 On 5/17/2010 11:35 AM, Andrew Thompson wrote: > Use an underscore where the period should be, the rc.d scripts support > this. > > ifconfig_em1.100="up" --> ifconfig_em1_100="up" > > > cheers, > Andrew > Thanks to some offlist postings (from Mykola Dzham and the one above), I came up with the following: ifconfig_DEFAULT="up" vlans_em1="100 101 102 103 104 105 106 107 108 109 110" autobridge_interfaces="bridge0" autobridge_bridge0="em0 em1.*" I wanted to make certain interfaces on the bridge 'sticky', but if I add: ifconfig_bridge0="sticky em1.100 sticky em1.101 sticky em1.102 sticky em1.103 sticky em1.104 sticky em1.105 sticky em1.106 sticky em1.107 sticky em1.108 sticky em1.109 sticky em1.110" Then the autobridge interface isn't created and I'm back to my ugly ifconfig_bridge0 hack. Is there an alternative way to do this? Thank you, -Peter From owner-freebsd-net@FreeBSD.ORG Mon May 17 18:55:42 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 8A1F8106567A for ; Mon, 17 May 2010 18:55:42 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 4482E8FC26 for ; Mon, 17 May 2010 18:55:42 +0000 (UTC) Received: from [95.133.42.238] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OE4yM-0004rY-0R; Mon, 17 May 2010 21:23:28 +0300 Received: from levsha by laptop.levsha.me with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OE4xq-0002p1-U0; Mon, 17 May 2010 21:22:55 +0300 Date: Mon, 17 May 2010 21:22:54 +0300 From: Mykola Dzham To: Peter Kieser Message-ID: <20100517182254.GA36060@laptop.levsha.me> References: <4BF17814.50707@kieser.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF17814.50707@kieser.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 95.133.42.238 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: Bringing VLANs created with rc.conf vlans_ 'up' on boot? 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, 17 May 2010 18:55:42 -0000 Peter Kieser wrote: > Hello, > > I am experimenting with FreeBSD vlan's using the vlans option > in rc.conf, my configuration is as follows: > > ifconfig_em1="up" > vlans_em1="100 101 102 103 104 105 106 107 108 109 110" > autobridge_interfaces="bridge0" > autobridge_bridge0="em0 em1.*" > ifconfig_bridge0="up" > > rc script create em1.100 - em1.110 but doesn't bring the interfaces up > on boot, I have to issue 'ifconfig em1.100 up', etc. to bring them > online. I also cannot use 'ifconfig_em1.100="up"' because the rc scripts > don't support periods in the variable names. Is there a way to > accomplish this? ifconfig_em1_100="up" from network.subr: # get_if_var if var [default] # Return the value of the pseudo-hash corresponding to $if where # $var is a string containg the sub-string "IF" which will be # replaced with $if after the characters defined in _punct are # replaced with '_'. If the variable is unset, replace it with # $default if given. -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-net@FreeBSD.ORG Mon May 17 19:05:30 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 631921065672; Mon, 17 May 2010 19:05:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B79F08FC0A; Mon, 17 May 2010 19:05:29 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4HJ5djE031537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 22:05:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4HJ5PNV094245; Mon, 17 May 2010 22:05:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4HJ5P3s094244; Mon, 17 May 2010 22:05:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 17 May 2010 22:05:25 +0300 From: Kostik Belousov To: Yoshihiko Sarumaru Message-ID: <20100517190525.GP83316@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WU1McKeqU8MHoLZD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: odd behavior on select() after shutdown() 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, 17 May 2010 19:05:30 -0000 --WU1McKeqU8MHoLZD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2010 at 01:08:50AM +0900, Yoshihiko Sarumaru wrote: > Hi all, >=20 > Select(2) has three arguments to get socket status for read, write and ex= cept. > After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) returns = with > the status exceptfds is set. It means out-of-bound data can be read > from the socket, > but recv() with OOB flag returns ECONNRESET, and no packets with urgent f= lag > was observed by tcpdump. > It seems strange for me, but is it an intentional change on 8.x ? >=20 > This behavior breaks net/stone on 8.0-RELEASE. > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/141103 > The continuous recv() error on PR might lead by incorrectly setted > exceptfds on every recv() > and it should be fixed, but it doesn't matter if above behavior of > select() doesn't occur. The patch below would fix the problem at hand. I am wondering what unintended consequences it might have. diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c index eaefd9c..293dbb1 100644 --- a/sys/kern/sys_generic.c +++ b/sys/kern/sys_generic.c @@ -996,7 +996,7 @@ done: static int select_flags[3] =3D { POLLRDNORM | POLLHUP | POLLERR, POLLWRNORM | POLLHUP | POLLERR, - POLLRDBAND | POLLHUP | POLLERR + POLLRDBAND | POLLERR }; =20 /* --WU1McKeqU8MHoLZD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvxk3UACgkQC3+MBN1Mb4jAjACcC4GG1mQAc0P/VILhbTLePh8S XGUAoI7HPzC9LT1HfFRbLExOfjvWm9Rz =wZ1x -----END PGP SIGNATURE----- --WU1McKeqU8MHoLZD-- From owner-freebsd-net@FreeBSD.ORG Mon May 17 19:31: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 11A2B1065675 for ; Mon, 17 May 2010 19:31:26 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by mx1.freebsd.org (Postfix) with ESMTP id D361B8FC12 for ; Mon, 17 May 2010 19:31:25 +0000 (UTC) Received: by pzk11 with SMTP id 11so3665880pzk.28 for ; Mon, 17 May 2010 12:31:25 -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 :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=/Ve8SI7kFR0tmbL0N8UJTNc5c+kifo3DAraudAyIf9g=; b=rgfE0opgpjRaGZ2qBi3GNdIbmIz3hRnBaB4DLHQzkJ5voTkZcUOIh4CdFNBsEck4Lj sLfwVsPaAYZpMWdNdcZAWtjys2qHtkZvqoFO+SfHFLlwhIL2N3z75VJewhdy0yICKpgb ptjcIZJ+rZYcsdOGNjAYYieOe3pFrp0b6jWjk= 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:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=CW2GG331/KtVzD4ipYbSgMHsP99D2L5ceIPHZJiOWcq54eAjER/wN6beRM2PTjD15s +p2am4Sm79cfjyDi8aP5TeRbGiaSWj7/7cop9RyGa+wIR608V3TiBvmp3h7ZoItGfcZr 4vcZYiQEXJOoI6IHufEB9BEClyxBPUmHgDvIU= Received: by 10.143.24.24 with SMTP id b24mr3643831wfj.180.1274124685520; Mon, 17 May 2010 12:31:25 -0700 (PDT) Received: from centel.dataix.local (adsl-99-35-14-184.dsl.klmzmi.sbcglobal.net [99.35.14.184]) by mx.google.com with ESMTPS id u18sm1692281wfh.7.2010.05.17.12.31.23 (version=SSLv3 cipher=RC4-MD5); Mon, 17 May 2010 12:31:23 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BF19989.3070101@dataix.net> Date: Mon, 17 May 2010 15:31:21 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird/3.0.4 MIME-Version: 1.0 To: dave jones References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Questions about NFS and NTFS 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, 17 May 2010 19:31:26 -0000 On 05/16/2010 23:21, dave jones wrote: > Hi, > > I mount ntfs partition(/dev/ad4s3) using fuse-ntfs on FreeBSD and want > to export it via NFS > with no luck: > > # mount_ntfs-3g /dev/ad4s3 /wxp > # cat /etc/exports > /wxp -alldirs -maproot=root -network 192.168.1/24 >From this I assume that the exports line was either already in the exports file or you added it after you mounted the NTFS volume. Also that you have all the required daemons running (rpcbind, mountd, nfsd). > > # mount_nfs 192.168.1.1:/wxp /mnt > [tcp] 192.168.1.1:/wxp: Permission denined > I assume you run this command on the client machine & you have rpcbind running. > Any idea how to solve it? Thanks! > > Best regards, > Dave. If the above assumptions are correct then a simple 'pkill -HUP mountd' as root should solve the problem. If that does not then I recommend restarting the daemons on the server in the following order. service rpcbind restart ;services nfsd restart ;service mountd restart Good luck, -- jhell From owner-freebsd-net@FreeBSD.ORG Mon May 17 20:01:32 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 AEF1E106564A; Mon, 17 May 2010 20:01:32 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id B6EA08FC15; Mon, 17 May 2010 20:01:31 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so1248058fge.13 for ; Mon, 17 May 2010 13:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=izLA6BGa29sIhsk5zzAxW9cayHXFebsStGAi7zETJcs=; b=x6PTQNMUVx7Ny38+hXgxK3vapUPacG9H7Ah07zMRA91kulrh+pABxNmaBSwiFqvkzo vVJKjHpIEm/XXXLIKYq5VjoDeOVWPtmA+3ImibrkUOiMjoc+s6vSlfscn8z9WbM7z+L4 AHKfKst5ILwptUH4oHY1THhL7jEgK4H0Tsocw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=fQ28b/favchvmXnRytT8o9h8xWgZltchpUi7KCUFqkgVfPhzBZRRf/gwrp9lCE0rDi KEW+mKZ7XLJm6wrsTQ8cq3cTjg1ReawrL5VMySsTnd7CWusd+NbHpghkHn1WHRjszMVB qihHoukPx2QLcH5D38M+pMLk4S3SfAiKKJve4= Received: by 10.204.46.153 with SMTP id j25mr1904bkf.191.1274126490687; Mon, 17 May 2010 13:01:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.153.212 with HTTP; Mon, 17 May 2010 13:01:10 -0700 (PDT) In-Reply-To: <4B4BBE59.9010908@elischer.org> References: <4B4BBE59.9010908@elischer.org> From: Maxim Ignatenko Date: Mon, 17 May 2010 23:01:10 +0300 Message-ID: To: Julian Elischer , Alexander Motin Content-Type: multipart/mixed; boundary=0016e6d77f74e05a000486cfb045 Cc: freebsd-net@freebsd.org Subject: Re: ng_patch node 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, 17 May 2010 20:01:32 -0000 --0016e6d77f74e05a000486cfb045 Content-Type: text/plain; charset=UTF-8 Extended and improved version of ng_patch node: 1) added new operations ('*', '/', unary '-', '<<', '>>') 2) single node now able to apply arbitrary number of changes 3) m_pullup replaced with m_copydata/m_copyback 4) ntoh/hton used to apply changes correctly 5) checksum handling 6) added some stats --0016e6d77f74e05a000486cfb045 Content-Type: application/octet-stream; name="ng_patch.diff" Content-Disposition: attachment; filename="ng_patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9bepv970 SW5kZXg6IHNoYXJlL21hbi9tYW40L01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNoYXJlL21hbi9t YW40L01ha2VmaWxlCShyZXZpc2lvbiAyMDYzNDUpCisrKyBzaGFyZS9tYW4vbWFuNC9NYWtlZmls ZQkod29ya2luZyBjb3B5KQpAQCAtMjY3LDYgKzI2Nyw3IEBACiAJbmdfbmF0LjQgXAogCW5nX25l dGZsb3cuNCBcCiAJbmdfb25lMm1hbnkuNCBcCisJbmdfcGF0Y2guNCBcCiAJbmdfcHBwLjQgXAog CW5nX3BwcG9lLjQgXAogCW5nX3BwdHBncmUuNCBcCkluZGV4OiBzaGFyZS9tYW4vbWFuNC9uZ19w YXRjaC40Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHNoYXJlL21hbi9tYW40L25nX3BhdGNoLjQJKHJldmlzaW9u IDApCisrKyBzaGFyZS9tYW4vbWFuNC9uZ19wYXRjaC40CShyZXZpc2lvbiAwKQpAQCAtMCwwICsx LDIzNSBAQAorLlwiIENvcHlyaWdodCAoYykgMjAxMCBNYXhpbSBJZ25hdGVua28gPGdlbHJhZW4u dWFAZ21haWwuY29tPgorLlwiIENvcHlyaWdodCAoYykgMjAxMCBWYWRpbSBHb25jaGFyb3YgPHZh ZGltbnVjbGlnaHRAdHB1LnJ1PgorLlwiIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisuXCIKKy5cIiBS ZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9y IHdpdGhvdXQKKy5cIiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0 aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKy5cIiBhcmUgbWV0OgorLlwiIDEuIFJlZGlzdHJpYnV0 aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisuXCIg ICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNj bGFpbWVyLgorLlwiIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisuXCIgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29u ZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorLlwiICAgIGRvY3Vt ZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmli dXRpb24uCisuXCIKKy5cIiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1Ig QU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisuXCIgQU5ZIEVYUFJFU1MgT1IgSU1QTElF RCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisuXCIgSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UKKy5cIiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRI RSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorLlwiIEZPUiBBTlkgRElSRUNULCBJ TkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFM CisuXCIgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5U IE9GIFNVQlNUSVRVVEUgR09PRFMKKy5cIiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEs IE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKy5cIiBIT1dFVkVSIENBVVNF RCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNU UklDVAorLlwiIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RI RVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKy5cIiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNP RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisuXCIgU1VDSCBE QU1BR0UuCisuXCIKKy5cIiAkRnJlZUJTRCQKKy5cIgorLkRkIEphbnVhcnkgNiwgMjAxMAorLkR0 IE5HX1BBVENIIDQKKy5PcworLlNoIE5BTUUKKy5ObSBuZ19wYXRjaAorLk5kICJ0cml2aWFsIG1i dWYgZGF0YSBtb2RpZnlpbmcgbmV0Z3JhcGggbm9kZSB0eXBlIgorLlNoIFNZTk9QU0lTCisuSW4g bmV0Z3JhcGgvbmdfcGF0Y2guaAorLlNoIERFU0NSSVBUSU9OCitUaGUKKy5ObSBwYXRjaAorbm9k ZSBwZXJmb3JtcyBkYXRhIG1vZGlmaWNhdGlvbiBvZiBwYWNrZXRzIHBhc3NpbmcgdGhyb3VnaCBp dC4KK01vZGlmaWNhdGlvbnMgYXJlIHJlc3RyaWN0ZWQgdG8gYSBzdWJzZXQgb2YgQyBsYW5ndWFn ZSBvcGVyYXRpb25zCitvbiB1bnNpZ25lZCBpbnRlZ2VycyBvZiA4LCAxNiwgMzIgb3IgNjQgYml0 IHNpemUuCitUaGVzZSBhcmU6IHNldCB0byBuZXcgdmFsdWUgKD0pLCBhZGRpdGlvbiAoKz0pLCBz dWJ0cmFjdGlvbiAoLT0pLAorbXVsdGlwbGljYXRpb24gKCo9KSwgZGl2aXNpb24gKC89KSwgbmVn YXRpb24gKD0gLSksCitiaXR3aXNlIEFORCAoJj0pLCBiaXR3aXNlIE9SICh8PSksIGJpdHdpc2Ug ZVhjbHVzaXZlIE9SIChePSksCitzaGlmdCBsZWZ0ICg8PD0pLCBzaGlmdCByaWdodCAoPj49KS4K K0EgbmVnYXRpb24gb3BlcmF0aW9uIGlzIHRoZSBvbmUgZXhjZXB0aW9uOiBpbnRlZ2VyIGlzIHRy ZWF0ZWQgYXMgc2lnbmVkCithbmQgc2Vjb25kIG9wZXJhbmQgKHRoZQorLlZhIHZhbHVlICkKK2lz IG5vdCB1c2VkLgorVGhlcmUgbWF5IGJlIHNldmVyYWwgbW9kaWZpY2F0aW9uIG9wZXJhdGlvbnMs IHRoZXkgYXJlIGFsbCBhcHBsaWVkCit0byBhIHBhY2tldCBzZXF1ZW50aWFsbHkgaW4gb3JkZXIg dGhleSB3ZXJlIHNwZWNpZmllZCBieSB1c2VyLgorRGF0YSBwYXlsb2FkIG9mIHBhY2tldCBpcyB2 aWV3ZWQgYXMgYXJyYXkgb2YgYnl0ZXMsIHdpdGggemVybyBvZmZzZXQKK2NvcnJlc3BvbmRpbmcg dG8gdGhlIHZlcnkgZmlyc3QgYnl0ZSBvZiBwYWNrZXQgaGVhZGVycywgYW5kCisuVmEgbGVuZ3Ro CitieXRlcyBiZWdpbm5pbmcgZnJvbQorLlZhIG9mZnNldAorYXJlIHRha2VuIGFzIGEgc2luZ2xl IGludGVnZXIgaW4gbmV0d29yayBieXRlIG9yZGVyLgorLlNoIEhPT0tTCitUaGlzIG5vZGUgdHlw ZSBoYXMgdHdvIGhvb2tzOgorLkJsIC10YWcgLXdpZHRoIGluZGVudAorLkl0IFZhIGluCitQYWNr ZXRzIHJlY2VpdmVkIG9uIHRoaXMgaG9vayBhcmUgbW9kaWZpZWQgYWNjb3JkaW5nIHRvIHJ1bGVz IHNwZWNpZmllZAoraW4gY29uZmlnIGFuZCB0aGVuIGZvcndhcmRlZCB0bworLkFyIG91dAoraG9v aywgaWYgaXQgZXhpc3RzIGFuZCBjb25uZWN0ZWQuCitPdGhlcndpc2UgdGhleSBhcmUgcmVmbGVj dGVkIGJhY2sgdG8gdGhlCisuQXIgaW4KK2hvb2suCisuSXQgVmEgb3V0CitQYWNrZXRzIHJlY2Vp dmVkIG9uIHRoaXMgaG9vayBhcmUgZm9yd2FyZGVkIHRvCisuQXIgaW4KK2hvb2sgd2l0aG91dCBh bnkgY2hhbmdlcy4KKy5FbAorLlNoIENPTlRST0wgTUVTU0FHRVMKK1RoaXMgbm9kZSB0eXBlIHN1 cHBvcnRzIHRoZSBnZW5lcmljIGNvbnRyb2wgbWVzc2FnZXMsIHBsdXMgdGhlIGZvbGxvd2luZzoK Ky5CbCAtdGFnIC13aWR0aCBpbmRlbnQKKy5JdCBEdiBOR01fUEFUQ0hfU0VUQ09ORklHIFBxIExp IHNldGNvbmZpZworVGhpcyBjb21tYW5kIHNldHMgdGhlIHNlcXVlbmNlIG9mIG1vZGlmeSBvcGVy YXRpb25zCit0aGF0IHdpbGwgYmUgYXBwbGllZCB0byBpbmNvbWluZyBkYXRhIG9uIGEgaG9vay4K K1RoZSBmb2xsb3dpbmcKKy5WdCAic3RydWN0IG5nX3BhdGNoX2NvbmZpZyIKK211c3QgYmUgc3Vw cGxpZWQgYXMgYW4gYXJndW1lbnQ6CisuQmQgLWxpdGVyYWwgLW9mZnNldCA0bgorc3RydWN0IG5n X3BhdGNoX29wIHsKKwl1aW50NjRfdAl2YWx1ZTsKKwl1aW50MzJfdAlvZmZzZXQ7CisJdWludDE2 X3QJbGVuZ3RoOyAvKiAxLDIsNCBvciA4IGJ5dGVzICovCisJdWludDE2X3QJbW9kZTsKK307Cisv KiBQYXRjaGluZyBtb2RlcyAqLworI2RlZmluZSBOR19QQVRDSF9NT0RFX1NFVAkxCisjZGVmaW5l IE5HX1BBVENIX01PREVfQURECTIKKyNkZWZpbmUgTkdfUEFUQ0hfTU9ERV9TVUIJMworI2RlZmlu ZSBOR19QQVRDSF9NT0RFX01VTAk0CisjZGVmaW5lIE5HX1BBVENIX01PREVfRElWCTUKKyNkZWZp bmUgTkdfUEFUQ0hfTU9ERV9ORUcJNgorI2RlZmluZSBOR19QQVRDSF9NT0RFX0FORAk3CisjZGVm aW5lIE5HX1BBVENIX01PREVfT1IJOAorI2RlZmluZSBOR19QQVRDSF9NT0RFX1hPUgk5CisjZGVm aW5lIE5HX1BBVENIX01PREVfU0hMCTEwCisjZGVmaW5lIE5HX1BBVENIX01PREVfU0hSCTExCisK K3N0cnVjdCBuZ19wYXRjaF9jb25maWcgeworCXVpbnQzMl90CWNvdW50OworCXVpbnQzMl90CWNz dW1fZmxhZ3M7CisJc3RydWN0IG5nX3BhdGNoX29wIG9wc1tdOworfTsKKy5FZAorLlBwCitUaGUK Ky5WYSBjc3VtX2ZsYWdzCitjYW4gYmUgc2V0IHRvIGFueSBjb21iaW5hdGlvbiBvZiBDU1VNX0lQ LCBDU1VNX1RDUCwgQ1NVTV9TQ1RQIGFuZCBDU1VNX1VEUAorKG90aGVyIHZhbHVlcyBhcmUgaWdu b3JlZCkgZm9yIGluc3RydWN0aW5nIHRoZSBJUCBzdGFjayB0byByZWNhbGN1bGF0ZSB0aGUKK2Nv cnJlc3BvbmRpbmcgY2hlY2tzdW0gYmVmb3JlIHRyYW5zbWl0dGluZyBwYWNrZXQgb24gb3V0cHV0 IGludGVyZmFjZS4KK1RoZQorLk5tCitub2RlIGRvZXMgbm90IGRvIGFueSBjaGVja3N1bSBjb3Jy ZWN0aW9uIGJ5IGl0c2VsZi4KKy5JdCBEdiBOR01fUEFUQ0hfR0VUQ09ORklHIFBxIExpIGdldGNv bmZpZworVGhpcyBjb250cm9sIG1lc3NhZ2Ugb2J0YWlucyBjdXJyZW50IHNldCBvZiBtb2RpZnkg b3BlcmF0aW9ucywKK3JldHVybmVkIGFzCisuVnQgInN0cnVjdCBuZ19wYXRjaF9jb25maWciIC4K Ky5JdCBEdiBOR01fUEFUQ0hfR0VUX1NUQVRTIFBxIExpIGdldHN0YXRzCitSZXR1cm5zIG5vZGUg c3RhdGlzdGljcyBhcyBhCisuVnQgInN0cnVjdCBuZ19wYXRjaF9zdGF0cyIgLgorLkl0IER2IE5H TV9QQVRDSF9DTFJfU1RBVFMgUHEgTGkgY2xyc3RhdHMKK0NsZWFyIG5vZGUgc3RhdGlzdGljcy4K Ky5JdCBEdiBOR01fUEFUQ0hfR0VUQ0xSX1NUQVRTIFBxIExpIGdldGNscnN0YXRzCitUaGlzIGNv bW1hbmQgaXMgaWRlbnRpY2FsIHRvCisuRHYgTkdNX1BBVENIX0dFVF9TVEFUUyAsCitleGNlcHQg dGhhdCB0aGUgc3RhdGlzdGljcyBhcmUgYWxzbyBhdG9taWNhbGx5IGNsZWFyZWQuCisuRWwKKy5T aCBTSFVURE9XTgorVGhpcyBub2RlIHNodXRzIGRvd24gdXBvbiByZWNlaXB0IG9mIGEKKy5EdiBO R01fU0hVVERPV04KK2NvbnRyb2wgbWVzc2FnZSwgb3Igd2hlbiBhbGwgaG9va3MgaGF2ZSBiZWVu IGRpc2Nvbm5lY3RlZC4KKy5TaCBFWEFNUExFUworVGhlCisuTm0KK25vZGUgYWxsb3dzIHRvIG1v ZGlmeSBUVEwgYW5kIFRPUy9EU0NQIGZpZWxkcyBpbiBJUCBwYWNrZXRzLgorU3VwcG9zZSB5b3Ug aGF2ZSB0d28gYWRqYWNlbnQgc2ltcGxleCBsaW5rcyB0byByZW1vdGUgbmV0d29yaworKGUuZy5c JiBzYXRlbGxpdGUpLCBzbyB0aGF0IHRoZSBwYWNrZXRzIGV4cGlyaW5nIGluIGJldHdlZW4KK3dp bGwgZ2VuZXJhdGUgdW53YW50ZWQgSUNNUC1yZXBsaWVzIHdoaWNoIGhhdmUgdG8gZ28gZm9ydGgs IG5vdCBiYWNrLgorVGh1cyB5b3UgbmVlZCB0byByYWlzZSBUVEwgb2YgZXZlcnkgcGFja2V0IGVu dGVyaW5nIGxpbmsgbGluayBieSAyCit0byBlbnN1cmUgdGhlIFRUTCB3aWxsIG5vdCByZWFjaCB6 ZXJvIHRoZXJlLgorU28geW91IHNldHVwCisuWHIgaXBmdyA4CitydWxlIHdpdGgKKy5DbSBuZXRn cmFwaAorYWN0aW9uIHRvIGluamVjdCBwYWNrZXRzIGdvaW5nIHRvIG90aGVyIGVuZCBvZiBzaW1w bGV4IGxpbmsgYnkgdGhlCitmb2xsb3dpbmcKKy5YciBuZ2N0bCA4CitzY3JpcHQ6CisuQmQgLWxp dGVyYWwgLW9mZnNldCA0bgorL3Vzci9zYmluL25nY3RsIC1mLSA8PC1TRVEKKwlta3BlZXIgaXBm dzogcGF0Y2ggMjAwIGluCisJbmFtZSBpcGZ3OjIwMCB0dGxfYWRkCisJbXNnIHR0bF9hZGQ6IHNl dGNvbmZpZyB7IGNvdW50PTEgY3N1bV9mbGFncz0xIG9wcz1bCVxlCisJCXsgbW9kZT0yIHZhbHVl PTMgbGVuZ3RoPTEgb2Zmc2V0PTggfSBdIH0KK1NFUQorL3NiaW4vaXBmdyBhZGQgMTUwIG5ldGdy YXBoIDIwMCBpcCBmcm9tIGFueSB0byBzaW1wbGV4LnJlbW90ZS5uZXQKKy5FZAorLlBwCitIZXJl CisuRHEgTGkgdHRsX2FkZAorbm9kZSBvZiB0eXBlCisuTm0KK2NvbmZpZ3VyZWQgdG8gYWRkICht b2RlIAorLkR2IE5HX1BBVENIX01PREVfQUREICkKK2EKKy5WYSB2YWx1ZQorb2YgMyB0byBhIG9u ZS1ieXRlIFRUTCBmaWVsZCwgd2hpY2ggaXMgOXRoIGJ5dGUgb2YgSVAgcGFja2V0IGhlYWRlci4K Ky5QcAorQW5vdGhlciBleGFtcGxlIHdvdWxkIGJlIHR3byBjb25zZWN1dGl2ZSBtb2RpZmljYXRp b25zIG9mIHBhY2tldCBUT1MKK2ZpZWxkOiBzYXksIHlvdSBuZWVkIHRvIGNsZWFyIHRoZQorLkR2 IElQVE9TX1RIUk9VR0hQVVQKK2JpdCBhbmQgc2V0IHRoZQorLkR2IElQVE9TX01JTkNPU1QKK2Jp dC4KK1NvIHlvdSBkbzoKKy5CZCAtbGl0ZXJhbCAtb2Zmc2V0IDRuCisvdXNyL3NiaW4vbmdjdGwg LWYtIDw8LVNFUQorCW1rcGVlciBpcGZ3OiBwYXRjaCAzMDAgaW4KKwluYW1lIGlwZnc6MzAwIHRv c19jaGcKKwltc2cgdG9zX2NoZzogc2V0Y29uZmlnIHsgY291bnQ9MiBjc3VtX2ZsYWdzPTEgb3Bz PVsJXGUKKwkJeyBtb2RlPTcgdmFsdWU9MHhmNyBsZW5ndGg9MSBvZmZzZXQ9MSB9CQlcZQorCQl7 IG1vZGU9OCB2YWx1ZT0weDAyIGxlbmd0aD0xIG9mZnNldD0xIH0gXSB9CitTRVEKKy9zYmluL2lw ZncgYWRkIDE2MCBuZXRncmFwaCA2MDAgaXAgZnJvbSBhbnkgdG8gYW55IG5vdCBkc3QtcG9ydCA4 MAorLkVkCisuUHAKK1RoaXMgZmlyc3QgZG9lcworLkR2IE5HX1BBVENIX01PREVfQU5ECitjbGVh cmluZyB0aGUgZm91cnRoIGJpdCBhbmQgdGhlbgorLkR2IE5HX1BBVENIX01PREVfT1IKK3NldHRp bmcgdGhlIHRoaXJkIGJpdC4KKy5QcAorSW4gYm90aCBleGFtcGxlcyB0aGUKKy5WYSBjc3VtX2Zs YWdzCitmaWVsZCBpbmRpY2F0ZXMgdGhhdCBJUCBjaGVja3N1bSAoYnV0IG5vdCBUQ1Agb3IgVURQ IGNoZWNrc3VtKSBzaG91bGQgYmUKK3JlY2FsY3VsYXRlZCBiZWZvcmUgdHJhbnNtaXQuCisuUHAK K05vdGU6IG9uZSBzaG91bGQgZW5zdXJlIHRoYXQgcGFja2V0cyBhcmUgcmV0dXJuZWQgdG8gaXBm dyBhZnRlciBwcm9jZXNzaW5nCitpbnNpZGUKKy5YciBuZXRncmFwaCA0ICwKK2J5IHNldHRpbmcg YXBwcm9wcmlhdGUKKy5YciBzeXNjdGwgOAordmFyaWFibGU6CisuQmQgLWxpdGVyYWwgLW9mZnNl dCA0bgorc3lzY3RsIG5ldC5pbmV0LmlwLmZ3Lm9uZV9wYXNzPTAKKy5FZAorLlNoIFNFRSBBTFNP CisuWHIgbmV0Z3JhcGggNCAsCisuWHIgbmdfaXBmdyA0ICwKKy5YciBuZ2N0bCA4CisuU2ggSElT VE9SWQorVGhlCisuTm0KK25vZGUgdHlwZSB3YXMgaW1wbGVtZW50ZWQgaW4KKy5GeCA4LjEgLgor LlNoIEFVVEhPUlMKKy5BbiAiTWF4aW0gSWduYXRlbmtvIiBBcSBnZWxyYWVuLnVhQGdtYWlsLmNv bSAuCitUaGlzIG1hbnVhbCBwYWdlIHdhcyB3cml0dGVuIGJ5CisuQW4gIlZhZGltIEdvbmNoYXJv diIgQXEgdmFkaW1udWNsaWdodEB0cHUucnUgLgorLlNoIEJVR1MKK05vZGUgYmxpbmRseSB0cmll cyB0byBhcHBseSBldmVyeSBwYXRjaGluZyBvcGVyYXRpb24gdG8gZWFjaCBwYWNrZXQKKyhleGNl cHQgdGhvc2Ugd2hpY2ggb2Zmc2V0IGlmIGdyZWF0ZXIgdGhhbiBsZW5ndGggb2YgdGhlIHBhY2tl dCksCitzbyBiZSBzdXJlIHRoYXQgeW91IHN1cHBseSBvbmx5IHRoZSByaWdodCBwYWNrZXRzIHRv IGl0IChlLmcuIGNoYW5naW5nCitieXRlcyBpbiB0aGUgQVJQIHBhY2tldHMgbWVhbnQgdG8gYmUg aW4gSVAgaGVhZGVyIGNvdWxkIGNvcnJ1cHQKK3RoZW0gYW5kIG1ha2UgeW91ciBtYWNoaW5lIHVu cmVhY2hhYmxlIGZyb20gdGhlIG5ldHdvcmspLgorLlBwCisuRW0gISEhIFdBUk5JTkcgISEhCisu UHAKK091dHB1dCBwYXRoIG9mIHRoZSBJUCBzdGFjayBhc3N1bWVzIGNvcnJlY3QgZmllbGRzIGFu ZCBsZW5ndGhzIGluIHRoZQorcGFja2V0cyAtIGNoYW5naW5nIHRoZW0gYnkgbWlzdGFrZSB0byBp bmNvcnJlY3QgdmFsdWVzIGNhbiBjYXVzZQordW5wcmVkaWN0YWJsZSByZXN1bHRzIGluY2x1ZGlu ZyBrZXJuZWwgcGFuaWNzLgpJbmRleDogc3lzL25ldGdyYXBoL25nX3BhdGNoLmMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gc3lzL25ldGdyYXBoL25nX3BhdGNoLmMJKHJldmlzaW9uIDApCisrKyBzeXMvbmV0Z3Jh cGgvbmdfcGF0Y2guYwkocmV2aXNpb24gMCkKQEAgLTAsMCArMSw1ODYgQEAKKy8qCisgKiBuZ19w YXRjaC5jCisgKi8KKworLyotCisgKiAgIENvcHlyaWdodCAoQykgMjAxMCBieSBNYXhpbSBJZ25h dGVua28KKyAqICAgQWxsIHJpZ2h0cyByZXNlcnZlZC4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICoKKyAqICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoKKyAqICAgUmVk aXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0ICAgICoKKyAqICAgIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0 aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyAgICoKKyAqICAgIGFyZSBtZXQ6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoKKyAq ICAgICAqIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJv dmUgY29weXJpZ2h0ICAgICoKKyAqICAgICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4gICAgICoKKyAqICAgICAqIFJlZGlzdHJp YnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0 ICoKKyAqICAgICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xs b3dpbmcgZGlzY2xhaW1lciBpbiAgICoKKyAqICAgICAgIHRoZSBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgICAgICAgICoKKyAqICAgICAgIGRp c3RyaWJ1dGlvbi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICoKKyAqICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICoKKyAqICAgVEhJUyBTT0ZUV0FSRSBJUyBQUk9W SURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUyAgICoKKyAqICAg IkFTIElTIiBBTkQgQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcs IEJVVCBOT1QgICAgICoKKyAqICAgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SICoKKyAqICAgQSBQQVJUSUNVTEFSIFBV UlBPU0UgQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZUklHSFQgICoK KyAqICAgT1dORVIgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5E SVJFQ1QsIElOQ0lERU5UQUwsICoKKyAqICAgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFV RU5USUFMIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCAgICAgICoKKyAqICAgTElNSVRFRCBU TywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBV U0UsICoKKyAqICAgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBI T1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZICoKKyAqICAgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hF VEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVCAgICoKKyAqICAgKElO Q0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBP RiBUSEUgVVNFICoKKyAqICAgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRI RSBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4gICoKKyAqCisgKiBBdXRob3I6IE1heGltIEln bmF0ZW5rbyA8Z2VscmFlbi51YUBnbWFpbC5jb20+CisgKgorICogJEZyZWVCU0QkCisgKi8KKwor I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRl IDxzeXMvbWJ1Zi5oPgorI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMvY3R5 cGUuaD4KKyNpbmNsdWRlIDxzeXMvZXJybm8uaD4KKyNpbmNsdWRlIDxzeXMvZW5kaWFuLmg+CS8q IGJlNjR0b2goKSwgaHRvYmU2NCgpICovCisjaW5jbHVkZSA8bmV0Z3JhcGgvbmdfbWVzc2FnZS5o PgorI2luY2x1ZGUgPG5ldGdyYXBoL25nX3BhcnNlLmg+CisjaW5jbHVkZSA8bmV0Z3JhcGgvbmdf cGF0Y2guaD4KKyNpbmNsdWRlIDxuZXRncmFwaC9uZXRncmFwaC5oPgorCitzdGF0aWMgbmdfY29u c3RydWN0b3JfdAluZ19wYXRjaF9jb25zdHJ1Y3RvcjsKK3N0YXRpYyBuZ19yY3Ztc2dfdAluZ19w YXRjaF9yY3Ztc2c7CitzdGF0aWMgbmdfc2h1dGRvd25fdAluZ19wYXRjaF9zaHV0ZG93bjsKK3N0 YXRpYyBuZ19uZXdob29rX3QJbmdfcGF0Y2hfbmV3aG9vazsKK3N0YXRpYyBuZ19yY3ZkYXRhX3QJ bmdfcGF0Y2hfcmN2ZGF0YTsKK3N0YXRpYyBuZ19kaXNjb25uZWN0X3QJbmdfcGF0Y2hfZGlzY29u bmVjdDsKKworI2RlZmluZSBPRkZTRVRPRihzLCBlKSAoKGNoYXIgKikmKChzICopMCktPmUgLSAo Y2hhciAqKSgocyAqKTApKQorCitzdGF0aWMgaW50CituZ19wYXRjaF9jb25maWdfZ2V0bGVuKGNv bnN0IHN0cnVjdCBuZ19wYXJzZV90eXBlICp0eXBlLAorCQljb25zdCB1X2NoYXIgKnN0YXJ0LCBj b25zdCB1X2NoYXIgKmJ1ZikKK3sKKwljb25zdCBzdHJ1Y3QgbmdfcGF0Y2hfY29uZmlnICpwOwor CXAgPSAoY29uc3Qgc3RydWN0IG5nX3BhdGNoX2NvbmZpZyAqKShidWYgLSBPRkZTRVRPRihzdHJ1 Y3QgbmdfcGF0Y2hfY29uZmlnLCBvcHMpKTsKKwlyZXR1cm4gKHAtPmNvdW50KTsKK30KKworc3Rh dGljIGNvbnN0IHN0cnVjdCBuZ19wYXJzZV9zdHJ1Y3RfZmllbGQgbmdfcGF0Y2hfb3BfdHlwZV9m aWVsZHNbXQorCT0gTkdfUEFUQ0hfT1BfVFlQRV9JTkZPOworc3RhdGljIGNvbnN0IHN0cnVjdCBu Z19wYXJzZV90eXBlIG5nX3BhdGNoX29wX3R5cGUgPSB7CisJJm5nX3BhcnNlX3N0cnVjdF90eXBl LAorCSZuZ19wYXRjaF9vcF90eXBlX2ZpZWxkcworfTsKKworc3RhdGljIGNvbnN0IHN0cnVjdCBu Z19wYXJzZV9hcnJheV9pbmZvIG5nX3BhdGNoX2NvbmZhcnJfaW5mbyA9IHsKKwkmbmdfcGF0Y2hf b3BfdHlwZSwKKwkmbmdfcGF0Y2hfY29uZmlnX2dldGxlbgorfTsKK3N0YXRpYyBjb25zdCBzdHJ1 Y3QgbmdfcGFyc2VfdHlwZSBuZ19wYXRjaF9jb25mYXJyX3R5cGUgPSB7CisJJm5nX3BhcnNlX2Fy cmF5X3R5cGUsCisJJm5nX3BhdGNoX2NvbmZhcnJfaW5mbworfTsKKworc3RhdGljIGNvbnN0IHN0 cnVjdCBuZ19wYXJzZV9zdHJ1Y3RfZmllbGQgbmdfcGF0Y2hfY29uZmlnX3R5cGVfZmllbGRzW10K Kwk9IE5HX1BBVENIX0NPTkZJR19UWVBFX0lORk87CitzdGF0aWMgY29uc3Qgc3RydWN0IG5nX3Bh cnNlX3R5cGUgbmdfcGF0Y2hfY29uZmlnX3R5cGUgPSB7CisJJm5nX3BhcnNlX3N0cnVjdF90eXBl LAorCSZuZ19wYXRjaF9jb25maWdfdHlwZV9maWVsZHMKK307CisKK3N0YXRpYyBjb25zdCBzdHJ1 Y3QgbmdfcGFyc2Vfc3RydWN0X2ZpZWxkIG5nX3BhdGNoX3N0YXRzX2ZpZWxkc1tdCisJPSBOR19Q QVRDSF9TVEFUU19UWVBFX0lORk87CitzdGF0aWMgY29uc3Qgc3RydWN0IG5nX3BhcnNlX3R5cGUg bmdfcGF0Y2hfc3RhdHNfdHlwZSA9IHsKKwkmbmdfcGFyc2Vfc3RydWN0X3R5cGUsCisJJm5nX3Bh dGNoX3N0YXRzX2ZpZWxkcworfTsKKworc3RhdGljIGNvbnN0IHN0cnVjdCBuZ19jbWRsaXN0IG5n X3BhdGNoX2NtZGxpc3RbXSA9IHsKKwl7CisJCU5HTV9QQVRDSF9DT09LSUUsCisJCU5HTV9QQVRD SF9HRVRDT05GSUcsCisJCSJnZXRjb25maWciLAorCQlOVUxMLAorCQkmbmdfcGF0Y2hfY29uZmln X3R5cGUKKwl9LAorCXsKKwkJTkdNX1BBVENIX0NPT0tJRSwKKwkJTkdNX1BBVENIX1NFVENPTkZJ RywKKwkJInNldGNvbmZpZyIsCisJCSZuZ19wYXRjaF9jb25maWdfdHlwZSwKKwkJTlVMTAorCX0s CisJeworCQlOR01fUEFUQ0hfQ09PS0lFLAorCQlOR01fUEFUQ0hfR0VUX1NUQVRTLAorCQkiZ2V0 c3RhdHMiLAorCQlOVUxMLAorCQkmbmdfcGF0Y2hfc3RhdHNfdHlwZQorCX0sCisJeworCQlOR01f UEFUQ0hfQ09PS0lFLAorCQlOR01fUEFUQ0hfQ0xSX1NUQVRTLAorCQkiY2xyc3RhdHMiLAorCQlO VUxMLAorCQlOVUxMCisJfSwKKwl7CisJCU5HTV9QQVRDSF9DT09LSUUsCisJCU5HTV9QQVRDSF9H RVRDTFJfU1RBVFMsCisJCSJnZXRjbHJzdGF0cyIsCisJCU5VTEwsCisJCSZuZ19wYXRjaF9zdGF0 c190eXBlCisJfSwKKwl7IDAgfQorfTsKKworc3RhdGljIHN0cnVjdCBuZ190eXBlIHR5cGVzdHJ1 Y3QgPSB7CisJLnZlcnNpb24gPQlOR19BQklfVkVSU0lPTiwKKwkubmFtZSA9CQlOR19QQVRDSF9O T0RFX1RZUEUsCisJLmNvbnN0cnVjdG9yID0JbmdfcGF0Y2hfY29uc3RydWN0b3IsCisJLnJjdm1z ZyA9CW5nX3BhdGNoX3Jjdm1zZywKKwkuc2h1dGRvd24gPQluZ19wYXRjaF9zaHV0ZG93biwKKwku bmV3aG9vayA9CW5nX3BhdGNoX25ld2hvb2ssCisJLnJjdmRhdGEgPQluZ19wYXRjaF9yY3ZkYXRh LAorCS5kaXNjb25uZWN0ID0JbmdfcGF0Y2hfZGlzY29ubmVjdCwKKwkuY21kbGlzdCA9CW5nX3Bh dGNoX2NtZGxpc3QsCit9OworTkVUR1JBUEhfSU5JVChwYXRjaCwgJnR5cGVzdHJ1Y3QpOworCit1 bmlvbiBwYXRjaF92YWwgeworCXVpbnQ4X3QJCXYxOworCXVpbnQxNl90CXYyOworCXVpbnQzMl90 CXY0OworCXVpbnQ2NF90CXY4OworfTsKKworc3RydWN0IG5nX3BhdGNoX3ByaXYgeworCWhvb2tf cAkJaW47CisJaG9va19wCQlvdXQ7CisJc3RydWN0IG5nX3BhdGNoX2NvbmZpZyAqY29uZmlnOwor CXVuaW9uIHBhdGNoX3ZhbCAqdmFsOworCXN0cnVjdCBuZ19wYXRjaF9zdGF0cyBzdGF0czsKK307 Cit0eXBlZGVmIHN0cnVjdCBuZ19wYXRjaF9wcml2ICpwcml2X3A7CisKKyNkZWZpbmUgTkdfUEFU Q0hfQ09ORl9TSVpFKGNvdW50KQkoc2l6ZW9mKHN0cnVjdCBuZ19wYXRjaF9jb25maWcpICsgXAor CQkoY291bnQpICogc2l6ZW9mKHN0cnVjdCBuZ19wYXRjaF9vcCkpCisKK3N0YXRpYyB2b2lkIGRv X3BhdGNoKHByaXZfcCBjb25mLCBzdHJ1Y3QgbWJ1ZiAqbSk7CisKK3N0YXRpYyBpbnQKK25nX3Bh dGNoX2NvbnN0cnVjdG9yKG5vZGVfcCBub2RlKQoreworCXByaXZfcCBwcml2ZGF0YTsKKworCXBy aXZkYXRhID0gbWFsbG9jKHNpemVvZigqcHJpdmRhdGEpLCBNX05FVEdSQVBILAorCQlNX1dBSVQg fCBNX1pFUk8pOworLyoJaWYgKHByaXZkYXRhID09IE5VTEwpCisJCXJldHVybiAoRU5PTUVNKTsK KyovCisJTkdfTk9ERV9TRVRfUFJJVkFURShub2RlLCBwcml2ZGF0YSk7CisJcHJpdmRhdGEtPmlu ID0gTlVMTDsKKwlwcml2ZGF0YS0+b3V0ID0gTlVMTDsKKwlwcml2ZGF0YS0+Y29uZmlnID0gTlVM TDsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CituZ19wYXRjaF9uZXdob29rKG5vZGVf cCBub2RlLCBob29rX3AgaG9vaywgY29uc3QgY2hhciAqbmFtZSkKK3sKKwljb25zdCBwcml2X3Ag cHJpdnAgPSBOR19OT0RFX1BSSVZBVEUobm9kZSk7CisKKwlpZiAoc3RybmNtcChuYW1lLCBOR19Q QVRDSF9IT09LX0lOLAorCSAgICBzdHJsZW4oTkdfUEFUQ0hfSE9PS19JTikpID09IDApIHsKKwkJ cHJpdnAtPmluID0gaG9vazsKKwl9IGVsc2UgaWYgKHN0cm5jbXAobmFtZSwgTkdfUEFUQ0hfSE9P S19PVVQsCisJICAgIHN0cmxlbihOR19QQVRDSF9IT09LX09VVCkpID09IDApIHsKKwkJcHJpdnAt Pm91dCA9IGhvb2s7CisJfSBlbHNlCisJCXJldHVybiAoRUlOVkFMKTsKKwlyZXR1cm4oMCk7Cit9 CisKK3N0YXRpYyBpbnQKK25nX3BhdGNoX3Jjdm1zZyhub2RlX3Agbm9kZSwgaXRlbV9wIGl0ZW0s IGhvb2tfcCBsYXN0aG9vaykKK3sKKwljb25zdCBwcml2X3AgcHJpdnAgPSBOR19OT0RFX1BSSVZB VEUobm9kZSk7CisJc3RydWN0IG5nX21lc2cgKnJlc3AgPSBOVUxMOworCWludCBlcnJvciA9IDA7 CisJc3RydWN0IG5nX21lc2cgKm1zZzsKKwlzdHJ1Y3QgbmdfcGF0Y2hfY29uZmlnICpjb25mOwor CWludCBpLCBjbGVhciA9IDA7CisKKwlOR0lfR0VUX01TRyhpdGVtLCBtc2cpOworCXN3aXRjaCAo bXNnLT5oZWFkZXIudHlwZWNvb2tpZSkgeworCWNhc2UgTkdNX1BBVENIX0NPT0tJRToKKwkJc3dp dGNoIChtc2ctPmhlYWRlci5jbWQpIHsKKwkJY2FzZSBOR01fUEFUQ0hfR0VUQ09ORklHOgorCQkJ aWYgKHByaXZwLT5jb25maWcgPT0gTlVMTCkKKwkJCQlicmVhazsKKwkJCU5HX01LUkVTUE9OU0Uo cmVzcCwgbXNnLCBOR19QQVRDSF9DT05GX1NJWkUocHJpdnAtPmNvbmZpZy0+Y291bnQpLCBNX1dB SVQpOworLyoJCQlpZiAoIXJlc3ApIHsKKwkJCQllcnJvciA9IEVOT01FTTsKKwkJCQlicmVhazsK KwkJCX0KKyovCisJCQliY29weShwcml2cC0+Y29uZmlnLCByZXNwLT5kYXRhLCBOR19QQVRDSF9D T05GX1NJWkUocHJpdnAtPmNvbmZpZy0+Y291bnQpKTsKKwkJCWJyZWFrOworCQljYXNlIE5HTV9Q QVRDSF9TRVRDT05GSUc6CisJCQl7CisJCQl1bmlvbiBwYXRjaF92YWwgKm5ld3ZhbDsKKwkJCXN0 cnVjdCBuZ19wYXRjaF9jb25maWcgKm5ld2NvbmY7CisJCQlpZiAobXNnLT5oZWFkZXIuYXJnbGVu IDwgc2l6ZW9mKHN0cnVjdCBuZ19wYXRjaF9jb25maWcpKSB7CisJCQkJZXJyb3IgPSBFSU5WQUw7 CisJCQkJYnJlYWs7CisJCQl9CisKKwkJCWNvbmYgPSAoc3RydWN0IG5nX3BhdGNoX2NvbmZpZyAq KW1zZy0+ZGF0YTsKKwkJCWlmIChtc2ctPmhlYWRlci5hcmdsZW4gPCBOR19QQVRDSF9DT05GX1NJ WkUoY29uZi0+Y291bnQpKSB7CisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQkJYnJlYWs7CisJCQl9 CisKKwkJCWZvcihpID0gMDsgaSA8IGNvbmYtPmNvdW50OyBpKyspIHsKKwkJCQlzd2l0Y2goY29u Zi0+b3BzW2ldLmxlbmd0aCkgeworCQkJCWNhc2UgMToKKwkJCQljYXNlIDI6CisJCQkJY2FzZSA0 OgorCQkJCWNhc2UgODoKKwkJCQkJYnJlYWs7CisJCQkJZGVmYXVsdDoKKwkJCQkJZXJyb3IgPSBF SU5WQUw7CisJCQkJCWJyZWFrOworCQkJCX0KKwkJCQlpZiAoZXJyb3IgIT0gMCkKKwkJCQkJYnJl YWs7CisJCQl9CisKKwkJCWNvbmYtPmNzdW1fZmxhZ3MgJj0gQ1NVTV9JUCB8IENTVU1fVENQIHwg Q1NVTV9VRFAgfCBDU1VNX1NDVFA7CisKKwkJCWlmIChlcnJvciA9PSAwKSB7CisJCQkJbmV3Y29u ZiA9IG1hbGxvYyhOR19QQVRDSF9DT05GX1NJWkUoY29uZi0+Y291bnQpLCBNX05FVEdSQVBILCBN X1dBSVQpOworLyoJCQkJaWYgKG5ld2NvbmYgPT0gTlVMTCkgeworCQkJCQllcnJvciA9IEVOT01F TTsKKwkJCQkJYnJlYWs7CisJCQkJfQorKi8KKwkJCQluZXd2YWwgPSBtYWxsb2MoY29uZi0+Y291 bnQgKiBzaXplb2YodW5pb24gcGF0Y2hfdmFsKSwKKwkJCQkgICAgTV9ORVRHUkFQSCwgTV9XQUlU KTsKKy8qCQkJCWlmIChuZXd2YWwgPT0gTlVMTCkgeworCQkJCQllcnJvciA9IEVOT01FTTsKKwkJ CQkJZnJlZShuZXdjb25mLCBNX05FVEdSQVBIKTsKKwkJCQkJYnJlYWs7CisJCQkJfSovCisJCQkJ Zm9yKGkgPSAwOyBpIDwgY29uZi0+Y291bnQ7IGkrKykgeworCQkJCQlzd2l0Y2ggKGNvbmYtPm9w c1tpXS5sZW5ndGgpIHsKKwkJCQkJY2FzZSAxOgorCQkJCQkJbmV3dmFsW2ldLnYxID0gY29uZi0+ b3BzW2ldLnZhbHVlOworCQkJCQkJYnJlYWs7CisJCQkJCWNhc2UgMjoKKwkJCQkJCW5ld3ZhbFtp XS52MiA9IGNvbmYtPm9wc1tpXS52YWx1ZTsKKwkJCQkJCWJyZWFrOworCQkJCQljYXNlIDQ6CisJ CQkJCQluZXd2YWxbaV0udjQgPSBjb25mLT5vcHNbaV0udmFsdWU7CisJCQkJCQlicmVhazsKKwkJ CQkJY2FzZSA4OgorCQkJCQkJbmV3dmFsW2ldLnY4ID0gY29uZi0+b3BzW2ldLnZhbHVlOworCQkJ CQkJYnJlYWs7CisJCQkJCX0KKwkJCQl9CisJCQkJYmNvcHkoY29uZiwgbmV3Y29uZiwgTkdfUEFU Q0hfQ09ORl9TSVpFKGNvbmYtPmNvdW50KSk7CisJCQkJaWYgKHByaXZwLT52YWwgIT0gTlVMTCkK KwkJCQkJZnJlZShwcml2cC0+dmFsLCBNX05FVEdSQVBIKTsKKwkJCQlwcml2cC0+dmFsID0gbmV3 dmFsOworCQkJCWlmIChwcml2cC0+Y29uZmlnICE9IE5VTEwpCisJCQkJCWZyZWUocHJpdnAtPmNv bmZpZywgTV9ORVRHUkFQSCk7CisJCQkJcHJpdnAtPmNvbmZpZyA9IG5ld2NvbmY7CisJCQl9CisJ CQlicmVhazsKKwkJCX0KKwkJY2FzZSBOR01fUEFUQ0hfR0VUQ0xSX1NUQVRTOgorCQkJY2xlYXIg PSAxOworCQkJLyogRkFMTFRIUk9VR0ggKi8KKwkJY2FzZSBOR01fUEFUQ0hfR0VUX1NUQVRTOgor CQkJTkdfTUtSRVNQT05TRShyZXNwLCBtc2csIHNpemVvZihzdHJ1Y3QgbmdfcGF0Y2hfc3RhdHMp LCBNX1dBSVQpOworLyoKKwkJCWlmIChyZXNwID09IE5VTEwpCisJCQkJcmV0dXJuIChFTk9NRU0p OworKi8KKwkJCWJjb3B5KCYocHJpdnAtPnN0YXRzKSwgcmVzcC0+ZGF0YSwgc2l6ZW9mKHN0cnVj dCBuZ19wYXRjaF9zdGF0cykpOworCQkJaWYgKGNsZWFyID09IDApCisJCQkJYnJlYWs7CisJCQkv KiBlbHNlIEZBTExUSFJPVUdIICovCisJCWNhc2UgTkdNX1BBVENIX0NMUl9TVEFUUzoKKwkJCWJ6 ZXJvKCYocHJpdnAtPnN0YXRzKSwgc2l6ZW9mKHN0cnVjdCBuZ19wYXRjaF9zdGF0cykpOworCQkJ YnJlYWs7CisJCWRlZmF1bHQ6CisJCQllcnJvciA9IEVJTlZBTDsKKwkJCWJyZWFrOworCQl9CisJ CWJyZWFrOworCWRlZmF1bHQ6CisJCWVycm9yID0gRUlOVkFMOworCQlicmVhazsKKwl9CisKKwlO R19SRVNQT05EX01TRyhlcnJvciwgbm9kZSwgaXRlbSwgcmVzcCk7CisJTkdfRlJFRV9NU0cobXNn KTsKKwlyZXR1cm4oZXJyb3IpOworfQorCitzdGF0aWMgdm9pZAorZG9fcGF0Y2gocHJpdl9wIHBy aXZwLCBzdHJ1Y3QgbWJ1ZiAqbSkKK3sKKwl1aW50NjRfdCBidWY7CisJaW50IGksIHBhdGNoZWQg PSAwOworCXN0cnVjdCBuZ19wYXRjaF9jb25maWcgKmNvbmYgPSBwcml2cC0+Y29uZmlnOworCisJ Zm9yKGkgPSAwOyBpIDwgY29uZi0+Y291bnQ7IGkrKykgeworCQlpZiAoY29uZi0+b3BzW2ldLm9m ZnNldCArIGNvbmYtPm9wc1tpXS5sZW5ndGggPiBtLT5tX3BrdGhkci5sZW4pCisJCQljb250aW51 ZTsKKworCQkvKiBmb3IgIj0iIG9wZXJhdGlvbiB3ZSBkb24ndCBuZWVkIHRvIGNvcHkgZGF0YSBm cm9tIG1idWYgKi8KKwkJaWYgKGNvbmYtPm9wc1tpXS5tb2RlICE9IE5HX1BBVENIX01PREVfU0VU KSB7CisJCQltX2NvcHlkYXRhKG0sIGNvbmYtPm9wc1tpXS5vZmZzZXQsCisJCQkgICAgY29uZi0+ b3BzW2ldLmxlbmd0aCwgKGNhZGRyX3QpICZidWYpOworCQl9CisJCQorCQlzd2l0Y2ggKGNvbmYt Pm9wc1tpXS5sZW5ndGgpIHsKKwkJY2FzZSAxOgorCQkJc3dpdGNoIChjb25mLT5vcHNbaV0ubW9k ZSkgeworCQkJY2FzZSBOR19QQVRDSF9NT0RFX1NFVDoKKwkJCQkqKCh1aW50OF90ICopJmJ1Zikg PSBwcml2cC0+dmFsW2ldLnYxOworCQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX0FE RDoKKwkJCQkqKCh1aW50OF90ICopJmJ1ZikgKz0gcHJpdnAtPnZhbFtpXS52MTsKKwkJCQlicmVh azsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9TVUI6CisJCQkJKigodWludDhfdCAqKSZidWYpIC09 IHByaXZwLT52YWxbaV0udjE7CisJCQkJYnJlYWs7CisJCQljYXNlIE5HX1BBVENIX01PREVfTVVM OgorCQkJCSooKHVpbnQ4X3QgKikmYnVmKSAqPSBwcml2cC0+dmFsW2ldLnYxOworCQkJCWJyZWFr OworCQkJY2FzZSBOR19QQVRDSF9NT0RFX0RJVjoKKwkJCQkqKCh1aW50OF90ICopJmJ1ZikgLz0g cHJpdnAtPnZhbFtpXS52MTsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9ORUc6 CisJCQkJKigoaW50OF90ICopJmJ1ZikgPSAtICooKGludDhfdCAqKSZidWYpOworCQkJCWJyZWFr OworCQkJY2FzZSBOR19QQVRDSF9NT0RFX0FORDoKKwkJCQkqKCh1aW50OF90ICopJmJ1ZikgJj0g cHJpdnAtPnZhbFtpXS52MTsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9PUjoK KwkJCQkqKCh1aW50OF90ICopJmJ1ZikgfD0gcHJpdnAtPnZhbFtpXS52MTsKKwkJCQlicmVhazsK KwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9YT1I6CisJCQkJKigodWludDhfdCAqKSZidWYpIF49IHBy aXZwLT52YWxbaV0udjE7CisJCQkJYnJlYWs7CisJCQljYXNlIE5HX1BBVENIX01PREVfU0hMOgor CQkJCSooKHVpbnQ4X3QgKikmYnVmKSA8PD0gcHJpdnAtPnZhbFtpXS52MTsKKwkJCQlicmVhazsK KwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9TSFI6CisJCQkJKigodWludDhfdCAqKSZidWYpID4+PSBw cml2cC0+dmFsW2ldLnYxOworCQkJCWJyZWFrOworCQkJfQorCQkJYnJlYWs7CisJCWNhc2UgMjoK KwkJCSooKGludDE2X3QgKikmYnVmKSA9ICBudG9ocygqKChpbnQxNl90ICopJmJ1ZikpOworCQkJ c3dpdGNoIChjb25mLT5vcHNbaV0ubW9kZSkgeworCQkJY2FzZSBOR19QQVRDSF9NT0RFX1NFVDoK KwkJCQkqKCh1aW50MTZfdCAqKSZidWYpID0gcHJpdnAtPnZhbFtpXS52MjsKKwkJCQlicmVhazsK KwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9BREQ6CisJCQkJKigodWludDE2X3QgKikmYnVmKSArPSBw cml2cC0+dmFsW2ldLnYyOworCQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX1NVQjoK KwkJCQkqKCh1aW50MTZfdCAqKSZidWYpIC09IHByaXZwLT52YWxbaV0udjI7CisJCQkJYnJlYWs7 CisJCQljYXNlIE5HX1BBVENIX01PREVfTVVMOgorCQkJCSooKHVpbnQxNl90ICopJmJ1ZikgKj0g cHJpdnAtPnZhbFtpXS52MjsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9ESVY6 CisJCQkJKigodWludDE2X3QgKikmYnVmKSAvPSBwcml2cC0+dmFsW2ldLnYyOworCQkJCWJyZWFr OworCQkJY2FzZSBOR19QQVRDSF9NT0RFX05FRzoKKwkJCQkqKChpbnQxNl90ICopJmJ1ZikgPSAt ICooKGludDE2X3QgKikmYnVmKTsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9B TkQ6CisJCQkJKigodWludDE2X3QgKikmYnVmKSAmPSBwcml2cC0+dmFsW2ldLnYyOworCQkJCWJy ZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX09SOgorCQkJCSooKHVpbnQxNl90ICopJmJ1Zikg fD0gcHJpdnAtPnZhbFtpXS52MjsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9Y T1I6CisJCQkJKigodWludDE2X3QgKikmYnVmKSBePSBwcml2cC0+dmFsW2ldLnYyOworCQkJCWJy ZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX1NITDoKKwkJCQkqKCh1aW50MTZfdCAqKSZidWYp IDw8PSBwcml2cC0+dmFsW2ldLnYyOworCQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RF X1NIUjoKKwkJCQkqKCh1aW50MTZfdCAqKSZidWYpID4+PSBwcml2cC0+dmFsW2ldLnYyOworCQkJ CWJyZWFrOworCQkJfQorCQkJKigoaW50MTZfdCAqKSZidWYpID0gIGh0b25zKCooKGludDE2X3Qg KikmYnVmKSk7CisJCQlicmVhazsKKwkJY2FzZSA0OgorCQkJKigoaW50MzJfdCAqKSZidWYpID0g IG50b2hsKCooKGludDMyX3QgKikmYnVmKSk7CisJCQlzd2l0Y2ggKGNvbmYtPm9wc1tpXS5tb2Rl KSB7CisJCQljYXNlIE5HX1BBVENIX01PREVfU0VUOgorCQkJCSooKHVpbnQzMl90ICopJmJ1Zikg PSBwcml2cC0+dmFsW2ldLnY0OworCQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX0FE RDoKKwkJCQkqKCh1aW50MzJfdCAqKSZidWYpICs9IHByaXZwLT52YWxbaV0udjQ7CisJCQkJYnJl YWs7CisJCQljYXNlIE5HX1BBVENIX01PREVfU1VCOgorCQkJCSooKHVpbnQzMl90ICopJmJ1Zikg LT0gcHJpdnAtPnZhbFtpXS52NDsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9N VUw6CisJCQkJKigodWludDMyX3QgKikmYnVmKSAqPSBwcml2cC0+dmFsW2ldLnY0OworCQkJCWJy ZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX0RJVjoKKwkJCQkqKCh1aW50MzJfdCAqKSZidWYp IC89IHByaXZwLT52YWxbaV0udjQ7CisJCQkJYnJlYWs7CisJCQljYXNlIE5HX1BBVENIX01PREVf TkVHOgorCQkJCSooKGludDMyX3QgKikmYnVmKSA9IC0gKigoaW50MzJfdCAqKSZidWYpOworCQkJ CWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX0FORDoKKwkJCQkqKCh1aW50MzJfdCAqKSZi dWYpICY9IHByaXZwLT52YWxbaV0udjQ7CisJCQkJYnJlYWs7CisJCQljYXNlIE5HX1BBVENIX01P REVfT1I6CisJCQkJKigodWludDMyX3QgKikmYnVmKSB8PSBwcml2cC0+dmFsW2ldLnY0OworCQkJ CWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX1hPUjoKKwkJCQkqKCh1aW50MzJfdCAqKSZi dWYpIF49IHByaXZwLT52YWxbaV0udjQ7CisJCQkJYnJlYWs7CisJCQljYXNlIE5HX1BBVENIX01P REVfU0hMOgorCQkJCSooKHVpbnQzMl90ICopJmJ1ZikgPDw9IHByaXZwLT52YWxbaV0udjQ7CisJ CQkJYnJlYWs7CisJCQljYXNlIE5HX1BBVENIX01PREVfU0hSOgorCQkJCSooKHVpbnQzMl90ICop JmJ1ZikgPj49IHByaXZwLT52YWxbaV0udjQ7CisJCQkJYnJlYWs7CisJCQl9CisJCQkqKChpbnQz Ml90ICopJmJ1ZikgPSAgaHRvbmwoKigoaW50MzJfdCAqKSZidWYpKTsKKwkJCWJyZWFrOworCQlj YXNlIDg6CisJCQkqKChpbnQ2NF90ICopJmJ1ZikgPSAgYmU2NHRvaCgqKChpbnQ2NF90ICopJmJ1 ZikpOworCQkJc3dpdGNoIChjb25mLT5vcHNbaV0ubW9kZSkgeworCQkJY2FzZSBOR19QQVRDSF9N T0RFX1NFVDoKKwkJCQkqKCh1aW50NjRfdCAqKSZidWYpID0gcHJpdnAtPnZhbFtpXS52ODsKKwkJ CQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hfTU9ERV9BREQ6CisJCQkJKigodWludDY0X3QgKikm YnVmKSArPSBwcml2cC0+dmFsW2ldLnY4OworCQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9N T0RFX1NVQjoKKwkJCQkqKCh1aW50NjRfdCAqKSZidWYpIC09IHByaXZwLT52YWxbaV0udjg7CisJ CQkJYnJlYWs7CisJCQljYXNlIE5HX1BBVENIX01PREVfTVVMOgorCQkJCSooKHVpbnQ2NF90ICop JmJ1ZikgKj0gcHJpdnAtPnZhbFtpXS52ODsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFUQ0hf TU9ERV9ESVY6CisJCQkJKigodWludDY0X3QgKikmYnVmKSAvPSBwcml2cC0+dmFsW2ldLnY4Owor CQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX05FRzoKKwkJCQkqKChpbnQ2NF90ICop JmJ1ZikgPSAtICooKGludDY0X3QgKikmYnVmKTsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFU Q0hfTU9ERV9BTkQ6CisJCQkJKigodWludDY0X3QgKikmYnVmKSAmPSBwcml2cC0+dmFsW2ldLnY4 OworCQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX09SOgorCQkJCSooKHVpbnQ2NF90 ICopJmJ1ZikgfD0gcHJpdnAtPnZhbFtpXS52ODsKKwkJCQlicmVhazsKKwkJCWNhc2UgTkdfUEFU Q0hfTU9ERV9YT1I6CisJCQkJKigodWludDY0X3QgKikmYnVmKSBePSBwcml2cC0+dmFsW2ldLnY4 OworCQkJCWJyZWFrOworCQkJY2FzZSBOR19QQVRDSF9NT0RFX1NITDoKKwkJCQkqKCh1aW50NjRf dCAqKSZidWYpIDw8PSBwcml2cC0+dmFsW2ldLnY4OworCQkJCWJyZWFrOworCQkJY2FzZSBOR19Q QVRDSF9NT0RFX1NIUjoKKwkJCQkqKCh1aW50NjRfdCAqKSZidWYpID4+PSBwcml2cC0+dmFsW2ld LnY4OworCQkJCWJyZWFrOworCQkJfQorCQkJKigoaW50NjRfdCAqKSZidWYpID0gIGh0b2JlNjQo KigoaW50NjRfdCAqKSZidWYpKTsKKwkJCWJyZWFrOworCQl9CisKKwkJbV9jb3B5YmFjayhtLCBj b25mLT5vcHNbaV0ub2Zmc2V0LCBjb25mLT5vcHNbaV0ubGVuZ3RoLAorCQkgICAgKGNfY2FkZHJf dCkgJmJ1Zik7CisJCXBhdGNoZWQgPSAxOworCX0KKwlpZiAocGF0Y2hlZCA+IDApCisJCXByaXZw LT5zdGF0cy5wYXRjaGVkKys7Cit9CisKK3N0YXRpYyBpbnQKK25nX3BhdGNoX3JjdmRhdGEoaG9v a19wIGhvb2ssIGl0ZW1fcCBpdGVtKQoreworCWNvbnN0IHByaXZfcCBwcml2ID0gTkdfTk9ERV9Q UklWQVRFKE5HX0hPT0tfTk9ERShob29rKSk7CisJaW50IGVycm9yOworCXN0cnVjdCBtYnVmICpt OworCWhvb2tfcCB0YXJnZXQ7CisJcHJpdi0+c3RhdHMucmVjZWl2ZWQrKzsKKworCU5HSV9HRVRf TShpdGVtLCBtKTsKKwlpZiAocHJpdi0+Y29uZmlnICE9IE5VTEwgJiYgaG9vayA9PSBwcml2LT5p biAmJgorCSAgICAobS0+bV9mbGFncyAmIE1fUEtUSERSKSAhPSAwKSB7CisJCW0gPSBtX3Vuc2hh cmUobSxNX05PV0FJVCk7CisJCWlmIChtID09IE5VTEwpIHsKKwkJCXByaXYtPnN0YXRzLmRyb3Bw ZWQrKzsKKwkJCU5HX0ZSRUVfSVRFTShpdGVtKTsKKwkJCXJldHVybiAoRU5PTUVNKTsKKwkJfQor CQlkb19wYXRjaChwcml2LCBtKTsKKwkJbS0+bV9mbGFncyB8PSBwcml2LT5jb25maWctPmNzdW1f ZmxhZ3M7CisJfQorCisJdGFyZ2V0ID0gTlVMTDsKKwlpZiAoaG9vayA9PSBwcml2LT5pbikgewor CQlpZiAocHJpdi0+b3V0ICE9IE5VTEwpCisJCQl0YXJnZXQgPSBwcml2LT5vdXQ7CisJCWVsc2UK KwkJCXRhcmdldCA9IHByaXYtPmluOyAvKiByZXR1cm4gZnJhbWVzIG9uICdpbicgaG9vayBpZiAn b3V0JyBub3QgY29ubmVjdGVkKi8KKwl9CisJaWYgKGhvb2sgPT0gcHJpdi0+b3V0ICYmIHByaXYt PmluICE9IE5VTEwpCisJCXRhcmdldCA9IHByaXYtPmluOworCisJaWYgKHRhcmdldCA9PSBOVUxM KSB7CisJCXByaXYtPnN0YXRzLmRyb3BwZWQrKzsKKwkJTkdfRlJFRV9JVEVNKGl0ZW0pOworCQlO R19GUkVFX00obSk7CisJCXJldHVybiAoMCk7CisJfQorCisJTkdfRldEX05FV19EQVRBKGVycm9y LCBpdGVtLCB0YXJnZXQsIG0pOworCisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQK K25nX3BhdGNoX3NodXRkb3duKG5vZGVfcCBub2RlKQoreworCWNvbnN0IHByaXZfcCBwcml2ZGF0 YSA9IE5HX05PREVfUFJJVkFURShub2RlKTsKKworCWlmIChwcml2ZGF0YS0+dmFsICE9IE5VTEwp CisJCWZyZWUocHJpdmRhdGEtPnZhbCwgTV9ORVRHUkFQSCk7CisJaWYgKHByaXZkYXRhLT5jb25m aWcgIT0gTlVMTCkKKwkJZnJlZShwcml2ZGF0YS0+Y29uZmlnLCBNX05FVEdSQVBIKTsKKwlOR19O T0RFX1NFVF9QUklWQVRFKG5vZGUsIE5VTEwpOworCU5HX05PREVfVU5SRUYobm9kZSk7CisJZnJl ZShwcml2ZGF0YSwgTV9ORVRHUkFQSCk7CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAor bmdfcGF0Y2hfZGlzY29ubmVjdChob29rX3AgaG9vaykKK3sKKwlwcml2X3AgcHJpdiA9IE5HX05P REVfUFJJVkFURShOR19IT09LX05PREUoaG9vaykpOworCisJaWYgKGhvb2sgPT0gcHJpdi0+aW4p IHsKKwkJcHJpdi0+aW4gPSBOVUxMOworCX0KKwlpZiAoaG9vayA9PSBwcml2LT5vdXQpIHsKKwkJ cHJpdi0+b3V0ID0gTlVMTDsKKwl9CisJaWYgKChOR19OT0RFX05VTUhPT0tTKE5HX0hPT0tfTk9E RShob29rKSkgPT0gMCkKKwkmJiAoTkdfTk9ERV9JU19WQUxJRChOR19IT09LX05PREUoaG9vaykp KSkgLyogYWxyZWFkeSBzaHV0dGluZyBkb3duPyAqLworCQluZ19ybW5vZGVfc2VsZihOR19IT09L X05PREUoaG9vaykpOworCXJldHVybiAoMCk7Cit9CkluZGV4OiBzeXMvbmV0Z3JhcGgvbmdfcGF0 Y2guaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0Z3JhcGgvbmdfcGF0Y2guaAkocmV2aXNpb24gMCkK KysrIHN5cy9uZXRncmFwaC9uZ19wYXRjaC5oCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDExNCBA QAorLyoKKyAqIG5nX3BhdGNoLmgKKyAqLworCisvKi0KKyAqICAgQ29weXJpZ2h0IChDKSAyMDEw IGJ5IE1heGltIElnbmF0ZW5rbworICogICBBbGwgcmlnaHRzIHJlc2VydmVkLiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgorICogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKgorICogICBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZv cm1zLCB3aXRoIG9yIHdpdGhvdXQgICAgKgorICogICAgbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0 dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zICAgKgorICogICAgYXJl IG1ldDogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKgorICogICAgICogUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3Qg cmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQgICAgKgorICogICAgICAgbm90aWNlLCB0aGlzIGxp c3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLiAgICAgKgorICog ICAgICogUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBh Ym92ZSBjb3B5cmlnaHQgKgorICogICAgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluICAgKgorICogICAgICAgdGhlIGRvY3Vt ZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSAgICAgICAg KgorICogICAgICAgZGlzdHJpYnV0aW9uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKgorICogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKgorICogICBUSElTIFNP RlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBDT1BZUklHSFQgSE9MREVSUyBBTkQgQ09OVFJJQlVU T1JTICAgKgorICogICAiQVMgSVMiIEFORCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJ RVMsIElOQ0xVRElORywgQlVUIE5PVCAgICAgKgorICogICBMSU1JVEVEIFRPLCBUSEUgSU1QTElF RCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgKgorICogICBB IFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhF IENPUFlSSUdIVCAgKgorICogICBPV05FUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZPUiBB TlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgKgorICogICBTUEVDSUFMLCBFWEVNUExB UlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UICAgICAgKgor ICogICBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJ Q0VTOyBMT1NTIE9GIFVTRSwgKgorICogICBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJ TlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgKgorICogICBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JU ICAgKgorICogICAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElO IEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgKgorICogICBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElG IEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLiAgKgorICoKKyAqIEF1 dGhvcjogTWF4aW0gSWduYXRlbmtvIDxnZWxyYWVuLnVhQGdtYWlsLmNvbT4KKyAqCisgKiAkRnJl ZUJTRCQKKyAqLworCisjaWZuZGVmIF9ORVRHUkFQSF9OR19QQVRDSF9IXworI2RlZmluZSBfTkVU R1JBUEhfTkdfUEFUQ0hfSF8KKworLyogTm9kZSB0eXBlIG5hbWUuICovCisjZGVmaW5lIE5HX1BB VENIX05PREVfVFlQRQkicGF0Y2giCisKKy8qIE5vZGUgdHlwZSBjb29raWUuICovCisjZGVmaW5l IE5HTV9QQVRDSF9DT09LSUUJMTI2MjQ0NTUwOQorCisvKiBIb29rIG5hbWVzICovCisjZGVmaW5l IE5HX1BBVENIX0hPT0tfSU4JImluIgorI2RlZmluZSBOR19QQVRDSF9IT09LX09VVAkib3V0Igor CisvKiBOZXRncmFwaCBjb21tYW5kcyB1bmRlcnN0b29kIGJ5IHRoaXMgbm9kZSB0eXBlICovCitl bnVtIHsKKwlOR01fUEFUQ0hfU0VUQ09ORklHID0gMSwKKwlOR01fUEFUQ0hfR0VUQ09ORklHLAor CU5HTV9QQVRDSF9HRVRfU1RBVFMsCisJTkdNX1BBVENIX0NMUl9TVEFUUywKKwlOR01fUEFUQ0hf R0VUQ0xSX1NUQVRTCit9OworCisvKiBQYXRjaGluZyBtb2RlcyAqLworZW51bSB7CisJTkdfUEFU Q0hfTU9ERV9TRVQgPSAxLAorCU5HX1BBVENIX01PREVfQUREID0gMiwKKwlOR19QQVRDSF9NT0RF X1NVQiA9IDMsCisJTkdfUEFUQ0hfTU9ERV9NVUwgPSA0LAorCU5HX1BBVENIX01PREVfRElWID0g NSwKKwlOR19QQVRDSF9NT0RFX05FRyA9IDYsCisJTkdfUEFUQ0hfTU9ERV9BTkQgPSA3LAorCU5H X1BBVENIX01PREVfT1IgPSA4LAorCU5HX1BBVENIX01PREVfWE9SID0gOSwKKwlOR19QQVRDSF9N T0RFX1NITCA9IDEwLAorCU5HX1BBVENIX01PREVfU0hSID0gMTEKK307CisKK3N0cnVjdCBuZ19w YXRjaF9vcCB7CisJdWludDY0X3QJdmFsdWU7CisJdWludDMyX3QJb2Zmc2V0OworCXVpbnQxNl90 CWxlbmd0aDsJLyogMSwyLDQgb3IgOCAoYnl0ZXMpICovCisJdWludDE2X3QJbW9kZTsKK307CisK KyNkZWZpbmUgTkdfUEFUQ0hfT1BfVFlQRV9JTkZPCXsJXAorCQl7ICJ2YWx1ZSIsCSZuZ19wYXJz ZV91aW50NjRfdHlwZQl9LAlcCisJCXsgIm9mZnNldCIsCSZuZ19wYXJzZV91aW50MzJfdHlwZQl9 LAlcCisJCXsgImxlbmd0aCIsCSZuZ19wYXJzZV91aW50MTZfdHlwZQl9LAlcCisJCXsgIm1vZGUi LAkmbmdfcGFyc2VfdWludDE2X3R5cGUJfSwJXAorCQl7IE5VTEwgfSBcCit9CisKK3N0cnVjdCBu Z19wYXRjaF9jb25maWcgeworCXVpbnQzMl90CWNvdW50OworCXVpbnQzMl90CWNzdW1fZmxhZ3M7 CisJc3RydWN0IG5nX3BhdGNoX29wCW9wc1tdOworfTsKKworI2RlZmluZSBOR19QQVRDSF9DT05G SUdfVFlQRV9JTkZPCXsJXAorCQl7ICJjb3VudCIsCSZuZ19wYXJzZV91aW50MzJfdHlwZQl9LAlc CisJCXsgImNzdW1fZmxhZ3MiLAkmbmdfcGFyc2VfdWludDMyX3R5cGUJfSwJXAorCQl7ICJvcHMi LAkmbmdfcGF0Y2hfY29uZmFycl90eXBlCX0sCVwKKwkJeyBOVUxMIH0gXAorfQorCitzdHJ1Y3Qg bmdfcGF0Y2hfc3RhdHMgeworCXVpbnQ2NF90CXJlY2VpdmVkOworCXVpbnQ2NF90CXBhdGNoZWQ7 CisJdWludDY0X3QJZHJvcHBlZDsKK307CisKKyNkZWZpbmUgTkdfUEFUQ0hfU1RBVFNfVFlQRV9J TkZPIHsJXAorCQl7ICJyZWNlaXZlZCIsCSZuZ19wYXJzZV91aW50NjRfdHlwZQl9LAlcCisJCXsg InBhdGNoZWQiLAkmbmdfcGFyc2VfdWludDY0X3R5cGUJfSwJXAorCQl7ICJkcm9wcGVkIiwJJm5n X3BhcnNlX3VpbnQ2NF90eXBlCX0sCVwKKwkJeyBOVUxMIH0gXAorfQorCisjZW5kaWYgLyogX05F VEdSQVBIX05HX1BBVENIX0hfICovCkluZGV4OiBzeXMvbW9kdWxlcy9uZXRncmFwaC9wYXRjaC9N YWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbW9kdWxlcy9uZXRncmFwaC9wYXRjaC9NYWtlZmls ZQkocmV2aXNpb24gMCkKKysrIHN5cy9tb2R1bGVzL25ldGdyYXBoL3BhdGNoL01ha2VmaWxlCShy ZXZpc2lvbiAwKQpAQCAtMCwwICsxLDYgQEAKKyMgJEZyZWVCU0QkCisKK0tNT0Q9CW5nX3BhdGNo CitTUkNTPSAJbmdfcGF0Y2guYworCisuaW5jbHVkZSA8YnNkLmttb2QubWs+Cg== --0016e6d77f74e05a000486cfb045-- From owner-freebsd-net@FreeBSD.ORG Mon May 17 20:20:16 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 924931065676 for ; Mon, 17 May 2010 20:20:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 697A58FC27 for ; Mon, 17 May 2010 20:20:16 +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 o4HKKGxJ004151 for ; Mon, 17 May 2010 20:20:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4HKKGsS004135; Mon, 17 May 2010 20:20:16 GMT (envelope-from gnats) Date: Mon, 17 May 2010 20:20:16 GMT Message-Id: <201005172020.o4HKKGsS004135@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vincent Hoffman Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vincent Hoffman List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 20:20:16 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Vincent Hoffman To: bug-followup@FreeBSD.org, vince@unsane.co.uk Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Mon, 17 May 2010 19:33:47 +0100 Just an extra data point to confirm that the hardware is good. I tried an ubuntu livecd and could happily send thousands of pings (nomally or using -f to flood) with no packet loss or other errors. From owner-freebsd-net@FreeBSD.ORG Mon May 17 23:26:59 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 6C7271065670; Mon, 17 May 2010 23:26:59 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 448C28FC1F; Mon, 17 May 2010 23:26:59 +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 o4HNQwfm042747; Mon, 17 May 2010 23:26:58 GMT (envelope-from rpaulo@freefall.freebsd.org) Received: (from rpaulo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4HNQwkj042743; Mon, 17 May 2010 23:26:58 GMT (envelope-from rpaulo) Date: Mon, 17 May 2010 23:26:58 GMT Message-Id: <201005172326.o4HNQwkj042743@freefall.freebsd.org> To: vince@unsane.co.uk, rpaulo@FreeBSD.org, freebsd-net@FreeBSD.org From: rpaulo@FreeBSD.org Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. 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, 17 May 2010 23:26:59 -0000 Synopsis: [ath] [wlan] device timeouts for ath wlan device on recent stable. State-Changed-From-To: feedback->open State-Changed-By: rpaulo State-Changed-When: Mon May 17 23:26:43 UTC 2010 State-Changed-Why: feedback given http://www.freebsd.org/cgi/query-pr.cgi?pr=146517 From owner-freebsd-net@FreeBSD.ORG Tue May 18 03:58:07 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 57D0E1065670; Tue, 18 May 2010 03:58:07 +0000 (UTC) (envelope-from ysarumaru@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 E683D8FC15; Tue, 18 May 2010 03:58:06 +0000 (UTC) Received: by vws17 with SMTP id 17so310272vws.13 for ; Mon, 17 May 2010 20:58:06 -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=hzBTnRALn4C/oiY+VJXGVVFkh/vfjXIuqtiEDftBbNE=; b=ZODNyp6aW3PKDmjko0TsfI+qiWgvZgs4U6MvPNeWtMfhseAjKwJWusxEqRdTVILChM 60qjoQODv4ADk5pfdOU1mnUP1Se1OwwmyrCMtegOmlfyKWJ9Kij+eNmyUy97yCgn1xC2 aGvnROOYfEr8JDJD38tsYy1Eqdct/3xvTy3b4= 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=HoB/WdKCJFIG3gCn00qb6BoEpuo3//bEIwesT/GemwPo8SpoI8SLWs+CnbhfHaVEkY LgUydEbxpCJQWyjR/swtpsecnoH1CiJavu9/tP1AtRMSTES2AQNYu4//MBfsZq13PqxR wgBqfmWrdcG3TOLXBxvl3LYoqDhMPkre4iIFE= MIME-Version: 1.0 Received: by 10.220.59.5 with SMTP id j5mr3074179vch.106.1274155086015; Mon, 17 May 2010 20:58:06 -0700 (PDT) Received: by 10.220.92.129 with HTTP; Mon, 17 May 2010 20:58:05 -0700 (PDT) In-Reply-To: <20100517190525.GP83316@deviant.kiev.zoral.com.ua> References: <20100517190525.GP83316@deviant.kiev.zoral.com.ua> Date: Tue, 18 May 2010 12:58:05 +0900 Message-ID: From: Yoshihiko Sarumaru To: Kostik Belousov , kib@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: odd behavior on select() after shutdown() 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, 18 May 2010 03:58:07 -0000 Hi, 2010/5/18 Kostik Belousov : > On Tue, May 18, 2010 at 01:08:50AM +0900, Yoshihiko Sarumaru wrote: >> Hi all, >> >> Select(2) has three arguments to get socket status for read, write and except. >> After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) returns with >> the status exceptfds is set. It means out-of-bound data can be read >> from the socket, >> but recv() with OOB flag returns ECONNRESET, and no packets with urgent flag >> was observed by tcpdump. >> It seems strange for me, but is it an intentional change on 8.x ? > The patch below would fix the problem at hand. I am wondering what > unintended consequences it might have. It works perfect for me on 8.0-RELEASE, thanks! I can't see how much this change has side effects, but is it commitable to current or stable? Kib, it seems you had changed some code using POLLHUP in uipc_socket.c. I'm not sure it is related to this issue, but could you give us your comments? thanks, - yoshihiko From owner-freebsd-net@FreeBSD.ORG Tue May 18 05:43:09 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 14C60106566C; Tue, 18 May 2010 05:43:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD318FC0A; Tue, 18 May 2010 05:43:08 +0000 (UTC) Received: from alph.d.allbsd.org (p5247-ipbf302funabasi.chiba.ocn.ne.jp [125.170.154.247]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o4I5glUq049545; Tue, 18 May 2010 14:42:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o4I5gjEl098619; Tue, 18 May 2010 14:42:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 18 May 2010 14:19:33 +0900 (JST) Message-Id: <20100518.141933.111781762.hrs@allbsd.org> To: alfred@FreeBSD.org From: Hiroki Sato In-Reply-To: <20100516062211.GC6175@elvis.mu.org> References: <20100516062211.GC6175@elvis.mu.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_May_18_14_19_33_2010_043)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 18 May 2010 14:43:00 +0900 (JST) X-Spam-Status: No, score=-99.2 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, RCVD_IN_PBL, SPF_SOFTFAIL, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: Patch for ip6_sprintf(), please review 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, 18 May 2010 05:43:09 -0000 ----Security_Multipart(Tue_May_18_14_19_33_2010_043)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alfred Perlstein wrote in <20100516062211.GC6175@elvis.mu.org>: al> The following patch seems appropriate to apply al> to fix the kernel ip6_sprintf() function. al> al> What it is doing is ensuring that when we al> abbreviate addresses that the longest string al> of zeros is shortend, not the first run of al> zeros. (snip) al> Diff is attached in text format. I think the code is correct and reasonable for commit. -- Hiroki ----Security_Multipart(Tue_May_18_14_19_33_2010_043)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkvyI2UACgkQTyzT2CeTzy3onACeMSAlB1WT4HngMasbkeOQYsWA KKYAnRCXaBJkB2uDmu0/uCPHKFra+J/t =b9LX -----END PGP SIGNATURE----- ----Security_Multipart(Tue_May_18_14_19_33_2010_043)---- From owner-freebsd-net@FreeBSD.ORG Tue May 18 06: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 6764D106566C for ; Tue, 18 May 2010 06:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 374ED8FC12 for ; Tue, 18 May 2010 06: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 o4I6K3VQ000178 for ; Tue, 18 May 2010 06:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4I6K32I000177; Tue, 18 May 2010 06:20:03 GMT (envelope-from gnats) Date: Tue, 18 May 2010 06:20:03 GMT Message-Id: <201005180620.o4I6K32I000177@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Matthias Meyser Cc: Subject: Re: conf/143079: hostapd(8) startup missing multi wlan functionality X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Meyser List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 06:20:04 -0000 The following reply was made to PR conf/143079; it has been noted by GNATS. From: Matthias Meyser To: bug-followup@FreeBSD.org, Meyser@xenet.de Cc: Subject: Re: conf/143079: hostapd(8) startup missing multi wlan functionality Date: Tue, 18 May 2010 08:10:02 +0200 perhaps it schould be moved to -rc -- Matthias Meyser | XeNET Gesellschaft fuer Informations- und Kommunikationssysteme mbH Tel.: +49-5323-94018 | 38678 Clausthal-Zellerfeld, Burgstaetter Strasse 6 Fax: +49-5323-94014 | Registergericht: Amtsgericht Braunschweig, HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser From owner-freebsd-net@FreeBSD.ORG Tue May 18 07:38:46 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 163911065708 for ; Tue, 18 May 2010 07:38:46 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 026DB8FC29 for ; Tue, 18 May 2010 07:38:45 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id E25DE1A3D5F; Tue, 18 May 2010 00:38:45 -0700 (PDT) Date: Tue, 18 May 2010 00:38:45 -0700 From: Alfred Perlstein To: Hiroki Sato Message-ID: <20100518073845.GC6175@elvis.mu.org> References: <20100516062211.GC6175@elvis.mu.org> <20100518.141933.111781762.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100518.141933.111781762.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org Subject: Re: Patch for ip6_sprintf(), please review 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, 18 May 2010 07:38:46 -0000 * Hiroki Sato [100517 22:43] wrote: > Alfred Perlstein wrote > in <20100516062211.GC6175@elvis.mu.org>: > > al> The following patch seems appropriate to apply > al> to fix the kernel ip6_sprintf() function. > al> > al> What it is doing is ensuring that when we > al> abbreviate addresses that the longest string > al> of zeros is shortend, not the first run of > al> zeros. > (snip) > al> Diff is attached in text format. > > I think the code is correct and reasonable for commit. Ok, I will do some final checks and commit shortly. Thank you, -Alfred From owner-freebsd-net@FreeBSD.ORG Tue May 18 07:39:30 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 A63731065673; Tue, 18 May 2010 07:39:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 963DB8FC1F; Tue, 18 May 2010 07:39:30 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 816B71A3D5A; Tue, 18 May 2010 00:39:30 -0700 (PDT) Date: Tue, 18 May 2010 00:39:30 -0700 From: Alfred Perlstein To: Doug Barton Message-ID: <20100518073930.GD6175@elvis.mu.org> References: <20100516062211.GC6175@elvis.mu.org> <4BF045C9.1040906@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF045C9.1040906@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Patch for ip6_sprintf(), please review 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, 18 May 2010 07:39:30 -0000 Thank you Doug, I will be committing this shortly. * Doug Barton [100516 12:21] wrote: > Someone at work has been reading > http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation :) > > This change follows the rules in that draft which will become and RFC as > soon as it finishes winding its way through the process, so I am > supportive of the change you are proposing. > > > Doug > > On 5/15/2010 11:22 PM, Alfred Perlstein wrote: > > Hello, > > > > The following patch seems appropriate to apply > > to fix the kernel ip6_sprintf() function. > > > > What it is doing is ensuring that when we > > abbreviate addresses that the longest string > > of zeros is shortend, not the first run of > > zeros. > > > > Our internal commit log is: > > problem: > > Unification of IPv6 address representation > > fix: > > recommended format of text representing an IPv6 address > > is summarized as follows. > > > > 1. omit leading zeros > > > > 2. "::" used to their maximum extent whenever possible > > > > 3. "::" used where shortens address the most > > > > 4. "::" used in the former part in case of a tie breaker > > > > 5. do not shorten one 16 bit 0 field > > > > 6. use lower case > > > > Present code in ip6_sprintf() is following rules 1,2,5,6. > > Adding fix for following other rules also.For following > > rules 3 and 4, finding out the index where to replace zero's > > with '::' and using that index. > > References: > > http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04.html > > > > > > Diff is attached in text format. > > > > > > > > > > _______________________________________________ > > 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" > > > > -- > > ... 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/ > > _______________________________________________ > 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" -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-net@FreeBSD.ORG Tue May 18 08:40:41 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 789B01065670; Tue, 18 May 2010 08:40:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E5D718FC18; Tue, 18 May 2010 08:40:40 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4I8ejMD089792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 11:40:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4I8eW50078895; Tue, 18 May 2010 11:40:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4I8eWMr078894; Tue, 18 May 2010 11:40:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 May 2010 11:40:32 +0300 From: Kostik Belousov To: Yoshihiko Sarumaru Message-ID: <20100518084032.GU83316@deviant.kiev.zoral.com.ua> References: <20100517190525.GP83316@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3T4dLCyS4EPlIT+v" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: odd behavior on select() after shutdown() 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, 18 May 2010 08:40:41 -0000 --3T4dLCyS4EPlIT+v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2010 at 12:58:05PM +0900, Yoshihiko Sarumaru wrote: > Hi, >=20 > 2010/5/18 Kostik Belousov : > > On Tue, May 18, 2010 at 01:08:50AM +0900, Yoshihiko Sarumaru wrote: > >> Hi all, > >> > >> Select(2) has three arguments to get socket status for read, write and= except. > >> After upgrading to 8.0-RELEASE, select() after shutdown(SHUT_WR) retur= ns with > >> the status exceptfds is set. It means out-of-bound data can be read > >> from the socket, > >> but recv() with OOB flag returns ECONNRESET, and no packets with urgen= t flag > >> was observed by tcpdump. > >> It seems strange for me, but is it an intentional change on 8.x ? >=20 > > The patch below would fix the problem at hand. I am wondering what > > unintended consequences it might have. >=20 > It works perfect for me on 8.0-RELEASE, thanks! > I can't see how much this change has side effects, > but is it commitable to current or stable? >=20 > Kib, it seems you had changed some code using POLLHUP in uipc_socket.c. > I'm not sure it is related to this issue, but could you give us your comm= ents? Sometimes being kib, I have no further comments, except that I think that the behaviour you reported is consequence of Jeff and my changes. I intend to commit the patch tomorrow if nobody speaks up. We will see how it goes. --3T4dLCyS4EPlIT+v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvyUn8ACgkQC3+MBN1Mb4hpdgCg1W1GI7dPleoulAhLjKjun7ik odAAn0AtxJPvZrAPfEhVtQ6rAGGvtYBb =hloN -----END PGP SIGNATURE----- --3T4dLCyS4EPlIT+v-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 10:51:43 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 47D92106566B for ; Tue, 18 May 2010 10:51:43 +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 0C40A8FC16 for ; Tue, 18 May 2010 10:51:42 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 7E9AF11BA36; Tue, 18 May 2010 05:51:38 -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 RZNYPUTIETF1; Tue, 18 May 2010 05:51:38 -0500 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <201005180620.o4I6K32I000177@freefall.freebsd.org> Date: Tue, 18 May 2010 11:51:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B3E12CC-346D-4DE3-B5A5-8013747D9F72@FreeBSD.org> References: <201005180620.o4I6K32I000177@freefall.freebsd.org> To: Matthias Meyser X-Mailer: Apple Mail (2.1078) Cc: freebsd-net@FreeBSD.org Subject: Re: conf/143079: hostapd(8) startup missing multi wlan functionality 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, 18 May 2010 10:51:43 -0000 On 18 May 2010, at 07:20, Matthias Meyser wrote: > The following reply was made to PR conf/143079; it has been noted by = GNATS. >=20 > From: Matthias Meyser > To: bug-followup@FreeBSD.org, Meyser@xenet.de > Cc: =20 > Subject: Re: conf/143079: hostapd(8) startup missing multi wlan = functionality > Date: Tue, 18 May 2010 08:10:02 +0200 >=20 > perhaps it schould be moved to -rc Just to let you know that this approach is fine with me. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue May 18 17:16: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 920D31065670; Tue, 18 May 2010 17:16:51 +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 6679E8FC17; Tue, 18 May 2010 17:16:51 +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 05A5546B7E; Tue, 18 May 2010 13:16:51 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 224B58A01F; Tue, 18 May 2010 13:16:50 -0400 (EDT) From: John Baldwin To: net@freebsd.org Date: Tue, 18 May 2010 13:15:37 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201005181315.37609.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 18 May 2010 13:16:50 -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: Navdeep Parhar Subject: Configuring flow control for network interfaces 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, 18 May 2010 17:16:51 -0000 I think it would be useful if we could pick a device-independent interface for configuring flow control on network interfaces, perhaps as media options via ifconfig. I know that the msk(4) driver allows RX and TX flow control to be toggled via the link0 and link1 flags (the manpage for msk(4) needs updating on this topic I think). I have a hack for work to disable TX flow control on cxgb(4), but it doesn't use flow control currently. Is flow control ethernet- specific? If so, perhaps we could add two new flags for RX and TX flow control to the Ethernet-specific options in that case? Do folks have other ideas? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue May 18 17:31:42 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 7687E1065670; Tue, 18 May 2010 17:31:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2BB218FC0C; Tue, 18 May 2010 17:31:41 +0000 (UTC) Received: by pxi7 with SMTP id 7so1982424pxi.13 for ; Tue, 18 May 2010 10:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=R1aPfXE034RWz6sybshAIJmPeKxAGjxSSBpZw/YeLEI=; b=cQMsS/S12s/5WLSOwmHl2NySArju0IaGxkFNFneCH6Fz/ziGZ1xet5LfWQpm/PzF9a dU7DXYM7LOmPFQlAFu2+En9ZNhn9XG9JKj70sZBGZnAi3EnXFpDen5aHJNFFsv/kRYGy 8Wu9hmrB99+xRVjRHghdyrpZsjr+E4w+lH+XY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tE7VCRJ1Z+BUB2jfNvQ5HyfP86XK4ajj0IdoJUCJXjDZF+HIfxNJroUEZX/gu0D4kV XBOgwVlYDST4jRHe4IkPJt7j5XHo2bxQFc3KGkNPXVmhzZtUHqUor1RCm+GyfDzz0Moi 9Qji9HXx1ele5P4Azp/FKwQk8RD0p+7BOoHIU= Received: by 10.115.100.15 with SMTP id c15mr6212944wam.11.1274203901551; Tue, 18 May 2010 10:31:41 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 33sm60354799wad.20.2010.05.18.10.31.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 May 2010 10:31:39 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 18 May 2010 10:30:32 -0700 From: Pyun YongHyeon Date: Tue, 18 May 2010 10:30:32 -0700 To: John Baldwin Message-ID: <20100518173032.GC5968@michelle.cdnetworks.com> References: <201005181315.37609.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005181315.37609.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Configuring flow control for network interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:31:42 -0000 On Tue, May 18, 2010 at 01:15:37PM -0400, John Baldwin wrote: > I think it would be useful if we could pick a device-independent interface for > configuring flow control on network interfaces, perhaps as media options via > ifconfig. I know that the msk(4) driver allows RX and TX flow control to be > toggled via the link0 and link1 flags (the manpage for msk(4) needs updating > on this topic I think). I have a hack for work to disable TX flow control on The hack used in e1000phy(4), brgphy(4) and ip1000phy(4) should be removed. > cxgb(4), but it doesn't use flow control currently. Is flow control ethernet- > specific? If so, perhaps we could add two new flags for RX and TX flow > control to the Ethernet-specific options in that case? Do folks have other > ideas? > AFAIK marius@ is working on it and may have latest patches. From owner-freebsd-net@FreeBSD.ORG Tue May 18 17:58: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 D54481065672; Tue, 18 May 2010 17:58:37 +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 A63788FC18; Tue, 18 May 2010 17:58:37 +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 5808446B65; Tue, 18 May 2010 13:58:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 74A108A01F; Tue, 18 May 2010 13:58:36 -0400 (EDT) From: John Baldwin To: pyunyh@gmail.com Date: Tue, 18 May 2010 13:58:36 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201005181315.37609.jhb@freebsd.org> <20100518173032.GC5968@michelle.cdnetworks.com> In-Reply-To: <20100518173032.GC5968@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005181358.36099.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 18 May 2010 13:58:36 -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: Navdeep Parhar , net@freebsd.org Subject: Re: Configuring flow control for network interfaces 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, 18 May 2010 17:58:37 -0000 On Tuesday 18 May 2010 1:30:32 pm Pyun YongHyeon wrote: > On Tue, May 18, 2010 at 01:15:37PM -0400, John Baldwin wrote: > > I think it would be useful if we could pick a device-independent interface for > > configuring flow control on network interfaces, perhaps as media options via > > ifconfig. I know that the msk(4) driver allows RX and TX flow control to be > > toggled via the link0 and link1 flags (the manpage for msk(4) needs updating > > on this topic I think). I have a hack for work to disable TX flow control on > > The hack used in e1000phy(4), brgphy(4) and ip1000phy(4) should be > removed. > > > cxgb(4), but it doesn't use flow control currently. Is flow control ethernet- > > specific? If so, perhaps we could add two new flags for RX and TX flow > > control to the Ethernet-specific options in that case? Do folks have other > > ideas? > > > > AFAIK marius@ is working on it and may have latest patches. > -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue May 18 18:07:44 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 4B51A1065670; Tue, 18 May 2010 18:07:44 +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 1F04A8FC1A; Tue, 18 May 2010 18:07:44 +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 CDAF146B8D; Tue, 18 May 2010 14:07:43 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0FAC48A01F; Tue, 18 May 2010 14:07:43 -0400 (EDT) From: John Baldwin To: pyunyh@gmail.com Date: Tue, 18 May 2010 14:07:33 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <201005181315.37609.jhb@freebsd.org> <20100518173032.GC5968@michelle.cdnetworks.com> In-Reply-To: <20100518173032.GC5968@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005181407.33474.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 18 May 2010 14:07:43 -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: Navdeep Parhar , net@freebsd.org Subject: Re: Configuring flow control for network interfaces 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, 18 May 2010 18:07:44 -0000 On Tuesday 18 May 2010 1:30:32 pm Pyun YongHyeon wrote: > On Tue, May 18, 2010 at 01:15:37PM -0400, John Baldwin wrote: > > I think it would be useful if we could pick a device-independent interface for > > configuring flow control on network interfaces, perhaps as media options via > > ifconfig. I know that the msk(4) driver allows RX and TX flow control to be > > toggled via the link0 and link1 flags (the manpage for msk(4) needs updating > > on this topic I think). I have a hack for work to disable TX flow control on > > The hack used in e1000phy(4), brgphy(4) and ip1000phy(4) should be > removed. So this looks to actually be different (I was confused). Apparently the link[012] flags are separate from the flag[012] shared flags for ifmedia. It does look like the link0 use in these drivers could be replaced by proper use of IFM_ETH_MASTER media option flag instead. It seems that IFM_ETH_MASTER is missing from IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS in ifmedia.h which would need to be fixed before ifconfig could get/set it. Once that change is in place I think these drivers could check that flag instead of the IFF_LINK0 to determine if they are the master. > > cxgb(4), but it doesn't use flow control currently. Is flow control ethernet- > > specific? If so, perhaps we could add two new flags for RX and TX flow > > control to the Ethernet-specific options in that case? Do folks have other > > ideas? > > > > AFAIK marius@ is working on it and may have latest patches. Ok. Does his patch use Ethernet-specific options or some other approach? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue May 18 18:28:20 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 066821065674; Tue, 18 May 2010 18:28:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB3838FC1B; Tue, 18 May 2010 18:28:19 +0000 (UTC) Received: by pvg4 with SMTP id 4so45174pvg.13 for ; Tue, 18 May 2010 11:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=ussPSR+DkXhW5Cid/Y4kExpme+Ls1PVvwwXpBZWVRPU=; b=OA8S8KAb4d6y75/iy5LpMUntfk3qpiwJAe8rgiu7TrO5btWLgLnrfQBDmsnC0vaVA+ XFIxN1CGuJOR8+LS8CBaEbqNcxpSDSbtM3H6SIwS1UQsetWMimgsCvzMPJVgdIMlqvOx GOn4D0tF7vjolf2BeFOlFmLo6KGZTfEMfami4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=arF/xiMFGsoIVBtOmbFCRlI7UYvY3BbHa6O3em9vl1ODSId1WKBLmcx8VdQrD7bvEJ BvPSk5JV8nPpruS1g453kmrxHMZPrCgjneQM25sDiRx7L7ZJADMDnZaYyE8EfRfrn9Lc cQX7YWNMAjsXkenb8vikgqHRrxDwOVLiOzrio= Received: by 10.114.164.37 with SMTP id m37mr3688178wae.39.1274207299173; Tue, 18 May 2010 11:28:19 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d16sm60721108wam.12.2010.05.18.11.28.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 May 2010 11:28:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 18 May 2010 11:27:08 -0700 From: Pyun YongHyeon Date: Tue, 18 May 2010 11:27:08 -0700 To: John Baldwin Message-ID: <20100518182708.GD5968@michelle.cdnetworks.com> References: <201005181315.37609.jhb@freebsd.org> <20100518173032.GC5968@michelle.cdnetworks.com> <201005181407.33474.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005181407.33474.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Configuring flow control for network interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 18:28:20 -0000 On Tue, May 18, 2010 at 02:07:33PM -0400, John Baldwin wrote: > On Tuesday 18 May 2010 1:30:32 pm Pyun YongHyeon wrote: > > On Tue, May 18, 2010 at 01:15:37PM -0400, John Baldwin wrote: > > > I think it would be useful if we could pick a device-independent interface for > > > configuring flow control on network interfaces, perhaps as media options via > > > ifconfig. I know that the msk(4) driver allows RX and TX flow control to be > > > toggled via the link0 and link1 flags (the manpage for msk(4) needs updating > > > on this topic I think). I have a hack for work to disable TX flow control on > > > > The hack used in e1000phy(4), brgphy(4) and ip1000phy(4) should be > > removed. > > So this looks to actually be different (I was confused). Apparently the > link[012] flags are separate from the flag[012] shared flags for ifmedia. > It does look like the link0 use in these drivers could be replaced by proper > use of IFM_ETH_MASTER media option flag instead. It seems that IFM_ETH_MASTER > is missing from IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS in ifmedia.h which > would need to be fixed before ifconfig could get/set it. Once that change is > in place I think these drivers could check that flag instead of the IFF_LINK0 > to determine if they are the master. > Right. marius's patch already included that. > > > cxgb(4), but it doesn't use flow control currently. Is flow control ethernet- > > > specific? If so, perhaps we could add two new flags for RX and TX flow > > > control to the Ethernet-specific options in that case? Do folks have other > > > ideas? > > > > > > > AFAIK marius@ is working on it and may have latest patches. > > Ok. Does his patch use Ethernet-specific options or some other approach? > The patch used ethernet-specific options. > -- > John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed May 19 01:41: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 DF345106566B for ; Wed, 19 May 2010 01:41:04 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id BABA58FC18 for ; Wed, 19 May 2010 01:41:04 +0000 (UTC) Received: by pvg3 with SMTP id 3so45645pvg.13 for ; Tue, 18 May 2010 18:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=hw07UOy7pxec/MTTlczqkizPMbtdnOvM6wNYupyycoI=; b=AQl/QhzUJq4o4zHCn+vfGaAoM8WYrWjt/00R8VV4CJ6KPnLMXrHlaCM9NY/tDqxeAw lqjvGnDCnW9DbyRwHZ5PPQsqZnw/1R2HgpDD7ouTRtnKVnA/EY3QdOuRxbFmroiVMe1b j5V/qM/OSB7fLz1Mvft6NWSw78ybxN24lHaEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QqLX2vof7AcLVOLy1T4PD8CEtfhBUYgBJOm+yILcm/HoneYWzBCuuUWCe5HQz3TS2Y WJEIpR095XtK/Ase2+QPXdmIwZ1OpdM0c2yc3rwQDhfn8ahLrfrxUZJvBwEy5RbXrTlv Cw0BBkIShxExa5b9m5Y51dt1FjmwLyhO6IQuU= MIME-Version: 1.0 Received: by 10.141.125.17 with SMTP id c17mr1464984rvn.248.1274233264241; Tue, 18 May 2010 18:41:04 -0700 (PDT) Received: by 10.140.125.6 with HTTP; Tue, 18 May 2010 18:41:04 -0700 (PDT) Date: Wed, 19 May 2010 09:41:04 +0800 Message-ID: From: dave jones To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Multicast tftpd 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, 19 May 2010 01:41:05 -0000 Hello, It seems that FreeBSD's tftpd doesn't support multicast. Does anyone know which multicast tftpd available on FreeBSD? Thank you. Regards, Dave. From owner-freebsd-net@FreeBSD.ORG Wed May 19 04:41:41 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 67D96106566B for ; Wed, 19 May 2010 04:41:41 +0000 (UTC) (envelope-from robin@icir.org) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by mx1.freebsd.org (Postfix) with ESMTP id 520D18FC1B for ; Wed, 19 May 2010 04:41:41 +0000 (UTC) Received: from empire.icsi.berkeley.edu (empire.ICSI.Berkeley.EDU [192.150.186.169]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o4J4L0YF016270 for ; Tue, 18 May 2010 21:21:00 -0700 (PDT) Received: by empire.icsi.berkeley.edu (Postfix, from userid 502) id D181F1BAF06; Tue, 18 May 2010 21:21:00 -0700 (PDT) Date: Tue, 18 May 2010 21:21:00 -0700 From: Robin Sommer To: freebsd-net@freebsd.org Message-ID: <20100519042100.GB6390@icir.org> References: <20100514180151.GA8175@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100514180151.GA8175@icir.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Crashes with ixgbe on FreeBSD 8 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, 19 May 2010 04:41:41 -0000 Hi all, I'm running into crashes with the ixgbe driver on a FreeBSD 8.0-RELEASE system equipped with an Intel X520-SR2 (and using a Supermicro X8DTU-F motherboard). I was wondering whether somebody might have seen this before. I updated the driver to the latest version I found on Intel's download page, which is 2.0.1. However, the moment I run tcpdump on my ix1 interface (which is connected to a switch's monitor port), I see almost immediate crashes of the kind below. Sometimes tcpdump outputs a few 10s of packets before the system crashes, but most of the time it doesn't even get that far. I saw that 8.0-STABLE comes with a more recent version of the driver. Any chance that that might fix the problem? Any other thoughts? Thanks, Robin --------- cut ------------------------------------------------------- syslog from crash: May 14 16:42:24 bart kernel: ix1: link state changed to UP May 14 16:43:34 bart kernel: ix1: promiscuous mode enabled May 14 16:43:35 bart kernel: May 14 16:43:35 bart kernel: May 14 16:43:35 bart kernel: Fatal trap 12: page fault while in kernel mode May 14 16:43:35 bart kernel: cpuid = 5; apic id = 05 May 14 16:43:35 bart kernel: fault virtual address = 0xffff80403d38d3b8 May 14 16:43:35 bart kernel: fault code = supervisor read data, page not present May 14 16:43:35 bart kernel: instruction pointer = 0x20:0xffffffff808437fe May 14 16:43:35 bart kernel: May 14 16:43:35 bart kernel: stack pointer = 0x28:0xffffff82b34d5970 May 14 16:43:35 bart kernel: frame pointer = 0x28:0xffffff82b34d5980 May 14 16:43:35 bart kernel: code segment = base 0x0, limit 0xfffff, type 0x1b May 14 16:43:35 bart kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 14 16:43:35 bart kernel: processor eflags = interrupt enabled, Driver initalization: ix0: port 0xec00-0xec1f mem 0xf8f80000-0xf8ffffff,0xf8f7c006 ix0: Using MSIX interrupts with 33 vectors ix0: [ITHREAD] [...] ix0: Ethernet address: 00:1b:21:55:7f:d8 ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ix1: port 0xe880-0xe89f mem 0xf8e80000-0xf8efffff,0xf8e7c006 ix1: Using MSIX interrupts with 33 vectors ix1: [ITHREAD] [...] ix1: Ethernet address: 00:1b:21:55:7f:d9 ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 ifconfig ix1 ix1: flags=8843 metric 0 mtu 1500 options=5bb ether 00:1b:21:55:7f:d9 media: Ethernet autoselect (10Gbase-SR ) status: active -- Robin Sommer * Phone +1 (510) 666-2886 * robin@icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From owner-freebsd-net@FreeBSD.ORG Wed May 19 05:28: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 B15E3106564A for ; Wed, 19 May 2010 05:28:27 +0000 (UTC) (envelope-from jfvogel@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 ED4ED8FC21 for ; Wed, 19 May 2010 05:28:26 +0000 (UTC) Received: by wye20 with SMTP id 20so237716wye.13 for ; Tue, 18 May 2010 22:28:25 -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=Jal8O9Ed/GqU3MwoiMQcnPNqmVkk+hQw1/XFRc+Ry+M=; b=ONqyHufRaUUc7UJaU5SVeu4oFKGBXUmzd3mTYzf5OfRU7g9DqUHMEVFi0e/y8M2Iqa yk5uS7atvuO6gsCNYRc5vPrmNxE61FOItwCesKHensp0ttTE0VURw0D+K7C3BgbWFoGx AIW2jOCC6M1el5CwcOaP9emG4TbNlcKzrzDN8= 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=PFRd4pJjfXtcUdC64R+JoyF0/H5v8hzXEq++qJpsHnOPAzcQKVJj0iHcq3/4ys/qNj nxDvqJzvN49EGWlTDzrnNfp6yzcsHaULtXGziZ/MxtV3LMfVbi8f9f4kkk5zXXnEQEzr QlPDvAF+CMpTx7PAQhlxiPCVd/nsUxbI5H5AM= MIME-Version: 1.0 Received: by 10.216.89.140 with SMTP id c12mr4700073wef.163.1274246905193; Tue, 18 May 2010 22:28:25 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Tue, 18 May 2010 22:28:25 -0700 (PDT) In-Reply-To: <20100519042100.GB6390@icir.org> References: <20100514180151.GA8175@icir.org> <20100519042100.GB6390@icir.org> Date: Tue, 18 May 2010 22:28:25 -0700 Message-ID: From: Jack Vogel To: Robin Sommer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Crashes with ixgbe on FreeBSD 8 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, 19 May 2010 05:28:27 -0000 Hi Robin, Yes, download the latest code, oh hmmm, can you install STABLE, because there's one small issue that will cause a problem on 8 REL, but if that's a big problem I can also give you a patch so it will work. What I'd like to see you try is the newest code that I checked into HEAD today, that's what I am planning for 8.1 and I want as much testing as I can get anyway. I believe that the version on our external page has problems when you exceed 32 vectors, the new code will reduce that by going to queues rather than individual rx and tx vectors, it also fixes the problem underlying it anyway. Regards, Jack On Tue, May 18, 2010 at 9:21 PM, Robin Sommer wrote: > Hi all, > > I'm running into crashes with the ixgbe driver on a FreeBSD > 8.0-RELEASE system equipped with an Intel X520-SR2 (and using a > Supermicro X8DTU-F motherboard). I was wondering whether somebody > might have seen this before. > > I updated the driver to the latest version I found on Intel's > download page, which is 2.0.1. However, the moment I run tcpdump on > my ix1 interface (which is connected to a switch's monitor port), I > see almost immediate crashes of the kind below. Sometimes tcpdump > outputs a few 10s of packets before the system crashes, but most of > the time it doesn't even get that far. > > I saw that 8.0-STABLE comes with a more recent version of the > driver. Any chance that that might fix the problem? Any other > thoughts? > > Thanks, > > Robin > > --------- cut ------------------------------------------------------- > > syslog from crash: > > May 14 16:42:24 bart kernel: ix1: link state changed to UP > May 14 16:43:34 bart kernel: ix1: promiscuous mode enabled > May 14 16:43:35 bart kernel: > May 14 16:43:35 bart kernel: > May 14 16:43:35 bart kernel: Fatal trap 12: page fault while in kernel mode > May 14 16:43:35 bart kernel: cpuid = 5; apic id = 05 > May 14 16:43:35 bart kernel: fault virtual address = > 0xffff80403d38d3b8 > May 14 16:43:35 bart kernel: fault code = supervisor read data, > page not present > May 14 16:43:35 bart kernel: instruction pointer = > 0x20:0xffffffff808437fe > May 14 16:43:35 bart kernel: > May 14 16:43:35 bart kernel: stack pointer = > 0x28:0xffffff82b34d5970 > May 14 16:43:35 bart kernel: frame pointer = > 0x28:0xffffff82b34d5980 > May 14 16:43:35 bart kernel: code segment = base 0x0, limit > 0xfffff, type 0x1b > May 14 16:43:35 bart kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > May 14 16:43:35 bart kernel: processor eflags = interrupt enabled, > > Driver initalization: > > ix0: port > 0xec00-0xec1f mem 0xf8f80000-0xf8ffffff,0xf8f7c006 > ix0: Using MSIX interrupts with 33 vectors > ix0: [ITHREAD] > [...] > ix0: Ethernet address: 00:1b:21:55:7f:d8 > ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 > ix1: port > 0xe880-0xe89f mem 0xf8e80000-0xf8efffff,0xf8e7c006 > ix1: Using MSIX interrupts with 33 vectors > ix1: [ITHREAD] > [...] > ix1: Ethernet address: 00:1b:21:55:7f:d9 > ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 > > ifconfig ix1 > > ix1: flags=8843 metric 0 mtu 1500 > > options=5bb > ether 00:1b:21:55:7f:d9 > media: Ethernet autoselect (10Gbase-SR ) > status: active > > > > -- > Robin Sommer * Phone +1 (510) 666-2886 * robin@icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed May 19 05:40: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 F18B61065676 for ; Wed, 19 May 2010 05:40:10 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D17EE8FC18 for ; Wed, 19 May 2010 05:40:10 +0000 (UTC) Received: by pvg3 with SMTP id 3so136241pvg.13 for ; Tue, 18 May 2010 22:40:10 -0700 (PDT) Received: by 10.140.58.1 with SMTP id g1mr5982404rva.138.1274247610196; Tue, 18 May 2010 22:40:10 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.140.247.13 with HTTP; Tue, 18 May 2010 22:39:50 -0700 (PDT) From: Juli Mallett Date: Tue, 18 May 2010 22:39:50 -0700 X-Google-Sender-Auth: kU-RQgn_GNLTAHE32Uwy6WMkdLY Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Dual-rate transceivers with ixgbe? 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, 19 May 2010 05:40:11 -0000 Hey all, Has anyone out there been able to get link using a dual-rate transceiver at 1gig with the ixgbe driver in FreeBSD? I have an SFP+ NIC and an Intel-branded dual-rate transceiver but it will only get link at 10gig. I used the latest driver from FreeBSD trunk backported (which IIRC didn't take any significant changes; jfv@ does a good job of keeping the drivers working across branches) to 7.x for my testing. A similarly-versioned Linux driver (with only trivial and mostly cosmetic differences in the hardware code outside of the main driver) worked at 1gig just fine. All testing was done with switches rather than host-to-host connections. It seems like someone else must have tried this and it seems like there must just be some trivial difference in card initialization between FreeBSD and Linux, so I thought I'd ask publicly to see if anyone had patches. I instrumented the code extensively but so far have come up empty-handed. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Wed May 19 07:26:33 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 ABB58106564A; Wed, 19 May 2010 07:26:33 +0000 (UTC) (envelope-from jfvogel@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 0F6808FC20; Wed, 19 May 2010 07:26:32 +0000 (UTC) Received: by wwb39 with SMTP id 39so328545wwb.13 for ; Wed, 19 May 2010 00:26:31 -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=4RzF3P0N1c0rLDynbKxd3ccNcmUKUXo2sinwngdOL00=; b=oj2B/Q9WZ7IjvIrHf3WR2oGkQCptW9p1/coGkroh94Rm6IdHpz3k1Slo3TufNH0MSA Zwj6oY2hO8D1GvUkCny2W+3dOrg1ODalxMcNmM0kg46TMFDO7w1kZMB51xmvn0xGLDX/ qVOZzrNniYxw3Wjf76+ngoSdY1Gs1DuL0hLcQ= 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=kY+vQMcbxKLONscT+dDIufqmNKFTIkTSyrsxlOpfB0NwfnwusGfREXC+xgxMcaVZPQ BRj3OU2OtXKMIkdq7c4Z+a4FeP4DK7iGeUukPKD99GoKL4yUW4sYB5Ep2ttTaI3jE/mp dL5D8JHVNeWjVJtRIHbMqm1o+fvFgxKm+6brU= MIME-Version: 1.0 Received: by 10.227.128.81 with SMTP id j17mr7452709wbs.149.1274253991595; Wed, 19 May 2010 00:26:31 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Wed, 19 May 2010 00:26:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 May 2010 00:26:31 -0700 Message-ID: From: Jack Vogel To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Dual-rate transceivers with ixgbe? 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, 19 May 2010 07:26:33 -0000 Hmmm, this is odd, I'm sure that was tested by my validation engineer. Tell me what the hardware looks like, ie what the 1G link partner is and I'll have him check into it... it SHOULD work. You could just ask me you know :) Jack On Tue, May 18, 2010 at 10:39 PM, Juli Mallett wrote: > Hey all, > > Has anyone out there been able to get link using a dual-rate > transceiver at 1gig with the ixgbe driver in FreeBSD? I have an SFP+ > NIC and an Intel-branded dual-rate transceiver but it will only get > link at 10gig. > > I used the latest driver from FreeBSD trunk backported (which IIRC > didn't take any significant changes; jfv@ does a good job of keeping > the drivers working across branches) to 7.x for my testing. A > similarly-versioned Linux driver (with only trivial and mostly > cosmetic differences in the hardware code outside of the main driver) > worked at 1gig just fine. All testing was done with switches rather > than host-to-host connections. > > It seems like someone else must have tried this and it seems like > there must just be some trivial difference in card initialization > between FreeBSD and Linux, so I thought I'd ask publicly to see if > anyone had patches. I instrumented the code extensively but so far > have come up empty-handed. > > Thanks, > Juli. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed May 19 09:03:47 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 B78BE1065672; Wed, 19 May 2010 09:03:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE898FC13; Wed, 19 May 2010 09:03:47 +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 o4J93lSw045148; Wed, 19 May 2010 09:03:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4J93lun045144; Wed, 19 May 2010 09:03:47 GMT (envelope-from linimon) Date: Wed, 19 May 2010 09:03:47 GMT Message-Id: <201005190903.o4J93lun045144@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146719: [pf] [panic] PF or dumynet kernel panic 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, 19 May 2010 09:03:47 -0000 Old Synopsis: PF or dumynet kernel panic New Synopsis: [pf] [panic] PF or dumynet kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed May 19 09:03:36 UTC 2010 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=146719 From owner-freebsd-net@FreeBSD.ORG Wed May 19 16:20: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 1EF121065670 for ; Wed, 19 May 2010 16:20:34 +0000 (UTC) (envelope-from robin@icir.org) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by mx1.freebsd.org (Postfix) with ESMTP id 085438FC12 for ; Wed, 19 May 2010 16:20:33 +0000 (UTC) Received: from empire.icsi.berkeley.edu (empire.ICSI.Berkeley.EDU [192.150.186.169]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o4JGKW5I011831; Wed, 19 May 2010 09:20:33 -0700 (PDT) Received: by empire.icsi.berkeley.edu (Postfix, from userid 502) id E03481BEF48; Wed, 19 May 2010 09:20:32 -0700 (PDT) Date: Wed, 19 May 2010 09:20:32 -0700 From: Robin Sommer To: Jack Vogel Message-ID: <20100519162032.GE6390@icir.org> References: <20100514180151.GA8175@icir.org> <20100519042100.GB6390@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-net@freebsd.org Subject: Re: Crashes with ixgbe on FreeBSD 8 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, 19 May 2010 16:20:34 -0000 On Tue, May 18, 2010 at 22:28 -0700, you wrote: > Yes, download the latest code, oh hmmm, can you install STABLE, > because there's one small issue that will cause a problem on 8 REL, > but if that's a big problem I can also give you a patch so it will work. Jack, thanks for the reply. I could upgrade to STABLE but I as I have quite a number of machines in my setup (and not not all of them need the driver) I would prefer to stay with RELEASE if that is an option. So if you could send me a patch, that would be very helpful. > What I'd like to see you try is the newest code that I checked into > HEAD today, that's what I am planning for 8.1 and I want as much > testing as I can get anyway. Sure, I'd be happy to try that. Can this be back-ported to RELEASE as well or does it need HEAD? Thanks! Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin@icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From owner-freebsd-net@FreeBSD.ORG Wed May 19 16:47: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 6221D106564A for ; Wed, 19 May 2010 16:47:34 +0000 (UTC) (envelope-from jfvogel@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 E3FDE8FC0C for ; Wed, 19 May 2010 16:47:33 +0000 (UTC) Received: by wye20 with SMTP id 20so766070wye.13 for ; Wed, 19 May 2010 09:47:30 -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=6+yakPuRkyl1AiFiMyoBCQ/nrhog1aDcCT40xFgLyfY=; b=q9xfYKHwqd+1SGh1N/zemNdUJ3xhHrIiKw20YChiR/GIq+VKYjvn6L4QZGLRsGU1VN 5LYPejaXIIpiW0P7poSDEvA8P8dq+YY8LnNA9B3U21prILRUGk7s5U3kC1poN7K3K6ad nUgraon3xqGDxUXWYRyHe/bk/dtoqwSYHdfoU= 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=Zq0myjOA663rw24Z8OTxWJDbPw67U/yloKTiepY8AJYZGQLuXwnatctthW856TZEqe UsEgtRkl1pkqIsCFCIhY+ILSm+LRmo5Z42JvYl3Q1ukQB8vvR2Y4UrEOUPMT7PTX8EzV u9u0Xm9oaPbzOqusxeQGq1OMDzaeEB2jJ3V/o= MIME-Version: 1.0 Received: by 10.216.90.136 with SMTP id e8mr5263363wef.121.1274287650668; Wed, 19 May 2010 09:47:30 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Wed, 19 May 2010 09:47:29 -0700 (PDT) In-Reply-To: <20100519162032.GE6390@icir.org> References: <20100514180151.GA8175@icir.org> <20100519042100.GB6390@icir.org> <20100519162032.GE6390@icir.org> Date: Wed, 19 May 2010 09:47:29 -0700 Message-ID: From: Jack Vogel To: Robin Sommer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Crashes with ixgbe on FreeBSD 8 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, 19 May 2010 16:47:34 -0000 It will work on 8 RELEASE just fine except for a macro define that ALTQ required that's not in RELEASE, what I did was stick the define into the header and all was well. I was thinking that I would not check that change in but I now see it will probably be useful to have it in the mainstream. I have another hot issue this morning but I will try and check the change into HEAD this afternoon then you will able to just pull that and the driver will drop into 8 REL with no problem. Jack On Wed, May 19, 2010 at 9:20 AM, Robin Sommer wrote: > > On Tue, May 18, 2010 at 22:28 -0700, you wrote: > > > Yes, download the latest code, oh hmmm, can you install STABLE, > > because there's one small issue that will cause a problem on 8 REL, > > but if that's a big problem I can also give you a patch so it will work. > > Jack, thanks for the reply. I could upgrade to STABLE but I as I > have quite a number of machines in my setup (and not not all of them > need the driver) I would prefer to stay with RELEASE if that is an > option. So if you could send me a patch, that would be very helpful. > > > What I'd like to see you try is the newest code that I checked into > > HEAD today, that's what I am planning for 8.1 and I want as much > > testing as I can get anyway. > > Sure, I'd be happy to try that. Can this be back-ported to RELEASE > as well or does it need HEAD? > > Thanks! > > Robin > > -- > Robin Sommer * Phone +1 (510) 666-2886 * robin@icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org > From owner-freebsd-net@FreeBSD.ORG Wed May 19 17:51:42 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 109CC1065670 for ; Wed, 19 May 2010 17:51:42 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx75.mail.ru (mx75.mail.ru [94.100.176.90]) by mx1.freebsd.org (Postfix) with ESMTP id C01C08FC19 for ; Wed, 19 May 2010 17:51:41 +0000 (UTC) Received: from [217.25.27.27] (port=15216 helo=[217.25.27.27]) by mx75.mail.ru with asmtp id 1OEnQh-000P5A-00 for freebsd-net@freebsd.org; Wed, 19 May 2010 21:51:39 +0400 Message-ID: <4BF4252F.8000208@mail.ru> Date: Wed, 19 May 2010 22:51:43 +0500 From: rihad User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: increasing em(4) buffer sizes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rihad List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 17:51:42 -0000 Hi there, We have a FreeBSD 7.2 Intel Server System 4GB RAM box doing traffic shaping and accounting. It has two em gigabit interfaces: one used for input, the other for output, servicing around 500-600 mbps load through it. Traffic limiting is accomplished by dynamically setting up IPFW pipes, which in turn work fine for our per-user traffic accounting needs thanks to byte counters. So the firewall is basically a longish string of pipe rules. This worked fine when the number of online users was low, but now, as we've slowly begun servicing 2-3K online users netstat -i's Ierrs column is growing at a rate of 5-15K per hour for em0, the interface used for input. Apparently searching through the firewall linearly for _each_ arriving packet locks the interface for the duration of the search (even though net.isr.direct=0), so some packets are periodically dropped on input. To mitigate the problem I've set up a two-level hash by means of skipto rules, dropping the number of up to several thousand rules to be searched for each packet to a mere 85 max, but the rate of Ierrs has only increased to 40-50K per hour, I don't know why. I've also tried setting these sysctls: hw.intr_storm_threshold=10000 dev.em.0.rx_processing_limit=3000 but they didn't help at all. BTW, the other current settings are: kern.hz=4000 net.inet.ip.fw.verbose=0 kern.ipc.nmbclusters=111111 net.inet.ip.fastforwarding=1 net.inet.ip.dummynet.io_fast=1 net.isr.direct=0 net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.intr_queue_drops is always zero. I think the problem lies in the buffer size of em not being large enough to buffer the packets as they're arriving. I looked in /sys/dev/e1000/if_em.c and found this: in em_attach(): adapter->rx_buffer_len = 2048; and later in em_initialize_receive_unit(): switch (adapter->rx_buffer_len) { default: case 2048: rctl |= E1000_RCTL_SZ_2048; break; case 4096: rctl |= E1000_RCTL_SZ_4096 | E1000_RCTL_BSEX | E1000_RCTL_LPE; break; case 8192: rctl |= E1000_RCTL_SZ_8192 | E1000_RCTL_BSEX | E1000_RCTL_LPE; break; case 16384: rctl |= E1000_RCTL_SZ_16384 | E1000_RCTL_BSEX | E1000_RCTL_LPE; break; } So apparently the default buffer size is 2048 bytes, and as much as 16384 is supported. But at what price? Those constants do look suspicious. Can I blindly change rx_buffer_len in em_attach()? Sorry, I'm not a kernel hacker :( Thanks for reading and thanks for any tips. Any help is much appreciated. From owner-freebsd-net@FreeBSD.ORG Wed May 19 17:53: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 AF839106566B for ; Wed, 19 May 2010 17:53:26 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE228FC1D for ; Wed, 19 May 2010 17:53:26 +0000 (UTC) Received: by pzk11 with SMTP id 11so4812568pzk.28 for ; Wed, 19 May 2010 10:53:26 -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 :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=8BvwlRyyhxzbmNoJlCT+SIQ88PdL6FhNfMTMPvoPUfQ=; b=Bh/2GPH/GBp0UXAFQYNGhj+KeoNCTTjpe6ENH57vNWCbh4xg51v3o0McjNsknUDmjH thkU1UHwzS5iG1M0uE0aLoFUBKcnGv0n3kM+IfWgDGvYrLbLNV6xFsuqjl5jw9NRh4vf SwKNDWkNOZ8cCwqNmQvl2SYwiJrwVqyVVKQ/c= 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:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=WxfidnWHjg8dXn0rEHIFuw0Wtsv+NRN7P/4XKOgpDdXLDbRhXRf1cQkgKsPXEO67Aw Vi9qsIZ9vQF8/NIT9NaHSOj6MRlZk6ZhNXiZ61/oE/I8Z5Rms2UIWflsM/UjhVClkS+U DMcWpYzKmoVUFzil9r/sPsHTq0aK7titCzJ3g= Received: by 10.142.2.28 with SMTP id 28mr1654675wfb.207.1274291605691; Wed, 19 May 2010 10:53:25 -0700 (PDT) Received: from centel.dataix.local (adsl-99-35-14-184.dsl.klmzmi.sbcglobal.net [99.35.14.184]) by mx.google.com with ESMTPS id y27sm2766197wfi.17.2010.05.19.10.53.23 (version=SSLv3 cipher=RC4-MD5); Wed, 19 May 2010 10:53:24 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BF42585.80307@dataix.net> Date: Wed, 19 May 2010 13:53:09 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird/3.0.4 MIME-Version: 1.0 To: dave jones References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Multicast tftpd 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, 19 May 2010 17:53:26 -0000 On 05/18/2010 21:41, dave jones wrote: > Hello, > > It seems that FreeBSD's tftpd doesn't support multicast. > Does anyone know which multicast tftpd available on FreeBSD? > Thank you. > There was talk at one point about updating tftpd to the one in NetBSD. I dont remember which one but there should be a thread for this out there somewhere. -- jhell From owner-freebsd-net@FreeBSD.ORG Wed May 19 19:21:19 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 40B3D1065673 for ; Wed, 19 May 2010 19:21:19 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id EA3EA8FC18 for ; Wed, 19 May 2010 19:21:17 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o4JJ56Xh029743; Thu, 20 May 2010 02:05:06 +0700 (NOVST) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.4/8.14.3/Submit) id o4JJ55BJ029742; Thu, 20 May 2010 02:05:05 +0700 (NOVST) (envelope-from eugen) Date: Thu, 20 May 2010 02:05:05 +0700 From: Eugene Grosbein To: rihad Message-ID: <20100519190505.GA29133@rdtc.ru> References: <4BF4252F.8000208@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF4252F.8000208@mail.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: increasing em(4) buffer sizes 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, 19 May 2010 19:21:19 -0000 On Wed, May 19, 2010 at 10:51:43PM +0500, rihad wrote: > We have a FreeBSD 7.2 Intel Server System 4GB RAM box doing traffic > shaping and accounting. It has two em gigabit interfaces: one used for > input, the other for output, servicing around 500-600 mbps load through > it. Traffic limiting is accomplished by dynamically setting up IPFW > pipes, which in turn work fine for our per-user traffic accounting needs > thanks to byte counters. So the firewall is basically a longish string > of pipe rules. This worked fine when the number of online users was low, > but now, as we've slowly begun servicing 2-3K online users netstat -i's > Ierrs column is growing at a rate of 5-15K per hour for em0, the > interface used for input. Apparently searching through the firewall > linearly for _each_ arriving packet locks the interface for the duration > of the search (even though net.isr.direct=0), so some packets are > periodically dropped on input. To mitigate the problem I've set up a > two-level hash by means of skipto rules, dropping the number of up to > several thousand rules to be searched for each packet to a mere 85 max, > but the rate of Ierrs has only increased to 40-50K per hour, I don't > know why. I've also tried setting these sysctls: First, read: http://www.intel.com/design/network/applnots/ap450.htm You'll see you may be restricted with your NIC's chip capabilities. > hw.intr_storm_threshold=10000 > dev.em.0.rx_processing_limit=3000 > > but they didn't help at all. BTW, the other current settings are: > kern.hz=4000 > net.inet.ip.fw.verbose=0 > kern.ipc.nmbclusters=111111 > net.inet.ip.fastforwarding=1 > net.inet.ip.dummynet.io_fast=1 > net.isr.direct=0 > net.inet.ip.intr_queue_maxlen=5000 > > net.inet.ip.intr_queue_drops is always zero. > > I think the problem lies in the buffer size of em not being large enough > to buffer the packets as they're arriving. I looked in > /sys/dev/e1000/if_em.c and found this: > > in em_attach(): > adapter->rx_buffer_len = 2048; > > and later in em_initialize_receive_unit(): > switch (adapter->rx_buffer_len) { > default: > case 2048: > rctl |= E1000_RCTL_SZ_2048; > break; > case 4096: > rctl |= E1000_RCTL_SZ_4096 | > E1000_RCTL_BSEX | E1000_RCTL_LPE; > break; > case 8192: > rctl |= E1000_RCTL_SZ_8192 | > E1000_RCTL_BSEX | E1000_RCTL_LPE; > break; > case 16384: > rctl |= E1000_RCTL_SZ_16384 | > E1000_RCTL_BSEX | E1000_RCTL_LPE; > break; > } > > > So apparently the default buffer size is 2048 bytes, and as much as > 16384 is supported. But at what price? Those constants do look > suspicious. Can I blindly change rx_buffer_len in em_attach()? Sorry, > I'm not a kernel hacker :( There are loader tunnables, set them in /etc/loader.conf: hw.em.rxd=4096 hw.em.txd=4096 The price is amount of kernel memory the driver may consume. Maxumum MTU=16110 for em(4), so it can consume about 64Mb of kernel memory for that long input buffer, in theory. Some more useful tunnables for loader.conf: dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.0.rx_abs_int_delay=200 dev.em.0.tx_abs_int_delay=200 dev.em.0.rx_processing_limit=-1 Alternatively, you may try kernel polling (ifconfig em0 polling) with other tunnables: kern.hz=4000 # for /boot/loader.conf kern.polling.burst_max=1000 # for /etc/sysctl.conf kern.polling.each_burst=500 Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu May 20 04:33:53 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 344E4106567B for ; Thu, 20 May 2010 04:33:53 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx33.mail.ru (mx33.mail.ru [94.100.176.47]) by mx1.freebsd.org (Postfix) with ESMTP id E31E88FC15 for ; Thu, 20 May 2010 04:33:52 +0000 (UTC) Received: from [217.25.27.27] (port=63210 helo=[217.25.27.27]) by mx33.mail.ru with asmtp id 1OExSA-000M63-00; Thu, 20 May 2010 08:33:51 +0400 Message-ID: <4BF4BBB2.8030806@mail.ru> Date: Thu, 20 May 2010 09:33:54 +0500 From: rihad User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eugene Grosbein References: <4BF4252F.8000208@mail.ru> <20100519190505.GA29133@rdtc.ru> In-Reply-To: <20100519190505.GA29133@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: increasing em(4) buffer sizes 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, 20 May 2010 04:33:53 -0000 On 05/20/2010 12:05 AM, Eugene Grosbein wrote: > On Wed, May 19, 2010 at 10:51:43PM +0500, rihad wrote: > >> We have a FreeBSD 7.2 Intel Server System 4GB RAM box doing traffic >> shaping and accounting. It has two em gigabit interfaces: one used for >> input, the other for output, servicing around 500-600 mbps load through >> it. Traffic limiting is accomplished by dynamically setting up IPFW >> pipes, which in turn work fine for our per-user traffic accounting needs >> thanks to byte counters. So the firewall is basically a longish string >> of pipe rules. This worked fine when the number of online users was low, >> but now, as we've slowly begun servicing 2-3K online users netstat -i's >> Ierrs column is growing at a rate of 5-15K per hour for em0, the >> interface used for input. Apparently searching through the firewall >> linearly for _each_ arriving packet locks the interface for the duration >> of the search (even though net.isr.direct=0), so some packets are >> periodically dropped on input. To mitigate the problem I've set up a >> two-level hash by means of skipto rules, dropping the number of up to >> several thousand rules to be searched for each packet to a mere 85 max, >> but the rate of Ierrs has only increased to 40-50K per hour, I don't >> know why. I've also tried setting these sysctls: > > First, read: http://www.intel.com/design/network/applnots/ap450.htm > You'll see you may be restricted with your NIC's chip capabilities. > Likely sooner than later these cards will be upgraded to 10 GigE ones, I just want to make sure that the delays imposed by traversing the firewall never cause traffic drops on input. > There are loader tunnables, set them in /etc/loader.conf: Do you mean /boot/loader.conf ? > > hw.em.rxd=4096 > hw.em.txd=4096 > BTW, I can't read the current value: $ sysctl hw.em.rxd sysctl: unknown oid 'hw.em.rxd' $ Is this a write-only value? :) > The price is amount of kernel memory the driver may consume. > Maxumum MTU=16110 for em(4), so it can consume about 64Mb of kernel memory > for that long input buffer, in theory. > > Some more useful tunnables for loader.conf: > > dev.em.0.rx_int_delay=200 > dev.em.0.tx_int_delay=200 > dev.em.0.rx_abs_int_delay=200 > dev.em.0.tx_abs_int_delay=200 > dev.em.0.rx_processing_limit=-1 > So this interrupt delay is the much talked about interrupt moderation? Thanks, I'll try them. Is there any risk the machine won't boot with them if rebooted remotely? > Alternatively, you may try kernel polling (ifconfig em0 polling) > with other tunnables: > > kern.hz=4000 # for /boot/loader.conf > kern.polling.burst_max=1000 # for /etc/sysctl.conf > kern.polling.each_burst=500 > Wow, I successfully used polling a couple of years ago when the load was low, but then I read some posting on this list claiming that Intel cards have the ability to do fast-interrupts (interrupt moderation), but for that DEVICE_POLLING needs to be out of the kernel. So I scratched it and rebuilt the kernel for no apparent reason. Maybe you're right, polling would've worked just fine, so I may go back to that too. > Eugene Grosbein > > From owner-freebsd-net@FreeBSD.ORG Thu May 20 04:38:44 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 B5A301065670 for ; Thu, 20 May 2010 04:38:44 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [94.100.176.48]) by mx1.freebsd.org (Postfix) with ESMTP id 70CC68FC18 for ; Thu, 20 May 2010 04:38:44 +0000 (UTC) Received: from [217.25.27.27] (port=50379 helo=[217.25.27.27]) by mx34.mail.ru with asmtp id 1OExWs-0001aq-00; Thu, 20 May 2010 08:38:42 +0400 Message-ID: <4BF4BCD6.4000303@mail.ru> Date: Thu, 20 May 2010 09:38:46 +0500 From: rihad User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sriram Gorti References: <4BF4252F.8000208@mail.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: increasing em(4) buffer sizes 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, 20 May 2010 04:38:44 -0000 On 05/20/2010 08:54 AM, Sriram Gorti wrote: > Hi, > > I'm new to FreeBSD but there is one aspect of your description (thanks > for the detail) on which I had a comment that I thought can be shared. > > > To mitigate the problem I've set up a two-level hash by means of > skipto rules, dropping the number of up to several thousand rules to be > searched for each packet to a mere 85 max, but the rate of Ierrs has > only increased to 40-50K per hour, > > Not exactly sure what kind of rules are in a firewall and what kind of > searcher your have. If you have a software searcher, it is not just the Not really, it's the lookup done by the OS for each outgoing packet (in my case). FreeBSD does so by walking the ruleset one by one, starting from the first rule. It does take some time if the number of rules to be walked is high. How do I know it's the firewall causing the drops: if I short circuit this process by adding "allow ip from any to any" as the first rule, all Ierrs disappear. > number of rules but the "kind" of rules can also make a big difference. > For example, most searchers become slower with regex intensive rules and > if some such rules in your original set were retained in the reduced set > of 85, then the drop will continue. However, why have the drops > increased - good question. One remote guess is that it can depend on the > behavior of the searcher - does it stop searching on the rest of the > rules if a rule is found. If this is the case, then it is again possible > that the set of 85 does not match most of the time causing more work for > the searcher. > > All the best for your investigations, > Thank you! > regards, > Sriram > From owner-freebsd-net@FreeBSD.ORG Thu May 20 05:51:19 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 220D8106564A for ; Thu, 20 May 2010 05:51:19 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id E241C8FC08 for ; Thu, 20 May 2010 05:51:16 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o4K5JoX9032717; Thu, 20 May 2010 12:19:51 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4BF4C676.8010709@grosbein.pp.ru> Date: Thu, 20 May 2010 12:19:50 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.9) Gecko/20100511 Thunderbird/3.0.4 MIME-Version: 1.0 To: rihad References: <4BF4252F.8000208@mail.ru> <20100519190505.GA29133@rdtc.ru> <4BF4BBB2.8030806@mail.ru> In-Reply-To: <4BF4BBB2.8030806@mail.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: increasing em(4) buffer sizes 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, 20 May 2010 05:51:19 -0000 On 20.05.2010 11:33, rihad wrote: >> First, read: http://www.intel.com/design/network/applnots/ap450.htm >> You'll see you may be restricted with your NIC's chip capabilities. >> > Likely sooner than later these cards will be upgraded to 10 GigE ones, I > just want to make sure that the delays imposed by traversing the > firewall never cause traffic drops on input. That document is needed to understand tunnables mentioned later. >> There are loader tunnables, set them in /etc/loader.conf: > > Do you mean /boot/loader.conf ? Yes, /boot/loader.conf >> >> hw.em.rxd=4096 >> hw.em.txd=4096 >> > > BTW, I can't read the current value: > $ sysctl hw.em.rxd > sysctl: unknown oid 'hw.em.rxd' > $ > > Is this a write-only value? :) They are loader tunnables that have no sysctl variables with same names - as an example of such rare case :-) They are documented in man em, though. >> The price is amount of kernel memory the driver may consume. >> Maxumum MTU=16110 for em(4), so it can consume about 64Mb of kernel memory >> for that long input buffer, in theory. >> >> Some more useful tunnables for loader.conf: >> >> dev.em.0.rx_int_delay=200 >> dev.em.0.tx_int_delay=200 >> dev.em.0.rx_abs_int_delay=200 >> dev.em.0.tx_abs_int_delay=200 >> dev.em.0.rx_processing_limit=-1 >> > So this interrupt delay is the much talked about interrupt moderation? > Thanks, I'll try them. Is there any risk the machine won't boot with > them if rebooted remotely? Yes, for hw.em.rxd/hw.em.txd only. em interfaces will not function if you set these two too high for your nic chip, so read man em and mentioned Intel document carefully. It's pretty safe to play with other tunnables. >> Alternatively, you may try kernel polling (ifconfig em0 polling) >> with other tunnables: >> >> kern.hz=4000 # for /boot/loader.conf >> kern.polling.burst_max=1000 # for /etc/sysctl.conf >> kern.polling.each_burst=500 >> > Wow, I successfully used polling a couple of years ago when the load was > low, but then I read some posting on this list claiming that Intel cards > have the ability to do fast-interrupts (interrupt moderation), Yes, they have but some tuning for interrupt moderation may be needed. > but for that DEVICE_POLLING needs to be out of the kernel. That may be true long time ago but not for 7.x afaik. Just use ifconfig to enable/disable polling per-device. > So I scratched it and > rebuilt the kernel for no apparent reason. Maybe you're right, polling > would've worked just fine, so I may go back to that too. For ng_source-based outgoing flood of 64 byte UDP packets in test lab I've obtained best results with polling enabled using FreeBSD 7.1 For Pentium-D 2.8Ghz dualcore and desktop motherboard Intel D975XBX with integrated NIC: em0@pci0:4:0:0: class=0x020000 card=0x30a58086 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet I've got 742359pps / 772Mbps at wire. Note, that was not forwarding speed, only outgoing UDP flood. The CPU horsepower was limiting point, one core was fully loaded and another one idle. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu May 20 06:06: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 1795C1065678 for ; Thu, 20 May 2010 06:06:10 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx39.mail.ru (mx39.mail.ru [94.100.176.53]) by mx1.freebsd.org (Postfix) with ESMTP id C6D3C8FC15 for ; Thu, 20 May 2010 06:06:09 +0000 (UTC) Received: from [217.25.27.27] (port=40383 helo=[217.25.27.27]) by mx39.mail.ru with asmtp id 1OEytT-0005zg-00; Thu, 20 May 2010 10:06:07 +0400 Message-ID: <4BF4D152.8030005@mail.ru> Date: Thu, 20 May 2010 11:06:10 +0500 From: rihad User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eugene Grosbein References: <4BF4252F.8000208@mail.ru> <20100519190505.GA29133@rdtc.ru> <4BF4BBB2.8030806@mail.ru> <4BF4C676.8010709@grosbein.pp.ru> In-Reply-To: <4BF4C676.8010709@grosbein.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: increasing em(4) buffer sizes 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, 20 May 2010 06:06:10 -0000 On 05/20/2010 10:19 AM, Eugene Grosbein wrote: > On 20.05.2010 11:33, rihad wrote: > >> BTW, I can't read the current value: >> $ sysctl hw.em.rxd >> sysctl: unknown oid 'hw.em.rxd' >> $ >> >> Is this a write-only value? :) > > They are loader tunnables that have no sysctl variables > with same names - as an example of such rare case :-) > They are documented in man em, though. > >>> The price is amount of kernel memory the driver may consume. >>> Maxumum MTU=16110 for em(4), so it can consume about 64Mb of kernel memory >>> for that long input buffer, in theory. >>> Oh, if only this would solve the problem :) I understand the packets can't stay in the buffer for long, so an extremely large input buffer holding on to packets for several seconds is practically useless for TCP, as it will retransmit by that time. But packets dropped on input feel just as bad for the end user due to slower web browsing. >>> Some more useful tunnables for loader.conf: >>> >>> dev.em.0.rx_int_delay=200 >>> dev.em.0.tx_int_delay=200 >>> dev.em.0.rx_abs_int_delay=200 >>> dev.em.0.tx_abs_int_delay=200 >>> dev.em.0.rx_processing_limit=-1 >>> >> So this interrupt delay is the much talked about interrupt moderation? >> Thanks, I'll try them. Is there any risk the machine won't boot with >> them if rebooted remotely? > > Yes, for hw.em.rxd/hw.em.txd only. em interfaces will not function > if you set these two too high for your nic chip, so read man em > and mentioned Intel document carefully. > > It's pretty safe to play with other tunnables. > Can I even set the mentioned dev.em.0.* settings on a live system remotely? You seem to also have an em card, have you tried doing that? I've already set dev.em.0.rx_processing_limit=-1, but to see its effects I'll have to wait a couple of ours for the load to get heavier. >> So I scratched it and >> rebuilt the kernel for no apparent reason. Maybe you're right, polling >> would've worked just fine, so I may go back to that too. > > For ng_source-based outgoing flood of 64 byte UDP packets in test lab > I've obtained best results with polling enabled using FreeBSD 7.1 > > For Pentium-D 2.8Ghz dualcore and desktop motherboard Intel D975XBX > with integrated NIC: > > em0@pci0:4:0:0: class=0x020000 card=0x30a58086 chip=0x109a8086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > Ours is: em0@pci0:5:0:0: class=0x020000 card=0x346c8086 chip=0x10968086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 EB Network Connection' class = network subclass = ethernet hw.em.rxd Number of receive descriptors allocated by the driver. The default value is 256. The 82542 and 82543-based adapters can handle up to 256 descriptors, while others can have up to 4096. We have a EB with an unknown numeric ID. The only EB in the em manual is 82546EB, so I guess it does support hw.em.rxd=4096. I now have several things to try (rxd, polling). > I've got 742359pps / 772Mbps at wire. Note, that was not forwarding > speed, only outgoing UDP flood. The CPU horsepower was limiting point, > one core was fully loaded and another one idle. > I believe FreeBSD 8.x is better in this regard as it spreads the ISR load across multiple cores evenly. > Eugene Grosbein > > From owner-freebsd-net@FreeBSD.ORG Thu May 20 09:27: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 A9775106564A for ; Thu, 20 May 2010 09:27:11 +0000 (UTC) (envelope-from jiani1012@126.com) Received: from m15-64.126.com (m15-64.126.com [220.181.15.64]) by mx1.freebsd.org (Postfix) with ESMTP id 418698FC14 for ; Thu, 20 May 2010 09:27:08 +0000 (UTC) Received: from jiani1012 ( [124.205.28.146] ) by ajax-webmail-wmsvr64 (Coremail) ; Thu, 20 May 2010 17:27:02 +0800 (CST) Date: Thu, 20 May 2010 17:27:02 +0800 (CST) From: jiani1012 To: "Paul B Mahol" Message-ID: <33d419.14b34.128b5099117.Coremail.jiani1012@126.com> In-Reply-To: References: <20100506120022.A331D10656C2@hub.freebsd.org> <45e58af.dfb8.128723a15b9.Coremail.jiani1012@126.com> <4ce970a1.1bc70.12895cdbd14.Coremail.jiani1012@126.com> MIME-Version: 1.0 X-Originating-IP: [124.205.28.146] X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 100504(10496.3041.3041) Copyright (c) 2002-2010 www.mailtech.cn 126com X-CM-CTRLDATA: 2+9KSGZvb3Rlcl9odG09NjczOjEzMA== X-CM-TRANSID: QMqowLCLZgNmAPVL3VISAA--.7925W X-CM-SenderInfo: xmld0xarqrjqqrswhudrp/1tbiqgPWlEe9K96DjwABsp X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== X-Mailman-Approved-At: Thu, 20 May 2010 11:40:19 +0000 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re:Re: Re: convert Windows NDIS drivers for use with FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 09:27:11 -0000 VGhhbmsgeW91IGluIGFkdmFuY2UhIEkgZ290IGl0IHdpdGggc3VjY2VzcyEgClRvZGF5LCBJIGRv IHRoZSBzYW1lIHRoaW5nIHdpdGggSW50ZWwgNDk2NWFnbiBkcml2ZXIgY29ycmVzcG9uZGluZyB0 byBpd24gb24gRlJFRUJTRDguMCByZWxlYXNlLgogSSBjcmVhdGUgd2xhbjAgZnJvbSBpd24wLCBh cyB3ZWxsIGtsZGxvYWQgdGhlIGl3bixpd25mdyBiZWZvcmUgYSBwaW5nIHN1Y2Nlc3NmdWwgY29u bXVuaWNhdGlvbi4gCkJ1dCB3aGVuIEkgZG8gd2xhbjAgc2NhbiwgdGFrZSBlcnJvcnM6Cml3bjA6 ZXJyb3IsSU5UUj0yMDAwMDAwMDxIV19FUlJPUj4gU1RBVFVTPTB4MAppd24wOml3bl90cmFuc2Zl cl9maXJtd2FyZTp0aW1lb3V0IHdhaXRpbmcgZm9yIGZpcnN0IGFsaXZlIG5vdGljZSxlcnJvciAz NQppd24wOml3bl9pbml0X2xvY2tlZDpjb3VsZCBub3QgbG9hZCBmaXJtd2FyZSxlcnJvciAzNQoK CgpUaHVzLHRoZSBsaW5rIGlzIGRpc2Nvbm5lY3RlZC4gV2hhdCdzIHRoZSBtYXR0ZXI/ClRoYW5r cyEKCgpKZW55 From owner-freebsd-net@FreeBSD.ORG Thu May 20 12:19:51 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 66DCE106566B for ; Thu, 20 May 2010 12:19:51 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id B8A448FC1C for ; Thu, 20 May 2010 12:19:50 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o4KCJldg002733; Thu, 20 May 2010 19:19:48 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4BF528E3.7020502@grosbein.pp.ru> Date: Thu, 20 May 2010 19:19:47 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.9) Gecko/20100511 Thunderbird/3.0.4 MIME-Version: 1.0 To: rihad References: <4BF4252F.8000208@mail.ru> <20100519190505.GA29133@rdtc.ru> <4BF4BBB2.8030806@mail.ru> <4BF4C676.8010709@grosbein.pp.ru> <4BF4D152.8030005@mail.ru> In-Reply-To: <4BF4D152.8030005@mail.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: increasing em(4) buffer sizes 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, 20 May 2010 12:19:51 -0000 On 20.05.2010 13:06, rihad wrote: >>>> Some more useful tunnables for loader.conf: >>>> >>>> dev.em.0.rx_int_delay=200 >>>> dev.em.0.tx_int_delay=200 >>>> dev.em.0.rx_abs_int_delay=200 >>>> dev.em.0.tx_abs_int_delay=200 >>>> dev.em.0.rx_processing_limit=-1 >>>> >>> So this interrupt delay is the much talked about interrupt moderation? >>> Thanks, I'll try them. Is there any risk the machine won't boot with >>> them if rebooted remotely? >> >> Yes, for hw.em.rxd/hw.em.txd only. em interfaces will not function >> if you set these two too high for your nic chip, so read man em >> and mentioned Intel document carefully. >> >> It's pretty safe to play with other tunnables. >> > Can I even set the mentioned dev.em.0.* settings on a live system > remotely? You seem to also have an em card, have you tried doing that? Yes, it is permitted. From owner-freebsd-net@FreeBSD.ORG Thu May 20 13:01: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 6BD201065670 for ; Thu, 20 May 2010 13:01:11 +0000 (UTC) (envelope-from grand@mindless.gr) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 07AED8FC1F for ; Thu, 20 May 2010 13:01:10 +0000 (UTC) Received: by wwb39 with SMTP id 39so1632340wwb.13 for ; Thu, 20 May 2010 06:01:10 -0700 (PDT) Received: by 10.227.151.66 with SMTP id b2mr687008wbw.158.1274358961046; Thu, 20 May 2010 05:36:01 -0700 (PDT) Received: from [85.196.7.91] ([85.196.7.91]) by mx.google.com with ESMTPS id h22sm40805988wbh.9.2010.05.20.05.35.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 May 2010 05:36:00 -0700 (PDT) From: "Thodoris S." Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 May 2010 15:35:57 +0300 Message-Id: <4F9B8F64-218B-4DC2-BF0B-965F79466557@gmail.com> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: Strange BGP/OSPF 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: Thu, 20 May 2010 13:01:11 -0000 an one of my border router ospf started flapping without reason the link = was ok i have tested it the log file shows the following at the beggining started with this messages 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.213.128.0/17: = rtm_write() unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.214.0.0/17: rtm_write() = unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.214.128.0/17: = rtm_write() unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.215.0.0/17: rtm_write() = unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.215.128.0/17: = rtm_write() unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.216.0.0/15: rtm_write() = unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.218.0.0/16: rtm_write() = unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.219.0.0/16: rtm_write() = unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.220.0.0/15: rtm_write() = unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.240.0.0/13: rtm_write() = unexpectedly returned -4 for command RTM_DELETE 2010/05/01 17:36:25 ZEBRA: kernel_rtm_ipv4: 222.246.191.0/24: = rtm_write() unexpectedly returned -4 for command RTM_DELETE Later OSPF started to flap after this i restarted quagga deamon and the = ospf continued to flap with this messages 2010/05/18 18:42:19 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 43227ms (cpu time 0ms) 2010/05/18 18:42:28 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 9140ms (cpu time 0ms) 2010/05/18 18:42:59 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 30557ms (cpu time 0ms) 2010/05/18 18:42:59 OSPF: SLOW THREAD: task ospf_write (800670920) ran = for 19783ms (cpu time 0ms) 2010/05/18 18:44:31 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 92158ms (cpu time 0ms) 2010/05/18 18:45:17 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 46164ms (cpu time 0ms) 2010/05/18 18:45:17 BGP: SLOW THREAD: task bgp_scan_timer (439890) ran = for 119622ms (cpu time 372ms) 2010/05/18 18:45:28 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 11152ms (cpu time 0ms) 2010/05/18 18:47:56 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 147739ms (cpu time 0ms) 2010/05/18 18:47:56 BGP: SLOW THREAD: task bgp_scan_timer (439890) ran = for 158815ms (cpu time 373ms) 2010/05/18 18:48:44 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 47649ms (cpu time 0ms) 2010/05/18 18:50:39 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 115218ms (cpu time 0ms) 2010/05/18 18:50:39 BGP: SLOW THREAD: task bgp_scan_timer (439890) ran = for 162774ms (cpu time 372ms) 2010/05/18 18:51:23 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 44371ms (cpu time 0ms) 2010/05/18 18:52:19 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 55878ms (cpu time 0ms) 2010/05/18 18:52:20 BGP: SLOW THREAD: task bgp_scan_timer (439890) ran = for 100162ms (cpu time 378ms) 2010/05/18 18:55:27 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 187961ms (cpu time 60ms) 2010/05/18 18:55:27 BGP: SLOW THREAD: task bgp_scan_timer (439890) ran = for 187858ms (cpu time 369ms) 2010/05/18 18:55:49 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 22402ms (cpu time 0ms) 2010/05/18 18:55:49 OSPF: SLOW THREAD: task ospf_write (800670920) ran = for 20494ms (cpu time 0ms) 2010/05/18 18:55:50 BGP: SLOW THREAD: task bgp_scan_timer (439890) ran = for 20924ms (cpu time 373ms) 2010/05/18 18:55:59 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 7289ms (cpu time 0ms) 2010/05/18 18:56:32 ZEBRA: SLOW THREAD: task work_queue_run (8006a2b90) = ran for 31641ms (cpu time 0ms) then i rebooted the machine and all worked perftectly The Setup is as follows:=20 2 FreeBSD 8.0 routers with 4 interfaces each Each router has 2 layer 2 links (no load balancing just redudancy) i will try to illustrate it with ascii Lo0 = Lo1 = PROVIDER------------------------------------------------------------------= ----------------- | Link1 |Link2 = |Link3 |Link4=20 | | = | | | | = | | \ / = \ / em0 em1 = em0 em1 FBSD0 = em2------------------------------em2 FBSD1 | = | em3 carp = em3 carp FBSD0: Link 1 OSPF cost 10 Link 2 OSPF cost 20 eBGP Provider lo0 with FBSD0 Lo1 (LocalPref 120 on incoming)(eBGP = multihop) iBGP with FBSD1 (next hop self) and CARP for lan interface FBSD1: Link3 OSPF cost 30 Link4 OSPF cost 40 eBGP with Provider lo1 to FBD1 Lo1 (LocalPref 80 on incoming)(eBGP = multihop) iBGP with FBSD0 (next hop self) and CARP for lan interface Any idea why this is happening? these logs all generated at FBSD1 = (backup router) FBSD0 working well.= From owner-freebsd-net@FreeBSD.ORG Thu May 20 15:17: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 ED9B6106566B for ; Thu, 20 May 2010 15:17:21 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx74.mail.ru (mx74.mail.ru [94.100.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id A79B68FC1B for ; Thu, 20 May 2010 15:17:21 +0000 (UTC) Received: from [217.25.27.27] (port=26875 helo=[217.25.27.27]) by mx74.mail.ru with asmtp id 1OF7Ut-000Ldl-00; Thu, 20 May 2010 19:17:19 +0400 Message-ID: <4BF55280.6090504@mail.ru> Date: Thu, 20 May 2010 20:17:20 +0500 From: rihad User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eugene Grosbein References: <4BF4252F.8000208@mail.ru> <20100519190505.GA29133@rdtc.ru> <4BF4BBB2.8030806@mail.ru> <4BF4C676.8010709@grosbein.pp.ru> <4BF4D152.8030005@mail.ru> <4BF528E3.7020502@grosbein.pp.ru> In-Reply-To: <4BF528E3.7020502@grosbein.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: increasing em(4) buffer sizes 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, 20 May 2010 15:17:22 -0000 On 05/20/2010 05:19 PM, Eugene Grosbein wrote: > On 20.05.2010 13:06, rihad wrote: > >>>>> Some more useful tunnables for loader.conf: >>>>> >>>>> dev.em.0.rx_int_delay=200 >>>>> dev.em.0.tx_int_delay=200 >>>>> dev.em.0.rx_abs_int_delay=200 >>>>> dev.em.0.tx_abs_int_delay=200 >>>>> dev.em.0.rx_processing_limit=-1 >>>>> >>>> So this interrupt delay is the much talked about interrupt moderation? >>>> Thanks, I'll try them. Is there any risk the machine won't boot with >>>> them if rebooted remotely? >>> >>> Yes, for hw.em.rxd/hw.em.txd only. em interfaces will not function >>> if you set these two too high for your nic chip, so read man em >>> and mentioned Intel document carefully. >>> >>> It's pretty safe to play with other tunnables. >>> >> Can I even set the mentioned dev.em.0.* settings on a live system >> remotely? You seem to also have an em card, have you tried doing that? > > Yes, it is permitted. > > I haven't tweaked rx_abs_int_delay yet, but I've read the Intel specs that you suggested. It says in the paragraph 4.4: "The expected network use. High use implies high traffic rates, which makes the GbE controller more susceptible to overrun conditions if it delays interrupts too long." Doesn't this mean that increasing the absolute timer (rx_abs_int_delay) would only aggravate the issue and the Ierrs will only increase? It's currently 66, by default I think: dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 I'm pretty sure interrupt overload is not an issue on our system: Here's what top -HS currently shows: 12 root 171 ki31 0K 16K CPU2 2 174.3H 100.00% idle: cpu2 14 root 171 ki31 0K 16K CPU0 0 168.9H 99.76% idle: cpu0 11 root 171 ki31 0K 16K RUN 3 150.4H 94.19% idle: cpu3 13 root 171 ki31 0K 16K RUN 1 118.1H 73.97% idle: cpu1 27 root -68 - 0K 16K - 1 70.1H 31.88% em0 taskq 42 root -68 - 0K 16K - 3 30.5H 7.57% dummynet The interrupt load is only 31% for em0. So, hw.em.rxd=4096 seems to be the only way out? Increasing the buffer size. From owner-freebsd-net@FreeBSD.ORG Thu May 20 15:46: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 BC4E31065670; Thu, 20 May 2010 15:46:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 93D358FC16; Thu, 20 May 2010 15:46: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 o4KFkvlh068402; Thu, 20 May 2010 15:46:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4KFkvcs068398; Thu, 20 May 2010 15:46:57 GMT (envelope-from linimon) Date: Thu, 20 May 2010 15:46:57 GMT Message-Id: <201005201546.o4KFkvcs068398@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146759: [cxgb] [patch] cxgb panic calling cxgb_set_lro() without port lock held 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, 20 May 2010 15:46:57 -0000 Old Synopsis: cxgb panic calling without cxgb_set_lro() without port lock held New Synopsis: [cxgb] [patch] cxgb panic calling cxgb_set_lro() without port lock held Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 20 15:45:51 UTC 2010 Responsible-Changed-Why: Fix synopsis per submitter request and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=146759 From owner-freebsd-net@FreeBSD.ORG Thu May 20 18:30:09 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 27A4C1065670 for ; Thu, 20 May 2010 18:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 17BEA8FC17 for ; Thu, 20 May 2010 18:30:09 +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 o4KIU81r005265 for ; Thu, 20 May 2010 18:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4KIU8TC005260; Thu, 20 May 2010 18:30:08 GMT (envelope-from gnats) Date: Thu, 20 May 2010 18:30:08 GMT Message-Id: <201005201830.o4KIU8TC005260@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/146759: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 18:30:09 -0000 The following reply was made to PR kern/146759; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/146759: commit references a PR Date: Thu, 20 May 2010 18:22:57 +0000 (UTC) Author: np Date: Thu May 20 18:22:45 2010 New Revision: 208356 URL: http://svn.freebsd.org/changeset/base/208356 Log: Remove invalid assertion. Holding the adapter lock while changing the LRO settings is sufficient. PR: kern/146759 MFC after: 3 days Modified: head/sys/dev/cxgb/cxgb_main.c Modified: head/sys/dev/cxgb/cxgb_main.c ============================================================================== --- head/sys/dev/cxgb/cxgb_main.c Thu May 20 17:30:55 2010 (r208355) +++ head/sys/dev/cxgb/cxgb_main.c Thu May 20 18:22:45 2010 (r208356) @@ -1979,7 +1979,6 @@ cxgb_set_lro(struct port_info *p, int en struct adapter *adp = p->adapter; struct sge_qset *q; - PORT_LOCK_ASSERT_OWNED(p); for (i = 0; i < p->nqsets; i++) { q = &adp->sge.qs[p->first_qset + i]; q->lro.enabled = (enabled != 0); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri May 21 20:51:44 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 3667B1065670; Fri, 21 May 2010 20:51:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0CECE8FC0C; Fri, 21 May 2010 20:51:44 +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 o4LKphFp000623; Fri, 21 May 2010 20:51:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4LKphlO000619; Fri, 21 May 2010 20:51:43 GMT (envelope-from linimon) Date: Fri, 21 May 2010 20:51:43 GMT Message-Id: <201005212051.o4LKphlO000619@freefall.freebsd.org> To: kvas@bf.pstu.ac.ru, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146788: [fxp] [patch] New PCI devID for if_fxp driver (tested, worked) 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, 21 May 2010 20:51:44 -0000 Old Synopsis: New PCI devID for if_fxp driver (tested, worked) New Synopsis: [fxp] [patch] New PCI devID for if_fxp driver (tested, worked) State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Fri May 21 20:51:04 UTC 2010 State-Changed-Why: Note that feedback was requested. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 21 20:51:04 UTC 2010 Responsible-Changed-Why: Reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=146788 From owner-freebsd-net@FreeBSD.ORG Fri May 21 20:53:17 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 8D9991065670; Fri, 21 May 2010 20:53:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 652EE8FC08; Fri, 21 May 2010 20:53:16 +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 o4LKrG2v000708; Fri, 21 May 2010 20:53:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4LKrGYa000704; Fri, 21 May 2010 20:53:16 GMT (envelope-from linimon) Date: Fri, 21 May 2010 20:53:16 GMT Message-Id: <201005212053.o4LKrGYa000704@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load 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, 21 May 2010 20:53:17 -0000 Old Synopsis: flowcleaner 100% cpu's core load New Synopsis: [flowtable] flowcleaner 100% cpu's core load Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 21 20:52:17 UTC 2010 Responsible-Changed-Why: Probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=146792 From owner-freebsd-net@FreeBSD.ORG Fri May 21 21:13:27 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 7E75F106566C; Fri, 21 May 2010 21:13:27 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 547E48FC19; Fri, 21 May 2010 21:13:27 +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 o4LLDRfS017979; Fri, 21 May 2010 21:13:27 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4LLDQ3m017975; Fri, 21 May 2010 21:13:26 GMT (envelope-from yongari) Date: Fri, 21 May 2010 21:13:26 GMT Message-Id: <201005212113.o4LLDQ3m017975@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/146788: [fxp] [patch] New PCI devID for if_fxp driver (tested, worked) 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, 21 May 2010 21:13:27 -0000 Synopsis: [fxp] [patch] New PCI devID for if_fxp driver (tested, worked) Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri May 21 21:10:33 UTC 2010 Responsible-Changed-Why: Grab. Would you show me the output of "pciconf -lcbv"? http://www.freebsd.org/cgi/query-pr.cgi?pr=146788 From owner-freebsd-net@FreeBSD.ORG Sat May 22 06:10: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 9DE1F1065679 for ; Sat, 22 May 2010 06:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE8A8FC20 for ; Sat, 22 May 2010 06:10: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 o4M6A4DB086673 for ; Sat, 22 May 2010 06:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4M6A4Zp086672; Sat, 22 May 2010 06:10:04 GMT (envelope-from gnats) Date: Sat, 22 May 2010 06:10:04 GMT Message-Id: <201005220610.o4M6A4Zp086672@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Earl Lapus Cc: Subject: Re: kern/146534: [icmp6] wrong source address in echo reply X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Earl Lapus List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 06:10:04 -0000 The following reply was made to PR kern/146534; it has been noted by GNATS. From: Earl Lapus To: bug-followup@FreeBSD.org, earl.lapus@gmail.com Cc: Subject: Re: kern/146534: [icmp6] wrong source address in echo reply Date: Sat, 22 May 2010 14:06:45 +0800 --001636b14d02cd6f320487289c7c Content-Type: text/plain; charset=ISO-8859-1 Attached patch fixes the problem --001636b14d02cd6f320487289c7c Content-Type: application/octet-stream; name="icmp6.c.diff" Content-Disposition: attachment; filename="icmp6.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g9i17div0 SW5kZXg6IGljbXA2LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaWNtcDYuYwkocmV2aXNpb24gMjA4MzY5KQor KysgaWNtcDYuYwkod29ya2luZyBjb3B5KQpAQCAtMjE2Miw5ICsyMTYyLDE5IEBACiAJfQogCiAJ aWYgKChzcmNwICE9IE5VTEwpICYmIAotCSAgICAoaW42X2FkZHJzY29wZShzcmNwKSAhPSBpbjZf YWRkcnNjb3BlKCZpcDYtPmlwNl9zcmMpKSkKLQkJc3JjcCA9IE5VTEw7CisJICAgIChpbjZfYWRk cnNjb3BlKHNyY3ApICE9IGluNl9hZGRyc2NvcGUoJmlwNi0+aXA2X3NyYykpKSB7CisgICAgICAg ICAgICAgICAgc3RydWN0IHNvY2thZGRyX2luNiBkOwogCisgICAgICAgICAgICAgICAgYnplcm8o JmQsIHNpemVvZihkKSk7CisgICAgICAgICAgICAgICAgZC5zaW42X2ZhbWlseSA9IEFGX0lORVQ2 OworICAgICAgICAgICAgICAgIGQuc2luNl9sZW4gPSBzaXplb2YoZCk7CisgICAgICAgICAgICAg ICAgZC5zaW42X2FkZHIgPSBvcmlnZHN0OworICAgICAgICAgICAgICAgIGlhID0gKHN0cnVjdCBp bjZfaWZhZGRyICopCisgICAgICAgICAgICAgICAgICAgIGlmYV9pZndpdGhhZGRyKChzdHJ1Y3Qg c29ja2FkZHIgKikmZCk7CisgICAgICAgICAgICAgICAgaWYgKGlhICYmIChpYS0+aWE2X2ZsYWdz ICYgSU42X0lGRl9BTllDQVNUKSkKKwkJICAgICAgICBzcmNwID0gTlVMTDsKKyAgICAgICAgfQor CiAJaWYgKHNyY3AgPT0gTlVMTCkgewogCQlpbnQgZTsKIAkJc3RydWN0IHNvY2thZGRyX2luNiBz aW42Owo= --001636b14d02cd6f320487289c7c-- From owner-freebsd-net@FreeBSD.ORG Sat May 22 06:27:22 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 2DFBC106564A for ; Sat, 22 May 2010 06:27:22 +0000 (UTC) (envelope-from earl.lapus@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED9ED8FC1C for ; Sat, 22 May 2010 06:27:21 +0000 (UTC) Received: by iwn5 with SMTP id 5so2189451iwn.13 for ; Fri, 21 May 2010 23:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=gV57RxdEvAOb8VhEUDhdcECqcQ08cYSukpO0tln9xG4=; b=rKmlvXO4NiyvXlnbtxi5yKEuWBfG4+nFR1ifP654jf3asE8+Y/GxFb8u+wOw+4rZlP t8THMLh5Y7cre7RoJso37dOK+dGTUvV8xHoUHaOgPV3PFkkbduWkK8zKtMEYdR717x6z p5fUX/At8JBG/KaGre1bS8XSH+YvIR8YcmSVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VEO+ZqU5IoYPXsXHqV3AJ1m/e34gwCiwPk86sn2kwLRWUmidUV+E89h7O2SsJXWnjj +6l1Akus45nUo5/N3SXQfmW44Dhh4aKagM2V0sRTZXmgfBhqLotzH0/HIosZ1PXGPixI q96wHjflhlfZnvBLjU5J6SWLMqafjd7HZEMuE= MIME-Version: 1.0 Received: by 10.231.120.210 with SMTP id e18mr1816522ibr.84.1274509638091; Fri, 21 May 2010 23:27:18 -0700 (PDT) Received: by 10.231.146.65 with HTTP; Fri, 21 May 2010 23:27:18 -0700 (PDT) Date: Sat, 22 May 2010 14:27:18 +0800 Message-ID: From: Earl Lapus To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: patch review for kern/146534 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, 22 May 2010 06:27:22 -0000 Hi, I submitted a patch which fixes the problem described in the PR and it also retains this (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/icmp6.c.diff?r1=1.118;r2=1.119;f=h) fix. I also ran the TAHI (tool version REL_3_3_0; test program version V6LC_4_0_5) phase 2 NDP test scripts and they all passed. I'm not 100% sure that the patch is correct. The code used to check if the original destination address is an anycast address is a bit redundant. I hope someone from the list can have a look at it. Cheers! Earl -- There are seven words in this sentence. From owner-freebsd-net@FreeBSD.ORG Sat May 22 12:22:12 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 042D91065677; Sat, 22 May 2010 12:22:12 +0000 (UTC) (envelope-from anjali@juniper.net) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by mx1.freebsd.org (Postfix) with ESMTP id 7D38B8FC13; Sat, 22 May 2010 12:22:11 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS/fMcogCQeW/xWIWWE/5Hwvo2syv7ZpM@postini.com; Sat, 22 May 2010 05:22:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sat, 22 May 2010 05:09:32 -0700 From: Anjali Kulkarni To: "freebsd-net@freebsd.org" Date: Sat, 22 May 2010 05:09:31 -0700 Thread-Topic: Common OS/kernel code between freebsd and linux Thread-Index: AQHK+aeiVE/G37v7OkKM7CCVvJavpQ== Message-ID: <50B3A5560BA4D74CADEC55A48B4641B23D5119D0BA@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" Subject: Common OS/kernel code between freebsd and linux 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, 22 May 2010 12:22:12 -0000 Hi Folks, I am not sure the right forum to ask this question - is there any effort do= ne to find portable code between different OSes, particularly freebsd and l= inux?=20 Specifically, the networking layer could be portable between the 2 and ther= e could be some set of APIs to call into the OS specific parts. This could = be modeled as - if I want to port the networking layer or other stuff to us= erland, what set of code could reside in userspace such that that layer is = portable between OSes ? For eg, there could be an API to access mbufs or sk= buffs in freebsd or linux respectively, but the processing to be done for I= P etc could remain the same. I don't know if this is worth thinking about? = Please share your thoughts. Anjali= From owner-freebsd-net@FreeBSD.ORG Sat May 22 12:35:13 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 D05651065672 for ; Sat, 22 May 2010 12:35:13 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 18F828FC22 for ; Sat, 22 May 2010 12:35:12 +0000 (UTC) Received: (qmail 37351 invoked from network); 22 May 2010 12:35:11 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 May 2010 12:35:11 -0000 Date: Sat, 22 May 2010 14:35:11 +0200 (CEST) Message-Id: <20100522.143511.74745433.sthaug@nethelp.no> To: anjali@juniper.net From: sthaug@nethelp.no In-Reply-To: <50B3A5560BA4D74CADEC55A48B4641B23D5119D0BA@EMBX01-HQ.jnpr.net> References: <50B3A5560BA4D74CADEC55A48B4641B23D5119D0BA@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Common OS/kernel code between freebsd and linux 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, 22 May 2010 12:35:13 -0000 > I am not sure the right forum to ask this question - is there any effort done to find portable code between different OSes, particularly freebsd and linux? > Specifically, the networking layer could be portable between the 2 and there could be some set of APIs to call into the OS specific parts. This could be modeled as - if I want to port the networking layer or other stuff to userland, what set of code could reside in userspace such that that layer is portable between OSes ? For eg, there could be an API to access mbufs or skbuffs in freebsd or linux respectively, but the processing to be done for IP etc could remain the same. I don't know if this is worth thinking about? Please share your thoughts. Are you sure the Linux crowd is interested in this? As far as I know the BSD networking code has been *available* to the Linux crowd basically from day 1 - but they chose to write their own... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat May 22 15:49:44 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 F2A5A106566B; Sat, 22 May 2010 15:49:44 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id F3DCE8FC16; Sat, 22 May 2010 15:49:42 +0000 (UTC) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 39ED0CA9C12; Sat, 22 May 2010 17:32:58 +0200 (CEST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 223C24B00B7; Sat, 22 May 2010 17:32:50 +0200 (CEST) Received: from [127.0.0.1] (san94-2-78-239-228-93.fbx.proxad.net [78.239.228.93]) by smtp2-g21.free.fr (Postfix) with ESMTP; Sat, 22 May 2010 17:32:49 +0200 (CEST) Message-ID: <4BF7F90E.7060901@esigetel.fr> Date: Sat, 22 May 2010 17:32:30 +0200 From: Aman Jassal User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: sthaug@nethelp.no References: <50B3A5560BA4D74CADEC55A48B4641B23D5119D0BA@EMBX01-HQ.jnpr.net> <20100522.143511.74745433.sthaug@nethelp.no> In-Reply-To: <20100522.143511.74745433.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100522-0, 22/05/2010), Outbound message X-Antivirus-Status: Clean Cc: freebsd-net@freebsd.org, anjali@juniper.net, freebsd-hackers@freebsd.org Subject: Re: Common OS/kernel code between freebsd and linux 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, 22 May 2010 15:49:45 -0000 Hello, sthaug@nethelp.no a écrit : >> I am not sure the right forum to ask this question - is there any effort done to find portable code between different OSes, particularly freebsd and linux? >> Specifically, the networking layer could be portable between the 2 and there could be some set of APIs to call into the OS specific parts. This could be modeled as - if I want to port the networking layer or other stuff to userland, what set of code could reside in userspace such that that layer is portable between OSes ? For eg, there could be an API to access mbufs or skbuffs in freebsd or linux respectively, but the processing to be done for IP etc could remain the same. I don't know if this is worth thinking about? Please share your thoughts. >> > > Are you sure the Linux crowd is interested in this? > > As far as I know the BSD networking code has been *available* to the > Linux crowd basically from day 1 - but they chose to write their own... > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > 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" > I don't think the BSD and Linux networking code are similar enough, or that there is any effort being done to make them similar. Linux also has a few interfaces that are exclusive to it (and were written from scratch), like the Netlink socket to mention but one (although I remember Bruce Simpson saying that it would be worthwhile implementing this socket for BSD, it was some time ago...). Therefore, their networking stack probably has some features and APIs that will be a little difficult to port... I don't have a lot of experience with the Linux networking kernel, but as Steinar Haug pointed out : if the Linux community was interested in our networking code, something would have been done or in the process of being done already. If I may : Anjali, what kind of project are you working on (that would require portability between both networking code) ? ---------------- Aman Jassal Wisdom comes from experience. Experience comes from a lack of wisdom. From owner-freebsd-net@FreeBSD.ORG Sat May 22 19:50:17 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 87DE61065675 for ; Sat, 22 May 2010 19:50:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE018FC18 for ; Sat, 22 May 2010 19:50:16 +0000 (UTC) Received: by qyk11 with SMTP id 11so3694987qyk.13 for ; Sat, 22 May 2010 12:50:16 -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 :content-transfer-encoding; bh=dz8JPW5Yrfo1Pf0zQT1vRPAjQT+SF1HgbG3ttRihFSI=; b=TMFyzPXvbbTv59fKRBqPCVQay0vDoC3mR7WKARr9MYHvf9yp9H+RDMlzLCzptP71Vf oxm+e/yHDXBXvO0ByNCfnLZaj2Y0+KudA81eJwenULIthECFumlLBamg0zInxJq1UfYj Nql8tFVuk1EhT0g7ByDYg28pERIMK3ymdHUR0= 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=YgKdHH9vPSIh4oU4JVe3+WDja/WeQuKREsKm6Ame4aNR4ZVnI1cTCpE7jExYINsvFC a9ggEQ6Q9vnQZiOeNL01GwSQQdmC2+LzS++eVD+jI0vi5JqXqrK2TsFZ8jgSAv394bl6 UsMZ7MlxA4+DyhpMiEZovZXmpw24XS0i2jJuo= MIME-Version: 1.0 Received: by 10.229.213.80 with SMTP id gv16mr747816qcb.72.1274555926065; Sat, 22 May 2010 12:18:46 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Sat, 22 May 2010 12:18:45 -0700 (PDT) In-Reply-To: <50B3A5560BA4D74CADEC55A48B4641B23D5119D0BA@EMBX01-HQ.jnpr.net> References: <50B3A5560BA4D74CADEC55A48B4641B23D5119D0BA@EMBX01-HQ.jnpr.net> Date: Sat, 22 May 2010 12:18:45 -0700 Message-ID: From: Garrett Cooper To: Anjali Kulkarni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Common OS/kernel code between freebsd and linux 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, 22 May 2010 19:50:17 -0000 On Sat, May 22, 2010 at 5:09 AM, Anjali Kulkarni wrote= : > Hi Folks, > > I am not sure the right forum to ask this question - is there any effort = done to find portable code between different OSes, particularly freebsd and= linux? > Specifically, the networking layer could be portable between the 2 and th= ere could be some set of APIs to call into the OS specific parts. This coul= d be modeled as - if I want to port the networking layer or other stuff to = userland, what set of code could reside in userspace such that that layer i= s portable between OSes ? For eg, there could be an API to access mbufs or = skbuffs in freebsd or linux respectively, but the processing to be done for= IP etc could remain the same. I don't know if this is worth thinking about= ? Please share your thoughts. Hi Anjali, About the closest that you'll probably get to portability between OSes is the POSIX layer (which is just libcalls for the most part, and thus doesn't include the scope you're requesting). Even so, there are areas that *BSD is not 100% POSIX compliant, Linux is not 100% POSIX compliant, and there are other areas beyond that where stuff doesn't meet requirements like it says in the manpage documentation under Linux [ioctl(2)'s, for instance]. While this may seem like a valiant effort, I think that trying to unify a network stack and kernel code between FreeBSD and Linux would result in a `religious' war over licensing, ownership, and style. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Sat May 22 22:37:28 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 9E17E106564A for ; Sat, 22 May 2010 22:37:28 +0000 (UTC) (envelope-from brunner@nic-naa.net) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by mx1.freebsd.org (Postfix) with ESMTP id 5BCDE8FC14 for ; Sat, 22 May 2010 22:37:28 +0000 (UTC) Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o4MLx4Vt073180 for ; Sat, 22 May 2010 17:59:05 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-ID: <4BF85740.1090401@nic-naa.net> Date: Sat, 22 May 2010 18:14:24 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <50B3A5560BA4D74CADEC55A48B4641B23D5119D0BA@EMBX01-HQ.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Common OS/kernel code between freebsd and linux 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, 22 May 2010 22:37:28 -0000 Howdy Anjali, I was paid for over a year to read libc implementations and the supporting kernel code, and wrote XPG/1 as a specification of what my employers at the time, Bull, ICL, Siemons, Olivetti and Nixdorff, circa 1986, were intending to implement, from their various v7, PWB, SysIII and SySV starting points. I was paid for over a year to sort of do the same thing and co-wrote XPG/4.2 as a specification of what the big installed base thought were the syntax and semantics of the kernel entry points and library routines, even commands, that each assumed was present on a host operating system. What you propose is a butt load of work, in effect, the academic exercise of specification of an abstract platform and its interface to a network stack. So who would pay? The correct answer should be of the form "the cost of not doing this to some parties who can (a) become aware of this, and (b) pay, is greater than the cost of doing it. So how much code does either camp care about being portable, and isn't the best answer to "portability" simply tossing another pizza box at the problem and running the application native? You can have fun, but you should have realistic expectations about the uptake of your work by working programmers and program managers and product planners and corporate strategic platform planners. Eric