From owner-freebsd-net@FreeBSD.ORG Sun Aug 9 04:27:18 2009 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 C316E1065670 for ; Sun, 9 Aug 2009 04:27:18 +0000 (UTC) (envelope-from pz-freebsd-net@ziemba.us) Received: from ziemba.us (208-106-105-148.dsl.static.sonic.net [208.106.105.148]) by mx1.freebsd.org (Postfix) with ESMTP id 997D98FC22 for ; Sun, 9 Aug 2009 04:27:18 +0000 (UTC) Received: from hairball.ziemba.us (localhost.ziemba.us [127.0.0.1]) by hairball.ziemba.us (8.14.3/8.14.3) with ESMTP id n7942OiE067127 for ; Sat, 8 Aug 2009 21:02:24 -0700 (PDT) (envelope-from pz-freebsd-net@ziemba.us) Received: (from mailnull@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id n7942Oc7067126 for freebsd-net@freebsd.org; Sat, 8 Aug 2009 21:02:24 -0700 (PDT) (envelope-from pz-freebsd-net@ziemba.us) X-Authentication-Warning: hairball.ziemba.us: mailnull set sender to pz-freebsd-net@ziemba.us using -f Received: (from news@localhost) by hairball.ziemba.us (8.14.3/8.14.3/Submit) id n7942NS4067061 for treehouse-mail-freebsd-net@hairball.treehouse.napa.ca.us; Sat, 8 Aug 2009 21:02:23 -0700 (PDT) (envelope-from news) From: "G. Paul Ziemba" To: freebsd-net@freebsd.org Date: Sun, 9 Aug 2009 04:02:23 +0000 (UTC) Message-id: References: <4A7A886B.3060900@elischer.org> <429535.52145.qm@web62106.mail.re1.yahoo.com> Errors-to: "G. Paul Ziemba" Subject: Re: How to port/build TCP/IP Stack. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: paul+usenet@w6yx.stanford.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 04:27:18 -0000 boseatjntu@yahoo.com (bose vemuri) writes: >Actually we need to implement TCP/IP stack on B >oot Loader(MIPS). We are planning to port FreeBSD TCP/IP Stack. Please help > me out how can i proceed further. An experienced developer could port IP, UDP, and TCP to an existing embedded system that already has an ethernet (or whatever lower layer you need) driver in a few weeks. You'll need to grab appropriate files from /usr/src/sys/netinet as well as the socket and mbuf related files from /usr/src/sys/kern and then connect it to the network driver for your physical interface. -- G. Paul Ziemba FreeBSD unix: 9:01PM up 13:05, 11 users, load averages: 0.02, 0.07, 0.07 From owner-freebsd-net@FreeBSD.ORG Sun Aug 9 09:49:24 2009 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 68C3E1065673; Sun, 9 Aug 2009 09:49:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2A28FC1A; Sun, 9 Aug 2009 09:49:24 +0000 (UTC) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n799nOIF082246; Sun, 9 Aug 2009 09:49:24 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n799nN3K082156; Sun, 9 Aug 2009 09:49:23 GMT (envelope-from bms) Date: Sun, 9 Aug 2009 09:49:23 GMT Message-Id: <200908090949.n799nN3K082156@freefall.freebsd.org> To: netch@segfault.kiev.ua, bms@FreeBSD.org, freebsd-net@FreeBSD.org From: bms@FreeBSD.org Cc: Subject: Re: kern/136803: [sctp] [panic] Kernel panic and hanging on using SCTP 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, 09 Aug 2009 09:49:24 -0000 Synopsis: [sctp] [panic] Kernel panic and hanging on using SCTP State-Changed-From-To: open->closed State-Changed-By: bms State-Changed-When: Sun 9 Aug 2009 09:49:09 UTC State-Changed-Why: I committed the fix. Oops http://www.freebsd.org/cgi/query-pr.cgi?pr=136803 From owner-freebsd-net@FreeBSD.ORG Sun Aug 9 12:09:31 2009 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 9FB3E106564A for ; Sun, 9 Aug 2009 12:09:31 +0000 (UTC) (envelope-from ady@ady.ro) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 240238FC08 for ; Sun, 9 Aug 2009 12:09:30 +0000 (UTC) Received: by ewy2 with SMTP id 2so2489401ewy.43 for ; Sun, 09 Aug 2009 05:09:30 -0700 (PDT) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.210.110.2 with SMTP id i2mr1729944ebc.31.1249817902980; Sun, 09 Aug 2009 04:38:22 -0700 (PDT) In-Reply-To: <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> Date: Sun, 9 Aug 2009 13:38:22 +0200 X-Google-Sender-Auth: 2e5e3ee8c2bbd032 Message-ID: <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> From: Adrian Penisoara To: Denis Berezhnoy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kevent behavior with TCP socket 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, 09 Aug 2009 12:09:31 -0000 Hi, On Sat, Aug 8, 2009 at 10:42 AM, Denis Berezhnoy wrote: > Hi, > > Sorry for my previous post it was completely unclear I believe. Here is > problem description in pure C. Can you please take a look at the code > below: > > #include > #include > #include > #include > #include > #include > #include > > #include > #include > #include > #include > > > > int main(int argc, char *argv[]) > { > struct sockaddr_in addr; > struct sockaddr_in addr2; > > int sd, cd, port, sRet; > > int sHandle; > int sEventNum = 0; > > struct kevent sChange; > struct kevent sEvent; > > struct timespec *sTimeoutPtr; > struct timespec sTimeout; > > struct timeval sTimeVal1 = {0,0}; > struct timeval sTimeVal2 = {0,0}; > > printf("Socket test start\n"); > > sd = socket(PF_INET, SOCK_STREAM, 0); > > if ( sd < 0 ) > { > printf("Server socket error\n"); > return 0; > } > > port = htons(10000); > > > memset(&addr, 0, sizeof(addr)); > addr.sin_family = AF_INET; > addr.sin_port = port; > addr.sin_addr.s_addr = htonl(INADDR_ANY); > > if ( bind(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0 ) > > { > printf ("Server bind errror\n"); > return 0; > } > > > > if ( listen(sd, 1) != 0 ) > { > printf ("Server listen error \n"); > return 0; > } > > > cd = socket(PF_INET, SOCK_STREAM, 0); > > if ( cd < 0 ) > { > printf("Client socket error\n"); > return 0; > } > > sRet = fcntl(cd, F_GETFL, 0); > > sRet |= O_NONBLOCK; > > sRet = fcntl(cd, F_SETFL, sRet); > > if (sRet < 0) > { > printf("can not set non block\n"); > } > > port = htons(10000); > > memset(&addr2, 0, sizeof(addr2)); /* Clear struct */ > addr2.sin_family = AF_INET; /* Internet/IP */ > addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */ > addr2.sin_port = port; /* server port */ > > /* Establish connection */ > > if ((sRet = connect(cd, > (struct sockaddr *) &addr2, > sizeof(addr2))) < 0) > { > > printf("Failed to connect with server %d\n", errno); > > } > > > sHandle = kqueue(); > > > if (sHandle == -1) > { > printf("Poll can not created queue\n"); > } > > sTimeout.tv_sec = 0; > sTimeout.tv_nsec = 100000000;; > > EV_SET(&sChange, cd, EVFILT_WRITE, EV_ADD,0, 0, 0); > > > gettimeofday(&sTimeVal1, NULL); > > sEventNum = kevent(sHandle, > &sChange, > 1, > &sEvent, > 1, > &sTimeout); > > gettimeofday(&sTimeVal2, NULL); > > printf ("Kevent event num %d wait time %d \n", sEventNum, sTimeVal2.tv_usec > - sTimeVal1.tv_usec); > > if (sEventNum == 1) > { > printf ("Event filter %d flag %d data %d \n", sEvent.filter, sEvent.flags, > sEvent.data); > } > > close(sHandle); > > close(cd); > > close(sd); > > printf("Socket test end\n"); > } > > Program output > > Socket test start > Failed to connect with server 36 > Kevent event num 1 wait time 26 > Event filter -2 flag 0 data 43008 > Socket test end > > The question is why kevent returns 1 event when server does not accept > connections from clients. > Question: is there something listening on your loopback address (127.0.0.1) or all addresses at port 10000 (sockstat -4 output should be evident) ? If not, have you also tested with something listening on that address ? If there is nothing to connect onto the loopback address then the connection will immediately fail. Then I believe kevent should return with a failure filter flag set. One problem I see is that you are checking the action flags (kevent.flags) instead of the filter flags (kevent.fflags). Please re-run checking the sEvent.fflags field and compare with values in and let us/me know what do you get. Regards, Adrian Penisoara EnterpriseBSD From owner-freebsd-net@FreeBSD.ORG Sun Aug 9 12:50:27 2009 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 79F411065675 for ; Sun, 9 Aug 2009 12:50:27 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 69D878FC2B for ; Sun, 9 Aug 2009 12:50:27 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n79CoRHJ056654 for ; Sun, 9 Aug 2009 12:50:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n79CoRTv056645; Sun, 9 Aug 2009 12:50:27 GMT (envelope-from gnats) Date: Sun, 9 Aug 2009 12:50:27 GMT Message-Id: <200908091250.n79CoRTv056645@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Reko Turja Cc: Subject: Re: kern/129352: [xl] [patch] xl0 watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Reko Turja List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 12:50:28 -0000 The following reply was made to PR kern/129352; it has been noted by GNATS. From: Reko Turja To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129352: [xl] [patch] xl0 watchdog timeout Date: Sun, 9 Aug 2009 14:56:44 +0300 (EEST) After running the patch from this PR for some days I still got some watchdog timeouts. As another approach, I'm trying the driver revision 1.4 from /src/sys/dev/xl/ (8.x sourcetree) which compiled clean on my system with sources updated as of today. My uname -a: FreeBSD xxx.org 7.2-STABLE FreeBSD 7.2-STABLE #10: Sun Aug 9 14:13:47 EEST 2009 root@xxx.org:/usr/obj/usr/src/sys/MORIA i386 The reason for trying 1.4 was the commit message: SVN rev 191345 on 2009-04-21 00:42:11Z by yongari To make it easy whether xl(4) missed Tx completion interrupt check number of queued packets in watchdog timeout handler. If there are no queued packets just print a informational message and return without resetting controller. Also fix to invoke correct Tx completion handler as 3C905B needs different handler. I will send a followup after testing the driver for a while - if it seems to work, is there any chance of backporting it for 7.x? -Reko From owner-freebsd-net@FreeBSD.ORG Sun Aug 9 14:13:53 2009 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 C74EA106566B for ; Sun, 9 Aug 2009 14:13:53 +0000 (UTC) (envelope-from alireza.torabi@gmail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 610BE8FC19 for ; Sun, 9 Aug 2009 14:13:53 +0000 (UTC) Received: by ewy2 with SMTP id 2so2520326ewy.43 for ; Sun, 09 Aug 2009 07:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=GFq1lfU6d7xAOVVaPnd/Seyz8xcY2r6VMWUVfXxEt0c=; b=KpUSv4mf2p2UszBqoZErM6s/PT3IjMINtKqWNeA5GoMrfSpWT1G68FQoNhuZrWj+mS jCd48Mv6dOj3Y7SCFR+NYkqnO6BDo8JN8aacLziNEQFVBf0iEslKkOdrAAraOSxFrqJf a7Xp8amfDc11m42rO3ClwRfbI7KPGphxQzmPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=immbeRCKmskM3K8xUCDS4rXm6rpSxIbp/+ySiQy8njdoxlMUnM4+QSqaaCoZqLO2mu mfAsqlRJfjX9ekImBghKX5eipoVNhZgNhgtE0IcxYjW2xucYLZxeWXhd5bPWBuemTwOv bNsvyeHfRduUpbrYFk7eNac/9umyTqj4x5Vw4= MIME-Version: 1.0 Received: by 10.216.90.76 with SMTP id d54mr676352wef.55.1249825280407; Sun, 09 Aug 2009 06:41:20 -0700 (PDT) Date: Sun, 9 Aug 2009 14:41:20 +0100 Message-ID: From: Alireza Torabi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: 8. Current and Intel 5100 AGN wifi 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, 09 Aug 2009 14:13:54 -0000 folks, Can anyone please shet any lights on this. are iwn & iwnfw going to support 5100 agn wifi? I've updated mine to 8. Current with iwn & iwnfw and still not going anywhere with the card. Thanks From owner-freebsd-net@FreeBSD.ORG Sun Aug 9 16:27:02 2009 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 69D60106567E; Sun, 9 Aug 2009 16:27:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 418F48FC28; Sun, 9 Aug 2009 16:27:02 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n79GR2mv021737; Sun, 9 Aug 2009 16:27:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n79GR2lM021733; Sun, 9 Aug 2009 16:27:02 GMT (envelope-from linimon) Date: Sun, 9 Aug 2009 16:27:02 GMT Message-Id: <200908091627.n79GR2lM021733@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/137592: [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on network 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, 09 Aug 2009 16:27:02 -0000 Synopsis: [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on network Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 9 16:26:52 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137592 From owner-freebsd-net@FreeBSD.ORG Mon Aug 10 03:17:23 2009 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 67ACC106566B for ; Mon, 10 Aug 2009 03:17:23 +0000 (UTC) (envelope-from denis.berezhnoy@gmail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 90EF28FC19 for ; Mon, 10 Aug 2009 03:17:22 +0000 (UTC) Received: by ewy2 with SMTP id 2so2737087ewy.43 for ; Sun, 09 Aug 2009 20:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DHz99I1b6595t2YIX6kPSjHJUOMxnMhpm0bS0th5EWU=; b=bPWF5ncLWDgpn4mFaAngh8OSZuokXjdGQw0xkPbwNSxAqdCVMMJJUMNhvDf+5wEUDK BYz4a4icwGL/XrhB4yAozCUfxwObtidofA6g0wy4Xqjf9V6gDXXC0uiysGrdeoVyZ+pM nl1d6BIVllgRQ9DrJUGzAzjsfZCkswfamkqCc= 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=SFMQ1d7/Ngdtf6hqtzua1K622L5ZP9GojG+3WTZjJwoKJRsfahtx82Emb8nCpIY4Fq dc4c9v0oCDu91LjXo0p7XQ5qxGmKMjPbUAvbVPHqYoUH5F/URcuk6+Z3xLZr0+42bFjZ i8/7BV7qszkidq2GLCXC64IdSEFfVDbL/qD8w= MIME-Version: 1.0 Received: by 10.210.115.15 with SMTP id n15mr2502988ebc.2.1249874241514; Sun, 09 Aug 2009 20:17:21 -0700 (PDT) In-Reply-To: <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> Date: Mon, 10 Aug 2009 12:17:21 +0900 Message-ID: <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> From: Denis Berezhnoy To: Adrian Penisoara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kevent behavior with TCP socket 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, 10 Aug 2009 03:17:23 -0000 Hi Adrian, Thank for your answer! I checked that nobody listens for loopback address: [denis@freebsd ~]$ sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS denis sshd 95390 3 tcp4 192.168.1.103:22 192.168.11.26:53616 root sshd 95387 3 tcp4 192.168.1.103:22 192.168.11.26:53616 denis sshd 95324 3 tcp4 192.168.1.103:22 192.168.11.26:53608 root sshd 95321 3 tcp4 192.168.1.103:22 192.168.11.26:53608 root sshd 8149 4 tcp4 *:22 *:* root inetd 870 5 tcp4 *:21 *:* root inetd 870 6 tcp4 *:23 *:* root sendmail 821 4 tcp4 127.0.0.1:25 *:* root syslogd 689 7 udp4 *:514 *:* [denis@freebsd ~]$ I printed out fflags. Here is the result: Kevent event num 1 wait time 46 Event filter -2 flag 0 filter flags 0 data 43008 When I comment out the part of the code that listens socket then I have the following output: Kevent event num 1 wait time 23 Event filter -2 flag 32768 filter flags 61 data 32768 61 is ECONNREFUSED And more when I make loopback address listening and try to connect it I still get the same output: Socket test start Failed to connect with server 36 Kevent event num 1 wait time 23 Event filter -2 flag 0 filter flags 0 data 43008 Socket test end but connection is actually accepted. I am totally confused here. Best regards, Denis 2009/8/9 Adrian Penisoara > Hi, > > > On Sat, Aug 8, 2009 at 10:42 AM, Denis Berezhnoy < > denis.berezhnoy@gmail.com> wrote: > >> Hi, >> >> Sorry for my previous post it was completely unclear I believe. Here is >> problem description in pure C. Can you please take a look at the code >> below: >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #include >> #include >> #include >> #include >> >> >> >> int main(int argc, char *argv[]) >> { >> struct sockaddr_in addr; >> struct sockaddr_in addr2; >> >> int sd, cd, port, sRet; >> >> int sHandle; >> int sEventNum = 0; >> >> struct kevent sChange; >> struct kevent sEvent; >> >> struct timespec *sTimeoutPtr; >> struct timespec sTimeout; >> >> struct timeval sTimeVal1 = {0,0}; >> struct timeval sTimeVal2 = {0,0}; >> >> printf("Socket test start\n"); >> >> sd = socket(PF_INET, SOCK_STREAM, 0); >> >> if ( sd < 0 ) >> { >> printf("Server socket error\n"); >> return 0; >> } >> >> port = htons(10000); >> >> >> memset(&addr, 0, sizeof(addr)); >> addr.sin_family = AF_INET; >> addr.sin_port = port; >> addr.sin_addr.s_addr = htonl(INADDR_ANY); >> >> if ( bind(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0 ) >> >> { >> printf ("Server bind errror\n"); >> return 0; >> } >> >> >> >> if ( listen(sd, 1) != 0 ) >> { >> printf ("Server listen error \n"); >> return 0; >> } >> >> >> cd = socket(PF_INET, SOCK_STREAM, 0); >> >> if ( cd < 0 ) >> { >> printf("Client socket error\n"); >> return 0; >> } >> >> sRet = fcntl(cd, F_GETFL, 0); >> >> sRet |= O_NONBLOCK; >> >> sRet = fcntl(cd, F_SETFL, sRet); >> >> if (sRet < 0) >> { >> printf("can not set non block\n"); >> } >> >> port = htons(10000); >> >> memset(&addr2, 0, sizeof(addr2)); /* Clear struct */ >> addr2.sin_family = AF_INET; /* Internet/IP */ >> addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */ >> addr2.sin_port = port; /* server port */ >> >> /* Establish connection */ >> >> if ((sRet = connect(cd, >> (struct sockaddr *) &addr2, >> sizeof(addr2))) < 0) >> { >> >> printf("Failed to connect with server %d\n", errno); >> >> } >> >> >> sHandle = kqueue(); >> >> >> if (sHandle == -1) >> { >> printf("Poll can not created queue\n"); >> } >> >> sTimeout.tv_sec = 0; >> sTimeout.tv_nsec = 100000000;; >> >> EV_SET(&sChange, cd, EVFILT_WRITE, EV_ADD,0, 0, 0); >> >> >> gettimeofday(&sTimeVal1, NULL); >> >> sEventNum = kevent(sHandle, >> &sChange, >> 1, >> &sEvent, >> 1, >> &sTimeout); >> >> gettimeofday(&sTimeVal2, NULL); >> >> printf ("Kevent event num %d wait time %d \n", sEventNum, >> sTimeVal2.tv_usec >> - sTimeVal1.tv_usec); >> >> if (sEventNum == 1) >> { >> printf ("Event filter %d flag %d data %d \n", sEvent.filter, sEvent.flags, >> sEvent.data); >> } >> >> close(sHandle); >> >> close(cd); >> >> close(sd); >> >> printf("Socket test end\n"); >> } >> >> Program output >> >> Socket test start >> Failed to connect with server 36 >> Kevent event num 1 wait time 26 >> Event filter -2 flag 0 data 43008 >> Socket test end >> >> The question is why kevent returns 1 event when server does not accept >> connections from clients. >> > > Question: is there something listening on your loopback address > (127.0.0.1) or all addresses at port 10000 (sockstat -4 output should be > evident) ? If not, have you also tested with something listening on that > address ? > > If there is nothing to connect onto the loopback address then the > connection will immediately fail. Then I believe kevent should return with a > failure filter flag set. > > One problem I see is that you are checking the action flags > (kevent.flags) instead of the filter flags (kevent.fflags). Please re-run > checking the sEvent.fflags field and compare with values in > and let us/me know what do you get. > > Regards, > Adrian Penisoara > EnterpriseBSD > From owner-freebsd-net@FreeBSD.ORG Mon Aug 10 07:31:45 2009 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 DDE15106566C for ; Mon, 10 Aug 2009 07:31:45 +0000 (UTC) (envelope-from ady@ady.ro) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 3CFC98FC20 for ; Mon, 10 Aug 2009 07:31:44 +0000 (UTC) Received: by ewy2 with SMTP id 2so2806051ewy.43 for ; Mon, 10 Aug 2009 00:31:43 -0700 (PDT) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.211.201.8 with SMTP id d8mr4857355ebq.7.1249889503878; Mon, 10 Aug 2009 00:31:43 -0700 (PDT) In-Reply-To: <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> Date: Mon, 10 Aug 2009 09:31:43 +0200 X-Google-Sender-Auth: 9c37dd54d69672e4 Message-ID: <78cb3d3f0908100031k73301f88xef1bc9bf04730d09@mail.gmail.com> From: Adrian Penisoara To: Denis Berezhnoy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kevent behavior with TCP socket 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, 10 Aug 2009 07:31:46 -0000 Hi, On Mon, Aug 10, 2009 at 5:17 AM, Denis Berezhnoy wrote: > Hi Adrian, > Thank for your answer! I checked that nobody listens for loopback address: > > [denis@freebsd ~]$ sockstat -4 > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > > denis sshd 95390 3 tcp4 192.168.1.103:22 > 192.168.11.26:53616 > root sshd 95387 3 tcp4 192.168.1.103:22 > 192.168.11.26:53616 > denis sshd 95324 3 tcp4 192.168.1.103:22 > 192.168.11.26:53608 > root sshd 95321 3 tcp4 192.168.1.103:22 > 192.168.11.26:53608 > root sshd 8149 4 tcp4 *:22 *:* > root inetd 870 5 tcp4 *:21 *:* > root inetd 870 6 tcp4 *:23 *:* > root sendmail 821 4 tcp4 127.0.0.1:25 *:* > root syslogd 689 7 udp4 *:514 *:* > [denis@freebsd ~]$ > > > I printed out fflags. Here is the result: > > Kevent event num 1 wait time 46 > Event filter -2 flag 0 filter flags 0 data 43008 > > > When I comment out the part of the code that listens socket then I have the > following output: > > Kevent event num 1 wait time 23 > Event filter -2 flag 32768 filter flags 61 data 32768 > > > 61 is ECONNREFUSED > > > And more when I make loopback address listening and try to connect it I > still get the same output: > > Socket test start > Failed to connect with server 36 > Kevent event num 1 wait time 23 > Event filter -2 flag 0 filter flags 0 data 43008 > Socket test end > > but connection is actually accepted. I am totally confused here. > Well, actually it's very much evident: * When you don't make the listen() first, then the connection is correctly reported as refused * When you make the listen() on the INADDR_ANY then you will open port 10000 on all local IP addresses, _including_ the loopback address -- that's why the client connect() succeeds and kevent reports a success event. This is an expected behavior. Try to bind the sd descriptor to another port than the one used to connect onto the loopback address and you will see the connection being refused. Regards, Adrian EnterpriseBSD From owner-freebsd-net@FreeBSD.ORG Mon Aug 10 11:07:01 2009 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 86FD1106564A for ; Mon, 10 Aug 2009 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 74A078FC1E for ; Mon, 10 Aug 2009 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7AB71BC025244 for ; Mon, 10 Aug 2009 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7AB70vT025240 for freebsd-net@FreeBSD.org; Mon, 10 Aug 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Aug 2009 11:07:00 GMT Message-Id: <200908101107.n7AB70vT025240@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, 10 Aug 2009 11:07:02 -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/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/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net [ath] atheros AR9285 not recognised 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 kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after 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/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. 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/134369 net [route] [ip6] IPV6 in Head broken for routing table up 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/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 o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem 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 [fib] [patch] allow to setup fib for service running f 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/132625 net [iwn] iwn drivers don't support setting country 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 conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla 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/131162 net [ath] Atheros driver bugginess and kernel crashes 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/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo 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 kern/129135 net [vge] vge driver on a VIA mini-ITX not working 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/128884 net [msk] if_msk page fault while in kernel mode 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/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami 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/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode 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/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov 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/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o 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/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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 [reg 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] ppp(8): fix local stack overflow in ppp 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 bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output 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/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic 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/116328 net [bge]: Solid hang with bge interface 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/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/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 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 s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress 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/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE 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/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K 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/64556 net [sis] if_sis short cable fix problems with NetGear FA3 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 319 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 10 15:36:15 2009 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 76784106567B; Mon, 10 Aug 2009 15:36:15 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF7B8FC47; Mon, 10 Aug 2009 15:36:15 +0000 (UTC) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7AFaFj9045955; Mon, 10 Aug 2009 15:36:15 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7AFaFnB045951; Mon, 10 Aug 2009 15:36:15 GMT (envelope-from remko) Date: Mon, 10 Aug 2009 15:36:15 GMT Message-Id: <200908101536.n7AFaFnB045951@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: misc/137641: Various problems with "vlan_device.vlan_id" syntax 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, 10 Aug 2009 15:36:16 -0000 Synopsis: Various problems with "vlan_device.vlan_id" syntax Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Aug 10 15:36:01 UTC 2009 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=137641 From owner-freebsd-net@FreeBSD.ORG Mon Aug 10 18:40:03 2009 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 DFE42106564A for ; Mon, 10 Aug 2009 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CEDFC8FC1E for ; Mon, 10 Aug 2009 18:40:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7AIe39p084076 for ; Mon, 10 Aug 2009 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7AIe3Zf084075; Mon, 10 Aug 2009 18:40:03 GMT (envelope-from gnats) Date: Mon, 10 Aug 2009 18:40:03 GMT Message-Id: <200908101840.n7AIe3Zf084075@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Artis Caune Cc: Subject: Re: bin/137641: ifconfig(8): various problems with "vlan_device.vlan_id" syntax X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Artis Caune List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:40:04 -0000 The following reply was made to PR bin/137641; it has been noted by GNATS. From: Artis Caune To: bug-followup@FreeBSD.org, vladimir.shebaldenkov@gmail.com Cc: Subject: Re: bin/137641: ifconfig(8): various problems with "vlan_device.vlan_id" syntax Date: Mon, 10 Aug 2009 21:33:20 +0300 --0016e659fbf0f99c790470cdd17e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, attached patch should fix automatic loading of if_vlan when creating interface as device.vlan_id and vlan module is not loaded. -- Artis Caune Everything should be made as simple as possible, but not simpler. --0016e659fbf0f99c790470cdd17e Content-Type: text/plain; charset=US-ASCII; name="device.vlan_id.patch.txt" Content-Disposition: attachment; filename="device.vlan_id.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fy7jgzm40 SW5kZXg6IGlmY29uZmlnLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaWZjb25maWcuYwkocmV2aXNpb24gMTk2 MDQ3KQorKysgaWZjb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAtOTk4LDYgKzk5OCwxMCBAQAog CQkJYnJlYWs7CiAJCX0KIAorCS8qIHRyeSB0byBsb2FkIHZsYW4gbW9kdWxlIGlmIGludGVyZmFj ZSBuYW1lIGlzIGRldmljZS52bGFuX2lkICovCisJaWYgKGluZGV4KG5hbWUsICcuJykgIT0gTlVM TCkKKwkJc3RybGNweShpZm5hbWUsICJ2bGFuIiwgc2l6ZW9mKGlmbmFtZSkpOworCiAJLyogdHVy biBpbnRlcmZhY2UgYW5kIHVuaXQgaW50byBtb2R1bGUgbmFtZSAqLwogCXN0cmNweShpZmtpbmQs ICJpZl8iKTsKIAlzdHJsY3B5KGlma2luZCArIE1PRF9QUkVGSVhfTEVOLCBpZm5hbWUsCg== --0016e659fbf0f99c790470cdd17e-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 10 18:52:28 2009 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 66B19106566B for ; Mon, 10 Aug 2009 18:52:28 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id E08E58FC16 for ; Mon, 10 Aug 2009 18:52:27 +0000 (UTC) Received: by bwz2 with SMTP id 2so2119650bwz.43 for ; Mon, 10 Aug 2009 11:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=mSMS4AjOEdfTxehN+ytobg9ZrZsvf737Jv24AOIDNY4=; b=NxGk8CLJe1iQhZC7xMHkK7a6oLD3XB+AHfeqjuii0SpGljUf3e7Yi6W6Igl95m6TAM rRif9wqLA/VvsbS6BEKpSEhj30/bF+e7pX85eo1d5UJ3A0GUTv3WtcfLT5q9zWVCyLN6 D3Db7/TfGYUKGT0T3qgBPs2EI7A6eYdz4FVYQ= 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 :content-type; b=TH/I+GOkPIVRjZ8g8HyXVTZvs290lof3zF5GnNPQ1upr/++4HCQaQ6haikbHNxEE87 DilbgSWq5Ppe1ZMai10iBexboffcnEy2UIMynBHpcpNQEs0GmPq8AqVI57w/SvShGJkt 4E3unFMr09S7bX8h+OX4VDbOQyhimk7b6h9TQ= MIME-Version: 1.0 Received: by 10.103.197.17 with SMTP id z17mr1978419mup.131.1249930346481; Mon, 10 Aug 2009 11:52:26 -0700 (PDT) In-Reply-To: <200908101840.n7AIe3Zf084075@freefall.freebsd.org> References: <200908101840.n7AIe3Zf084075@freefall.freebsd.org> Date: Mon, 10 Aug 2009 21:52:26 +0300 Message-ID: <9e20d71e0908101152tcaf4cc3p83ff6de3ac1f1280@mail.gmail.com> From: Artis Caune To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=0016e659fc5a4bc83f0470ce16ae Subject: Re: bin/137641: ifconfig(8): various problems with "vlan_device.vlan_id" syntax 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, 10 Aug 2009 18:52:28 -0000 --0016e659fc5a4bc83f0470ce16ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2009/8/10 Artis Caune : > The following reply was made to PR bin/137641; it has been noted by GNATS= . > > =C2=A0Hi, > > =C2=A0attached patch should fix automatic loading of if_vlan when creatin= g > =C2=A0interface as device.vlan_id and vlan module is not loaded. Here is a patch. --=20 Artis Caune Everything should be made as simple as possible, but not simpler. --0016e659fc5a4bc83f0470ce16ae Content-Type: text/plain; charset=US-ASCII; name="device.vlan_id.patch.txt" Content-Disposition: attachment; filename="device.vlan_id.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fy7k826w0 SW5kZXg6IGlmY29uZmlnLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaWZjb25maWcuYwkocmV2aXNpb24gMTk2 MDQ3KQorKysgaWZjb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAtOTk4LDYgKzk5OCwxMCBAQAog CQkJYnJlYWs7CiAJCX0KIAorCS8qIHRyeSB0byBsb2FkIHZsYW4gbW9kdWxlIGlmIGludGVyZmFj ZSBuYW1lIGlzIGRldmljZS52bGFuX2lkICovCisJaWYgKGluZGV4KG5hbWUsICcuJykgIT0gTlVM TCkKKwkJc3RybGNweShpZm5hbWUsICJ2bGFuIiwgc2l6ZW9mKGlmbmFtZSkpOworCiAJLyogdHVy biBpbnRlcmZhY2UgYW5kIHVuaXQgaW50byBtb2R1bGUgbmFtZSAqLwogCXN0cmNweShpZmtpbmQs ICJpZl8iKTsKIAlzdHJsY3B5KGlma2luZCArIE1PRF9QUkVGSVhfTEVOLCBpZm5hbWUsCg== --0016e659fc5a4bc83f0470ce16ae-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 01:15:13 2009 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 363871065672 for ; Wed, 12 Aug 2009 01:15:13 +0000 (UTC) (envelope-from denis.berezhnoy@gmail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 602238FC60 for ; Wed, 12 Aug 2009 01:15:12 +0000 (UTC) Received: by ewy2 with SMTP id 2so4122364ewy.43 for ; Tue, 11 Aug 2009 18:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=snoz97C8fxu0xEJa3Jl6KlC0nSkDger2edLK0QrSKU0=; b=O0aDkumcKbITE2++WoGm59tsW2OqA86EsAPzQOGFLavFnPy9DpJaou52B0jODDt9li lvLwMZ0Acs+g5XUVEX5PxEwb0tvR3CzNIA1OpRL6dkWtwz7QVkI3N/wfZXIdNPRVGTmP sYi1RYG22S/bgpONvX9dsRZuGWOAWnhgfPoHc= 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=FubsHHelqeUou+cXelOVFup8ncNZK5mDili0havIvgf9MqzEVEv66rNgeIMTUojb3Y zyw05kKEVji8wVf1RdfLaQ8w8G3sspkP5BdJbleRdtzqpFMUY7S8iGQh4MM0PLgFG3Cd 06Tgu2p6q8S8HC+POGXuWRQVj04KbRlB/hh3k= MIME-Version: 1.0 Received: by 10.210.81.3 with SMTP id e3mr1730643ebb.18.1250039711246; Tue, 11 Aug 2009 18:15:11 -0700 (PDT) In-Reply-To: <78cb3d3f0908100031k73301f88xef1bc9bf04730d09@mail.gmail.com> References: <18b5e36e0908060115g76a56da3qb23fdd208e7c4a4c@mail.gmail.com> <18b5e36e0908080142o5914903n335ebae17e82e985@mail.gmail.com> <78cb3d3f0908090438n63eefbb2t462385e8fcfb2395@mail.gmail.com> <18b5e36e0908092017o1d014262t45ef7cab7df098f0@mail.gmail.com> <78cb3d3f0908100031k73301f88xef1bc9bf04730d09@mail.gmail.com> Date: Wed, 12 Aug 2009 10:15:11 +0900 Message-ID: <18b5e36e0908111815i6fe3322cu36fe6093097ce59f@mail.gmail.com> From: Denis Berezhnoy To: Adrian Penisoara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: kevent behavior with TCP socket 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, 12 Aug 2009 01:15:13 -0000 Hi Adrian, Thank you very much for clarification! Now it is clear for me. I have the last question. When I try to make mulltiple connections (loop over 100 client sockets) and check status of sockets by getsockopt then for the first couple connections everything seems OK, no error code but for the following connections I got socket error 54 ECONNRESET. I am concerned about it since I expected to get ECONNREFUSED. Here is code snippet (client thread the server part which listens socket is the same as in my previous example) and output void *ThreadFunc(void *arg) { struct sockaddr_in addr2; int cd[100], port; int sRet, i; int sHandle; int sEventNum = 0; struct kevent sChange; struct kevent sEvent; struct timespec *sTimeoutPtr; struct timespec sTimeout; struct timeval sTimeVal1 = {0,0}; struct timeval sTimeVal2 = {0,0}; for (i=0;i < 100; i++) { cd[i] = socket(AF_INET, SOCK_STREAM, 0); if ( cd[i] < 0 ) { printf("Client socket error\n"); return 0; } sRet = fcntl(cd[i], F_GETFL, 0); sRet |= O_NONBLOCK; sRet = fcntl(cd[i], F_SETFL, sRet); if (sRet < 0) { printf("can not set non block\n"); } port = htons(10000); memset(&addr2, 0, sizeof(addr2)); /* Clear struct */ addr2.sin_family = AF_INET; /* Internet/IP */ addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */ addr2.sin_port = port; /* server port */ /* Establish connection */ if ((sRet = connect(cd[i], (struct sockaddr *) &addr2, sizeof(addr2))) < 0) { printf("Failed to connect with server %d\n", errno); } sHandle = kqueue(); if (sHandle == -1) { printf("Poll can not created queue\n"); } sTimeout.tv_sec = 0; sTimeout.tv_nsec = 100000000;; EV_SET(&sChange, cd[i], EVFILT_WRITE, EV_ADD,0, 0, 0); gettimeofday(&sTimeVal1, NULL); sEventNum = kevent(sHandle, &sChange, 1, &sEvent, 1, &sTimeout); gettimeofday(&sTimeVal2, NULL); printf ("Kevent event num %d wait time %d \n", sEventNum, sTimeVal2.tv_usec - sTimeVal1.tv_usec); if (sEventNum == 1) { int aOptVal = 0; int aOptLen = sizeof(aOptVal); printf ("Event filter %d flag %d filter flags %d data %d \n", sEvent.filter, sEvent.flags, sEvent.fflags, sEvent.data); sRet = getsockopt(cd[i], SOL_SOCKET, SO_ERROR, &aOptVal, &aOptLen); printf("error %d sockopt ret %d\n", aOptVal, sRet); } close(sHandle); close(cd[i]); } pthread_exit(NULL); } OutputL Socket test start Failed to connect with server 36 Kevent event num 1 wait time 24 Event filter -2 flag 0 filter flags 0 data 43008 error 0 sockopt ret 0 Failed to connect with server 36 Kevent event num 1 wait time 21 Event filter -2 flag 0 filter flags 0 data 43008 error 0 sockopt ret 0 Failed to connect with server 36 Kevent event num 1 wait time 13 Event filter -2 flag 0 filter flags 0 data 43008 error 54 sockopt ret 0 Failed to connect with server 36 Kevent event num 1 wait time 20 Event filter -2 flag 0 filter flags 0 data 43008 error 54 sockopt ret 0 Best regards, Denis 2009/8/10 Adrian Penisoara > Hi, > > On Mon, Aug 10, 2009 at 5:17 AM, Denis Berezhnoy < > denis.berezhnoy@gmail.com> wrote: > >> Hi Adrian, >> Thank for your answer! I checked that nobody listens for loopback address: >> >> [denis@freebsd ~]$ sockstat -4 >> USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS >> >> denis sshd 95390 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53616 >> root sshd 95387 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53616 >> denis sshd 95324 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53608 >> root sshd 95321 3 tcp4 192.168.1.103:22 >> 192.168.11.26:53608 >> root sshd 8149 4 tcp4 *:22 *:* >> root inetd 870 5 tcp4 *:21 *:* >> root inetd 870 6 tcp4 *:23 *:* >> root sendmail 821 4 tcp4 127.0.0.1:25 *:* >> root syslogd 689 7 udp4 *:514 *:* >> [denis@freebsd ~]$ >> >> >> I printed out fflags. Here is the result: >> >> Kevent event num 1 wait time 46 >> Event filter -2 flag 0 filter flags 0 data 43008 >> >> >> When I comment out the part of the code that listens socket then I have >> the following output: >> >> Kevent event num 1 wait time 23 >> Event filter -2 flag 32768 filter flags 61 data 32768 >> >> >> 61 is ECONNREFUSED >> >> >> And more when I make loopback address listening and try to connect it I >> still get the same output: >> >> Socket test start >> Failed to connect with server 36 >> Kevent event num 1 wait time 23 >> Event filter -2 flag 0 filter flags 0 data 43008 >> Socket test end >> >> but connection is actually accepted. I am totally confused here. >> > > Well, actually it's very much evident: > * When you don't make the listen() first, then the connection is correctly > reported as refused > * When you make the listen() on the INADDR_ANY then you will open port > 10000 on all local IP addresses, _including_ the loopback address -- that's > why the client connect() succeeds and kevent reports a success event. This > is an expected behavior. > > Try to bind the sd descriptor to another port than the one used to connect > onto the loopback address and you will see the connection being refused. > > Regards, > Adrian > EnterpriseBSD > From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 11:00:18 2009 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 73A88106564A for ; Wed, 12 Aug 2009 11:00:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6108E8FC44 for ; Wed, 12 Aug 2009 11:00:18 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7CB0IE8027374 for ; Wed, 12 Aug 2009 11:00:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7CB0I2m027373; Wed, 12 Aug 2009 11:00:18 GMT (envelope-from gnats) Date: Wed, 12 Aug 2009 11:00:18 GMT Message-Id: <200908121100.n7CB0I2m027373@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Jens Kassel" Cc: Subject: Re: bin/127192: routed(8) removes the secondary alias IP of interface after 5 minutes - FreeBSD version 7.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jens Kassel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 11:00:18 -0000 The following reply was made to PR bin/127192; it has been noted by GNATS. From: "Jens Kassel" To: , Cc: Subject: Re: bin/127192: routed(8) removes the secondary alias IP of interface after 5 minutes - FreeBSD version 7.0 Date: Wed, 12 Aug 2009 12:30:14 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1B37.E9011F13 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA1B37.E9011F13" ------_=_NextPart_002_01CA1B37.E9011F13 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I got a similar (or same) problem. I'm running FreeBSD 7.2 and running = RIP with following configuration. =20 # cat /etc/gateways if=3Drl0 no_ripv1_in no_ripv2_in ripv2_out rdisc_adv redirect_ok if=3Drl1 no_rip no_solicit no_rdisc_adv if=3Drl2 no_rip no_solicit no_rdisc_adv if=3Dvr0 no_rip no_solicit no_rdisc_adv if=3Dvlan1 no_rip no_solicit no_rdisc_adv if=3Dvlan3 no_rip no_solicit no_rdisc_adv if=3Dvlan4 no_rip no_solicit no_rdisc_adv if=3Dvlan2 no_rip no_solicit no_rdisc_adv if=3Dvlan99 no_rip no_solicit no_rdisc_adv if=3Dvlan313 no_rip no_solicit no_rdisc_adv if=3Dvlan9 no_rip no_solicit no_rdisc_adv if=3Dng0 no_rip no_solicit no_rdisc_adv if=3Dng1 no_rip no_solicit no_rdisc_adv subnet=3D10.1.1.0/24 subnet=3D172.16.99.0/24 if=3Dlo1 passive if=3Dlo2 passive if=3Dlo3 passive =20 # cat /etc/rc.conf.d/routed router_enable=3D"YES" router_flags=3D"-s" =20 Default route exists on rl0. =20 If I only have 1 IP address configured at rl0 it works fine. If I add a secondary (alias) address on rl0 routed will change the route = to default router to point to itself (primary rl0 address). =20 And it will toggle between "correct" and "incorrect" routing. =20 E.g rl0 has IP 217.13.255.147 255.255.255.192 and default router = 217.13.255.129. If adding a alias IP address the routing table will periodically = (toggle) have destination 217.13.255.129 pointed to 217.13.255.147 = (itself). =20 Also noted that with same version of routed (2.31) running on FreeBSD = 6.4 works fine. =20 Regards, =20 Jens =20 Jens Kassel Senior System Engineer Mobile: + 46 678 60 61 Email: jens.kassel@birdstep.com =20 =20 Birdstep Technology H=E4singegatan 32, 7th Floor SE-113 43 Stockholm, Sweden www.birdstep.com =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_002_01CA1B37.E9011F13 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I got a similar (or same) = =A0problem. I’m running FreeBSD 7.2 and running RIP with following = configuration.

 

# cat = /etc/gateways

if=3Drl0 no_ripv1_in no_ripv2_in = ripv2_out rdisc_adv redirect_ok

if=3Drl1 no_rip no_solicit = no_rdisc_adv

if=3Drl2 no_rip no_solicit = no_rdisc_adv

if=3Dvr0 no_rip no_solicit = no_rdisc_adv

if=3Dvlan1 no_rip no_solicit = no_rdisc_adv

if=3Dvlan3 no_rip no_solicit = no_rdisc_adv

if=3Dvlan4 no_rip no_solicit = no_rdisc_adv

if=3Dvlan2 no_rip no_solicit = no_rdisc_adv

if=3Dvlan99 no_rip no_solicit = no_rdisc_adv

if=3Dvlan313 no_rip no_solicit = no_rdisc_adv

if=3Dvlan9 no_rip no_solicit = no_rdisc_adv

if=3Dng0 no_rip no_solicit = no_rdisc_adv

if=3Dng1 no_rip no_solicit = no_rdisc_adv

subnet=3D10.1.1.0/24

subnet=3D172.16.99.0/24

if=3Dlo1 = passive

if=3Dlo2 = passive

if=3Dlo3 = passive

 

# cat = /etc/rc.conf.d/routed

router_enable=3D"YES"

router_flags=3D"-s"

 

Default route exists on = rl0.

 

If I only have 1 IP address = configured at rl0 it works fine.

If I add a secondary (alias) = address on rl0 routed will change the route to default router to point to itself = (primary rl0 address). =A0

And it will toggle between = “correct” and “incorrect” routing.

 

E.g rl0 has IP 217.13.255.147 = 255.255.255.192 and default router 217.13.255.129.

If adding a alias IP address the = routing table will periodically (toggle) have destination 217.13.255.129 pointed = to 217.13.255.147 (itself).

 

Also noted that with same = version of routed (2.31) running on FreeBSD 6.4 works fine.

 

Regards,

 

Jens

 

Jens Kassel

Senior System Engineer

Mobile: + 46 678 60 61

Email: jens.kassel@birdstep.com

 

Birdstep Technology

H=E4singegatan= 32, 7th Floor

SE-113 43 Stockholm, Sweden

www.birdstep.com

 

 

3D"mail_footer"=

 

 

 

------_=_NextPart_002_01CA1B37.E9011F13-- ------_=_NextPart_001_01CA1B37.E9011F13 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAUoAAAAnCAIAAADmVpZiAAAABGdBTUEAAK/INwWK6QAAABl0RVh0 U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAACxnSURBVHja3H15kF1nded3vnvf603qVmtX a5e8STaxIhskA2GzLSbYJFM4TKoGMlAsIZUayPzF1AyQqVQglZCpqcIhzFSmBkwWT6ocmyEawMYG 4gEby9iyjRfJ8oIkt6TW1upN6n7LvWfO+fbv3vteP5lhUkVbll7fd+93v+2c8zvrB5+55zkAEB1+ UAio+vz/9odbBvXPL8sPCoRf1Gz9Mw7K/PyyDeyX9yedmG6EZAVd17ELAULxS1j0QctV6FG0T9jP FTfRN1h6g7pf84YCk6h+Zec+gaVL23DFbUFfArYkVB/KrwJUXfa32Htcl10b6oq9r2r4wZMBo8VO 8y0qpyp4O6gPCEE/9Cfs/PLSjAFg8CroxAnc+sZzFU6Nf1k874UBop97P8X6bnW9JyFht4zfdFXb IFjraE7NegkBGN9ftc0Qq7ckz5xqDYLdJMqT0XEPF7dKtBMDukiTVBYX0ax6V0aOVcvfiwRQUxS2 j3pd7OIBQlEOFraTiHa4/Re6iBYzlT13N19cRkF8Q6eXQmGk4VKW51k9IrtQt9lU6sFcNfLzCVLo RRiXUZubH9CEBUWGA93YKlS2X3oLlHdj9Dm4KS/M2mKC6PWCF9Az3wuMDTeqwIodUx5g1X7ozuqh LDmC9eK/UrScL2wGe9sY+Dp3VEX7ZiQMagtdxjKAxxK1LPZSuKzehi13QaR4+S/F8EN5nt3ehZCa K1pGzxn/v8LyilHIAPL0ODMd2kfRbbCVOxNjjuN/5C9maoKZ731cWtrjYm1W7AcJiujNTsBOgBk6 LlBqyOl1S4FuFNabtt79FgkR+1SjNJqtA/KwmIKIl0XXpScgAhHVnceqdsCy546DXGSK8J9RzYVq zOmgEDqBAwaqaBzWdbxdJu31221+HimNxaWGy3s1VCEWLL3CqyGlN3QHGhbGK1LvTnQBhLJyIkWo hq3YwxSFShf0PMHlBcGy1gNQ0QHQGiL9LxWdg2Vt4YNm00UgRkLPO7qz5a8rBqvGXXYsooP6g5ev 3zhwjr9IExeKjspXiCRdN+wOArwsnQ0usz8dmuiufAWzXdFCF3rGSmW88OrK/V/UL50BCSo0X1iE dfn7ocsr/EDCTZVq8YidGUInZgveomUsxR2nDotGEqziEqHJJWauUBKOdjilXa5sWVITuX8dlG0g ENzjjTbghxy/UQOsiikCUS3aocK24jQOiPHt5YBD1YjECtWsdzLqHcxAyWLgt5MBjTFsBL++6Dvc bSNjZ8xQXvci04UQcEHHsbuvMN7MUIV5RRdNpDOqKaMAjTHd310130DqxnsS/TSKjiopFvG5I6U0 4CyAi6izVVwHu2F7AL8QWFpuKM64fwirzD+hVh5ubQxfJKUFQVBloIAOxgoo8R1YxJrWEweO1W+A RTk29KbS/1w2ost7EKqgJwAIXKRB6GQejAcLnR7s8G3B+gOL23iDbyGi0tc9jbDoQNBvJyjJyI67 BSBsB6JmobM1tGQbdzenWgaGMMMLnq4Th4tOjnNkScDQGgeLCBFc7I1YBU6KvbI8gAne8kGMTHla XEectZp/+BUMmRN0FZ8QS77QFQNFn9BlCdYy21qkJ/Fuwar7O3SmF56FrwMYAETbo6PdofO4ehxy 2dKJ+HpgTJfJr2ynMJ/RtpEWBlZwcnSiTRF6hAgqh1x+UdwbDc6hk1no59LvoDebxy/K+IueF0g1 c9LTnIUzUuR5hUjXf7Ds7oGYt8ausQL10t/S/R3PBki/iovw9c6zYxpRI1KYpcIbU4TMbgjBuIrL BD1b0KGrUaWA1kpzBbF1O8Kfjp/KznqDfF37QV5+fFaswXl1EDrgroCSRaz8mcVy+wE863dUaqSR eyr0ocuug7I3B4wg7by6l0fYr59mf1EGIgh5mTICITjjJf+qbpCJFUbG3ouYI1bAYChaIkSVViGi WbZ/GxNU5CqDEhSHKq0OuhgmMcBvICJPCUT2C98UgujIuwEWczhA7wsJVshDSdsMTKdQUH0wfFBA Z728Eh5XRL6U+9Mlaqn7uGx/1JwDdLux7CKQ8V7yzjC/b9CryW4dgy0BHTWCaA+YJYZAemPPK9iZ fXdEmdCD9b93P0HvLCS2haH1tyuLEDisbN0Oasb1XEq1FCzrE4GZyDN+PHcxTrHXRya8U/N2AThB URPzT0ExZDVqEHoSJnFTyh6L1tjZ2W6D4vIcP4tMcZcxlobjlSBLZtVXINq72MsrRNUjVSgosqVh DGNehyTvZSZjo2NogQMRjz36rPZmfH/1wkERMhTNWWk5TqwbSYKPLinFxsWYR2JEYQC9GJD4ukQf YYghloNqg2Voeyizboey7XeYpOLiBfHiw9hqiPqg2PFO6BtiiW2s/8jTISV9C+ePw/BKHFoBBOAT dKqrYQhaME2NY6sJKzez8w3QwXm0u9f+A5HCxRzBWxujXsPikxTPt/dFYQ9SqOilWMToA5dD+l2i ocCFYKKlDief7fYDrHwq6h5gJ16HpTEWBHogvUFxdYQKOLSYeHPgB7Da/1NYNxBlwzt4EBGCEYwX FEPmjxX2pjJkQCEKPDwVoU8QO4tna6gE2vqgAS1JtEwpQcBXeMuyrFP8QookUQ/kQt9TCG0qqqkB iNYTRw0qA6CNYbXboxBvzO9W6wQ21NVK5Cic2Vl7+aPErCnOvCIas6J/GK9+m0hIA6e2pGGZ3GQO zz4gxp/NB0fEG9+Py9ZBnhkuJkk3ynl3JjVx4nk8+E2Rt/GKt8KOd3KzBTgPoZvNqm0aI0s9Kyaq MnJMTp2CZ79j5unXPlq5AT2BRFsbqlwFoe8HquzeVqwBlp0EVbFSTqoU9IvQTgkl3IwFUKkXFSK5 Gu1BK3icAy7cQiGx6JvK5AUFo7XruYE8BtIFT5bioQNnMgpRCNaE2EwQcAsoK+0V2CcaqY+Yh2hO AKs1uY6OiGjtUoSSBwRLwW7Wv86rdPhhMXGEP1zxZth8PWZtcWlaPLMfFy7yFh/bQTQPJB6f+kfR buCKrXDtzSgDvmKNCSENBIZNfZFNBayu6A2Tm6iFwkbVEtISME8EOmMV+PXmf3K9ilZJIQol4pQ1 kdSF1JOr/9KcBUSGojknWguikQJRb5IwwRt+o/dkzk+0FqA1L9qZaM3JmuF6OVr0gQ4yB+5DCx4t f1M7OJdgLpbFB0SWTox9vIEmHWwAMGwzNDCW/MDeFCggslXEuzv0JkNkpzNCIYjrgPB6V83KrzXa UaBnxxByHb+Q0aiqpKL5xhqmSvIOiygGsKxgRlwCMMTR3fyYsuQuBuxgxgKzicDaeoI1MgbzqJM9 2DIxfNyzM4TUaPkQ8DcQPswVIxMgpnUgcDv5Gl9fsUlsuV6kNZw9BWePIRHD5Disv5bIEmdOi/Ov CUK/a67CtEYUYiwHxiuQeXzoLdsRllZmbivsHEaLNz8qvReYoHK0iEuYt+RR9okM+KqEOL6e5LAm cdSUyySe9uH17xGrtoqRNWLFBu4/d1xaglQGcYIqG69D4hQ0zA0786xtok8TdRvfTM3mhjflunHg njpaZNSjLklDSEaPWLrSdG7JSrNt3KjzINnIBfaBX6hQSHpBKjHaDHkcVxPpuzYQw8GNOPzPX8HS coRiFTv7zrGafVUg27LZCCokdLTVzcQYvahSa45kgtP/wV/0d0qocN4VRxGEjfiMCMDOChZKowK6 NS3Mht3JHWB/hVoF3NUcXR8sniVwXhXM5/O3pEaOzqaJYnRM9C+lPQ0Ls6LdJMVVzJylzS7q/WJm QmQN6BsUs+f5JcQLVmwQMuU3JylrsISHqY3+JTwAogeFckNrv9pgUjKFADYvkXgUaZ/oG2KazdpG FspUB2bK5iWRtZjY6I00COI7tAGb89hui4Eh7nqWKVaBYTirSEK7JT1Vg1aD3zUwAmlKz/LMY5sJ mzA53dNusuhmVqJ4U3sBmgvcTq0fqG/b38TtZC36QyNB6hvDjSxvzJEOoDo/yH5/aEn6ln6k+o2w A92zQAChhfUBaod5H+N/BgU8k/qn1mfN7zYqUIqipq1HhrEfJfTdmGfB+1pkMa5IRLF/BUxbgNng 3TZl27zbiLIDvWo3YYV0L2UAuo2YdzAtVf4KUJ2dW4i2KIUGRXFQ5TuhClnH43AwRKjNK3KrChQS XRGLHLA4V4gQB4G6kCtvNyzmvjLnNXtDhspEqvXosl0CwcV3o9dsqZ3hVXl9gDa9mD0rswZmNTF7 Tg0tEdOnZbsh+gfx4iRT79AoLBnlbtGGPvYMHj2Ic+e5xaWrxBVvkmPXMPlJ0xUl25XobTXzl57E 00fExWnW5ImuiNKu2gurtgJkHI959qg49jS9i/ACthuwYpN84x1ECXz9pR/npLgSIyAOsmmX3P5G kqWYK/4kFQrW06lhEV3K2vkT32BLG9HVwDD1Cja+gcfdXsDH78ELp3LiNLtuk2u24ex58epP8Nxx 0bwoWk1B19/2O3j6ZTz0TzzV666S179btFs4/lM8dVjMnCP2l5OSQhxnyUrYdqMYu5q7gcoPR2T/ yk/y8WdxdhKoa7U69i2Vm98gN1+f82LkeR479xC9STOSzODVPQmxcQoCEIulcAaXBGIDAQCiUByP AqJ9/Zaxr9+y8ct/dOCJG1bf9+rUnsnmmCMI89VjP4nsuSjesp6u/8UfHfgJBvgfPbPJrSXAsAbF W/1Y9Lc3rLnv5o1f/t8/+48vTN5s8EXIOHzcZGDCicgDRaFNZ8RCo367GVWUaejohlXfeHV6z4Xm WABquIc3rrrvlk1f3v+z//D85C3+SdcuBKhESeoq7uASjXxECs/q9JsuNNaH4tfpLehcciLW9TR7 d8p7kGPG5J0E/hQMM7GtGgAhA6NpGxptDS7DSzM4PwckvdNGNn1aJBz9hvQr0Xz/YOvSBb55cFgu XcGa7OH/kz/3PbpHjq4ngsTTL+H548nu98qtu0XWZP4BVknl8AzMjz4hLs0A0VtaEwtzePKwOHcU 3vYhWLGR+p699AieOMTQoDbAsnxkdTK4JHvt+fzAPYKE8MhaQgdi8gQ+8228NJnsug0TF6wFbO4j GCNlprkbYY2Zs9QxbFzCS9Ni6mSS9sGG60S7kc1N4tRpkaaQNWRaxzOvtl/4Pktj0jXovYMjyeBo PvFyRvdQy8vWJHTPwlz+3ENi7gI/1beE1Hu6ImYniQukb7wDSJEhkJ+320/ux6NPM5MZXc8mgMlx MXOGuirXXiGJG2JG2KVliUGmkqcmN1szt6sk49UN1Cq7qURB4+rs1qrOcDD/3L71C7tX37fQHv6b w19xvIGImf6dOvO+wD2hyURGZhvpeiCh8GqzsdV1o1oFXzm1TSVg3L71Tx45+eFDk7ca0RX4hQNC im05EHsjoORlLpobAoZoPxJvog4ePP2+QsO3b9P92SfDJyFWHhzAweo4aDAOafj4dR98YfIWalDP 6sEzG6OkEE/nEA1ZWBUwjBgozDCTt7Lu2AIPTiDY5L7Ya8bsLklg+XoWlXkLLk4Sjm3PnicpzTKT KGTmNIyu4y1OGHvpilr/cDZxJD/yKEmtdOc7k+veReTaeuTv84mX8iM/qq2/miCuWl5pGWqOfQO1 3b/JFLJ8DOqD2fFnW4/dI0hQH3sqXb1JZLT9a0wVAtKd70iu3Es8hdrMn/8+/Z1s+pX0pn9F5No+ +J3syKP50adw03Vy1RbIMjSC0CSc5PpzbaD2tt+Ro2Ptpx9oH/6hoCGMv5Bu2IESMmJYaUpNMYkR JGdrXB9rBCu31N/+b4gdiHqdp4Z7gizMlS0QFP3TLKZv/dfJyk3Z4R+1fvog4fb8+FP1jTtEfSA7 9EOmbcIkV+yp7b4N52eb/3QXTp9mHUGrXEo5h+FVOHNWDq9KqbfsgHcmX73nbeJY7rMOlKJvBIUM gnlKPtjQNQrdE2hv3vAXRNt/e+S/EnlPLOzYvuxxvS9H+04M1Gbow5vX3XXzhjtJ4Bw8+z791ceu /cCFxob7Xv7TcCN++sZ3UpPfH/8U3bas78Qd2z+9bugQ/frIxIfXDb7w5rV3DaSz3xv/5LrBQ/TG +Wzpfa/82clLOzXivG3L5xVwuGtifgfd9q4Nd9Kv33vtk9TU2NBh6kB/MkNNnby4g8a6Y/RBuoG6 R1362cyenaMP8c303nPvG1XvHa2feGTiQ4+e+vA6epbfS89+cu3gYRqFeu8XT17a4Yyc9MhgOnvt yod0mzQJ3zr2ma3DB1x/Tl3cccf2f09f0UB+fOpDNKib1n19IJmhsdBAaDj96cwLk7eO9o3TV9Sf f3jlz3avuvcta79O16n/3zr6mds2f4G+oj9TzQ38utqslHDTurvesu6uCwvr733lixcaYx+8+vfp BhqmauFPqRtWjmvqtKLRKN7KQ2uVa0nygeM4FH1JsAGZ6n+deQU+SpNvp6fT5esZzVK7F6cEia92 U46sIaomSqNNKeanSWrRBk6Wb+BmT71ChCeHltWu2pskiSRBx/ST4MVpnDol01S9x+JlpeDKDdek 66/mPXrhBKu1TEICZ86zAYH7ajciMZo0kf1DeP41agrqAwlh/oGlSV9/uvV6IA2W9PCzx5KUKUea BDMdg6tN5crLV6tTH+TytYrsJWFvyImWwQcWstC32XHGM5jKWp/0kkpLL7DWe/6PhDlL3uVjzCNI C6AJIQW+1chOHuIH+gaSrbuB7nHeMWbEkr1uUr2RtG66Ruq9XjQ0blrJxhJIgUEXzWWtntbqSa2W prWE3pamCf2h66oRyc3pUYHS92lJeAZBv4Kv6NvUtCZqlIn9NmEDiNy5/CHaUsdn956Z35lYVpGo f+me9UuYKr597LPfePXPtemfNiXt0fuPfVa6d6jr/+Xphw9duPVdG++kC0SuR2f3fvWFu4lm1g8d 3j7yOL3l6XN3NPOR27Z84auH/u7whX3v2fKFRC+2hO8c/xy18P0Tn5pubHjP5s/f9+oX6Q/dSc9u Gz5A9PzUuTtOX9qZqnfR2+nPF544SK/Yveq+rzy7/9DUrTdvvJNau23z54kw7j7y34jw1i95cfvI gZ3LH3z67PsaGb338//jsH7v580UAQ9fc6flqs0/eeIpaoree7/tz+GpffTrQjZ890vU5p1jQy9u G3585+iDNJYzl64lLkAd+8pz++ktR2f30AzQlRtX3/fi1L6/fHb/Xz63n7pH7FKP7gcnPkXX9euI Z1Fr1E9qmTpG3eCmzt6hW7hh9TfU0qgu6v/Uj95/+iu11ry49HcqB+osBLT5mf7J0abzMQejJzEI oNEaMuFh0TckGhfF9ESWsvgiSZvUB/LXnid9Mjv9itZEklWbMWvkc2c4/ItItLWQTY7nFy9kp46w oW9+Or80RUJdGaXA22XozrnzzZcP5CdfzOemjBnRcBqjpgkbWGqiAC5OkuAlUczmz9OvkLKQnTuO eYakDM+e5w9SPacylBm4RgFt4D0urHRJZOIO7D/6sRCyShNXCP4udYd0Lgd+mVRUaR2XHAiAjTlk XAPQvyRZMsIeRGsI0zda1hPoydImo2rsAT7USqN1/YUMcFohUoVXEdHq6wok5RibkSAqHxag32V9 47Q1fXpOnJ21bfgx+vun5+6g61vVZ5Kl9x//bDMblt5sZHDtdHMDyR+aWtqj9Jk2PV1f0XdCN3r4 wq3XjPKVHcsfXDf0Ask9t9p6fkmr2jrCYvPYzB7dgW0jj+tnj0zt4zBt5djQXIYY2ZTSYBv5CH3g 94IgAfjYxIfPzu/QPdfNEolqCX/t6EOEI+i9EmIrhRMlIKYaG3RTekSJbfOMEvhbRx7Td744davO AGhkS4kl0Qci1GY+bNYTBBHt2kHm8qP1k8elMwmayd2mhkn8lDjUTWu/pr+mpogNWbuRtd9F3n+I giKsEyltzl4ini8JpNdYaqC22WOeE53n2iRnvQMmsDPHoWWwZAVJJJw5p0RVTS5fzyb0JM3nzokz rOGyUW1whK3l7RZfn5+Zv//L/JmIgjb36m2kIcvhNRzyKb37haX69JnmI3+P58YJDtR27SNKaD75 LXY+GbKByATJmc85++TYLp01HmUYz+Kq1gfL1kmCAOu2MdCAMLQLwqqBTFLWA+m9xsL7fpRpAMJk Mm32wNB0DIzMMch/Z0SSSOfF1B4BZjekjROzkzJXLBi9oRuFaUEz0FX8VL0v0N/AqbjoI5SN6M91 LGOhfojRemWxhgeaybNB+EFNCrRWNWUNoQ1NFC5tkLj+oElIOpXT/Ur7uD28ZekBohmwBQDMXgQR ul+pzRfn9339xbsnLu7cu+Zr9gbDDp4591sPHP+sBCgYBqRwrDXKmwDhaw+4Z8zN0vOXUDsG6ztJ ABxPe+b8bz0w/jmA2AXnYwtFqGlLH6IPViGC0G5miFmam8Gu1r/c+umJSzv/6rn9n77hVyWg9Qub mPTQe26u2JwFzTLsdRsaaaPAMAwnAMuYSHo3p+aV5GGHLUPlmiS0R1iNwB6JdmuORBOmoWI3YWip HF6RTb7GRjX6vW9Qjq5hB9iS5Qy5p88Q0RIIh8El/I7+IR22Xdvxa3LVRhgagTozAiAdlfdZO8zE oI+tI4/i+RMwOFzf8xtyyy6cPOk98xBZiUDrpQRXB5ZyD7Ms3byDHoHBpUAvJaaT1hnPEioOzREy cgSGfn5vyfCbSGhXVvxeJWclRFYdiNMMItcRmv1H05vWOdyVeQwanSQ0ZoHZOOk1b46Mw1ARV+If AvC+3FJWjXXniygUzFnCgkwLxcp97iwxzmfO3/H2sS/tWn0vyZ+jM3uidBQQR+f2vl18adeqeycu 7tAXH3jtc799xSdenN5Hkke4SKKIsIT6CgkUkBKuOJrp6On5ncwg8mHSaUk1Fc3iSOiRt4s7r1HC lsX43N7NSx4ruMRCdmJYj+3AxKUdm4cPTMxfS79RU5uXHtBPnVLvnc+HT+n3KnkbOelcalDRPKjb fGxCtXB0bs8W1abylpsuIRRzjWjUhMMNNVuxMUJTAUaAUjtvF2LLyAFqjdp3hYbc5IMC1JZeAK1b AEVYidTY10nIKBzJJumsvdBozc4vTM7MT85eOjdDfxamLrYuLuStjEE7ofl6kvYntb56unoTe8KI bluNZPkYKcBEVHJ0jI3DpPHSDJM2TtSV1FmtpeZJbg8sSbffQAo5kPAfGFZBKRr3as1BfWDt/TzH ivQNkvglZZW9wc4VAFJEgpYpijAGM5e+AZE12aa1dVeyeotcspy0fUxraOMfw58oB9ZaFSJrKrhd b0sOxfZWEd5jCqKCT+6E4B7vx0IaNSxdITDD+VkO9Uv7lHbsnPAy7CieH4feftAFmoIfqnt7PPJS tWStlyGawHg1OazLEINP5eOTH39m8v3v3vjH9Gd0yYSKRxAiMXKEtvXDp/6AvvrNbZ/WQzh68SYS 3XRF35BbyYZeOssHXvvD/mT2EztvJ8bRR+RkCFJOtTb9r2N/Thfpq6uJho3pAEyuK8DEwnXEPt69 6Y/pzwPjf3iKCNW0CagJSUqMQ2U87LLvJe7z8Kl/R005pjDd2vTNY//5HWNf+r2dt1+z7CHUmhk1 FVOgi4bCxOlfQN3oT1WbJ/9gYuFatCSq+xwyZtca3Xn9yns/ce3tNHvMF6SkK7tW3qt1E2A2d91j Zz7y29s/QZPzwPh/sqUQwcWHoJEuduforho7B5h5U3+YoD76P5+LSxe5pbeRubbsEQF41uJTKfvY ydz4wV088sZC36/e3LfnvSjTxoH9jYPfZaqW0Pfm9ycke/M2yfPmd/97PnuWBHJy1V45ug6ydk4y eXhlcuWbIGv5N6td1Xj03vaRH5OEr+/+9fTqPYQF5h/8qrh0IVl3Rd+/+D2R5Y2H/zY7/jy9uvam 3yApBwrwNx6+u330Gaj3J1t3pWNXMhKeOYNZu/6Gd0UBmDw1SX7hZON7XxfzM6Q+DOz7XTm6tvnS gdYj9xJvStZfU3/HB+lD43tfy88cE2mt720foDbbh37UfPQfaE7SjTv6bvkYqQM0zNbzD7ee/DZn qWzd1f+OD+ZzUwvf/StSWGhm+2/7pFyxIRs/1Hj470hfgGVr+vd9nJBL84n7208/QEgn2for9Rvf S9p44wd/zVbDkdV9t3xEDo1yBHur0XzsG/n0mWTdlbUbfr1zBlh1BBcGcruAYwvCXzOd0InqMl9K ecpgs9OktVwgxKnliC4XK6ia0Lna/OKFkMoFDLqkfHQop7xYkg1gUGkj7FLH6m7VlSSgol5sZdBQ DKwq4/WqZyZK5upSwSr6UUGpgOU4HgjKj+nG8yxjMd4QMN8WYpBtYKRJCtHuXw4LbSlbQBp4kog2 B66lazbJGkd/iWUrxd73Nh69D2cvtJ68nyPD2FZwKVmzLd2+W1nxoxIrtZ1vxbPHmAJ/8s3m4R9C lhEdYpY7uUosg6hPheGhTn0neVK78d04P5OfOdo+/Gj75ccZlZAS3jdY2/IGdtRlWawBqFi0VpNZ gyrnwn1oM1Iwdj4VVMdufM2mlemG7hcK41hGyRYKFdOGQkXd8iRlTQ74AZu1z8pHS9CLMtZBaCz1 a9+Kk+PZ+OHslYPzx18wQEul30jj0QLiaETb7JU/9VId3lO5bNJHDEdBKFEWEoCo8PvG6Rix/9tG RoSb2wepGouNL7CurBrsEVRZREp4gi90bU15IkizE0bLK4WSuaipYtRalCUjSyGhoarZOcOtXGgC fL3NwGDYueR4lIFWebZEGF+AvnK/DHI8SyEG0CEjPc5KMaHWyh4CIOLs7nJKZlg6MsXEKxZYkfkd RGgj67lmMmr9YvteMXNWpP3Z4Jr25BRv+dpyseUGNoMNjbZlf9Josm0e27Vt16crx1ovP5mdHcfG PPT1w9KVJCcVGJQqzVfph8iBmemKdXLfR9vHns/OHRdzU4RgYf1VybK1ydhVTEUEv8eulATFhUyW reL14ECvLGHx+JHsZz/NTr2cz8+yG3loGQl8gugqqBuiNPD+wfSK3YQ7oH9Q1usstIdX1K7aS7AZ RteqeAOZbtyJy9YQYmFVImvJ4ZW1q1lplMvX8a5mtTlPlq/Dq/YwIa/exK70WppuuR7n56iTCfUQ czk0XLviBmYZg8sku89zGnvfOz7Q/tkz2bHnSYsRS5blp4/hxSlwwSEgkjWbk7Ers5MvEafzJqyK /QphFali2hN0lmkyChIN81FdvJkMBUYxDbtQYcBoF4jO4On1PxOMGJcmwLDIpnogB2sqBYMCgu2I jvWUQabbx+XKTZXHKujkQzemuJ62AroulxF86k8c92cV8rAEUuG4ldhmAhC5HDpVSjdKXkXNHxna zIpc2iSHR8DNi8uP3nOop6ILpXxvNo/pmFIuZpAbTkV0pbg6yzFl2WanHOH5tJbUUkhZo0tYWLHo w7xlasMa012up5wgOmvmZjPlKiyWVOycoT4Hv9aU0AN2iWNuxAs74hIO+YT4tCK+pyqiXtZRS0Dq Z65mUHnXWTFWySGiVmfWg6qFPOeyDWmqxFGOHOiuZoIu0iQoDVZdpI7XjBbdbqhNmkCio9BJsLdB i7taH0EYugJpLZs6Pb//y/nMOeIaA+/+mBxYisoM2RUdFgpWBBHTVadJFSuzlhOrEQqHp4SZo5Ul CkB0rqzvc81EVATHRqBGORtRAZmoqm7o4kOXZIgx7DdfWFytpRaKqMRBXCwmiiLrHcmX1qKng0pi CNDLUTk9VnTu/lR4WyqS6jOrinRiyUKozBQ1ublKgcgDG5Lg+DC96tLICA61bmWi2QbrW1A5XYkK p2HXu2QzvXLPp4n1sOdsUffx95nNtOJcayRiI6yuqi64uhYsn/NceXTRRXLFmXwYbei8qXK5lGai 7SBZA01Qp2otaxsfIavrnFjDdj7rYTFl1nlsTZvDqpgBPQW5tV+qbLCs4YgBle2wefAHhAXk0uXU 89bLB/OL0zQiuWw1AQ1hM8bBZLkVUrVFUT0rpG9D4Ie3Bxqh9Xd1qguBEqPmZTEDATBKLItTni02 QIxQucQIK2gdX0KQoWXAQ1zcMoxH9/nm4HR1n7fnXovltBYdAmRrUAdx5hHdW6dkGeZUMdYoQ96W SxPYLdcN4vB7H9wdQ6qwY7JwT6EYp4yO+EHv74S4fonLZSfdW+uvUdaqX0+AUkdAWrO7tWY7tm8v A/g6JcJmtoY4h73qjaxtO21uYOmXmICpREXI6Ygx5gsJGG4tmYaZP0mVCmo4iynxYshRSQxpDjSy MStBASP7FYILG9MNmARnMIlKBp1I9Sv/g1IHnygqkJozeGkC4EKNpdmwOkAQTRGotN46/kLjsf0M DfoGmTs055lLLVvdd/27+N5MliKLoXN9DagouBE6bHsQ/6Kq/n4R5y5yjE2pFHFlTSb02yLgIMbv g2FFCLdrw8RtnyuCBggAxDooBP7S0HYoRYjMhY/aMreb9Fi0YRVGXzA5Fxi4710ejjQQGiHgqBjW KUXLPjBKsBdR2rXxL4CuMSIwzh/XA5Uhm8TyTFeHtNu5Bvjdf3yplBFfgiJ2LFHtCAMJseCcxQIw FLHeEB/qaPh+VCrYIF8t5FWIoKqRwqJespAk6A7OE4QuU9ul4AHmwosib4Iq1EPMTbyaMB+txgeB fqkDdXOXaxPrRRiUGggNVlFtEs/mABM22rdffjo/N57PXSChDf1D6dpttR03yZGVpKpArwUo4zqn WFVxHOPaLgU0Xra7V2YmVwWjw6Km/OjY0wBjAxY1g67Hay5W76RDKxAcIOFrYmJxwN6oJ03abIBT oFDYRIMhn+6u9gSUNKVydaZSnTLwrMQYLXJTP8BtFlsQEMPsOGeccImhEeWFqxiFUv7+/lf8aR16 14NnJIUzef0JQRiAtLg8D0bGnw7+kYoyw1Fqo7PTBLUDELwjVwW06LBp5aolmmd5ChDgDFc0z8Vl xiXHIWDphlrN/IEoaJ7ozvNVcTIIAUv25s2YmzqbjXsDczKOsZc5p47lJmWKVBKOC8ggLC8TV+or 1NOrik+LswuL7UBQbzfcNWGZrLh4lShWxMa4WH+UkoyBhU24cDgoHnhcMBUgunWIcWZ0sK0WKoAg KgpIoYtJQvMwxudqoLNBOmiJxVps7nvsLODKbBuw2/lEcQvB4QSF0sehLQQio0VgyccAOwTlKMBV 5wCLKxD8kTzq31RCrFjIQKWSPg02TJcrDgiiVPOwRkB0uk+BkYUJp2Xrl4ydDqH2o213GRdxI5Ve 1VlS+i6ngysdWMl5qSS9isFAFdMnlcKUGxXCBHJCblT1PFdsQ8N9HxehXi8NdAdD1zYYACJ4o/Ld FGT3wyyc+KnK0VHXTfiBnh8mdVW2wMbFQFDfyCSQgUQfYGdKeRRsRiiCE0O1rpOji+uIy7KCgx5G CEQFDAIrV4ilsZByXlXeFeJyENFpBRCW7NbbMKBRn8VpCwki+LhbU9QhQoPSx69Y05vX2S0VS3fQ sish5RJVg4MoXekSobK9jYKGGHkZUYeBuTPNAQMREsVLm5y+oH5joDCb3IIS1A2y+0Xgs1NQ1NeK KFsHdLd9GDA49MsD/7fffrUC4DnOHx0sXij+WrC5eBgDhSORrLkrbD9K0a04rCM479udYqbV/sCa EvK6opkDXUVqpd1LpTrrjKhE2sQpiWGksiAGYfNr1MjyOFCjUOerusRsVYalt4OZ6XFFC+IjpUS3 gt2lKmM92HsXK2vtUZSragOd0Tl2DqwpDx0jaxyWrHrhdi3nqlaXMe1SrSW+uUIQ935cbVD9oZfZ Lov6rsoEiuoohLjwRFdHVhXhOW4TFZBLWb5h5KFzwsGk4aALq5Zxw4FpDUPzSZhzHLXrq0CCNbpF DlT0ZkDHflSipGmvdG4lFLLXRTHo21jydGk070PNHLORLodOmvjYusH7XCeGRqcrJKMS4KjoP1Nk j8plhw6YRykOFntCYLdQxRjM+MAm6mq3v8dr6GNaBUYpFIbBhKlbAfANS8M6O7oUWGneDbsavKiy rphjMuiiIxxHhohyoqrywdpYDGDaz6PKj2FRYAvzpLN8RwexxK+D0IHnC3AKV/Jd+CNBtGSSQbeL /iBfe1vjAsRifdJYe0YRlNLwbmYMDsZxUqlQwdusilHdnMh18lPEDpIqCWDLdWCwDkGOt4095P2X 2nmWGqVEpbysyTsQvSBEoWJGEGVtY0uFb8YFJaA72UdJZIiiGj0iD8//BXd2dNE4ariL9FodVntg rZLs835CCtG8rJmhNVyYbHB3SEyi8qFd9myi5ktngkJiQnydtNemj0yHclu8FB4tmhRKPkuduZeD hKCctT1RJphGDAtJQqGuOwSxeFAscQtlwzhg6EoJjlg14eu+hEdU2sn7maAU7wTlGmeGf3kyA4yf CjxnvoyhNXbaozXQa0LC5tbqomK+OjJ4dG0wXtHRDyUBLuMDQiEsM4phNggUfJGePxopJcJzAqQ/ xg2L0w/leAVbvDcKKvJquS0XJcEdUAte9fG1n9AHKAUsXkkgTIXLNENRTjoILNxVwbeFyCB3pywd uBrWeApdOlh9Dk0wBwIw9gFh7DdCUQgVqkZcEuLY3WLmXfkwAa6bqP+H3LFrsJnergQFV0FIZMqV ntjJqFPtfdUtnaehfuXgF5VEn/scLYIA0thKIQL9apllUIo32Ai+cFBoHozEUemgyWDqoKCmQwz5 nPEBMNDSvMfFUBEGNxRRlQy6B94yWox9sesfLSfaow3MQVHaqBFDNAxjadVXOeRBFLfNvPNjkpYz 6D6jrVsmMSwzB0Ytz4MdrYkm9xxCFnirNFA0tirputrGxyY76BXgbUo2jzgwYaK0PMBCJ5MHomGt ybUSMlPnZikrEtpMXzO9HFziglojF2TIbLzJJI9kN3r8I3QZ0IIaIEPjbXjggmfdUVAOZ+QU3m0M z6idjYa1I1aekyUhDKuKDM4+8BCiM0ALgh2iE0KtX9um9poIGO5HZmuVq6QrW84T9cbn2sqqOoou 8KYqp6g3kwCv8YwzF+Cx8pkQQhv2c3tESo5GEcAw3ANE6GQFdK7JgBsE7lTsVDnfY04QhSBvKBxm EEU5Ipa2ZameJ2KFlQADJhJEVxScgPEZmiEmKGsYYdaF11CksbELiC0lwpdGLsX0VRxADxUpOuDt UMF2leWIcVfFMEgetDFFgHGt6MjQAHEYERbdd6rttrIEtxRUzFWJbaUe8icIo3uYQ+oDPsT/FWAA JHTTHWNZCIwAAAAASUVORK5CYII= ------_=_NextPart_001_01CA1B37.E9011F13-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 13:57:16 2009 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 9B370106564A for ; Wed, 12 Aug 2009 13:57:16 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by mx1.freebsd.org (Postfix) with ESMTP id 84CB78FC4A for ; Wed, 12 Aug 2009 13:57:16 +0000 (UTC) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n7CDhtv6020183 for ; Wed, 12 Aug 2009 06:43:55 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from gnnmac.hudson-trading.com (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.3) with ESMTP id n7CDht5m012430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 12 Aug 2009 06:43:55 -0700 (PDT) (envelope-from gnn@neville-neil.com) Message-Id: <533A2900-CDAC-4BFB-952B-45FB18E19B7E@neville-neil.com> From: George Neville-Neil To: net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 09:43:54 -0400 X-Mailer: Apple Mail (2.936) Cc: Subject: RFC: ARP Statistics 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, 12 Aug 2009 13:57:16 -0000 Howdy, Here is a small patch that updates the kernel and the netstat(1) program to print out protocol statistics for ARP. I'd be interested in any feedback people have on this. Sample output: netstat -s -p arp arp: 469 ARP requests sent 2117 ARP replies received 0 total packets dropped due to no ARP entry 469 ARP entrys timed out 0 Duplicate IPs seen Best, George Index: usr.bin/netstat/inet.c =================================================================== --- usr.bin/netstat/inet.c (revision 196095) +++ usr.bin/netstat/inet.c (working copy) @@ -49,6 +49,7 @@ #include #include +#include #include #include #include @@ -871,6 +872,44 @@ #undef p1a } +/* + * Dump ARP statistics structure. + */ +void +arp_stats(u_long off, const char *name, int af1 __unused, int proto __unused) +{ + struct arpstat arpstat, zerostat; + size_t len = sizeof(arpstat); + + if (live) { + if (zflag) + memset(&zerostat, 0, len); + if (sysctlbyname("net.link.ether.arp.stats", &arpstat, &len, + zflag ? &zerostat : NULL, zflag ? len : 0) < 0) { + warn("sysctl: net.link.ether.arp.stats"); + return; + } + } else + kread(off, &arpstat, len); + + printf("%s:\n", name); + +#define p(f, m) if (arpstat.f || sflag <= 1) \ + printf(m, arpstat.f, plural(arpstat.f)) +#define p1a(f, m) if (arpstat.f || sflag <= 1) \ + printf(m, arpstat.f) + + p(arp_requests, "\t%lu ARP request%s sent\n"); + p(arp_replies, "\t%lu ARP replie%s received\n"); + p(arp_dropped, "\t%lu total packet%s dropped due to no ARP entry\n"); + p(arp_timeout, "\t%lu ARP entry%s timed out\n"); + p(arp_dupips, "\t%lu Duplicate IP%s seen\n"); +#undef p +#undef p1a +} + + + static const char *icmpnames[ICMP_MAXTYPE + 1] = { "echo reply", /* RFC 792 */ "#1", Index: usr.bin/netstat/main.c =================================================================== --- usr.bin/netstat/main.c (revision 196095) +++ usr.bin/netstat/main.c (working copy) @@ -184,6 +184,8 @@ { .n_name = "_sctpstat" }, #define N_MFCTABLESIZE 54 { .n_name = "_mfctablesize" }, +#define N_ARPSTAT 55 + { .n_name = "_arpstat" }, { .n_name = NULL }, }; @@ -232,6 +234,8 @@ carp_stats, NULL, "carp", 1, 0 }, { -1, N_PFSYNCSTAT, 1, NULL, pfsync_stats, NULL, "pfsync", 1, 0 }, + { -1, N_ARPSTAT, 1, NULL, + arp_stats, NULL, "arp", 1, 0 }, { -1, -1, 0, NULL, NULL, NULL, NULL, 0, 0 } }; Index: usr.bin/netstat/netstat.h =================================================================== --- usr.bin/netstat/netstat.h (revision 196095) +++ usr.bin/netstat/netstat.h (working copy) @@ -75,6 +75,7 @@ void sctp_protopr(u_long, const char *, int, int); void sctp_stats(u_long, const char *, int, int); #endif +void arp_stats(u_long, const char *, int, int); void ip_stats(u_long, const char *, int, int); void icmp_stats(u_long, const char *, int, int); void igmp_stats(u_long, const char *, int, int); Index: sys/netinet/if_ether.c =================================================================== --- sys/netinet/if_ether.c (revision 196095) +++ sys/netinet/if_ether.c (working copy) @@ -80,6 +80,7 @@ SYSCTL_DECL(_net_link_ether); SYSCTL_NODE(_net_link_ether, PF_INET, inet, CTLFLAG_RW, 0, ""); +SYSCTL_NODE(_net_link_ether, PF_ARP, arp, CTLFLAG_RW, 0, ""); VNET_DEFINE(int, useloopback) = 1; /* use loopback interface for * local traffic */ @@ -108,6 +109,11 @@ &VNET_NAME(arp_proxyall), 0, "Enable proxy ARP for all suitable requests"); +struct arpstat arpstat; /* ARP statistics, see if_arp.h */ +SYSCTL_STRUCT(_net_link_ether_arp, OID_AUTO, stats, CTLFLAG_RW, + &arpstat, arpstat, + "ARP statistics (struct arpstat, net/if_arp.h)"); + static void arp_init(void); void arprequest(struct ifnet *, struct in_addr *, struct in_addr *, u_char *); @@ -127,6 +133,7 @@ #ifdef AF_INET void arp_ifscrub(struct ifnet *ifp, uint32_t addr); + /* * called by in_ifscrub to remove entry from the table when * the interface goes away @@ -165,12 +172,13 @@ ifp = lle->lle_tbl->llt_ifp; IF_AFDATA_LOCK(ifp); LLE_WLOCK(lle); - if (((lle->la_flags & LLE_DELETED) - || (time_second >= lle->la_expire)) - && (!callout_pending(&lle->la_timer) && - callout_active(&lle->la_timer))) + if (((lle->la_flags & LLE_DELETED) || + (time_second >= lle->la_expire)) && + (!callout_pending(&lle->la_timer) && + callout_active(&lle->la_timer))) { (void) llentry_free(lle); - else { + arpstat.arp_timeout++; + } else { /* * Still valid, just drop our reference */ @@ -238,6 +246,7 @@ sa.sa_len = 2; m->m_flags |= M_BCAST; (*ifp->if_output)(ifp, m, &sa, NULL); + arpstat.arp_requests++; } /* @@ -339,8 +348,10 @@ * latest one. */ if (m != NULL) { - if (la->la_hold != NULL) + if (la->la_hold != NULL) { m_freem(la->la_hold); + arpstat.arp_dropped++; + } la->la_hold = m; if (renew == 0 && (flags & LLE_EXCLUSIVE)) { flags &= ~LLE_EXCLUSIVE; @@ -413,6 +424,7 @@ ar = mtod(m, struct arphdr *); } + arpstat.arp_replies++; switch (ntohs(ar->ar_pro)) { #ifdef INET case ETHERTYPE_IP: @@ -603,6 +615,7 @@ ifp->if_addrlen, (u_char *)ar_sha(ah), ":", inet_ntoa(isaddr), ifp->if_xname); itaddr = myaddr; + arpstat.arp_dupips++; goto reply; } if (ifp->if_flags & IFF_STATICARP) @@ -821,7 +834,7 @@ static void arp_init(void) { - + bzero(&arpstat, sizeof(arpstat)); netisr_register(&arp_nh); } SYSINIT(arp, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, arp_init, 0); Index: sys/net/if_arp.h =================================================================== --- sys/net/if_arp.h (revision 196095) +++ sys/net/if_arp.h (working copy) @@ -108,6 +108,16 @@ #define IFP2AC(ifp) ((struct arpcom *)(ifp->if_l2com)) #define AC2IFP(ac) ((ac)->ac_ifp) -#endif +#endif /* _KERNEL */ +struct arpstat { + /* Normal things that happen */ + u_long arp_requests; /* # of ARP requests sent by this host */ + u_long arp_replies; /* # of ARP replies received by this host */ + /* Abnormal event and error counting */ + u_long arp_dropped; /* # of packets dropped while waiting for a reply */ + u_long arp_timeout; /* # of times an entry is removed due to timeout */ + u_long arp_dupips; /* # of duplicate IPs detected. */ +}; + #endif /* !_NET_IF_ARP_H_ */ From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 21:36:29 2009 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 47E09106566B for ; Wed, 12 Aug 2009 21:36:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id ED57A8FC47 for ; Wed, 12 Aug 2009 21:36:28 +0000 (UTC) Received: by mail-yx0-f181.google.com with SMTP id 11so462269yxe.3 for ; Wed, 12 Aug 2009 14:36:28 -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=0GoSbJZbIhxGje95SEey4zKxcivexqjB1TxP5QIW/0s=; b=LrvzRF/N+Wc+BIDURxbp0Tqykx7HquDYbvR5UpOR9LFphgNTVgrzgJrYeUBtLobaU7 NXJfb1ixYCWHq0lrhfu7yqIL/yiP3nXkf3RMBgytrlz+9QysBEjMLjaFGfS/JzxmaW3m Oz58KKiIS6r1HC4hd5klhm0fWsPb42uDRNXCI= 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=cpd0daCIdm8aN6+fM5e/aJOTM0Nb0bD5W3A/wkmpcYzoFffCdQGbulihVQ4YjKE94m 0d0K+Q293fRXc4ANv0N4AVn2A98ktSkbj7bwtqXfP241mh21Fa/QWH0/izWDweppY59I Ucdoo2YY5Z+LGniusQ2nES5GVAVaNag9sxu08= Received: by 10.101.165.2 with SMTP id s2mr475064ano.16.1250112985642; Wed, 12 Aug 2009 14:36:25 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c14sm532519ana.19.2009.08.12.14.36.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 14:36:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Aug 2009 14:35:21 -0700 From: Pyun YongHyeon Date: Wed, 12 Aug 2009 14:35:21 -0700 To: Peter Steele Message-ID: <20090812213521.GG55129@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: nfe taskq performance issues 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: Wed, 12 Aug 2009 21:36:29 -0000 On Thu, Jul 23, 2009 at 08:58:07AM -0700, Peter Steele wrote: > We've been hitting serious nfe taskq performance issues during stress > tests and in doing some research on the problem we came across this old > email: > > > > From: Ivan Voras > Date: April 28, 2009 3:53:14 AM PDT > To: freebsd-threads@freebsd.org > Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org > Subject: Re: FreeBSD 7.1 taskq em performance > > > > I have been hitting some barrier with FreeBSD 7.1 network performance. > I > > have written an application which contains two kernel threads that > takes > > mbufs directly from a network interface and forwards to another > network > > interface. This idea is to simulate different network environment. > > > > I have been using FreeBSD 6.4 amd64 and tested with an Ixia box > > (specialised hardware firing very high packet rate). The PC was a > Core2 2.6 > > GHz with dual ports Intel PCIE Gigabit network card. It can manage up > to 1.2 > > million pps. > > > > I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz > and > > PCIE Gigabit network card. The performance can only achieve up to 600k > pps. > > I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is > not in > > FreeBSD 6.4. > > > > In our case we are running FreeBSD 7.0, but we are seeing our boxes > experience serious thread starvation issues as the nfe0 cpu percentage > climbs steadily while cpu idle time drops at times to 0 percent. This > email thread mentioned a patch for the em driver here: > > > > http://people.yandex-team.ru/~wawa/ > > > > > Does anyone know if this patch will work with the nfe driver? > That's for em(4). AFAIK all nfe(4) controllers lacks intelligent interrupts moderation so driver should be prepared to handle excessive interrupt loads. I'm not sure whether NVIDIA ethernet controllers really lacks efficient interrupt mitigation mechanism but it seems Linux also faces the same hardware problem. As you might know there is no publicly available data sheet for NVIDIA controllers so setting it right looks very hard to me. From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 21:37:30 2009 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 93C12106567B; Wed, 12 Aug 2009 21:37:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB7D8FC15; Wed, 12 Aug 2009 21:37:30 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7CLbUHr020263; Wed, 12 Aug 2009 21:37:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7CLbUPw020259; Wed, 12 Aug 2009 21:37:30 GMT (envelope-from linimon) Date: Wed, 12 Aug 2009 21:37:30 GMT Message-Id: <200908122137.n7CLbUPw020259@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in 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, 12 Aug 2009 21:37:31 -0000 Old Synopsis: NET_RT_DUMP not working in FreeBSD 8 New Synopsis: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 12 21:36:18 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137700 From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 21:59:40 2009 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 0E2931065674; Wed, 12 Aug 2009 21:59:40 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id E77EE8FC51; Wed, 12 Aug 2009 21:59:39 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7CLw6el009017; Wed, 12 Aug 2009 14:59:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 14:59:06 -0700 Message-ID: In-Reply-To: <200908122137.n7CLbUPw020259@freefall.freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Thread-Index: AcoblTboaVD+bjgwR/CS0o5QrNc4RwAAovgA References: <200908122137.n7CLbUPw020259@freefall.freebsd.org> From: "Li, Qing" To: , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, linimon@freebsd.org Subject: RE: bin/137700: sysctl(8): NET_RT_DUMP not working in 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, 12 Aug 2009 21:59:40 -0000 Hi, What's not working ? The code reported in the bug is identical to the code in /usr.sbin/netstat/route.c, function "ntreestuff()". Please take a look at this code. "netstat -r" works in FreeBSD 8. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of linimon@freebsd.org > Sent: Wednesday, August 12, 2009 2:38 PM > To: linimon@freebsd.org; freebsd-bugs@freebsd.org; freebsd- > net@freebsd.org > Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD > 8 >=20 > Old Synopsis: NET_RT_DUMP not working in FreeBSD 8 > New Synopsis: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 >=20 > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Aug 12 21:36:18 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D137700 > _______________________________________________ > 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 Aug 12 22:30:07 2009 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 EB36C1065673 for ; Wed, 12 Aug 2009 22:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9CEB38FC1F for ; Wed, 12 Aug 2009 22:30:07 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7CMU7fq056623 for ; Wed, 12 Aug 2009 22:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7CMU7Gt056618; Wed, 12 Aug 2009 22:30:07 GMT (envelope-from gnats) Date: Wed, 12 Aug 2009 22:30:07 GMT Message-Id: <200908122230.n7CMU7Gt056618@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bjoern A. Zeeb" Cc: Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 22:30:08 -0000 The following reply was made to PR bin/137700; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, lab@gta.com Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Date: Wed, 12 Aug 2009 22:24:14 +0000 (UTC) On Wed, 12 Aug 2009, Li, Qing wrote: > Hi, > > What's not working ? > > The code reported in the bug is identical to the code in > /usr.sbin/netstat/route.c, function "ntreestuff()". > Please take a look at this code. > > "netstat -r" works in FreeBSD 8. uses kvm still. If the sysctl doesn't work, then that's probably my fault; assign the PR to bz and I'll look. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 22:35:27 2009 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 B96511065687; Wed, 12 Aug 2009 22:35:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7385D8FC41; Wed, 12 Aug 2009 22:35:27 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D2F3C41C690; Thu, 13 Aug 2009 00:25:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id bR3Y1ggV8cEM; Thu, 13 Aug 2009 00:25:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 5C3B441C679; Thu, 13 Aug 2009 00:25: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 893694448EC; Wed, 12 Aug 2009 22:24:14 +0000 (UTC) Date: Wed, 12 Aug 2009 22:24:14 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: bug-followup@FreeBSD.org, lab@gta.com In-Reply-To: Message-ID: <20090812222214.S93661@maildrop.int.zabbadoz.net> References: <200908122137.n7CLbUPw020259@freefall.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in 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, 12 Aug 2009 22:35:28 -0000 On Wed, 12 Aug 2009, Li, Qing wrote: > Hi, > > What's not working ? > > The code reported in the bug is identical to the code in > /usr.sbin/netstat/route.c, function "ntreestuff()". > Please take a look at this code. > > "netstat -r" works in FreeBSD 8. uses kvm still. If the sysctl doesn't work, then that's probably my fault; assign the PR to bz and I'll look. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 23:12:16 2009 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 BC183106566C; Wed, 12 Aug 2009 23:12:16 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 94E088FC49; Wed, 12 Aug 2009 23:12:16 +0000 (UTC) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7CNCGH1093408; Wed, 12 Aug 2009 23:12:16 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7CNCGPX093404; Wed, 12 Aug 2009 23:12:16 GMT (envelope-from bz) Date: Wed, 12 Aug 2009 23:12:16 GMT Message-Id: <200908122312.n7CNCGPX093404@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in 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, 12 Aug 2009 23:12:17 -0000 Synopsis: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Wed Aug 12 23:11:55 UTC 2009 Responsible-Changed-Why: My bug. my fix. http://www.freebsd.org/cgi/query-pr.cgi?pr=137700 From owner-freebsd-net@FreeBSD.ORG Wed Aug 12 23:30:28 2009 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 0AD711065673; Wed, 12 Aug 2009 23:30:28 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id B66D88FC16; Wed, 12 Aug 2009 23:30:27 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7FCF041C667; Thu, 13 Aug 2009 01:15:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 7KQMrlFKPCOu; Thu, 13 Aug 2009 01:15:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 05F2241C64C; Thu, 13 Aug 2009 01:15:06 +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 BA5E54448EC; Wed, 12 Aug 2009 23:14:48 +0000 (UTC) Date: Wed, 12 Aug 2009 23:14:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: bug-followup@FreeBSD.org, lab@gta.com In-Reply-To: <20090812222214.S93661@maildrop.int.zabbadoz.net> Message-ID: <20090812231244.U93661@maildrop.int.zabbadoz.net> References: <200908122137.n7CLbUPw020259@freefall.freebsd.org> <20090812222214.S93661@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/137700: sysctl(8): NET_RT_DUMP not working in FreeBSD 8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bug-followup@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 23:30:28 -0000 On Wed, 12 Aug 2009, Bjoern A. Zeeb wrote: Here's the fix (untested): http://people.freebsd.org/~bz/20090812-04-rtsock-rt_dump-bugfix-pr137700.diff Shame on me:( /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 10:22:48 2009 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 4482E106566B for ; Thu, 13 Aug 2009 10:22:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C603B8FC3A for ; Thu, 13 Aug 2009 10:22:47 +0000 (UTC) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 251466005 for freebsd-net@freebsd.org; Thu, 13 Aug 2009 12:22:43 +0300 Message-ID: <4A83DB62.9090303@FreeBSD.org> Date: Thu, 13 Aug 2009 12:22:42 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.22 (X11/20090805) MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: RFC: server side support for libradius 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, 13 Aug 2009 10:22:48 -0000 Hi. I have made a patch, extending libradius functionality by adding simple embedded RADIUS server support to it. It doesn't change any of existing client functionality and reuses much of it's code. Only four new functions were added with respect to the new server operation flow: rad_server_open(), rad_receive_request(), rad_create_response() and rad_send_response(). First consumer of this functionality is going to become forthcoming mpd5.4 release (now in CVS). It will include embedded RADIUS server, to support long awaited RADIUS Dynamic Authorization Extensions (RFC 3576), such as Change-of-Authorization (CoA) and Disconnect-Request (DR/PoD). Patch against HEAD (it should apply clean to previous versions): http://people.freebsd.org/~mav/libradius.server.20090813.patch If there will be no objections, I am going to commit it to the HEAD and merge down as soon as tree will be unfrozen. This work was sponsored by JSC "Ufanet", http://ufanet.ru/. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 10:46:18 2009 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 EA59D106564A for ; Thu, 13 Aug 2009 10:46:17 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 215208FC47 for ; Thu, 13 Aug 2009 10:46:17 +0000 (UTC) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 4DD755C025 for ; Thu, 13 Aug 2009 18:46:16 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 07A0A55CDC2D; Thu, 13 Aug 2009 18:46:16 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id hiZ62lUeApFs; Thu, 13 Aug 2009 18:45:22 +0800 (CST) Received: from charlie.delphij.net (c-67-188-2-183.hsd1.ca.comcast.net [67.188.2.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1CE5E55CDC1F; Thu, 13 Aug 2009 18:45:14 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type; b=FwapPwgnh3mdEKa2rQBQCB1u09aBI76D6IZXBGkKteRSMaafcpRTR5gProAD/PUVg DXj28lXMdi/tTXK0xlsuw== Message-ID: <4A83EEA8.5080202@delphij.net> Date: Thu, 13 Aug 2009 03:44:56 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090803) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.96.0 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------090505000704070004090000" Subject: RFC: interface description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 10:46:18 -0000 This is a multi-part message in MIME format. --------------090505000704070004090000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, While playing with some OpenBSD installation I found that they have an interesting feature - adding description to a NIC. This is useful for system administrators to "tag" the interface, also, the ladvd program has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP peer like: em0: flags=8843 metric 0 mtu 1500 ether 00:11:22:33:44:55 description: connected to myrouter.home (CDP) [...] The attached patch ported the feature to FreeBSD. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqD7qgACgkQi+vbBBjt66CF+QCeO6INwh3S1T/LvhIUTjZ/Ix4H zQkAniftv+SQ+irEcnItGHTbLH0HyUez =cEsJ -----END PGP SIGNATURE----- --------------090505000704070004090000 Content-Type: text/plain; name="ifdescr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifdescr.diff" Index: sbin/ifconfig/ifconfig.8 =================================================================== --- sbin/ifconfig/ifconfig.8 (revision 196163) +++ sbin/ifconfig/ifconfig.8 (working copy) @@ -28,7 +28,7 @@ .\" From: @(#)ifconfig.8 8.3 (Berkeley) 1/5/94 .\" $FreeBSD$ .\" -.Dd July 8, 2009 +.Dd September 14, 2009 .Dt IFCONFIG 8 .Os .Sh NAME @@ -258,6 +258,12 @@ Disable permanently promiscuous mode. Another name for the .Fl alias parameter. +.It Cm description Ar value +Specify a description of the interface. +This can be used to label interfaces in situations where they may +otherwise be difficult to distinguish. +.It Cm -description +Clear the interface description. .It Cm down Mark an interface .Dq down . @@ -2443,6 +2449,10 @@ Configure the interface to use 100baseTX, full duplex Ethernet media options: .Dl # ifconfig xl0 media 100baseTX mediaopt full-duplex .Pp +Label the em0 interface as an uplink: +.Pp +.Dl # ifconfig em0 description \&"Uplink to Gigabit Switch 2\&" +.Pp Create the software network interface .Li gif1 : .Dl # ifconfig gif1 create Index: sbin/ifconfig/ifconfig.c =================================================================== --- sbin/ifconfig/ifconfig.c (revision 196163) +++ sbin/ifconfig/ifconfig.c (working copy) @@ -83,6 +83,7 @@ static const char rcsid[] = struct ifreq ifr; char name[IFNAMSIZ]; +char descr[IFDESCRSIZE]; int setaddr; int setmask; int doalias; @@ -822,6 +823,36 @@ setifname(const char *val, int dummy __unused, int free(newname); } +/* ARGSUSED */ +static void +setifdescr(const char *val, int dummy __unused, int s, + const struct afswtch *afp) +{ + char *newdescr; + + newdescr = strdup(val); + if (newdescr == NULL) { + warn("no memory to set ifdescr"); + return; + } + ifr.ifr_data = newdescr; + if (ioctl(s, SIOCSIFDESCR, (caddr_t)&ifr) < 0) { + warn("ioctl (set descr)"); + free(newdescr); + return; + } + strlcpy(descr, newdescr, sizeof(descr)); + free(newdescr); +} + +/* ARGSUSED */ +static void +unsetifdescr(const char *val, int value, int s, const struct afswtch *afp) +{ + + setifdescr("", 0, s, 0); +} + #define IFFBITS \ "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ @@ -866,6 +897,11 @@ status(const struct afswtch *afp, const struct soc printf(" mtu %d", ifr.ifr_mtu); putchar('\n'); + ifr.ifr_data = (caddr_t)&descr; + if (ioctl(s, SIOCGIFDESCR, &ifr) == 0 && + strlen(ifr.ifr_data) > 0) + printf("\tdescription: %s\n", ifr.ifr_data); + if (ioctl(s, SIOCGIFCAP, (caddr_t)&ifr) == 0) { if (ifr.ifr_curcap != 0) { printb("\toptions", ifr.ifr_curcap, IFCAPBITS); @@ -1035,6 +1071,10 @@ static struct cmd basic_cmds[] = { DEF_CMD("-arp", IFF_NOARP, setifflags), DEF_CMD("debug", IFF_DEBUG, setifflags), DEF_CMD("-debug", -IFF_DEBUG, setifflags), + DEF_CMD_ARG("description", setifdescr), + DEF_CMD_ARG("descr", setifdescr), + DEF_CMD("-description", 0, unsetifdescr), + DEF_CMD("-descr", 0, unsetifdescr), DEF_CMD("promisc", IFF_PPROMISC, setifflags), DEF_CMD("-promisc", -IFF_PPROMISC, setifflags), DEF_CMD("add", IFF_UP, notealias), Index: share/man/man4/netintro.4 =================================================================== --- share/man/man4/netintro.4 (revision 196163) +++ share/man/man4/netintro.4 (working copy) @@ -32,7 +32,7 @@ .\" @(#)netintro.4 8.2 (Berkeley) 11/30/93 .\" $FreeBSD$ .\" -.Dd June 18, 2004 +.Dd September 15, 2009 .Dt NETINTRO 4 .Os .Sh NAME @@ -277,6 +277,15 @@ and fields of the .Vt ifreq structure, respectively. +.It Dv SIOCGIFDESCR Fa "struct ifreq *" +Get the interface description, returned in the +.Va ifru_data +field. +.It Dv SIOCSIFDESCR Fa "struct ifreq *" +Set the interface description to the value of the +.Va ifru_data +field, limited to the size of +.Dv IFDESCRSIZE . .It Dv SIOCSIFFLAGS Set interface flags field. If the interface is marked down, Index: sys/kern/kern_jail.c =================================================================== --- sys/kern/kern_jail.c (revision 196163) +++ sys/kern/kern_jail.c (working copy) @@ -3437,6 +3437,7 @@ prison_priv_check(struct ucred *cred, int priv) case PRIV_NET_SETIFMETRIC: case PRIV_NET_SETIFPHYS: case PRIV_NET_SETIFMAC: + case PRIV_NET_SETIFDESCR: case PRIV_NET_ADDMULTI: case PRIV_NET_DELMULTI: case PRIV_NET_HWIOCTL: Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 196163) +++ sys/net/if.c (working copy) @@ -1927,6 +1927,7 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d int new_flags, temp_flags; size_t namelen, onamelen; char new_name[IFNAMSIZ]; + char ifdescrbuf[IFDESCRSIZE]; struct ifaddr *ifa; struct sockaddr_dl *sdl; @@ -1965,6 +1966,25 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d ifr->ifr_phys = ifp->if_physical; break; + case SIOCGIFDESCR: + bzero(ifdescrbuf, sizeof(ifdescrbuf)); + strlcpy(ifdescrbuf, ifp->if_description, IFDESCRSIZE); + error = copyout(ifdescrbuf, ifr->ifr_data, IFDESCRSIZE); + break; + + case SIOCSIFDESCR: + error = priv_check(td, PRIV_NET_SETIFDESCR); + if (error) + return (error); + error = copyinstr(ifr->ifr_data, ifdescrbuf, + IFDESCRSIZE, NULL); + if (error == 0) { + bzero(ifp->if_description, IFDESCRSIZE); + strlcpy(ifp->if_description, ifdescrbuf, IFDESCRSIZE); + getmicrotime(&ifp->if_lastchange); + } + break; + case SIOCSIFFLAGS: error = priv_check(td, PRIV_NET_SETIFFLAGS); if (error) Index: sys/net/if.h =================================================================== --- sys/net/if.h (revision 196163) +++ sys/net/if.h (working copy) @@ -60,6 +60,10 @@ struct ifnet; #define IFNAMSIZ IF_NAMESIZE #define IF_MAXUNIT 0x7fff /* historical value */ #endif + +/* Length of interface description, including terminating '\0'. */ +#define IFDESCRSIZE 64 + #if __BSD_VISIBLE /* Index: sys/net/if_var.h =================================================================== --- sys/net/if_var.h (revision 196163) +++ sys/net/if_var.h (working copy) @@ -197,6 +197,7 @@ struct ifnet { void *if_pf_kif; void *if_lagg; /* lagg glue */ u_char if_alloctype; /* if_type at time of allocation */ + char if_description[IFDESCRSIZE]; /* interface description */ /* * Spare fields are added so that we can modify sensitive data Index: sys/sys/priv.h =================================================================== --- sys/sys/priv.h (revision 196163) +++ sys/sys/priv.h (working copy) @@ -335,6 +335,7 @@ #define PRIV_NET_LAGG 415 /* Administer lagg interface. */ #define PRIV_NET_GIF 416 /* Administer gif interface. */ #define PRIV_NET_SETIFVNET 417 /* Move interface to vnet. */ +#define PRIV_NET_SETIFDESCR 418 /* Set interface description. */ /* * 802.11-related privileges. --------------090505000704070004090000-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 11:34:26 2009 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 772B41065673 for ; Thu, 13 Aug 2009 11:34:26 +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 BCF988FC65 for ; Thu, 13 Aug 2009 11:34:25 +0000 (UTC) Received: (qmail 76684 invoked from network); 13 Aug 2009 11:34:24 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Aug 2009 11:34:24 -0000 Date: Thu, 13 Aug 2009 13:34:24 +0200 (CEST) Message-Id: <20090813.133424.41729466.sthaug@nethelp.no> To: d@delphij.net, delphij@delphij.net From: sthaug@nethelp.no In-Reply-To: <4A83EEA8.5080202@delphij.net> References: <4A83EEA8.5080202@delphij.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 Subject: Re: RFC: interface description 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, 13 Aug 2009 11:34:26 -0000 > While playing with some OpenBSD installation I found that they have an > interesting feature - adding description to a NIC. This is useful for > system administrators to "tag" the interface, also, the ladvd program > has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP > peer like: Yes please! This is an "obvious" feature to those of us who are router geeks, and I've been wishing for this to show up in FreeBSD for years. Now if I could have "sticky" static routes also I would be even happier (as in: Next hop disappears -> route disappears. Next hop available again -> route shows up in routing table again). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 11:56:34 2009 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 6C8D7106567C for ; Thu, 13 Aug 2009 11:56:34 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 238688FC4A for ; Thu, 13 Aug 2009 11:56:32 +0000 (UTC) Received: (qmail 63274 invoked by uid 60001); 13 Aug 2009 11:56:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250164592; bh=H349Hk3jfSjEHQWEkIeD3Ic6djCg/pwxZiW3+9WD9q4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2fHNAAYST1XSJ7CIBljq1QPIXk328XJmaM65MOGx6iAAanI6mNpEcuvMYo8hr0WkqP9nNPcpxQcZSzdynoSvub9nm1JIuBav+W4D4Tq2+OccGqDFBHTEH+UzGRjVDZZVnct4JAW0lBcapLB+DB8A9MtHI0HesGiNFJEY6u+X5ck= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=veOvk4q8K+/pCCOspEwT9bdWaKe/H48lU2oKvBENauKnn5Jh/6mwORncfjKJwsjE6qvML+r/Aadi1TZzWmq6ulZESX0zW5ED5d7VTU1XM9XjzAIw9sZmciTp2YC5oVmICPcRpK7amj1rKKU4zNgymL7G1/pkbRdue2NW6fXT4B0=; Message-ID: <430428.63263.qm@web63902.mail.re1.yahoo.com> X-YMail-OSG: gl1OqG8VM1l9rjwEqXqTidNctAOwuPi3MnoMMMGLDNfMbT6A0IDV62w6nHM2lzckfWIWDIu2njfcc_wljExKGn2PYTeAHcR8FsBKrc1nHKpcWHYD_ybXrX_JOf23oSbi6yV8HemlIDyrj4KTbv1yqLTbfOTJ4QC_bz71L_YPDiZf6hPYRl1bAVSGNja.Lem8tefMFheGHLNfSQEos7jtzdgxQvdLYo9Q.Zw9H19KB9jZObeYYTX9xPsjLnYe6Uubatf_iIp4GuIbvZFM8Qasj5iGg5G4j53TpSpx.SaVSX0r9B50Fm8qnyitvQ-- Received: from [66.176.162.245] by web63902.mail.re1.yahoo.com via HTTP; Thu, 13 Aug 2009 04:56:32 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Thu, 13 Aug 2009 04:56:32 -0700 (PDT) From: Barney Cordoba To: Peter Steele , pyunyh@gmail.com In-Reply-To: <20090812213521.GG55129@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: nfe taskq performance issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:56:34 -0000 =0A=0A--- On Wed, 8/12/09, Pyun YongHyeon wrote:=0A=0A> = From: Pyun YongHyeon =0A> Subject: Re: nfe taskq performa= nce issues=0A> To: "Peter Steele" =0A> Cc: f= reebsd-net@freebsd.org=0A> Date: Wednesday, August 12, 2009, 5:35 PM=0A> On= Thu, Jul 23, 2009 at 08:58:07AM=0A> -0700, Peter Steele wrote:=0A> > We've= been hitting serious nfe taskq performance=0A> issues during stress=0A> > = tests and in doing some research on the problem we=0A> came across this old= =0A> > email:=0A> > =0A> >=A0 =0A> > =0A> > From: Ivan Voras =0A> > Date: April 28, 2009 3:53:14 AM PDT=0A> > To: freebsd-threads@= freebsd.org=0A> > Cc: freebsd-net@freebsd.org,=0A> freebsd-performance@free= bsd.org=0A> > Subject: Re: FreeBSD 7.1 taskq em performance=0A> > >=0A> > >= I have been hitting some barrier with FreeBSD 7.1=0A> network performance.= =0A> > I=0A> > > have written an application which contains two=0A> kernel = threads that=0A> > takes=0A> > > mbufs directly from a network interface an= d=0A> forwards to another=0A> > network=0A> > > interface. This idea is to = simulate different=0A> network environment.=0A> > >=0A> > > I have been usi= ng FreeBSD 6.4 amd64 and tested=0A> with an Ixia box=0A> > > (specialised h= ardware firing very high packet=0A> rate). The PC was a=0A> > Core2 2.6=0A>= > > GHz with dual ports Intel PCIE Gigabit network=0A> card. It can manage= up=0A> > to 1.2=0A> > > million pps.=0A> > >=0A> > > I have a higher spec = PC with FreeBSD 7.1 amd64=0A> and Quadcore 2.3 GHz=0A> > and=0A> > > PCIE G= igabit network card. The performance can=0A> only achieve up to 600k=0A> > = pps.=0A> > > I notice the 'taskq em0' and 'taskq em1' is solid=0A> 100% CPU= but it is=0A> > not in=0A> > > FreeBSD 6.4. =0A> > =0A> >=A0 =0A> > =0A> >= In our case we are running FreeBSD 7.0, but we are=0A> seeing our boxes=0A= > > experience serious thread starvation issues as the=0A> nfe0 cpu percent= age=0A> > climbs steadily while cpu idle time drops at times to=0A> 0 perce= nt. This=0A> > email thread mentioned a patch for the em driver=0A> here:= =0A> > =0A> >=A0 =0A> > =0A> > http://people.yandex-team.ru/~wawa/ =0A> > <= http://people.yandex-team.ru/%7Ewawa/>=0A> =0A> > =0A> >=A0 =0A> > =0A> > D= oes anyone know if this patch will work with the nfe=0A> driver?=0A> > =0A>= =0A> That's for em(4).=0A> =0A> AFAIK all nfe(4) controllers lacks intelli= gent interrupts=0A> moderation so driver should be prepared to handle=0A> e= xcessive=0A> interrupt loads. I'm not sure whether NVIDIA ethernet=0A> cont= rollers=0A> really lacks efficient interrupt mitigation mechanism but=0A> i= t=0A> seems Linux also faces the same hardware problem.=0A> As you might kn= ow there is no publicly available data sheet=0A> for=0A> NVIDIA controllers= so setting it right looks very hard to=0A> me.=0A> =0A=0ATry removing the = INTR_MPSAFE flag from the bus_setup_intr() call.=0AThe entire point of usin= g filters is to reduce lock contention.=0AIt might not solve the problem bu= t its clearly an unnecessary=0Apotential bottleneck.=0A=0ABarney=0A=0A=0A = From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 12:37:26 2009 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 093BD1065678 for ; Thu, 13 Aug 2009 12:37:26 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63904.mail.re1.yahoo.com (web63904.mail.re1.yahoo.com [69.147.97.119]) by mx1.freebsd.org (Postfix) with SMTP id A6B928FC72 for ; Thu, 13 Aug 2009 12:37:25 +0000 (UTC) Received: (qmail 18759 invoked by uid 60001); 13 Aug 2009 12:37:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250167044; bh=2fByGnqq2nnQmlt9ur5GcEKLpL7Kn1WMCuk9faQ0YgM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wCrOhpZ31ocKVZl182ZHIAZu8Z+fuOUsjIilFrWa4I/3X4KcGd5D69VJ5h2D6yZZ42we07lUthPDBGd2X4O+annNqqOURXNQ20cfiPa8AsqHww01/995RcrL4DHyXG/5h27/No2br/YZ84tS+QIFNvdf1hkJhbZ7pBPWp2Lz9+o= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=M5D819koxHV3hkfgd2+RvY3O1P4/dwsMx1AZ667VRpkE2/YDjhp4OqZ8A9t4ozDhpW8z0GkgmypTjN0K/OTyHFKVuC59ToKw18WLwuxBTKOkDecl94A57jKY6OeYYhVLe4SChdWn+If2HtLVK3Y134XcLN3hICqlp6VLE8OQZSo=; Message-ID: <978222.18685.qm@web63904.mail.re1.yahoo.com> X-YMail-OSG: sIq0h_UVM1m3KRFbVcKqm17BHgOvRhOyqVwJx8RilKGGXLuHyGQn8eVcoIa5wg2xxgQevN84.MGiheFhNc6cscXVMSeE6gs6o73IU4ZLU9VCTg7RH9GcMhvcLXhMVB0IH2K.5hEpR77P7TmeyMVpek6.Toh7jumkuKVMyoSP3GMP_qD1V1Mu4EQEshC.z5rCpYj6DJsRsbYUUGlzIexkC8Ti5agAPoj5vjFTJkD.OQgGuf9vOtRhDHX_APrS4c6LnE2RyiV1NUCyUN2PuGBxuKNgqEF.NSvz8FSk10cokTLHMoqYgcr4ApvjZg-- Received: from [66.176.162.245] by web63904.mail.re1.yahoo.com via HTTP; Thu, 13 Aug 2009 05:37:24 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Thu, 13 Aug 2009 05:37:24 -0700 (PDT) From: Barney Cordoba To: Peter Steele , pyunyh@gmail.com In-Reply-To: <430428.63263.qm@web63902.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: nfe taskq performance issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 12:37:26 -0000 =0A=0A--- On Thu, 8/13/09, Barney Cordoba wrote:= =0A=0A> From: Barney Cordoba =0A> Subject: Re: nf= e taskq performance issues=0A> To: "Peter Steele" , pyunyh@gmail.com=0A> Cc: freebsd-net@freebsd.org=0A> Date: Thursday= , August 13, 2009, 7:56 AM=0A> =0A> =0A> --- On Wed, 8/12/09, Pyun YongHyeo= n =0A> wrote:=0A> =0A> > From: Pyun YongHyeon =0A> > Subject: Re: nfe taskq performance issues=0A> > To: "Peter St= eele" =0A> > Cc: freebsd-net@freebsd.org=0A>= > Date: Wednesday, August 12, 2009, 5:35 PM=0A> > On Thu, Jul 23, 2009 at = 08:58:07AM=0A> > -0700, Peter Steele wrote:=0A> > > We've been hitting seri= ous nfe taskq performance=0A> > issues during stress=0A> > > tests and in d= oing some research on the problem=0A> we=0A> > came across this old=0A> > >= email:=0A> > > =0A> > >=A0 =0A> > > =0A> > > From: Ivan Voras =0A> > > Date: April 28, 2009 3:53:14 AM PDT=0A> > > To: freebsd-th= reads@freebsd.org=0A> > > Cc: freebsd-net@freebsd.org,=0A> > freebsd-perfor= mance@freebsd.org=0A> > > Subject: Re: FreeBSD 7.1 taskq em performance=0A>= > > >=0A> > > > I have been hitting some barrier with=0A> FreeBSD 7.1=0A> = > network performance.=0A> > > I=0A> > > > have written an application whic= h contains=0A> two=0A> > kernel threads that=0A> > > takes=0A> > > > mbufs = directly from a network interface and=0A> > forwards to another=0A> > > net= work=0A> > > > interface. This idea is to simulate=0A> different=0A> > netw= ork environment.=0A> > > >=0A> > > > I have been using FreeBSD 6.4 amd64 an= d=0A> tested=0A> > with an Ixia box=0A> > > > (specialised hardware firing = very high=0A> packet=0A> > rate). The PC was a=0A> > > Core2 2.6=0A> > > > = GHz with dual ports Intel PCIE Gigabit=0A> network=0A> > card. It can manag= e up=0A> > > to 1.2=0A> > > > million pps.=0A> > > >=0A> > > > I have a hig= her spec PC with FreeBSD 7.1=0A> amd64=0A> > and Quadcore 2.3 GHz=0A> > > a= nd=0A> > > > PCIE Gigabit network card. The performance=0A> can=0A> > only = achieve up to 600k=0A> > > pps.=0A> > > > I notice the 'taskq em0' and 'tas= kq em1' is=0A> solid=0A> > 100% CPU but it is=0A> > > not in=0A> > > > Free= BSD 6.4. =0A> > > =0A> > >=A0 =0A> > > =0A> > > In our case we are running = FreeBSD 7.0, but we=0A> are=0A> > seeing our boxes=0A> > > experience serio= us thread starvation issues as=0A> the=0A> > nfe0 cpu percentage=0A> > > cl= imbs steadily while cpu idle time drops at=0A> times to=0A> > 0 percent. Th= is=0A> > > email thread mentioned a patch for the em driver=0A> > here:=0A>= > > =0A> > >=A0 =0A> > > =0A> > > http://people.yandex-team.ru/~wawa/ =0A>= > > =0A> > =0A> > > =0A> > >=A0 =0A= > > > =0A> > > Does anyone know if this patch will work with the=0A> nfe=0A= > > driver?=0A> > > =0A> > =0A> > That's for em(4).=0A> > =0A> > AFAIK all = nfe(4) controllers lacks intelligent=0A> interrupts=0A> > moderation so dri= ver should be prepared to handle=0A> > excessive=0A> > interrupt loads. I'm= not sure whether NVIDIA ethernet=0A> > controllers=0A> > really lacks effi= cient interrupt mitigation mechanism=0A> but=0A> > it=0A> > seems Linux als= o faces the same hardware problem.=0A> > As you might know there is no publ= icly available data=0A> sheet=0A> > for=0A> > NVIDIA controllers so setting= it right looks very hard=0A> to=0A> > me.=0A> > =0A> =0A> Try removing the= INTR_MPSAFE flag from the bus_setup_intr()=0A> call.=0A> The entire point = of using filters is to reduce lock=0A> contention.=0A> It might not solve t= he problem but its clearly an=0A> unnecessary=0A> potential bottleneck.=0A>= =0A> Barney=0A=0AI'm curious as to the statistics on your system. Your qua= d core adapter=0Amay actually be hurting the performance. What is the cpu u= sage=0Adistribution shown by top -SH when you are loaded, and how many =0Ai= nterrupts/second are you getting per nic? It looks like the=0Adefault moder= ation is set to 8000 ints/sec, which is probably ok=0Afor 1 interrupt per N= IC. Its not clear whether multiple msix =0Ainterrupts are allocated. Spread= ing interrupts isn't always a=0Agood thing as it increases lock contention = so much as to be=0Acounterproductive, unless you have properly written mute= x =0Amanagement code; which nfe doesn't. =0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 13:13:33 2009 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 ED367106566B for ; Thu, 13 Aug 2009 13:13:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.yandex.ru (forward5.yandex.ru [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3B27F8FC41 for ; Thu, 13 Aug 2009 13:13:33 +0000 (UTC) Received: from smtp2.yandex.ru (smtp2.yandex.ru [77.88.46.102]) by forward5.yandex.ru (Yandex) with ESMTP id 847D88705E2; Thu, 13 Aug 2009 16:57:07 +0400 (MSD) Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp2.yandex.ru (Yandex) with ESMTPSA id 4307FD181E9; Thu, 13 Aug 2009 16:57:07 +0400 (MSD) Message-ID: <4A840DA1.600@yandex.ru> Date: Thu, 13 Aug 2009 16:57:05 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: d@delphij.net References: <4A83EEA8.5080202@delphij.net> In-Reply-To: <4A83EEA8.5080202@delphij.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1250168227 X-Yandex-Spam: 1 X-Yandex-Front: smtp2.yandex.ru Cc: freebsd-net@freebsd.org Subject: Re: RFC: interface description 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, 13 Aug 2009 13:13:34 -0000 Xin LI wrote: > While playing with some OpenBSD installation I found that they have an > interesting feature - adding description to a NIC. This is useful for > system administrators to "tag" the interface, also, the ladvd program > has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP Something similar was rejected at least two times :) http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 14:15:07 2009 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 B44C1106566B for ; Thu, 13 Aug 2009 14:15:07 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7B48FC15 for ; Thu, 13 Aug 2009 14:15:07 +0000 (UTC) Received: by yxe11 with SMTP id 11so1028336yxe.3 for ; Thu, 13 Aug 2009 07:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=ws4v+ooOxf8nCuiJH9Hme15U1/3Ek9gI8AEa2lXjwFQ=; b=fplBvfjlFcyL9pQRUAp4dIca+fSkh1GUOq5cqnoltMuLNiTLEbnWZla5P4EcQXltn+ 4lV2LkTTWkn8no3aXGscHh2wc/QLMtdozdJFtt4eVBoj+8BRTcApXNVVB9MpFBsBeCe6 +q3vmzkQZHOP+LGLdeoYnB4ELRME2ZjBOR3jE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=hUZAsIFxx7UmOuuFuQ587so1mCqL2gYIkv/xotSPVTp41X3nYo5xFOcZJ7kjNmXoBN QjYrFosSibE81K2tGtslCmCgB3TSFfg6EQ57dLga2LEqycUBx0ti0j6CIuuFiaq8Lahg UbBzf0QiGE1bRKKt3mHIFiNFokMdu5nH8S7OQ= Received: by 10.90.51.4 with SMTP id y4mr575292agy.83.1250172906545; Thu, 13 Aug 2009 07:15:06 -0700 (PDT) Received: from adnote989 (201-42-157-19.dsl.telesp.net.br [201.42.157.19]) by mx.google.com with ESMTPS id 38sm1404694aga.79.2009.08.13.07.15.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Aug 2009 07:15:05 -0700 (PDT) Message-ID: From: "Luiz Otavio O Souza" To: "Andrey V. Elsukov" , References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> Date: Thu, 13 Aug 2009 11:14:56 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Thu, 13 Aug 2009 14:24:47 +0000 Cc: freebsd-net@freebsd.org Subject: Re: RFC: interface description 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, 13 Aug 2009 14:15:07 -0000 > Xin LI wrote: >> While playing with some OpenBSD installation I found that they have an >> interesting feature - adding description to a NIC. This is useful for >> system administrators to "tag" the interface, also, the ladvd program >> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP > > Something similar was rejected at least two times :) > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 > That was a long time ago... The Xin Li patch is a quite complete (manual pages updated as well) and only suffer from the 64 byte limit on interface description (and the 64 more bytes on ifnet), wich IMHO, should be easy to fix. Thank you Xin Li for bringing this =) Luiz From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 16:05:06 2009 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 D84761065672 for ; Thu, 13 Aug 2009 16:05:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 912F88FC45 for ; Thu, 13 Aug 2009 16:05:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E70BB41C6A3; Thu, 13 Aug 2009 18:05:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id XoycW5qnX1Ru; Thu, 13 Aug 2009 18:05:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 6F29441C6A1; Thu, 13 Aug 2009 18:05: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 19C314448EC; Thu, 13 Aug 2009 16:04:06 +0000 (UTC) Date: Thu, 13 Aug 2009 16:04:05 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org Message-ID: <20090813154703.Y93661@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: VANHULLEBUS Yvan Subject: NAT-T patch for 7-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: Thu, 13 Aug 2009 16:05:07 -0000 Hi, I just MFCed the UDP Control Block, which is a prerequisite for merging the NAT-T patch from HEAD (8) to 7-STABLE: http://svn.freebsd.org/viewvc/base?view=revision&revision=196192 I also merged back the NAT-T changes from FreeBSD 8/HEAD. This will allow us to provide the same API for tools for FreeBSD 7 (with patch) and stock FreeBSD 8.x and 9 (HEAD). Before anyone is going to ask: no the NAT-T is not comittable to FreeBSD 7-STABLE, so anyone on 7 will have to live with a patch. In case you use tools that rely on the right version of a patch (like ipsec-tools), I'd expect things to take a few days to get solved, so do not expect that things will mysteriously just work. Considering 8 is in BETA and I assume the ports tree will be frozen soon as well if it is not yet, it might even take a few days longer. This is mostly for the people doing the work, integrating things, changing software to have something to work with. Things have been bascially tested with a slightly modified to compile ipsec-tools CVS HEAD checkout. Last but not least - you can find the patch here: http://people.freebsd.org/~bz/20090813-01-mfc-r194062-natt.diff /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 16:35:09 2009 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 6E3E81065676 for ; Thu, 13 Aug 2009 16:35:09 +0000 (UTC) (envelope-from ady@ady.ro) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 937608FC6C for ; Thu, 13 Aug 2009 16:35:08 +0000 (UTC) Received: by ewy2 with SMTP id 2so237322ewy.43 for ; Thu, 13 Aug 2009 09:35:07 -0700 (PDT) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.210.12.13 with SMTP id 13mr4180002ebl.12.1250179413072; Thu, 13 Aug 2009 09:03:33 -0700 (PDT) In-Reply-To: <533A2900-CDAC-4BFB-952B-45FB18E19B7E@neville-neil.com> References: <533A2900-CDAC-4BFB-952B-45FB18E19B7E@neville-neil.com> Date: Thu, 13 Aug 2009 18:03:33 +0200 X-Google-Sender-Auth: c48f32e6af885789 Message-ID: <78cb3d3f0908130903v6b16d819qa27b9f5263676479@mail.gmail.com> From: Adrian Penisoara To: George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: RFC: ARP Statistics 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, 13 Aug 2009 16:35:09 -0000 Hi, Perhaps it would be useful to add a "ARP flip-flop events" field, counting the "arp: is on but got reply from on " events. PS: minor nit/correction: use "ARP cache entries timed out" instead of "ARP entrys timed out" Regards, Adrian Penisoara EnterpriseBSD On Wed, Aug 12, 2009 at 3:43 PM, George Neville-Neil wrote: > Howdy, > > Here is a small patch that updates the kernel and the netstat(1) program to > print out protocol > statistics for ARP. I'd be interested in any feedback people have on this. > > Sample output: > > netstat -s -p arp > arp: > 469 ARP requests sent > 2117 ARP replies received > 0 total packets dropped due to no ARP entry > 469 ARP entrys timed out > 0 Duplicate IPs seen > > > Best, > George > > > > Index: usr.bin/netstat/inet.c > =================================================================== > --- usr.bin/netstat/inet.c (revision 196095) > +++ usr.bin/netstat/inet.c (working copy) > @@ -49,6 +49,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -871,6 +872,44 @@ > #undef p1a > } > > +/* > + * Dump ARP statistics structure. > + */ > +void > +arp_stats(u_long off, const char *name, int af1 __unused, int proto > __unused) > +{ > + struct arpstat arpstat, zerostat; > + size_t len = sizeof(arpstat); > + > + if (live) { > + if (zflag) > + memset(&zerostat, 0, len); > + if (sysctlbyname("net.link.ether.arp.stats", &arpstat, > &len, > + zflag ? &zerostat : NULL, zflag ? len : 0) < 0) { > + warn("sysctl: net.link.ether.arp.stats"); > + return; > + } > + } else > + kread(off, &arpstat, len); > + > + printf("%s:\n", name); > + > +#define p(f, m) if (arpstat.f || sflag <= 1) \ > + printf(m, arpstat.f, plural(arpstat.f)) > +#define p1a(f, m) if (arpstat.f || sflag <= 1) \ > + printf(m, arpstat.f) > + > + p(arp_requests, "\t%lu ARP request%s sent\n"); > + p(arp_replies, "\t%lu ARP replie%s received\n"); > + p(arp_dropped, "\t%lu total packet%s dropped due to no ARP > entry\n"); > + p(arp_timeout, "\t%lu ARP entry%s timed out\n"); > + p(arp_dupips, "\t%lu Duplicate IP%s seen\n"); > +#undef p > +#undef p1a > +} > + > + > + > static const char *icmpnames[ICMP_MAXTYPE + 1] = { > "echo reply", /* RFC 792 */ > "#1", > Index: usr.bin/netstat/main.c > =================================================================== > --- usr.bin/netstat/main.c (revision 196095) > +++ usr.bin/netstat/main.c (working copy) > @@ -184,6 +184,8 @@ > { .n_name = "_sctpstat" }, > #define N_MFCTABLESIZE 54 > { .n_name = "_mfctablesize" }, > +#define N_ARPSTAT 55 > + { .n_name = "_arpstat" }, > { .n_name = NULL }, > }; > > @@ -232,6 +234,8 @@ > carp_stats, NULL, "carp", 1, 0 }, > { -1, N_PFSYNCSTAT, 1, NULL, > pfsync_stats, NULL, "pfsync", 1, 0 }, > + { -1, N_ARPSTAT, 1, NULL, > + arp_stats, NULL, "arp", 1, 0 }, > { -1, -1, 0, NULL, > NULL, NULL, NULL, 0, 0 } > }; > Index: usr.bin/netstat/netstat.h > =================================================================== > --- usr.bin/netstat/netstat.h (revision 196095) > +++ usr.bin/netstat/netstat.h (working copy) > @@ -75,6 +75,7 @@ > void sctp_protopr(u_long, const char *, int, int); > void sctp_stats(u_long, const char *, int, int); > #endif > +void arp_stats(u_long, const char *, int, int); > void ip_stats(u_long, const char *, int, int); > void icmp_stats(u_long, const char *, int, int); > void igmp_stats(u_long, const char *, int, int); > Index: sys/netinet/if_ether.c > =================================================================== > --- sys/netinet/if_ether.c (revision 196095) > +++ sys/netinet/if_ether.c (working copy) > @@ -80,6 +80,7 @@ > > SYSCTL_DECL(_net_link_ether); > SYSCTL_NODE(_net_link_ether, PF_INET, inet, CTLFLAG_RW, 0, ""); > +SYSCTL_NODE(_net_link_ether, PF_ARP, arp, CTLFLAG_RW, 0, ""); > > VNET_DEFINE(int, useloopback) = 1; /* use loopback interface for > * local traffic */ > @@ -108,6 +109,11 @@ > &VNET_NAME(arp_proxyall), 0, > "Enable proxy ARP for all suitable requests"); > > +struct arpstat arpstat; /* ARP statistics, see if_arp.h */ > +SYSCTL_STRUCT(_net_link_ether_arp, OID_AUTO, stats, CTLFLAG_RW, > + &arpstat, arpstat, > + "ARP statistics (struct arpstat, net/if_arp.h)"); > + > static void arp_init(void); > void arprequest(struct ifnet *, > struct in_addr *, struct in_addr *, u_char *); > @@ -127,6 +133,7 @@ > #ifdef AF_INET > void arp_ifscrub(struct ifnet *ifp, uint32_t addr); > > + > /* > * called by in_ifscrub to remove entry from the table when > * the interface goes away > @@ -165,12 +172,13 @@ > ifp = lle->lle_tbl->llt_ifp; > IF_AFDATA_LOCK(ifp); > LLE_WLOCK(lle); > - if (((lle->la_flags & LLE_DELETED) > - || (time_second >= lle->la_expire)) > - && (!callout_pending(&lle->la_timer) && > - callout_active(&lle->la_timer))) > + if (((lle->la_flags & LLE_DELETED) || > + (time_second >= lle->la_expire)) && > + (!callout_pending(&lle->la_timer) && > + callout_active(&lle->la_timer))) { > (void) llentry_free(lle); > - else { > + arpstat.arp_timeout++; > + } else { > /* > * Still valid, just drop our reference > */ > @@ -238,6 +246,7 @@ > sa.sa_len = 2; > m->m_flags |= M_BCAST; > (*ifp->if_output)(ifp, m, &sa, NULL); > + arpstat.arp_requests++; > } > > /* > @@ -339,8 +348,10 @@ > * latest one. > */ > if (m != NULL) { > - if (la->la_hold != NULL) > + if (la->la_hold != NULL) { > m_freem(la->la_hold); > + arpstat.arp_dropped++; > + } > la->la_hold = m; > if (renew == 0 && (flags & LLE_EXCLUSIVE)) { > flags &= ~LLE_EXCLUSIVE; > @@ -413,6 +424,7 @@ > ar = mtod(m, struct arphdr *); > } > > + arpstat.arp_replies++; > switch (ntohs(ar->ar_pro)) { > #ifdef INET > case ETHERTYPE_IP: > @@ -603,6 +615,7 @@ > ifp->if_addrlen, (u_char *)ar_sha(ah), ":", > inet_ntoa(isaddr), ifp->if_xname); > itaddr = myaddr; > + arpstat.arp_dupips++; > goto reply; > } > if (ifp->if_flags & IFF_STATICARP) > @@ -821,7 +834,7 @@ > static void > arp_init(void) > { > - > + bzero(&arpstat, sizeof(arpstat)); > netisr_register(&arp_nh); > } > SYSINIT(arp, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, arp_init, 0); > Index: sys/net/if_arp.h > =================================================================== > --- sys/net/if_arp.h (revision 196095) > +++ sys/net/if_arp.h (working copy) > @@ -108,6 +108,16 @@ > #define IFP2AC(ifp) ((struct arpcom *)(ifp->if_l2com)) > #define AC2IFP(ac) ((ac)->ac_ifp) > > -#endif > +#endif /* _KERNEL */ > > +struct arpstat { > + /* Normal things that happen */ > + u_long arp_requests; /* # of ARP requests sent by this host */ > + u_long arp_replies; /* # of ARP replies received by this host */ > + /* Abnormal event and error counting */ > + u_long arp_dropped; /* # of packets dropped while waiting for a > reply */ > + u_long arp_timeout; /* # of times an entry is removed due to > timeout */ > + u_long arp_dupips; /* # of duplicate IPs detected. */ > +}; > + > #endif /* !_NET_IF_ARP_H_ */ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 17:40:04 2009 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 03B5C106564A for ; Thu, 13 Aug 2009 17:40:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id E0B6D8FC16 for ; Thu, 13 Aug 2009 17:40:03 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E77757A76D; Thu, 13 Aug 2009 10:40:03 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 39FB42D601D; Thu, 13 Aug 2009 10:40:03 -0700 (PDT) Message-ID: <4A844FF2.9000307@elischer.org> Date: Thu, 13 Aug 2009 10:40:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> In-Reply-To: <4A840DA1.600@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, d@delphij.net Subject: Re: RFC: interface description 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, 13 Aug 2009 17:40:04 -0000 Andrey V. Elsukov wrote: > Xin LI wrote: >> While playing with some OpenBSD installation I found that they have an >> interesting feature - adding description to a NIC. This is useful for >> system administrators to "tag" the interface, also, the ladvd program >> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP > > Something similar was rejected at least two times :) not rejected.. suffered from lack of enthusiasm maybe. > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 > From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 18:35:07 2009 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 8535D106566C for ; Thu, 13 Aug 2009 18:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3F5928FC56 for ; Thu, 13 Aug 2009 18:35:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8812341C65E; Thu, 13 Aug 2009 20:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 338PkjWOv1Lk; Thu, 13 Aug 2009 20:35:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 02E4541C678; Thu, 13 Aug 2009 20:35: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 B4A254448EC; Thu, 13 Aug 2009 18:34:10 +0000 (UTC) Date: Thu, 13 Aug 2009 18:34:10 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <4A844FF2.9000307@elischer.org> Message-ID: <20090813182918.S93661@maildrop.int.zabbadoz.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Andrey V. Elsukov" , d@delphij.net Subject: Re: RFC: interface description 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, 13 Aug 2009 18:35:07 -0000 On Thu, 13 Aug 2009, Julian Elischer wrote: > Andrey V. Elsukov wrote: >> Xin LI wrote: >>> While playing with some OpenBSD installation I found that they have an >>> interesting feature - adding description to a NIC. This is useful for >>> system administrators to "tag" the interface, also, the ladvd program >>> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP >> >> Something similar was rejected at least two times :) >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 > > not rejected.. > > suffered from lack of enthusiasm maybe. My point has always been - if I have to add/do an ioctl I can always also use a library call that will read it from a .txt, .xml, .db file or whatever and I don't have to go to the kernel, handle all the string length problems there, ... especially as the kernel cannot do anything with that string. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 19:20:49 2009 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 23BFE10656AE for ; Thu, 13 Aug 2009 19:20:49 +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 6A9138FC52 for ; Thu, 13 Aug 2009 19:20:47 +0000 (UTC) Received: (qmail 5734 invoked from network); 13 Aug 2009 19:20:46 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Aug 2009 19:20:46 -0000 Date: Thu, 13 Aug 2009 21:20:46 +0200 (CEST) Message-Id: <20090813.212046.78768090.sthaug@nethelp.no> To: bzeeb-lists@lists.zabbadoz.net From: sthaug@nethelp.no In-Reply-To: <20090813182918.S93661@maildrop.int.zabbadoz.net> References: <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.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, bu7cher@yandex.ru, d@delphij.net, julian@elischer.org Subject: Re: RFC: interface description 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, 13 Aug 2009 19:20:49 -0000 > My point has always been - if I have to add/do an ioctl I can always also > use a library call that will read it from a .txt, .xml, .db file > or whatever and I don't have to go to the kernel, handle all the > string length problems there, ... especially as the kernel cannot do > anything with that string. Personally, I couldn't care less if an interface description is stored in the kernel or in a file. I *do* care about being able to set and show the description via ifconfig. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 19:36:09 2009 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 6E35F106564A for ; Thu, 13 Aug 2009 19:36:09 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id F1AE58FC51 for ; Thu, 13 Aug 2009 19:36:08 +0000 (UTC) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 9BC1F5C06F for ; Fri, 14 Aug 2009 03:36:07 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 5EFCD55CDC3A; Fri, 14 Aug 2009 03:36:07 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 2PP6TaWnu51V; Fri, 14 Aug 2009 03:35:08 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 02BC955CDC34; Fri, 14 Aug 2009 03:35:01 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=brxdwMDRrdbPgNvKGoxjEPiEUWmPskTTl87dMmpWaXLb2x2Uh4tUT7xfTd25qQTZl P6FxJ9Q0w4Rd/r7sbW3hQ== Message-ID: <4A846AD3.3080301@delphij.net> Date: Thu, 13 Aug 2009 12:34:43 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090803) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> In-Reply-To: <20090813182918.S93661@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Andrey V. Elsukov" , d@delphij.net, Julian Elischer Subject: Re: RFC: interface description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:36:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Bjoern A. Zeeb wrote: > On Thu, 13 Aug 2009, Julian Elischer wrote: > >> Andrey V. Elsukov wrote: >>> Xin LI wrote: >>>> While playing with some OpenBSD installation I found that they have an >>>> interesting feature - adding description to a NIC. This is useful for >>>> system administrators to "tag" the interface, also, the ladvd program >>>> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP >>> >>> Something similar was rejected at least two times :) >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110720 >> >> not rejected.. >> >> suffered from lack of enthusiasm maybe. > > My point has always been - if I have to add/do an ioctl I can always also > use a library call that will read it from a .txt, .xml, .db file > or whatever and I don't have to go to the kernel, handle all the > string length problems there, ... especially as the kernel cannot do > anything with that string. I have also received some private e-mail regarding this, and I think that would be more sensible (better flexibility, and of course, a better chance that we can MFC it since it won't change kernel ABI). The only question I have would be, that is it possible to uniquely identify a NIC without assistance from kernel? For instance, one can change an interface from being called "em0" to "eth0" and from "bge0" to "em0". It's easy to track this information through ifconfig(8) with a callback, clean up the file upon restart, but we can not prevent other programs from calling IOCSIFNAME on the interface. Any idea for this? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqEatIACgkQi+vbBBjt66Ah7gCgsv2O9FpF+fAbIPJqkICWkC+I HmYAoK4GmPynk4qh2FL2CnJY12MOBzEB =MG3y -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Aug 13 23:00:15 2009 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 432A3106568E for ; Thu, 13 Aug 2009 23:00:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 31D698FC41 for ; Thu, 13 Aug 2009 23:00:15 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7DN0Fbg037187 for ; Thu, 13 Aug 2009 23:00:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7DN0F9L037186; Thu, 13 Aug 2009 23:00:15 GMT (envelope-from gnats) Date: Thu, 13 Aug 2009 23:00:15 GMT Message-Id: <200908132300.n7DN0F9L037186@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Z3tbl4 []" Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Z3tbl4 \[\]" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 23:00:15 -0000 The following reply was made to PR kern/134557; it has been noted by GNATS. From: "Z3tbl4 []" To: bug-followup@FreeBSD.org, sergei.cherveni@gmail.com Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Fri, 14 Aug 2009 02:28:54 +0400 SGVsbG8gd29ybGQhIElzIGl0IHBvc3NpYmxlIHRvIHBhdGNoIG5nX2lmYWNlLmMgYW5kIG5nX2lm YWNlLmggb24KRnJlZUJTRCA2LjQtUkVMRUFTRSBzb21laG93PwpUaGFuayB5b3UuCiMjIyMjIyMj IyMjIyMjIyMjIyMjIyMK99PFzSDQ0snXxdQsINDP08/XxdTVytTFIN7UzyDExczB1Ngg1yDUwcvP yiDTydTVwcPJyS4uLgruwSDG0sUgKFA0IDNHSHopIDYuNC1yZWxlYXNlIMXT1NggbXBkNSwg0cTS zyDTz8LSwc7PINMKY3B1ICAgICAgICAgICAgIEk2ODZfQ1BVCm9wdGlvbnMgICAgICAgICBTTVAK b3B0aW9ucyAgICAgICAgIElQRklSRVdBTEwKb3B0aW9ucyAgICAgICAgIElQRElWRVJUCm9wdGlv bnMgICAgICAgICBEVU1NWU5FVApvcHRpb25zICAgICAgICAgTkVUR1JBUEgKb3B0aW9ucyAgICAg ICAgIE5FVEdSQVBIX1BQUApvcHRpb25zICAgICAgICAgTkVUR1JBUEhfUFBUUEdSRQoK1yDQ0s/J 2tfPzNjO2cUgzc/Nxc7U2SDawdfJ08HF1CDOxdTH0sHGLCDQ0sPF09MgInN3aTE6IG5ldCIgz9TW ydLBxdQK18XT2CDQ0s/DxdPTz9IsINfTxSDTxdTF19nFIMvB0tTZINDF0sXT1MHA1CDP1NfF3sHU 2Cwgy8/O08/M2ArSwcLP1MHF1Cwgzc/Wzs8g0sXC1dTO1dTY09EuCvPJzNjOzyDQz8fVx8zJ1ywg zsHbo8wsIN7UzyDc1MEgz9vJwsvBINfP2s7Jy8HF1CDJ2i3awSDUz8fPLCDe1M8gbXBkCtrBw8nL zMnXwcXUIMvBy8/KLdTPINPF1MXXz8og0MHLxdQgKN7UzyDX0NLJzsPJ0MUg08/HzMHT1cXU09Eg 0wrOwcLMwMTFzsnRzckpIMLBx9LF0M/S1CAia2Vybi8xMzI5ODQiCmh0dHA6Ly9saXN0cy5mcmVl YnNkLm9yZy9waXBlcm1haWwvZnJlZWJzZC1idWdzLzIwMDktTWFyY2gvMC4uLiAuCu7B26PMINDB 1N4gxMzRIC9zeXMvbmV0Z3JhcGgvbmdfaWZhY2UuYywgbmdfaWZhY2UuaCwgzs8gwsXEwSDXINTP zSwK3tTPIM/OIM7FINPPwsnSwcXU09Eg0M/EIDYuNCAo18nEyc3PIMTM0SDG0sDIIDcgySDX2dvF KS4K5dPMySDL1M8g2s7BxdQgy8HLIMnT0NLB18nU2CDc1M/UIG5nX2lmYWNlLmMg0M/EIDYuNCDC 1cTVIMLF2s3F0s7PCsLMwcfPxMHSxc4sINPQwdPJws8uCg== From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 00:05:48 2009 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 18CA6106568F for ; Fri, 14 Aug 2009 00:05:48 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id C2FE48FC4A for ; Fri, 14 Aug 2009 00:05:47 +0000 (UTC) Received: by qyk29 with SMTP id 29so954192qyk.3 for ; Thu, 13 Aug 2009 17:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CCt7lY8MVjQQfXQF3abEG7NWPMB8n1L/3sR8lp6B6SU=; b=kwzfLuJcdApS815UElBTwqj8V57CNo3hUJxdrbOyV932VXzQawQt1hVMOPN0Iw0NcO rfJd0gOi1tJtJRHhmaOJrtV7bbH+OiKmVroigP4ZlPfHL1e8gtpAinEVMd9Pm2mfMbLd /pSLr+dv1dNtFIa4NivJSV5/0CBoef9UpmMfM= 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=pnCYJW5A4j6gH+7QQeiNG7K9bwQBvleXYFYpmT4JxV7wEbgQ1bQbkHpS9kI9rLp2Hq XoZpwAnJ3M1ANIeX7wLSsDnNvpLrijkPn3DZwPYdukUCA35REmUc0C7whmnjEj9YIKhT LuYzBsHG/+FAFUhu7nTvW1HmJt3xLpq4v/ouk= MIME-Version: 1.0 Received: by 10.229.41.13 with SMTP id m13mr1203979qce.85.1250207098930; Thu, 13 Aug 2009 16:44:58 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Aug 2009 18:44:58 -0500 Message-ID: <11167f520908131644w60627074g968d64061849ed22@mail.gmail.com> From: "Sam Fourman Jr." To: serg vasilyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: LACP support and if_tap interface 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, 14 Aug 2009 00:05:48 -0000 On Thu, Aug 6, 2009 at 11:51 PM, serg vasilyev wrote: > Now i'm able to emulate a media and status on if_tap interface... > > tap0: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0ether 00:bd:49:f7:a6:00 > =A0 =A0 =A0 =A0media: Ethernet 100baseTX > =A0 =A0 =A0 =A0status: active > > BUT i suspect that there must be some another flag or capability of > if_tap to work with LACP... > can somebody tell me what flags exactly responsible for LACP functionalit= y ? > > > 2009/8/6, serg vasilyev : >> Hi everyone. >> Can anyone modify if_tap interface to achieve LACP needs (probably add >> a virtual media i suspect)? >> I want to create an Ethernet tunnel with aggregation via openvpn but >> if_tap interface cannot give right internal capabilities for lagg and >> LACP to work properly Did anyone ever get this to work? I want to do LACP over ssh tunnels aka tap0 tap1 Sam Fourman Jr. From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 06:05:16 2009 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 24A32106568C for ; Fri, 14 Aug 2009 06:05:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.yandex.ru (forward1.yandex.ru [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id D015A8FC6B for ; Fri, 14 Aug 2009 06:05:15 +0000 (UTC) Received: from smtp4.yandex.ru (smtp4.yandex.ru [77.88.46.104]) by forward1.yandex.ru (Yandex) with ESMTP id 5244914682E1; Fri, 14 Aug 2009 10:05:14 +0400 (MSD) Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp4.yandex.ru (Yandex) with ESMTPSA id E155AD3007A; Fri, 14 Aug 2009 10:05:13 +0400 (MSD) Message-ID: <4A84FE96.1070506@yandex.ru> Date: Fri, 14 Aug 2009 10:05:10 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: d@delphij.net References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> <4A846AD3.3080301@delphij.net> In-Reply-To: <4A846AD3.3080301@delphij.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1250229914 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.yandex.ru Cc: "Bjoern A. Zeeb" , Julian Elischer , freebsd-net@freebsd.org Subject: Re: RFC: interface description 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, 14 Aug 2009 06:05:16 -0000 Xin LI wrote: > The only question I have would be, that is it possible to uniquely > identify a NIC without assistance from kernel? For instance, one can > change an interface from being called "em0" to "eth0" and from "bge0" to > "em0". It's easy to track this information through ifconfig(8) with a > callback, clean up the file upon restart, but we can not prevent other > programs from calling IOCSIFNAME on the interface. Any idea for this? What about using interface index as a key(see if_nameindex(3))? -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 08:00:08 2009 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 11125106568D for ; Fri, 14 Aug 2009 08:00:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id B18028FC45 for ; Fri, 14 Aug 2009 08:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6E1F841C647; Fri, 14 Aug 2009 10:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id NXloOnDwlYaz; Fri, 14 Aug 2009 10:00:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E726841C667; Fri, 14 Aug 2009 10:00: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 0AA204448EC; Fri, 14 Aug 2009 07:58:34 +0000 (UTC) Date: Fri, 14 Aug 2009 07:58:33 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: d@delphij.net In-Reply-To: <4A84FE96.1070506@yandex.ru> Message-ID: <20090814071511.U93661@maildrop.int.zabbadoz.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> <4A846AD3.3080301@delphij.net> <4A84FE96.1070506@yandex.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: RFC: interface description 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, 14 Aug 2009 08:00:08 -0000 On Fri, 14 Aug 2009, Andrey V. Elsukov wrote: Hi, > Xin LI wrote: >> The only question I have would be, that is it possible to uniquely >> identify a NIC without assistance from kernel? For instance, one can >> change an interface from being called "em0" to "eth0" and from "bge0" to >> "em0". It's easy to track this information through ifconfig(8) with a >> callback, clean up the file upon restart, but we can not prevent other >> programs from calling IOCSIFNAME on the interface. Any idea for this? > > What about using interface index as a key(see if_nameindex(3))? So here comes the usual catch 22 on a classic PC system: you can change everything. Using RFC 2553 Section 4 is probably the best indeed but has drawbacks as well. If you match by xname, renaming the interface will break things. If you match by dname+unit, unit can still change between boots (see further on). If you match by MAC address the MAC address can be changed by the user. If you match by (PCI/..) slot, cards can be moved. If you match by card serial number, *oops* most of those don't have that in the consumer or even server world so that's not an option. Because of the above we don't have any metadata that would allow us to have persistent ifIndexes between boots. Once you add portable interfaces (pcmcia, usb, pc card, ..) to the game even your ifIndex upon boot may vary depending on if a card is plugged in or not or if you added another one, possibly using the same driver changing the unit number if unlucky (see above). Now add cloned interfaces from gif, tun, .. to wlan and you'll understand the big (problem|picture). Now let us look at this from a different view - what can venders do to avoid all this or how can they handle things: They might have ways to uniquely identify each interface so an ifIndex could possibly always be the same after the interface was first put into a device (interface serial number for example). They usually do not allow renaming of interface names. They usually do not have physical interfaces coming and going very often. They do have "cloned-a-like" interfaces as well so they have to handle them somehow. I have seldomly seen descriptions on those if they come and go. They possibly treat static "tunnel" interfaces, etc. more statically having a well defined bringup order. The cards lose their description if moved to a different slot or rather as the interface goes away usually and even if plugged into a different slot would lose the description but maybe not the ifIndex. What does that mean for us? For "dynamic" interfaces storing things with the kernel would for sure be easier as if you remove the interface the description is gone. If not storing in the kernel we get interface insertion and removal events already to userspace/devd imho we could use. The moment you add the description it doesn't matter what the interface is, as you can name it always some way. If you take the classic BSD scheme and will seed the "storage" upon boot from scratch from rc.conf or other places you will have a consitent ifIndex for all hard wired physical interfaces (non-hotpluggable). [Unless you move hardware that should even be the same if we don't change bus scanning orders, etc.] For all the cloned stuff things are harder, as we to my knowledge even recycle ifIndexes to not have huge gaps in the array (which is a real pain), so there are kernel limitations as well in the way we store/lookup things that also had come up during the vnet merges and that people are aware of. Bsnmp should have to handle parts of this all already and is for sure one of the first consumers so talking to harti and syrinx or looking at that code might also be a good thing todo. My biggest worry comes with the cloned interfaces like tuns or similar ones if they come and go often; if an ifIndex is recycled and even if the interface name is the same afterwards there should be no old description left, so "purging" entries on interface deletion and possibly asserting that on interface creation would be a good idea. JustMy2ctAndEndOfBrainDumpInTheMorningBeforeTheFirstCupOfCoffe /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 15:05:54 2009 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 9AD7D1065690 for ; Fri, 14 Aug 2009 15:05:54 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6EBEB8FC52 for ; Fri, 14 Aug 2009 15:05:54 +0000 (UTC) Received: from PM-G5.transsys.com (c-69-141-150-106.hsd1.nj.comcast.net [69.141.150.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 6349A5C4B; Fri, 14 Aug 2009 11:05:53 -0400 (EDT) Message-Id: From: Louis Mamakos To: freebsd-net@freebsd.org In-Reply-To: <20090814071511.U93661@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 11:05:52 -0400 References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru> <4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> <4A846AD3.3080301@delphij.net> <4A84FE96.1070506@yandex.ru> <20090814071511.U93661@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.936) Cc: "Bjoern A. Zeeb" , d@delphij.net Subject: Re: RFC: interface description 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, 14 Aug 2009 15:05:54 -0000 On Aug 14, 2009, at 3:58 AM, Bjoern A. Zeeb wrote: > On Fri, 14 Aug 2009, Andrey V. Elsukov wrote: > > Hi, > >> Xin LI wrote: >>> The only question I have would be, that is it possible to uniquely >>> identify a NIC without assistance from kernel? For instance, one >>> can >>> change an interface from being called "em0" to "eth0" and from >>> "bge0" to >>> "em0". It's easy to track this information through ifconfig(8) >>> with a >>> callback, clean up the file upon restart, but we can not prevent >>> other >>> programs from calling IOCSIFNAME on the interface. Any idea for >>> this? >> >> What about using interface index as a key(see if_nameindex(3))? > > So here comes the usual catch 22 on a classic PC system: > you can change everything. > > Using RFC 2553 Section 4 is probably the best indeed but has drawbacks > as well. > > > If you match by xname, renaming the interface will break things. > If you match by dname+unit, unit can still change between boots (see > further on). > If you match by MAC address the MAC address can be changed by the > user. > If you match by (PCI/..) slot, cards can be moved. > If you match by card serial number, *oops* most of those don't have > that in the consumer or even server world so that's not an option. > Because of the above we don't have any metadata that would allow us to > have persistent ifIndexes between boots. > Once you add portable interfaces (pcmcia, usb, pc card, ..) to the > game > even your ifIndex upon boot may vary depending on if a card is > plugged in or not or if you added another one, possibly using the > same driver changing the unit number if unlucky (see above). > Now add cloned interfaces from gif, tun, .. to wlan and you'll > understand the big (problem|picture). > > > Now let us look at this from a different view - what can venders do to > avoid all this or how can they handle things: > > They might have ways to uniquely identify each interface so an ifIndex > could possibly always be the same after the interface was first > put into a device (interface serial number for example). > They usually do not allow renaming of interface names. > They usually do not have physical interfaces coming and going very > often. > They do have "cloned-a-like" interfaces as well so they have to handle > them somehow. I have seldomly seen descriptions on those if they > come and go. They possibly treat static "tunnel" interfaces, etc. > more statically having a well defined bringup order. > The cards lose their description if moved to a different slot or > rather as the interface goes away usually and even if plugged into > a different slot would lose the description but maybe not the > ifIndex. > > > What does that mean for us? > > For "dynamic" interfaces storing things with the kernel would for sure > be easier as if you remove the interface the description is gone. > If not storing in the kernel we get interface insertion and removal > events already to userspace/devd imho we could use. > The moment you add the description it doesn't matter what the > interface is, as you can name it always some way. > If you take the classic BSD scheme and will seed the "storage" upon > boot from scratch from rc.conf or other places you will have a > consitent ifIndex for all hard wired physical interfaces > (non-hotpluggable). > [Unless you move hardware that should even be the same if we don't > change bus scanning orders, etc.] > For all the cloned stuff things are harder, as we to my knowledge even > recycle ifIndexes to not have huge gaps in the array (which is a > real pain), so there are kernel limitations as well in the way > we store/lookup things that also had come up during the vnet > merges and that people are aware of. > Bsnmp should have to handle parts of this all already and is for sure > one of the first consumers so talking to harti and syrinx or > looking at that code might also be a good thing todo. > > > My biggest worry comes with the cloned interfaces like tuns or similar > ones if they come and go often; if an ifIndex is recycled and even if > the interface name is the same afterwards there should be no old > description left, so "purging" entries on interface deletion and > possibly asserting that on interface creation would be a good idea. > > > JustMy2ctAndEndOfBrainDumpInTheMorningBeforeTheFirstCupOfCoffe > > /bz > Interface names (bge0, fxp1, etc.) name ports on the local host/router. The use of "interface descriptions" is almost always an attempt to name or describe what's connected on the other side of the network interface. This is what the various "discovery" protocols, like CDP[1] and LLDP[2] try to solve; to dynamically discover WTF this port is plugged into. The problem with ifIndex stability is somewhat related, but you could imagine choosing some physical identifier (like the manufactured MAC address) as the name. The ifIndex in the general case doesn't account for the user deciding to externally swap the ethernet cables between a pair of ports. Louis Mamakos [1] http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol [2] http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 17:51:46 2009 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 20F89106568C; Fri, 14 Aug 2009 17:51:46 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0654A8FC51; Fri, 14 Aug 2009 17:51:45 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7EHoKgp026600; Fri, 14 Aug 2009 10:50:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 10:49:24 -0700 Message-ID: In-Reply-To: <20090813182918.S93661@maildrop.int.zabbadoz.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: interface description Thread-Index: AcocROe0W5ePmY+QQbyuyIkH+vPOGwAwPAeQ References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru><4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net> From: "Li, Qing" To: "Bjoern A. Zeeb" , "Qing Li" Cc: freebsd-net@freebsd.org, "Andrey V. Elsukov" , d@delphij.net, Julian Elischer Subject: RE: RFC: interface description 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, 14 Aug 2009 17:51:46 -0000 >=20 > My point has always been - if I have to add/do an ioctl I can always > also use a library call that will read it from a .txt, .xml, .db file > or whatever and I don't have to go to the kernel, handle all the > string length problems there, ... especially as the kernel cannot do > anything with that string. >=20 The interface description feature is a useful feature. Quite a few products out there actually put a label on the physical box so it's reasonable to have the ability to label the ports in the kernel. There are quite a few embedded systems and not-so-standalone boxes out there that are derivatives of FreeBSD. These systems might not have the luxury of a file system. And getting coredumps from the field with such information embedded in the ifnet{} just makes debugging field issues a little bit easier. > > So here comes the usual catch 22 on a classic PC system: > you can change everything. > > Using RFC 2553 Section 4 is probably the best indeed but has=20 > drawbacks as well. > Seems rather off topic ... -- Qing From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 20:05:28 2009 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 B562A106568C; Fri, 14 Aug 2009 20:05:28 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC768FC52; Fri, 14 Aug 2009 20:05:27 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n7EJX4qX024478; Fri, 14 Aug 2009 14:33:04 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n7EJX3Va024477; Fri, 14 Aug 2009 14:33:03 -0500 (CDT) (envelope-from brooks) Date: Fri, 14 Aug 2009 14:33:03 -0500 From: Brooks Davis To: "Li, Qing" Message-ID: <20090814193303.GA21941@lor.one-eyed-alien.net> References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 14 Aug 2009 14:33:05 -0500 (CDT) Cc: d@delphij.net, freebsd-net@freebsd.org, Qing Li , "Andrey V. Elsukov" , Julian Elischer , "Bjoern A. Zeeb" Subject: Re: RFC: interface description 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, 14 Aug 2009 20:05:28 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 14, 2009 at 10:49:24AM -0700, Li, Qing wrote: > >=20 > > My point has always been - if I have to add/do an ioctl I can always > > also use a library call that will read it from a .txt, .xml, .db file > > or whatever and I don't have to go to the kernel, handle all the > > string length problems there, ... especially as the kernel cannot do > > anything with that string. >=20 > The interface description feature is a useful feature. Quite a few > products out there actually put a label on the physical box so it's > reasonable to have the ability to label the ports in the kernel. >=20 > There are quite a few embedded systems and not-so-standalone boxes > out there that are derivatives of FreeBSD. These systems might not > have the luxury of a file system. And getting coredumps from the > field with such information embedded in the ifnet{} just makes > debugging field issues a little bit easier. I think this is a decently compelling argument for in-kernel descriptions. They do solve some synchronization issues and one pointer is probably an acceptable price to pay given all the edge cases related to keeping a file in sync if you went the totally user land route. I general, I don't think we should try too hard to solve every problem here. Adding a pointer to ifnet, a quick get/set ioctl, ifconfig support, and support for ifdesc_ or similar variables in rc.conf is probably as much as makes sense to do. This is mostly a feature for appliance builders. If I were working on adding the ability to slim down ifnet to the base system, I'd certainly make this an optional feature, but there are much fatter targets at the moment. -- Brooks --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKhbvuXY6L6fI4GtQRAj0JAJ9iXA8oEllkQfdG4u2GVs3vpBkb2gCdEccj yzbomu5g8F2V9q0KRZtnRkM= =N36y -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 14 20:21:44 2009 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 B25FD1065672; Fri, 14 Aug 2009 20:21:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8A35D8FC4B; Fri, 14 Aug 2009 20:21:44 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7EKLiZ6063604; Fri, 14 Aug 2009 20:21:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7EKLiQ0063600; Fri, 14 Aug 2009 20:21:44 GMT (envelope-from linimon) Date: Fri, 14 Aug 2009 20:21:44 GMT Message-Id: <200908142021.n7EKLiQ0063600@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/137775: [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many 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, 14 Aug 2009 20:21:44 -0000 Old Synopsis: [patch] Add XMIT_FAILOVER to ng_one2many New Synopsis: [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 14 20:20:55 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137775 From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 00:32:38 2009 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 1B565106568B; Sat, 15 Aug 2009 00:32:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id D36C28FC5B; Sat, 15 Aug 2009 00:32:36 +0000 (UTC) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id C5C765C025; Sat, 15 Aug 2009 08:32:35 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 8A3A955CDC3B; Sat, 15 Aug 2009 08:32:30 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id xtKur-2chUx8; Sat, 15 Aug 2009 08:31:36 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 5810155CDC5B; Sat, 15 Aug 2009 08:31:28 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=RdV63K2kmX8Gvf2lqRIYRG6l6H3OtV2NGFehrUz07N8rbG0BI4d3i+Z/07aCDlvY8 j8RUlUmZ1INh8eT4RpgQg== Message-ID: <4A8601CE.5030205@delphij.net> Date: Fri, 14 Aug 2009 17:31:10 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090803) MIME-Version: 1.0 To: Brooks Davis References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <20090814193303.GA21941@lor.one-eyed-alien.net> In-Reply-To: <20090814193303.GA21941@lor.one-eyed-alien.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------070600020208080409030004" Cc: "Li, Qing" , d@delphij.net, freebsd-net@freebsd.org, Qing Li , "Andrey V. Elsukov" , Julian Elischer , "Bjoern A. Zeeb" Subject: [Take 2] Re: RFC: interface description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 00:32:38 -0000 This is a multi-part message in MIME format. --------------070600020208080409030004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, guys, Here is a patch that implements the functionality in userland (as setifdescription/getifdescription functions in libutil); with this I think we can also provide an option that some kernel feature (like Qing Li said it might be useful for embedded systems, but of course the kernel feature would require more careful design) being used without modifying programs. This version uses if_dname plus if_dunit as distinguished name, and a Berkeley DB (hash, /etc/ifdescr.db) to store the information. In order to obtain if_dname and if_duint I had to create a new ioctl, as we don't seem to expose these two fields in an KBI-stable manner in the past. I have not took a look at bsnmp yet but I'll take a look at it to see if we have some better ways to distinguish the interface name. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqGAc0ACgkQi+vbBBjt66D82QCeMV3G+2FepN5asaxvAwpc0qKS 1poAoIhQ719JdYPE7sq+lseTtszr++o0 =ph72 -----END PGP SIGNATURE----- --------------070600020208080409030004 Content-Type: text/plain; name="ifdescr-userland.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifdescr-userland.diff" Index: sbin/ifconfig/ifconfig.c =================================================================== --- sbin/ifconfig/ifconfig.c (revision 196234) +++ sbin/ifconfig/ifconfig.c (working copy) @@ -63,6 +63,7 @@ static const char rcsid[] = #include #include +#include #include #include #include @@ -822,6 +823,24 @@ setifname(const char *val, int dummy __unused, int free(newname); } +/* ARGSUSED */ +static void +setifdescr(const char *val, int dummy __unused, int s, + const struct afswtch *afp __unused) +{ + + setifdescription(s, &ifr, val); +} + +/* ARGSUSED */ +static void +unsetifdescr(const char *val __unused, int dummy __unused, int s, + const struct afswtch *afp __unused) +{ + + setifdescription(s, &ifr, NULL); +} + #define IFFBITS \ "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ @@ -843,6 +862,7 @@ status(const struct afswtch *afp, const struct soc struct ifaddrs *ift; int allfamilies, s; struct ifstat ifs; + char *description = NULL; if (afp == NULL) { allfamilies = 1; @@ -866,6 +886,11 @@ status(const struct afswtch *afp, const struct soc printf(" mtu %d", ifr.ifr_mtu); putchar('\n'); + if (getifdescription(s, &ifr, &description) == 0 && description != NULL) + printf("\tdescription: %s\n", description); + free(description); + description = NULL; + if (ioctl(s, SIOCGIFCAP, (caddr_t)&ifr) == 0) { if (ifr.ifr_curcap != 0) { printb("\toptions", ifr.ifr_curcap, IFCAPBITS); @@ -1035,6 +1060,10 @@ static struct cmd basic_cmds[] = { DEF_CMD("-arp", IFF_NOARP, setifflags), DEF_CMD("debug", IFF_DEBUG, setifflags), DEF_CMD("-debug", -IFF_DEBUG, setifflags), + DEF_CMD_ARG("description", setifdescr), + DEF_CMD_ARG("descr", setifdescr), + DEF_CMD("-description", 0, unsetifdescr), + DEF_CMD("-descr", 0, unsetifdescr), DEF_CMD("promisc", IFF_PPROMISC, setifflags), DEF_CMD("-promisc", -IFF_PPROMISC, setifflags), DEF_CMD("add", IFF_UP, notealias), Index: sbin/ifconfig/Makefile =================================================================== --- sbin/ifconfig/Makefile (revision 196234) +++ sbin/ifconfig/Makefile (working copy) @@ -27,8 +27,8 @@ SRCS+= ifgre.c # GRE keys etc SRCS+= ifgif.c # GIF reversed header workaround SRCS+= ifieee80211.c regdomain.c # SIOC[GS]IEEE80211 support -DPADD+= ${LIBBSDXML} ${LIBSBUF} ${LIBJAIL} -LDADD+= -lbsdxml -ljail -lsbuf +DPADD+= ${LIBBSDXML} ${LIBSBUF} ${LIBJAIL} ${LIBUTIL} +LDADD+= -lbsdxml -ljail -lsbuf -lutil SRCS+= ifcarp.c # SIOC[GS]VH support SRCS+= ifgroup.c # ... Index: lib/libutil/Makefile =================================================================== --- lib/libutil/Makefile (revision 196234) +++ lib/libutil/Makefile (working copy) @@ -10,11 +10,12 @@ SHLIB_MAJOR= 8 SRCS= _secure_path.c auth.c expand_number.c flopen.c fparseln.c gr_util.c \ hexdump.c humanize_number.c kinfo_getfile.c kinfo_getvmmap.c kld.c \ + if_description.c \ login.c login_auth.c login_cap.c \ login_class.c login_crypt.c login_ok.c login_times.c login_tty.c \ logout.c logwtmp.c pidfile.c property.c pty.c pw_util.c realhostname.c \ stub.c trimdomain.c uucplock.c -INCS= libutil.h login_cap.h +INCS= if_description.h libutil.h login_cap.h WARNS?= 6 @@ -31,7 +32,7 @@ MAN+= kld.3 login.3 login_auth.3 login_tty.3 logou _secure_path.3 uucplock.3 property.3 auth.3 realhostname.3 \ realhostname_sa.3 trimdomain.3 fparseln.3 humanize_number.3 \ pidfile.3 flopen.3 expand_number.3 hexdump.3 \ - kinfo_getfile.3 kinfo_getvmmap.3 + kinfo_getfile.3 kinfo_getvmmap.3 if_description.3 MAN+= login.conf.5 auth.conf.5 MLINKS+= kld.3 kld_isloaded.3 kld.3 kld_load.3 MLINKS+= property.3 properties_read.3 property.3 properties_free.3 @@ -59,5 +60,6 @@ MLINKS+=pidfile.3 pidfile_open.3 \ pidfile.3 pidfile_write.3 \ pidfile.3 pidfile_close.3 \ pidfile.3 pidfile_remove.3 +MLINKS+= if_description.3 setifdescription.3 if_description.3 getifdescription.3 .include Index: lib/libutil/if_description.3 =================================================================== --- lib/libutil/if_description.3 (revision 0) +++ lib/libutil/if_description.3 (revision 0) @@ -0,0 +1,90 @@ +.\"- +.\" Copyright (c) 2009 Xin LI +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd September 15, 2009 +.Os +.Dt IFSETDESCRIPTION 3 +.Sh NAME +.Nm ifsetdescription , +.Nm ifgetdescription +.Nd ifnet description utility functions +.Sh LIBRARY +.Lb libutil +.Sh SYNOPSIS +.In if_description.h +.Ft int +.Fn setifdescription "int s" "struct ifreq *ifr" "const char *val" +.Ft int +.Fn getifdescription "int s" "struct ifreq *ifr" "char **val" +.Sh DESCRIPTION +These functions manipulates auxiliary interface description facility +from userland. +.Pp +The +.Fn setifdescription +function store the description +.Fa val +on the socket +.Fa s +referencing the interface and a struct ifreq pointer +.Fa ifr +that is already filled in with appropriate request information. +If +.Fa val +is NULL or is a pointer to empty string, +the interface description is removed. +.Pp +The +.Fn getifdescription +function reads and fills the description information into +.Fa *val +from the socket +.Fa s +with a struct ifreq pointer +.Fa ifr +that is already filled in with appropriate request information. +The previous +.Fa *val +will be freed and reallocated if it is not NULL. +.Sh RETURN VALUES +.Rv -std +.Sh SEE ALSO +.Xr netintro 4 , +.Sh HISTORY +The +.Fn ifsetdescription +and +.Fn ifgetdescrition +functions first appeared in +.Fx 9.0 . +.Sh AUTHORS +The +.Fn ifsetdescription +and +.Fn ifgetdescription +functions and this manual page were written by +.An Xin LI Aq delphij@FreeBSD.org . Property changes on: lib/libutil/if_description.3 ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: lib/libutil/if_description.c =================================================================== --- lib/libutil/if_description.c (revision 0) +++ lib/libutil/if_description.c (revision 0) @@ -0,0 +1,107 @@ +/*- + * Copyright (c) 2009 Xin LI + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +int +setifdescription(int s, struct ifreq *ifr, const char *val) +{ + DB *res; + DBT key, entry; + char dname[IFNAMSIZ]; + + bzero(dname, sizeof(dname)); + ifr->ifr_data = (caddr_t)dname; + + errno = ioctl(s, SIOCGIFDNAME, ifr); + if (errno == 0) { + res = dbopen(_PATH_IFDESCR_DB, + O_RDWR|O_CREAT|O_EXLOCK, + S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH, + DB_HASH, NULL); + if (res != NULL) { + key.data = dname; + key.size = strlen(dname); + + if (val == NULL || strlen(val) == 0) { + (res->del)(res, &key, 0); + } else { + entry.data = __DECONST(void *, val); + entry.size = strlen(val) + 1; + (res->put)(res, &key, &entry, 0); + } + (res->close)(res); + return 0; + } + } + + return -1; +} + +int +getifdescription(int s, struct ifreq *ifr, char **val) +{ + DB *res; + DBT key, entry; + char dname[IFNAMSIZ]; + + bzero(dname, sizeof(dname)); + ifr->ifr_data = (caddr_t)dname; + + free(*val); + *val = NULL; + + errno = ioctl(s, SIOCGIFDNAME, ifr); + if (errno == 0) { + res = dbopen(_PATH_IFDESCR_DB, + O_RDONLY|O_SHLOCK, 0, DB_HASH, NULL); + if (res != NULL) { + key.data = dname; + key.size = strlen(dname); + + if ((res->get)(res, &key, &entry, 0) == 0) { + *val = malloc(entry.size); + strlcpy(*val, entry.data, entry.size); + } + (res->close)(res); + } + } + return 0; +} + Property changes on: lib/libutil/if_description.c ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: lib/libutil/if_description.h =================================================================== --- lib/libutil/if_description.h (revision 0) +++ lib/libutil/if_description.h (revision 0) @@ -0,0 +1,37 @@ +/*- + * Copyright (c) 2009 Xin LI + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _IF_DESCRIPTION_H_ +#define _IF_DESCRIPTION_H_ + +#define _PATH_IFDESCR_DB "/etc/ifdescr.db" + +int setifdescription(int s, struct ifreq *ifr, const char *val); +int getifdescription(int s, struct ifreq *ifr, char **val); + +#endif /* _IF_DESCRIPTION_H_ */ Property changes on: lib/libutil/if_description.h ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 196234) +++ sys/net/if.c (working copy) @@ -1927,6 +1927,7 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d int new_flags, temp_flags; size_t namelen, onamelen; char new_name[IFNAMSIZ]; + char dname[IFNAMSIZ]; struct ifaddr *ifa; struct sockaddr_dl *sdl; @@ -1965,6 +1966,18 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d ifr->ifr_phys = ifp->if_physical; break; + case SIOCGIFDNAME: + bzero(dname, sizeof(dname)); + if (ifp->if_dunit != IF_DUNIT_NONE) + snprintf(dname, IFNAMSIZ, "%s%d", ifp->if_dname, + ifp->if_dunit); + else + strlcpy(dname, ifp->if_dname, sizeof(dname)); + error = copyout(dname, ifr->ifr_data, sizeof(dname)); + if (error) + return (error); + break; + case SIOCSIFFLAGS: error = priv_check(td, PRIV_NET_SETIFFLAGS); if (error) Index: sys/sys/sockio.h =================================================================== --- sys/sys/sockio.h (revision 196234) +++ sys/sys/sockio.h (working copy) @@ -82,6 +82,7 @@ #define SIOCGIFMAC _IOWR('i', 38, struct ifreq) /* get IF MAC label */ #define SIOCSIFMAC _IOW('i', 39, struct ifreq) /* set IF MAC label */ #define SIOCSIFNAME _IOW('i', 40, struct ifreq) /* set IF name */ +#define SIOCGIFDNAME _IOWR('i', 41, struct ifreq) /* get IF dname */ #define SIOCADDMULTI _IOW('i', 49, struct ifreq) /* add m'cast addr */ #define SIOCDELMULTI _IOW('i', 50, struct ifreq) /* del m'cast addr */ --------------070600020208080409030004-- From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 00:45:34 2009 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 3DB57106568B for ; Sat, 15 Aug 2009 00:45:34 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id E07928FC15 for ; Sat, 15 Aug 2009 00:45:33 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so635968qwe.7 for ; Fri, 14 Aug 2009 17:45:33 -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:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=jEYKgb/u/I2rbvePWWtuuIbeuNHnZp4BGJBIXbicNRw=; b=dXniRWnqXCrUMJcbKflklw4miX0acq8mBSpTglUN/7ZJ3ogliHM1vCNqiNhLOsadcI BvjCI85NEx6PG34d+76U34cXtmWkg6xlvr8SWNhBCL2YQdzcxyB6JhoQufyKNlPdUp95 6KiyDVjQfAa6foEPEfvV/7R3ekSv8Y/Htjl4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=c1l+ObM9Oe9aAj4nGZEWjuF0FLyinEbAGUiTPLGRq94XVlAOaq1o6SPPCLM5zLj1om BNoqOsbnNd5pTGEovbXRG8/Il6UR2c7iJ3cSxFDVALFLFjg6f3o7aw0k4dbcRq78NYVq rJthVHD1QsKaNlqO2XOvr61eMIpptgQT0BS7w= Received: by 10.224.84.133 with SMTP id j5mr2823581qal.149.1250297133139; Fri, 14 Aug 2009 17:45:33 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 2sm4480937qwi.23.2009.08.14.17.45.31 (version=SSLv3 cipher=RC4-MD5); Fri, 14 Aug 2009 17:45:32 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Fri, 14 Aug 2009 17:45:49 -0700 From: Weongyo Jeong Date: Fri, 14 Aug 2009 17:45:49 -0700 To: Alireza Torabi Message-ID: <20090815004549.GA70621@weongyo.local> Mail-Followup-To: Alireza Torabi , freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-net@freebsd.org Subject: Re: 8. Current and Intel 5100 AGN wifi X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 00:45:34 -0000 On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: > folks, > > Can anyone please shet any lights on this. are iwn & iwnfw going to > support 5100 agn wifi? > I've updated mine to 8. Current with iwn & iwnfw and still not going > anywhere with the card. AFAIK no one working on it. regards, Weongyo Jeong From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 00:50:59 2009 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 6F08010656A7 for ; Sat, 15 Aug 2009 00:50:59 +0000 (UTC) (envelope-from alireza.torabi@gmail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id C90888FC15 for ; Sat, 15 Aug 2009 00:50:54 +0000 (UTC) Received: by ewy2 with SMTP id 2so1135977ewy.43 for ; Fri, 14 Aug 2009 17:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=MVZvj2LivZI8f7MpW/LJ5wXHFaKy2dVzmmTH3M9Gv3w=; b=YRrgn5jvqJDZpHt0Bc9KkIY3U349/KuaM4PiaUrg6Z1OHSj2NgQwxN/2JqKNDxHrjU fowTOVjsPD/fAPZhRrLd9Hdqf1g0P5h0Q1oiEYORxksOfDrFsllpQYLbPeh4cOJFyRfG srfjTeLLNog7HRbxWuaqOiwCz1RiJP1osOeN0= 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 :content-type:content-transfer-encoding; b=elem9xiskCS6OUCuY0RyhyyuJowOUo1nD+E4lThpOy+mjgnmD8P08Urv8LpKDtfry7 gG254uhQciNJm0lU0oxOXvKncU+XrNIznqXGa8CyVeus9s8HaB1N0FsLQF3+2/KOWS4P V4vDNOD61FvVztgRHnQJfoNy5X2y0dWyH7QpM= MIME-Version: 1.0 Received: by 10.216.0.84 with SMTP id 62mr509685wea.185.1250297453869; Fri, 14 Aug 2009 17:50:53 -0700 (PDT) In-Reply-To: <20090815004549.GA70621@weongyo.local> References: <20090815004549.GA70621@weongyo.local> Date: Sat, 15 Aug 2009 01:50:53 +0100 Message-ID: From: Alireza Torabi To: Weongyo Jeong , Alireza Torabi , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: 8. Current and Intel 5100 AGN wifi 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, 15 Aug 2009 00:50:59 -0000 thanks so i gathered by the lack of response i must say... On 8/15/09, Weongyo Jeong wrote: > On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: >> folks, >> >> Can anyone please shet any lights on this. are iwn & iwnfw going to >> support 5100 agn wifi? >> I've updated mine to 8. Current with iwn & iwnfw and still not going >> anywhere with the card. > > AFAIK no one working on it. > > regards, > Weongyo Jeong > > From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 03:10:41 2009 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 9DF71106568C; Sat, 15 Aug 2009 03:10:41 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0328FC57; Sat, 15 Aug 2009 03:10:40 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so653183qwe.7 for ; Fri, 14 Aug 2009 20:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=tv/lRny0j7Ipasi4QEzP1b+kujRsOrxU1JTxrSHSxN8=; b=Sy/vf/U7q2QlwWwJRggUt0qudk/EYpfs7DJdte/pO0dZ0YCBookscjGl+amGkgNSTo /SD8MhswO/wCLk+EjFcJWYE4PXq2aHnM6Cvl8+YSvRWcrX7P05PeinMO7iRr8FdcgRVL 2R+V0jeKxyTujbGkOtINnsWsnISt24TkD3Jq8= 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 :content-type:content-transfer-encoding; b=kXS7vXXCshQ4EufgOqzrKfI46BWVxDGQZPki1UHLF15MB0ONm731rKoW3B/yjzhYFn alUdxOlvuyizFZal1vH1nEN4IlNkqTKhAQCax+acKwrioD19hEZHh5FRu10C7aTJwDrv 4TUOWYVYHWS1WGafbmu2Zm262mFb/NVsVI/Fk= MIME-Version: 1.0 Received: by 10.229.33.70 with SMTP id g6mr1492989qcd.75.1250305840480; Fri, 14 Aug 2009 20:10:40 -0700 (PDT) In-Reply-To: <20090815004549.GA70621@weongyo.local> References: <20090815004549.GA70621@weongyo.local> Date: Fri, 14 Aug 2009 22:10:40 -0500 Message-ID: <11167f520908142010g278e0cd7q3acaf989b75ac69a@mail.gmail.com> From: "Sam Fourman Jr." To: Weongyo Jeong , Alireza Torabi , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: 8. Current and Intel 5100 AGN wifi 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, 15 Aug 2009 03:10:41 -0000 On Fri, Aug 14, 2009 at 7:45 PM, Weongyo Jeong wro= te: > On Sun, Aug 09, 2009 at 02:41:20PM +0100, Alireza Torabi wrote: >> folks, >> >> Can anyone please shet any lights on this. are iwn & iwnfw =A0going to >> support 5100 agn wifi? >> I've updated mine to 8. Current with iwn & iwnfw and still not going >> anywhere with the card. > > AFAIK no one working on it. > > regards, > Weongyo Jeong I have a spare 5100 agn to donate if someone want to work on a driver Sam Fourman Jr. From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 12:10:11 2009 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 DBBB0106568D; Sat, 15 Aug 2009 12:10:11 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B2B078FC55; Sat, 15 Aug 2009 12:10:11 +0000 (UTC) Received: from freefall.freebsd.org (brucec@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7FCABAB027134; Sat, 15 Aug 2009 12:10:11 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7FCABDq027124; Sat, 15 Aug 2009 12:10:11 GMT (envelope-from brucec) Date: Sat, 15 Aug 2009 12:10:11 GMT Message-Id: <200908151210.n7FCABDq027124@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/137795: [sctp] panic: mtx_lock() of destroyed mutex 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, 15 Aug 2009 12:10:12 -0000 Synopsis: [sctp] panic: mtx_lock() of destroyed mutex Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Sat Aug 15 12:09:35 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137795 From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 15:01:24 2009 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 DA7CB106568F for ; Sat, 15 Aug 2009 15:01:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8818FC15 for ; Sat, 15 Aug 2009 15:01:24 +0000 (UTC) Received: (qmail 96602 invoked from network); 15 Aug 2009 14:12:09 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Aug 2009 14:12:09 -0000 Message-ID: <4A86C782.5030808@freebsd.org> Date: Sat, 15 Aug 2009 16:34:42 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: d@delphij.net References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <20090814193303.GA21941@lor.one-eyed-alien.net> <4A8601CE.5030205@delphij.net> In-Reply-To: <4A8601CE.5030205@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , Brooks Davis , freebsd-net@freebsd.org, Qing Li , "Andrey V. Elsukov" , Julian Elischer , "Bjoern A. Zeeb" Subject: Re: [Take 2] Re: RFC: interface description 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, 15 Aug 2009 15:01:24 -0000 Xin LI wrote: > Hi, guys, > > Here is a patch that implements the functionality in userland (as > setifdescription/getifdescription functions in libutil); with this I > think we can also provide an option that some kernel feature (like Qing > Li said it might be useful for embedded systems, but of course the > kernel feature would require more careful design) being used without > modifying programs. This version uses if_dname plus if_dunit as > distinguished name, and a Berkeley DB (hash, /etc/ifdescr.db) to store > the information. I don't like this approach. Adding unconditional dependencies to libutil and libbsdxml unnecessarily complicates and bloats up ifconfig, which is a very central utility that resides on every rescue and minimal boot disk. Additionally the DB stored description can easily go out of sync when interface disappear and reappear. On top of that it complicates porting of routing daemons (Quagga suite, OpenBGPD/OSPFD). Having it only for ifconfig but nowhere else is not entirely pointless but seriously reduces its usefulness. IMHO interface description is a very useful feature and it should be stored in the kernel attached to struct ifnet. However it probably should only be a pointer to malloc'ed memory. It is only infrequently accessed and never in a critical code path. A slight disadvantage is either a separate IOCTL to retrieve the description or a little hack to copy it into struct ifnet just when it is retrieved by userspace from the kernel. [Which reminds me that somewhen we need something more flexible than the current routing socket.] -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 17:39:14 2009 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 11E241065692 for ; Sat, 15 Aug 2009 17:39:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id E2CF48FC61 for ; Sat, 15 Aug 2009 17:39:13 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 445BDA1049; Sat, 15 Aug 2009 10:39:13 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2A3672D6010; Sat, 15 Aug 2009 10:39:11 -0700 (PDT) Message-ID: <4A86F2BE.4050203@elischer.org> Date: Sat, 15 Aug 2009 10:39:10 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andre Oppermann References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <20090814193303.GA21941@lor.one-eyed-alien.net> <4A8601CE.5030205@delphij.net> <4A86C782.5030808@freebsd.org> In-Reply-To: <4A86C782.5030808@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , Brooks Davis , d@delphij.net, freebsd-net@freebsd.org, Qing Li , "Andrey V. Elsukov" , "Bjoern A. Zeeb" Subject: Re: [Take 2] Re: RFC: interface description 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, 15 Aug 2009 17:39:14 -0000 Andre Oppermann wrote: > Xin LI wrote: >> Hi, guys, >> >> Here is a patch that implements the functionality in userland (as >> setifdescription/getifdescription functions in libutil); with this I >> think we can also provide an option that some kernel feature (like Qing >> Li said it might be useful for embedded systems, but of course the >> kernel feature would require more careful design) being used without >> modifying programs. This version uses if_dname plus if_dunit as >> distinguished name, and a Berkeley DB (hash, /etc/ifdescr.db) to store >> the information. > > I don't like this approach. Adding unconditional dependencies to libutil > and libbsdxml unnecessarily complicates and bloats up ifconfig, which is > a very central utility that resides on every rescue and minimal boot disk. > > Additionally the DB stored description can easily go out of sync when > interface disappear and reappear. On top of that it complicates porting > of routing daemons (Quagga suite, OpenBGPD/OSPFD). Having it only for > ifconfig but nowhere else is not entirely pointless but seriously reduces > its usefulness. > > IMHO interface description is a very useful feature and it should be stored > in the kernel attached to struct ifnet. However it probably should only be > a pointer to malloc'ed memory. It is only infrequently accessed and never > in a critical code path. A slight disadvantage is either a separate IOCTL > to retrieve the description or a little hack to copy it into struct ifnet > just when it is retrieved by userspace from the kernel. [Which reminds me > that somewhen we need something more flexible than the current routing > socket.] > From my perspective, putting it in a separate db outside the kernel kind of defeats the purpose. I thought the first patches had the right idea. though for me the current ability to rename an interface is good enough. I mean is you can cal your interface "Sydney0" or "Melbourne2" that is really enough.. From owner-freebsd-net@FreeBSD.ORG Sat Aug 15 19:40:25 2009 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 070FF106568B for ; Sat, 15 Aug 2009 19:40:25 +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 49D3D8FC15 for ; Sat, 15 Aug 2009 19:40:23 +0000 (UTC) Received: (qmail 26292 invoked from network); 15 Aug 2009 19:40:22 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Aug 2009 19:40:22 -0000 Date: Sat, 15 Aug 2009 21:40:22 +0200 (CEST) Message-Id: <20090815.214022.41662662.sthaug@nethelp.no> To: julian@elischer.org From: sthaug@nethelp.no In-Reply-To: <4A86F2BE.4050203@elischer.org> References: <4A8601CE.5030205@delphij.net> <4A86C782.5030808@freebsd.org> <4A86F2BE.4050203@elischer.org> 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: qing.li@bluecoat.com, brooks@freebsd.org, d@delphij.net, freebsd-net@freebsd.org, qingli@freebsd.org, bu7cher@yandex.ru, bzeeb-lists@lists.zabbadoz.net, andre@freebsd.org Subject: Re: [Take 2] Re: RFC: interface description 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, 15 Aug 2009 19:40:25 -0000 > From my perspective, putting it in a separate db outside the kernel > kind of defeats the purpose. I thought the first patches had the > right idea. though for me the current ability to rename an interface > is good enough. I mean is you can cal your interface "Sydney0" or > "Melbourne2" that is really enough.. Having read the discussion, I agree that the description should be in the kernel. However, being a router geek the ability to rename an interface to "Sydney0" or "Melbourne2" is not at all enough. For the routers & switches I work with we really want a description of at least 50 characters - and it's important to be able to include space. Steinar Haug, Nethelp consulting, sthaug@nethelp.no