From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 00:02:24 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40B32106564A; Sun, 29 Aug 2010 00:02:24 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A60588FC0C; Sun, 29 Aug 2010 00:02:23 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o7T02LPZ008604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Aug 2010 02:02:22 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id o7T02JsK001980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2010 02:02:19 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o7T02J4R006081; Sun, 29 Aug 2010 02:02:19 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o7T02JLc006080; Sun, 29 Aug 2010 02:02:19 +0200 (CEST) (envelope-from ticso) Date: Sun, 29 Aug 2010 02:02:19 +0200 From: Bernd Walter To: Doug Barton Message-ID: <20100829000218.GI82417@cicely7.cicely.de> References: <20100828220844.GE82417@cicely7.cicely.de> <4C798CC4.1060904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C798CC4.1060904@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-net@FreeBSD.org, Bernd Walter , ticso@cicely.de Subject: Re: Problem with link-local addresses on USB interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 00:02:24 -0000 On Sat, Aug 28, 2010 at 03:25:08PM -0700, Doug Barton wrote: > On 8/28/2010 3:08 PM, Bernd Walter wrote: > >Only the PCI and loopback interface responds to their own link local > >address. > > > >I'm also puzzled about what I need to configure on an interface > >to get an link-local address. > >I've finally put ifconfig_ue0/1="UP" into rc.conf. > > You haven't said what version of FreeBSD you're using, but I'm assuming > -current. The security officer asked to have the default changed so that > link-local addresses are not accessible by default. I implemented a > version of this such that the interface comes up with "ifdisabled" by > default, which prevents all IPv6 traffic, but does not prevent you from > configuring the interface. Ah - Ok - quite unexpected after ~10 years IPv6 on FreeBSD. But now everything looks fine. > You can read in the ifconfig man page how to clear that flag, which will > allow traffic to flow. There are also examples in /etc/defaults/rc.conf > that demonstrate how to set up an ifconfig line to do nothing but > establish a link-local if that's how you want the interface to be > configured. Thank you for the quick response. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 01:31:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4218106564A for ; Sun, 29 Aug 2010 01:31:14 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 052258FC0A for ; Sun, 29 Aug 2010 01:31:13 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.3) with ESMTP id o7T1V8PZ032599 for ; Sun, 29 Aug 2010 04:31:08 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4C79B85C.70303@ukr.net> Date: Sun, 29 Aug 2010 04:31:08 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4C744053.6010403@ukr.net> In-Reply-To: <4C744053.6010403@ukr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.6 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: Error: em0: Watchdog timeout -- resetting 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, 29 Aug 2010 01:31:14 -0000 Problem resolved replacing the motherboard. ifconfig_em0="inet xxx.xxx.xxx.82/29" # ifconfig em0 | grep -v inet em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:25:90:06:bc:60 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active Note that the default setting network card no options: RXCSUM and TXCSUM! 25.08.2010 0:57, Vladislav V. Prodan wrote: > The server is sometimes off the network card. > It helps just to restart via KVM-IPMI. > > MotherBoard: X8SIL/X8SIL-F > BIOS Version: 1.0c > Build Date: 02/05/10 > > OS: FreeBSD 8.1-RELEASE, FreeBSD 8.1-STABLE, FreeBSD 9.0-CURRENT > > What would you recommend to address the problem? > > > # uname -a > FreeBSD solo.XXX.biz 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue Aug 24 > 15:52:21 EEST 2010 root@solo.XXX.biz:/usr/obj/usr/src/sys/solo.2 amd64 > > #pciconf -lv > ... > em0@pci0:2:0:0: class=0x020000 card=0x060515d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > em1@pci0:3:0:0: class=0x020000 card=0x060515d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > ... > From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 05:16:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B306510656AE for ; Sun, 29 Aug 2010 05:16:25 +0000 (UTC) (envelope-from sadishkr@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1638FC17 for ; Sun, 29 Aug 2010 05:16:25 +0000 (UTC) Received: by iwn36 with SMTP id 36so4420105iwn.13 for ; Sat, 28 Aug 2010 22:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=b/UZz3rH0mJTFVXQ/c5ejunSx5Q1bXQ3E2Zfx+yrZy4=; b=j+I475LZx1gyzK7rXxY3KvScl+aSTyicVT6PwWxvjlSe6Gr0jPoSF/H+aYsWigblJi 86NlwgtXAdnfLJ87J9gZ/1ezotrRtvmJ+rPBZtY42tzj9qvGLsa0JSu12xvSn7NwEYHU LAiRB5fp8KGKb/OkFqEluvt9FME+OfOb2N6Ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=thwSkeRjYH55LyAuCX8qYDlNk3R21YXEUhSeDv/rtTWAYcJC6NnPM0DBZR2creMCEl vPA8bvm2XjFUq3/Um/CrYGtxz2IMWyelko6ODSaGHdDow+eqtDuO9CoO3Ejq9lnOmj5+ YQsBdWovN6N53DGhHSCQQpywWKEqJX0daC/y8= MIME-Version: 1.0 Received: by 10.231.169.149 with SMTP id z21mr3397706iby.11.1283058984855; Sat, 28 Aug 2010 22:16:24 -0700 (PDT) Received: by 10.231.191.67 with HTTP; Sat, 28 Aug 2010 22:16:24 -0700 (PDT) Date: Sun, 29 Aug 2010 15:16:24 +1000 Message-ID: From: Sadish Kulasekere To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Sending packets at Kernel level 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, 29 Aug 2010 05:16:25 -0000 Hi, I need to know how to send packet from the kernel level. Can someone please point me to any documentation? Cheers, Sadish. From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 15:22:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1563E1065674 for ; Sun, 29 Aug 2010 15:22:15 +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 69EE58FC1D for ; Sun, 29 Aug 2010 15:22:14 +0000 (UTC) Received: (qmail 43391 invoked from network); 29 Aug 2010 15:20:12 -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 ; 29 Aug 2010 15:20:12 -0000 Message-ID: <4C7A7B25.9040300@freebsd.org> Date: Sun, 29 Aug 2010 17:22:13 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------030501000301080006010502" Subject: Removal of deprecated implied connect for TCP 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, 29 Aug 2010 15:22:15 -0000 This is a multi-part message in MIME format. --------------030501000301080006010502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago the semantics of sendto(2) with regard to TCP sockets were changed. It became possible directly do a sendto(2) call with the target address in the *to argument instead of doing a connect(2) first and subsequent write(2) or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR could be specified to close the connection again right again after the data has been sent out. This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD was the only OS to ever ship this. T/TCP was ill-defined and had major security issues and never gained any support. It has been defunct in FreeBSD and most code has been removed about 6 years ago. The sendto(2) extended functionality is one of the last parts that persisted and remained around living a zombie life. I want to remove it now because it is totally non-portable, has no known users and complicates the TCP send path. The patch is attached. If you have any objections speak up now. -- Andre --------------030501000301080006010502 Content-Type: text/plain; name="tcp_usrreq-implied-connect.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcp_usrreq-implied-connect.diff" Index: netinet/tcp_usrreq.c =================================================================== --- netinet/tcp_usrreq.c (revision 211874) +++ netinet/tcp_usrreq.c (working copy) @@ -740,86 +740,34 @@ int error = 0; struct inpcb *inp; struct tcpcb *tp = NULL; - int headlocked = 0; -#ifdef INET6 - int isipv6; -#endif + TCPDEBUG0; - /* - * We require the pcbinfo lock in two cases: - * - * (1) An implied connect is taking place, which can result in - * binding IPs and ports and hence modification of the pcb hash - * chains. - * - * (2) PRUS_EOF is set, resulting in explicit close on the send. - */ - if ((nam != NULL) || (flags & PRUS_EOF)) { - INP_INFO_WLOCK(&V_tcbinfo); - headlocked = 1; + /* TCP doesn't do control messages (rights, creds, etc.) */ + if (control != NULL && control->m_len) { + error = EINVAL; + goto out; } + inp = sotoinpcb(so); - KASSERT(inp != NULL, ("tcp_usr_send: inp == NULL")); + KASSERT(inp != NULL, ("%s: inp == NULL", __func__)); INP_WLOCK(inp); - if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) { - if (control) - m_freem(control); - if (m) - m_freem(m); + if (inp->inp_flags & (INP_DROPPED | INP_TIMEWAIT)) { error = ECONNRESET; - goto out; + goto done; } -#ifdef INET6 - isipv6 = nam && nam->sa_family == AF_INET6; -#endif /* INET6 */ tp = intotcpcb(inp); + TCPDEBUG1(); - if (control) { - /* TCP doesn't do control messages (rights, creds, etc) */ - if (control->m_len) { - m_freem(control); - if (m) - m_freem(m); - error = EINVAL; - goto out; - } - m_freem(control); /* empty control, just free it */ - } + + /* + * Append the new data to the send socket buffer and + * try to send it (may be limited by CWND). + */ if (!(flags & PRUS_OOB)) { sbappendstream(&so->so_snd, m); - if (nam && tp->t_state < TCPS_SYN_SENT) { - /* - * Do implied connect if not yet connected, - * initialize window to default value, and - * initialize maxseg/maxopd using peer's cached - * MSS. - */ - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); -#ifdef INET6 - if (isipv6) - error = tcp6_connect(tp, nam, td); - else -#endif /* INET6 */ - error = tcp_connect(tp, nam, td); - if (error) - goto out; - tp->snd_wnd = TTCP_CLIENT_SND_WND; - tcp_mss(tp, -1); - } - if (flags & PRUS_EOF) { - /* - * Close the send side of the connection after - * the data is sent. - */ - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); - socantsendmore(so); - tcp_usrclosed(tp); - } - if (headlocked) { - INP_INFO_WUNLOCK(&V_tcbinfo); - headlocked = 0; - } + m = NULL; + if (!(inp->inp_flags & INP_DROPPED)) { if (flags & PRUS_MORETOCOME) tp->t_flags |= TF_MORETOCOME; @@ -828,15 +776,11 @@ tp->t_flags &= ~TF_MORETOCOME; } } else { - /* - * XXXRW: PRUS_EOF not implemented with PRUS_OOB? - */ SOCKBUF_LOCK(&so->so_snd); if (sbspace(&so->so_snd) < -512) { SOCKBUF_UNLOCK(&so->so_snd); - m_freem(m); error = ENOBUFS; - goto out; + goto done; } /* * According to RFC961 (Assigned Protocols), @@ -847,42 +791,24 @@ * Otherwise, snd_up should be one lower. */ sbappendstream_locked(&so->so_snd, m); + m = NULL; SOCKBUF_UNLOCK(&so->so_snd); - if (nam && tp->t_state < TCPS_SYN_SENT) { - /* - * Do implied connect if not yet connected, - * initialize window to default value, and - * initialize maxseg/maxopd using peer's cached - * MSS. - */ - INP_INFO_WLOCK_ASSERT(&V_tcbinfo); -#ifdef INET6 - if (isipv6) - error = tcp6_connect(tp, nam, td); - else -#endif /* INET6 */ - error = tcp_connect(tp, nam, td); - if (error) - goto out; - tp->snd_wnd = TTCP_CLIENT_SND_WND; - tcp_mss(tp, -1); - INP_INFO_WUNLOCK(&V_tcbinfo); - headlocked = 0; - } else if (nam) { - INP_INFO_WUNLOCK(&V_tcbinfo); - headlocked = 0; - } + tp->snd_up = tp->snd_una + so->so_snd.sb_cc; tp->t_flags |= TF_FORCEDATA; error = tcp_output_send(tp); tp->t_flags &= ~TF_FORCEDATA; } -out: - TCPDEBUG2((flags & PRUS_OOB) ? PRU_SENDOOB : - ((flags & PRUS_EOF) ? PRU_SEND_EOF : PRU_SEND)); + TCPDEBUG2((flags & PRUS_OOB) ? PRU_SENDOOB : PRU_SEND); +done: INP_WUNLOCK(inp); - if (headlocked) - INP_INFO_WUNLOCK(&V_tcbinfo); +out: + /* Free mbufs in error cases. */ + if (m != NULL) + m_freem(m); + if (control != NULL) + m_freem(control); + return (error); } Index: netinet/in_proto.c =================================================================== --- netinet/in_proto.c (revision 211874) +++ netinet/in_proto.c (working copy) @@ -134,7 +134,7 @@ .pr_type = SOCK_STREAM, .pr_domain = &inetdomain, .pr_protocol = IPPROTO_TCP, - .pr_flags = PR_CONNREQUIRED|PR_IMPLOPCL|PR_WANTRCVD, + .pr_flags = PR_CONNREQUIRED|PR_WANTRCVD, .pr_input = tcp_input, .pr_ctlinput = tcp_ctlinput, .pr_ctloutput = tcp_ctloutput, --------------030501000301080006010502-- From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 18:18:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2475810656D4 for ; Sun, 29 Aug 2010 18:18:06 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D0ADC8FC12 for ; Sun, 29 Aug 2010 18:18:05 +0000 (UTC) Received: by qwg5 with SMTP id 5so4735107qwg.13 for ; Sun, 29 Aug 2010 11:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=S/myDPmx9hC5ltmTDO0PKAcT+13o8KdYsFuzHMiwKIU=; b=M72jxyq0CP65pSN6o+IQRcGSEWc3Hd9HDVB4hnBaRUACiL1dXh7NdWxBMZRRgeBjAX sR+ZrqVIXWU51fi9cmqMe+eMJPWl73Y+b0v1LcHjNbFpP+OUU5YyXyOf8FozJEBABZwV Cg1iFJXuRGqF37eopbIzBa3oUNk3dMvUP4mmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c/qYN/4GkiO83e4mD/8I4WHXHqRAf2qyOG0m1kukKyCAJESnCrkkfnDbLlSBy46mU3 TWIyctvuD3Hrmw15umO8SCcDNSYUsOStIGzbK8KWORlcYeCVEfmLVqR/7cjzCxrjLSTF zNgtL7+/jLAXNrGWDLaXhFSyPNNMMmY0CdknE= MIME-Version: 1.0 Received: by 10.224.89.11 with SMTP id c11mr2166442qam.182.1283104404984; Sun, 29 Aug 2010 10:53:24 -0700 (PDT) Received: by 10.229.46.146 with HTTP; Sun, 29 Aug 2010 10:53:24 -0700 (PDT) Date: Sun, 29 Aug 2010 20:53:24 +0300 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Default router changes unexpectedly 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, 29 Aug 2010 18:18:06 -0000 Hi, I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan used mostly. System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. Sometimes default router changes unexpectedly. I inspected logs if someone logged in or changed route. I found nothing. This problem repeats at least 1 times per day. I wrote a shell script which monitors the default router. I saw that sometimes netstat -rn shows that default router is changed as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but routing still routes to right router 212.X.Y.Z . After a while, routing really fails. I use em nics for all. At the weekends (when most clients are now working) i dont have any problems. I think some network packets affects the defaultrouter. I tried to block packets belongs to the IP addresses which shown as default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is solved. I wonder how the default router can be changed with packets that came from network? How can i prevent this without writing firewall rules? Or which packets should I drop? Any ideas? Regards, Ozkan KIRIK Mersin University @ Turkey From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 18:21:41 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D8F1065693 for ; Sun, 29 Aug 2010 18:21:41 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 31F998FC15 for ; Sun, 29 Aug 2010 18:21:40 +0000 (UTC) Received: by qyk4 with SMTP id 4so4963624qyk.13 for ; Sun, 29 Aug 2010 11:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=S/myDPmx9hC5ltmTDO0PKAcT+13o8KdYsFuzHMiwKIU=; b=vuSRCpxDxZakCdPN4uXFmuwZGv8/6xVBJjmUGLK2ipLo0ZAoTtZZbMRidIVBQATyzi 4Uzl6ip1ZeOYgPBxinwtO5GAyKoefyxPwb4x38Wxe0eCYnV6wCqlis0uz5a7odC3wnF1 BsCaRRBI6Rp3RWmAjWJGFCWYYbhb2voSf/Usg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CZ5x8oqmnHp8EEw3cirb3yTPtCHFc4x4DME21COJVv6eyehv0xaWuMVf8sO8kAAYvT eZTsy6O8hp+NnSOevCufZXeucZKe0k22eJvEjliLOqoaTS8J7Unwj4trlGb406ije6Zp Pjlw40AoLQUV8o6qrdNulM8ldXdqU/o1xmX9c= MIME-Version: 1.0 Received: by 10.224.89.11 with SMTP id c11mr2164732qam.182.1283104230248; Sun, 29 Aug 2010 10:50:30 -0700 (PDT) Received: by 10.229.46.146 with HTTP; Sun, 29 Aug 2010 10:50:30 -0700 (PDT) Date: Sun, 29 Aug 2010 20:50:30 +0300 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Default router changes unexpectedly 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, 29 Aug 2010 18:21:41 -0000 Hi, I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan used mostly. System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. Sometimes default router changes unexpectedly. I inspected logs if someone logged in or changed route. I found nothing. This problem repeats at least 1 times per day. I wrote a shell script which monitors the default router. I saw that sometimes netstat -rn shows that default router is changed as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but routing still routes to right router 212.X.Y.Z . After a while, routing really fails. I use em nics for all. At the weekends (when most clients are now working) i dont have any problems. I think some network packets affects the defaultrouter. I tried to block packets belongs to the IP addresses which shown as default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is solved. I wonder how the default router can be changed with packets that came from network? How can i prevent this without writing firewall rules? Or which packets should I drop? Any ideas? Regards, Ozkan KIRIK Mersin University @ Turkey From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 18:59:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E2941065698 for ; Sun, 29 Aug 2010 18:59:51 +0000 (UTC) (envelope-from freebsd@bitfreak.org) Received: from epona.bluerosetech.com (epona.bluerosetech.com [204.109.56.17]) by mx1.freebsd.org (Postfix) with ESMTP id 2A3188FC0A for ; Sun, 29 Aug 2010 18:59:50 +0000 (UTC) Received: from vivi.cat.pdx.edu (vivi.cat.pdx.edu [131.252.214.6]) by epona.bluerosetech.com (Postfix) with ESMTPSA id 4CACC5D2D6 for ; Sun, 29 Aug 2010 11:54:24 -0700 (PDT) Received: from [127.0.0.1] (c-71-236-221-127.hsd1.wa.comcast.net [71.236.221.127]) by vivi.cat.pdx.edu (Postfix) with ESMTPSA id 5791E24CDD for ; Sun, 29 Aug 2010 11:54:22 -0700 (PDT) Message-ID: <4C7AACDB.3020502@bitfreak.org> Date: Sun, 29 Aug 2010 11:54:19 -0700 From: Darren Pilgrim User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: How to configure specific router address to advertise with rtadvd? 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, 29 Aug 2010 18:59:51 -0000 I have a machine I want to do IPv6 routing. The interface out which its sending router advertisements has multiple static IPv6 addresses assigned from the same prefix. The problem is rtadvd is selecting the "wrong" address for the router. The man page for rtadvd.conf doesn't indicate how to do this. How do I tell rtadvd which address to advertise as the router? From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 19:04:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F07B10656AC for ; Sun, 29 Aug 2010 19:04:51 +0000 (UTC) (envelope-from freebsd@bitfreak.org) Received: from epona.bluerosetech.com (epona.bluerosetech.com [204.109.56.17]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5FD8FC13 for ; Sun, 29 Aug 2010 19:04:50 +0000 (UTC) Received: from vivi.cat.pdx.edu (vivi.cat.pdx.edu [131.252.214.6]) by epona.bluerosetech.com (Postfix) with ESMTPSA id 0D2FF5C052 for ; Sun, 29 Aug 2010 11:47:54 -0700 (PDT) Received: from [127.0.0.1] (c-71-236-221-127.hsd1.wa.comcast.net [71.236.221.127]) by vivi.cat.pdx.edu (Postfix) with ESMTPSA id 4C8D124CDD for ; Sun, 29 Aug 2010 11:47:52 -0700 (PDT) Message-ID: <4C7AAB54.2050309@bitfreak.org> Date: Sun, 29 Aug 2010 11:47:48 -0700 From: Darren Pilgrim User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: How to configure non-EUI64 IPv6 addresses with solicited prefixes? 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, 29 Aug 2010 19:04:51 -0000 I have two machines where I need them to: 1. Solicit a prefix; 2. Apply the solicitation to a non-EUI64 address; 3. Use the non-EUI64 address as the default source address. Retaining the EUI64 address is not necessary. Static configuration prevents 1 and I have not been able to get 2 or 3 to work at all. The original KAME documentation implies this is/was possible, but current documentation says nothing about it (not that I can find, anyway). A grep of /etc/* indicates interface_ipv6_ifid_* variables (mentioned in the KAME documentation) are not supported. One is running 8.1, the other 6.4 (I can upgrade it if necessary). From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 19:35:05 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53EFB10656B8 for ; Sun, 29 Aug 2010 19:35:05 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id B92AD8FC19 for ; Sun, 29 Aug 2010 19:35:04 +0000 (UTC) Received: from bel.soho.vwsoft.com (p57A0DC1B.dip.t-dialin.net [87.160.220.27]) by Mail.elbekies.net (Postfix) with ESMTPA id DF9FD2E05A; Sun, 29 Aug 2010 21:09:56 +0200 (CEST) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id C42E033C7E; Sun, 29 Aug 2010 21:08:08 +0200 (CEST) Message-ID: <4C7AB073.2040802@vwsoft.com> Date: Sun, 29 Aug 2010 21:09:39 +0200 From: volker@vwsoft.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.11) Gecko/20100811 Thunderbird/3.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: DF9FD2E05A.ABA9E X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com MailScanner-NULL-Check: 1283713805.72968@dLuZxfgrI0lvXxijBrLa2Q Cc: net@freebsd.org Subject: Re: Default router changes unexpectedly 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, 29 Aug 2010 19:35:05 -0000 On 08/29/10 19:50, Özkan KIRIK wrote: > Hi, > > I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan > used mostly. > System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. > > Sometimes default router changes unexpectedly. I inspected logs if > someone logged in or changed route. I found nothing. > This problem repeats at least 1 times per day. I wrote a shell script > which monitors the default router. > I saw that sometimes netstat -rn shows that default router is changed > as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but > routing still routes to right router 212.X.Y.Z . > After a while, routing really fails. > I use em nics for all. > At the weekends (when most clients are now working) i dont have any problems. > I think some network packets affects the defaultrouter. > I tried to block packets belongs to the IP addresses which shown as > default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is > solved. > > I wonder how the default router can be changed with packets that came > from network? > How can i prevent this without writing firewall rules? > Or which packets should I drop? > > Any ideas? Özkan, just one: Do you see RIP (521/tcp, 521/udp) traffic? Volker From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 19:48:13 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36CB310656A3 for ; Sun, 29 Aug 2010 19:48:13 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DCC678FC08 for ; Sun, 29 Aug 2010 19:48:12 +0000 (UTC) Received: by qwg5 with SMTP id 5so4773809qwg.13 for ; Sun, 29 Aug 2010 12:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4b20iDIrLqOUEDjBAgqyx3T1JLUBF2YC+rRNU5hqhm8=; b=B5bu61d3+zcclEhf4lECn+bE7dJglLlz46fXzS82mJ1n7caQ2lB7IvRdkAzY/CDNUx PqW2s1OdqVc5u8S70ysR1FWP+8UIH7tY3Xwn8McBnoiZomtB8NMZiNkYCUe/H7rHaWdy xvEX/iLyC4AexjGXgf3RljvZX3D7W4BO1+TKI= 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=x/4eNbhty0QG27qzWED5L6fooqOah2vIKVNAhc3/U5CKM1xcf7M0l+zzaiU4Nl7d/g lWCEGNzIrRELzt2SQNFlG8dcLwL+Y3rp+EnrRmE7wfg3zUVxJ6w/Zk8J+uIj0kkpb7dW x8w+X/8x85DTe6idWvH6KJFoveAABb9I5B2Tk= MIME-Version: 1.0 Received: by 10.229.223.195 with SMTP id il3mr2397426qcb.83.1283111259685; Sun, 29 Aug 2010 12:47:39 -0700 (PDT) Received: by 10.229.46.146 with HTTP; Sun, 29 Aug 2010 12:47:35 -0700 (PDT) In-Reply-To: <4C7AB073.2040802@vwsoft.com> References: <4C7AB073.2040802@vwsoft.com> Date: Sun, 29 Aug 2010 22:47:35 +0300 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: volker@vwsoft.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Default router changes unexpectedly 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, 29 Aug 2010 19:48:13 -0000 Hi Volker, There is no routing deamon working on this gateway. But I started a tcpdump that listening to port 521. I'll inform you about captured packets. Regards, Ozkan KIRIK Mersin University @ Turkey On Sun, Aug 29, 2010 at 10:09 PM, wrote: > On 08/29/10 19:50, =D6zkan KIRIK wrote: >> >> Hi, >> >> I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan >> used mostly. >> System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. >> >> Sometimes default router changes unexpectedly. I inspected logs if >> someone logged in or changed route. I found nothing. >> This problem repeats at least 1 times per day. I wrote a shell script >> which monitors the default router. >> I saw that sometimes netstat -rn shows that default router is changed >> as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but >> routing still routes to right router 212.X.Y.Z . >> After a while, routing really fails. >> I use em nics for all. >> At the weekends (when most clients are now working) i dont have any >> problems. I'll correct the type above: At the weekends (when most clients are noT working) i dont have any problems. >> I think some network packets affects the defaultrouter. >> I tried to block packets belongs to the IP addresses which shown as >> default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is >> solved. >> >> I wonder how the default router can be changed with packets that came >> from network? >> How can i prevent this without writing firewall rules? >> Or which packets should I drop? >> >> Any ideas? > > =D6zkan, > > just one: Do you see RIP (521/tcp, 521/udp) traffic? > > Volker > From owner-freebsd-net@FreeBSD.ORG Sun Aug 29 20:31:28 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3830410656A7; Sun, 29 Aug 2010 20:31:28 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EFF48FC08; Sun, 29 Aug 2010 20:31:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7TKVRhn076277; Sun, 29 Aug 2010 20:31:27 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o7TKVRi2076273; Sun, 29 Aug 2010 20:31:27 GMT (envelope-from vwe) Date: Sun, 29 Aug 2010 20:31:27 GMT Message-Id: <201008292031.o7TKVRi2076273@freefall.freebsd.org> To: davidgurvich@gmail.com, vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/149969: [wlan] [ral] ralink rt2661 fails to maintain connection 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, 29 Aug 2010 20:31:28 -0000 Synopsis: [wlan] [ral] ralink rt2661 fails to maintain connection State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Sun Aug 29 20:27:52 UTC 2010 State-Changed-Why: David, does the device work for your if you disable powersave operation? Please note: For your IRQ question, the asterisk in the output indicates more devices being assigned to that IRQ but vmstat -i is unable to display all. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sun Aug 29 20:27:52 UTC 2010 Responsible-Changed-Why: over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=149969 From owner-freebsd-net@FreeBSD.ORG Mon Aug 30 01:17:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F2910656B7 for ; Mon, 30 Aug 2010 01:17:05 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98EF38FC20 for ; Mon, 30 Aug 2010 01:17:05 +0000 (UTC) Received: by qyk4 with SMTP id 4so5144102qyk.13 for ; Sun, 29 Aug 2010 18:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xCnsO7yzumEOfyPAxlLWCRDkBtX3mWyHY6SN5teGufo=; b=ShEJX1gkOXinavf6XMBLF6eUtHhHUVoVbrhjsrdJZ9Wv46opE1Wgi1wsDI+uS3L5zu QKbft3TdOPyP4YD07TMRgQvs/UTBB2yk0tCer37nslwvDEx285l8LcJoy+I3oBjhJx0n 96HlkvpgLjFAQOZ5N74/Ky5J4ReMo39FS1LIc= 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=d6o2Z3yB0ZtxnDfFVDJOYIk9LWNllvB3kFW/fGkXMaBIFTvrNE+9pMzvgXesxWobb9 THBFMiUFO/eSxUEblvtlnzcuI4u0+L6Y0XZmzWvGxPktVTi25Xx/44vUZLqL6IbMSVFT Lnhr2aqHz88kMxnqEH2vsurUXLHQ4mYZ73hLY= MIME-Version: 1.0 Received: by 10.224.89.76 with SMTP id d12mr2362740qam.251.1283129639532; Sun, 29 Aug 2010 17:53:59 -0700 (PDT) Received: by 10.229.51.229 with HTTP; Sun, 29 Aug 2010 17:53:59 -0700 (PDT) In-Reply-To: <4C7AAB54.2050309@bitfreak.org> References: <4C7AAB54.2050309@bitfreak.org> Date: Sun, 29 Aug 2010 20:53:59 -0400 Message-ID: From: David Horn To: Darren Pilgrim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: How to configure non-EUI64 IPv6 addresses with solicited prefixes? 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, 30 Aug 2010 01:17:06 -0000 On Sun, Aug 29, 2010 at 2:47 PM, Darren Pilgrim wrot= e: > I have two machines where I need them to: > > 1. Solicit a prefix; > 2. Apply the solicitation to a non-EUI64 address; > 3. Use the non-EUI64 address as the default source address. > > Retaining the EUI64 address is not necessary. =A0Static configuration pre= vents > 1 and I have not been able to get 2 or 3 to work at all. =A0The original = KAME > documentation implies this is/was possible, but current documentation say= s > nothing about it (not that I can find, anyway). =A0A grep of /etc/* indic= ates > interface_ipv6_ifid_* variables (mentioned in the KAME documentation) are > not supported. > Your choices are: 1) Static IPv6 address using rc.conf variables or 2) RA IPv6 address using EUI64 or 3) RA IPv6 address using EUI64 + IPv6 address with Random IID EUI64 (only in head right now via rc.conf, otherwise needs sysctl entries for older code) {net.inet6.ip6.use_tempaddr/net.inet6.ip6.prefer_tempaddr} RFC3041 Doug B, how about an MFC to RELENG_8 of the relevant bits for privacy addresses in rc.conf. ? It is fairly self-contained. or a bit more work 4) Install a DHCPv6 client and roll your own configuration via dhcpv6 server config. or even more work 5) Submit a patch for review that does what you want. I'm certain that someone will come up with other options as well. Probably best to read the rc.conf man page, and /etc/defaults/rc.conf as well, although I can not seem to find any documentation on the use_tempaddr/prefer_tempaddr sysctls at the moment. Can you be specific on what you want to use instead of EUI64, or is this just a case of I want a dynamic prefix, and a static last 64 bits that are NOT EUI64 derived ? For example, are you wanting to use PREFIX::42 or something where PREFIX would be 2001:db8:: or the like which would result in 2001:db8::42/64 ? EUI64 without privacy extensions gives a fairly reliable static address (barring DAD issues with another mis-configured host). RFC3041 privacy extensions gives you both the normal (mac based IID) EUI64 address AND the random Interface Identifier (IID) EUI64 address. Are you just worried about EUI64 on the global address, or are you wanting it for link-local (fe80::) as well ? > One is running 8.1, the other 6.4 (I can upgrade it if necessary). 6.4 (and RELENG 6) are due to be EOL at the end of November, so probably best to consider your upgrade strategy. http://www.freebsd.org/security/#sup Good Luck. --Dave From owner-freebsd-net@FreeBSD.ORG Mon Aug 30 01:40:03 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F5510656A7 for ; Mon, 30 Aug 2010 01: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 9C3408FC1C for ; Mon, 30 Aug 2010 01:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7U1e3YR077351 for ; Mon, 30 Aug 2010 01:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o7U1e3Ar077349; Mon, 30 Aug 2010 01:40:03 GMT (envelope-from gnats) Date: Mon, 30 Aug 2010 01:40:03 GMT Message-Id: <201008300140.o7U1e3Ar077349@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: David Gurvich Cc: Subject: Re: kern/149969: [wlan] [ral] ralink rt2661 fails to maintain connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Gurvich List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 01:40:03 -0000 The following reply was made to PR kern/149969; it has been noted by GNATS. From: David Gurvich To: bug-followup@FreeBSD.org, davidgurvich@gmail.com Cc: Subject: Re: kern/149969: [wlan] [ral] ralink rt2661 fails to maintain connection Date: Sun, 29 Aug 2010 21:30:09 -0400 --001636284f88b99398048f006758 Content-Type: text/plain; charset=ISO-8859-1 Perhaps I am disabling powersave incorrectly? In rc.conf the ifconfig_wlan0="WPA DHCP -powersave". I've also tried on the command line "ifconfig wlan0 -powersave". If I do the same thing with ral0 I get an error that the argument is not valid. --001636284f88b99398048f006758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps I am disabling powersave incorrectly?=A0 In rc.conf the ifconfig_wl= an0=3D"WPA DHCP -powersave".=A0 I've also tried on the comman= d line "ifconfig wlan0 -powersave".=A0 If I do the same thing wit= h ral0 I get an error that the argument is not valid.
--001636284f88b99398048f006758-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 30 05:45:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C2951065674 for ; Mon, 30 Aug 2010 05:45:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8628FC08 for ; Mon, 30 Aug 2010 05:45:02 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o7U5KGTo016887; Sun, 29 Aug 2010 22:20:16 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 0A94B2D6010; Sun, 29 Aug 2010 22:20:15 -0700 (PDT) Message-ID: <4C7B3F9E.5010400@elischer.org> Date: Sun, 29 Aug 2010 22:20:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sadish Kulasekere References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: Sending packets at Kernel level 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, 30 Aug 2010 05:45:02 -0000 On 8/28/10 10:16 PM, Sadish Kulasekere wrote: > Hi, > > I need to know how to send packet from the kernel level. Can someone please > point me to any documentation? look how nfs does it... or the netgraph ksocket code does it too. maybe just use netgraph ksocket directly.. You don't say what you want to do. > > Cheers, > Sadish. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Aug 30 07:23:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A88AB10656AA for ; Mon, 30 Aug 2010 07:23:03 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 352398FC21 for ; Mon, 30 Aug 2010 07:23:02 +0000 (UTC) Received: by ewy4 with SMTP id 4so3130036ewy.13 for ; Mon, 30 Aug 2010 00:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=P9apTRmSR3n6bd/nuNje+B/LJ3AWWv21g5/GZTUI9PA=; b=NKemAxIOR2az/cmI1NPsQ4xuiF3E8r3RH/xz2JNi8qY3GpqKq4XWNYCr5inBwpRIEx +z0y4KcOTUr4p2qYymUos3BQdIJMgh4bqk1/nt+NdX1QtipQWwzWUBlxUq1oX4bUZ81J Qp332PCn3XuRWY5x9klv9XrvYpJ9Cc8PXKeOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=bKZ2l3AZGifSTO8IShJAN3f9pNWhT2GINVim8LNrBZ4EiV5YfOdQgpdY0/JfU5TdBY bakhhOUqByKqRgxqrkFT6J+gPO2xZeWUWE7GpKrhd/MyOQLWYBbxU55rAvjcJsM9HFLg IIqZwEa/mlECWhvJ6kK2NH6VH77pA57wwlQ8U= Received: by 10.213.22.198 with SMTP id o6mr2420431ebb.48.1283151130041; Sun, 29 Aug 2010 23:52:10 -0700 (PDT) Received: from 5.dynamic-n39.in72.ru ([91.203.39.5]) by mx.google.com with ESMTPS id a48sm11571160eei.12.2010.08.29.23.52.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Aug 2010 23:52:09 -0700 (PDT) Date: Mon, 30 Aug 2010 12:52:01 +0600 From: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsiAoRG1pdHJpeSBaYW11cmFldik=?= X-Priority: 3 (Normal) Message-ID: <825661318.20100830125201@gmail.com> To: Sadish Kulasekere In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Sending packets at Kernel level X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0JfQsNC80YPRgNCw0LXQsiAoRG1pdHJpeSBaYW11cmFldik=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 07:23:03 -0000 Maybe ng_source(4) can help you. > I need to know how to send packet from the kernel level. Can someone plea= se > point me to any documentation? From owner-freebsd-net@FreeBSD.ORG Mon Aug 30 07:54:15 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2635710656A7 for ; Mon, 30 Aug 2010 07:54:15 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 448B78FC14 for ; Mon, 30 Aug 2010 07:54:14 +0000 (UTC) Received: by qwg5 with SMTP id 5so5089205qwg.13 for ; Mon, 30 Aug 2010 00:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=S4mpHI0gh71/dfGrSMKNGs/Hvig0SdUsiD9bDbjFoyM=; b=gy7aWqTm3nydl19o1WkVKR8PCljALgKF610WkBhDnpzLaB1t8cKu0YnFlw3gF5OmeG m0U6XJf7O3Ls8Ojhr2T+MkTPY/j+NNWT0xUmwo1Z20kE5//2/bv7pYjjt1UWWXbxjmot /R1fCnUJOZH6+8LfkNRsMsxW05qI0CB0ZubtE= 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=sciFpU78UR0P5IzY876O5FnCUwcGz1AbHpm1EpZWgJSdqNkixQnkeCTqfQ9ZO8/aOx RNHASgpeUijyiavWv7Tpvr/WeImdB4aX2rsQH/975dgZ8ZBgVY4KdpPrN+klYtIG/9ep T4DHsmP16C8FzEcff5BZBq23QyZbIvY8l5rcQ= MIME-Version: 1.0 Received: by 10.229.2.32 with SMTP id 32mr2751517qch.270.1283154853363; Mon, 30 Aug 2010 00:54:13 -0700 (PDT) Received: by 10.229.46.146 with HTTP; Mon, 30 Aug 2010 00:54:13 -0700 (PDT) In-Reply-To: References: <4C7AB073.2040802@vwsoft.com> Date: Mon, 30 Aug 2010 10:54:13 +0300 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: =?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?= , net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Default router changes unexpectedly 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, 30 Aug 2010 07:54:15 -0000 Hi, # sysctl net.inet.icmp net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 1 net.inet.icmp.maskfake: 0 # ps ax | grep routed 37071 p1 S+ 0:00.00 grep routed # ps ax | grep -E "quagga|ospf|bgp" 37161 p1 S+ 0:00.00 grep -E quagga|ospf|bgp On Mon, Aug 30, 2010 at 1:28 AM, I=F1igo Ortiz de Urbina wrote: > Maybe icmp-redirect? You can use tshark or tcpdump to rotate > compressed captures. You can filter rip or any other dynamic routing > protocol and icmp. > > Have a nice day > > On 8/29/10, =D6zkan KIRIK wrote: >> Hi Volker, >> >> There is no routing deamon working on this gateway. But I started a >> tcpdump that listening to port 521. >> I'll inform you about captured packets. >> >> >> Regards, >> Ozkan KIRIK >> Mersin University @ Turkey >> >> >> On Sun, Aug 29, 2010 at 10:09 PM, =A0 wrote: >>> On 08/29/10 19:50, =D6zkan KIRIK wrote: >>>> >>>> Hi, >>>> >>>> I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan >>>> used mostly. >>>> System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. >>>> >>>> Sometimes default router changes unexpectedly. I inspected logs if >>>> someone logged in or changed route. I found nothing. >>>> This problem repeats at least 1 times per day. I wrote a shell script >>>> which monitors the default router. >>>> I saw that sometimes netstat -rn shows that default router is changed >>>> as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but >>>> routing still routes to right router 212.X.Y.Z . >>>> After a while, routing really fails. >>>> I use em nics for all. >>>> At the weekends (when most clients are now working) i dont have any >>>> problems. >> >> I'll correct the type above: At the weekends (when most clients are >> noT working) i dont have any problems. >> >> >> >>>> I think some network packets affects the defaultrouter. >>>> I tried to block packets belongs to the IP addresses which shown as >>>> default router (10.3.1.64, 10.5.3.189 etc.. ). Then the problem is >>>> solved. >>>> >>>> I wonder how the default router can be changed with packets that came >>>> from network? >>>> How can i prevent this without writing firewall rules? >>>> Or which packets should I drop? >>>> >>>> Any ideas? >>> >>> =D6zkan, >>> >>> just one: Do you see RIP (521/tcp, 521/udp) traffic? >>> >>> Volker >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Mon Aug 30 11:07:02 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0914110656A7 for ; Mon, 30 Aug 2010 11:07:02 +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 EAC3C8FC1D for ; Mon, 30 Aug 2010 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7UB71wc087499 for ; Mon, 30 Aug 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o7UB71Kf087497 for freebsd-net@FreeBSD.org; Mon, 30 Aug 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Aug 2010 11:07:01 GMT Message-Id: <201008301107.o7UB71Kf087497@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, 30 Aug 2010 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 -------------------------------------------------------------------------------- f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149804 net [icmp] [panic] ICMP redirect on causes "panic: rtqkill o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/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/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/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/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/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/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/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo 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) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption 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/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 o kern/118727 net [netgraph] [patch] [request] add new ng_pf module 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/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze 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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/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/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/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/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 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 s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging 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/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat 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 bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/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 a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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/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 355 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 30 20:22:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D50A91065694 for ; Mon, 30 Aug 2010 20:22:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B107B8FC16 for ; Mon, 30 Aug 2010 20:22:13 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 27EBF46B8E; Mon, 30 Aug 2010 16:22:13 -0400 (EDT) Date: Mon, 30 Aug 2010 21:22:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sadish Kulasekere In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Sending packets at Kernel level 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, 30 Aug 2010 20:22:13 -0000 On Sun, 29 Aug 2010, Sadish Kulasekere wrote: > I need to know how to send packet from the kernel level. Can someone please > point me to any documentation? Hi Sadish: Take a look at the socket(9) man page, which is the KPI used by in-kernel consumers of sockets such as the NFS client and server, smbfs (via netsmb), ncpfs (via netncp), etc. This is very close to the socket(2) system call API, but non-identical, so give a ping if you have any questions. Robert From owner-freebsd-net@FreeBSD.ORG Tue Aug 31 10:04:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 886C91065672; Tue, 31 Aug 2010 10:04:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 622E88FC16; Tue, 31 Aug 2010 10:04:02 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A525546B53; Tue, 31 Aug 2010 06:04:01 -0400 (EDT) Date: Tue, 31 Aug 2010 11:04:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <4C7A7B25.9040300@freebsd.org> Message-ID: References: <4C7A7B25.9040300@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 10:04:02 -0000 On Sun, 29 Aug 2010, Andre Oppermann wrote: > When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago > the semantics of sendto(2) with regard to TCP sockets were changed. > > It became possible directly do a sendto(2) call with the target address in > the *to argument instead of doing a connect(2) first and subsequent write(2) > or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR > could be specified to close the connection again right again after the data > has been sent out. > > This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, > Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD > was the only OS to ever ship this. > > T/TCP was ill-defined and had major security issues and never gained any > support. It has been defunct in FreeBSD and most code has been removed about > 6 years ago. The sendto(2) extended functionality is one of the last parts > that persisted and remained around living a zombie life. > > I want to remove it now because it is totally non-portable, has no known > users and complicates the TCP send path. The patch is attached. > > If you have any objections speak up now. I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit more. While I'm not aware of any applications depending on the semantic for TCP, I know that we do use it for UNIX domain sockets. Since it's a documented API, if we are going to remove it, then we need to go through a deprecation process, not least by marking it as a deprecated API in 8.x before having it vanish in 9.0. (I won't be sorry to see the complexity go, but I'm not sure I have all the implications in mind as yet...) Robert From owner-freebsd-net@FreeBSD.ORG Tue Aug 31 13:01:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33FC510656A6; Tue, 31 Aug 2010 13:01:45 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 091978FC13; Tue, 31 Aug 2010 13:01:44 +0000 (UTC) Received: from [172.10.20.2] (tmo-109-179.customers.d1-online.com [80.187.109.179]) by mail-n.franken.de (Postfix) with ESMTP id 47A6B1C0C0BD8; Tue, 31 Aug 2010 15:01:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Tue, 31 Aug 2010 15:01:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B42D7FB-B782-4EE9-8813-BF7D3ED3274B@lurchi.franken.de> References: <4C7A7B25.9040300@freebsd.org> To: Robert Watson X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 13:01:45 -0000 On Aug 31, 2010, at 12:04 PM, Robert Watson wrote: >=20 > On Sun, 29 Aug 2010, Andre Oppermann wrote: >=20 >> When T/TCP RFC1644 support was introduced in r6283 by wollman 15 = years ago the semantics of sendto(2) with regard to TCP sockets were = changed. >>=20 >> It became possible directly do a sendto(2) call with the target = address in the *to argument instead of doing a connect(2) first and = subsequent write(2) or send(2) calls as the standard TCP API specifies. = Optionally MSG_EOR could be specified to close the connection again = right again after the data has been sent out. >>=20 >> This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, = Solaris, HP-UX) ever supported this functionality for TCP sockets. = FreeBSD was the only OS to ever ship this. >>=20 >> T/TCP was ill-defined and had major security issues and never gained = any support. It has been defunct in FreeBSD and most code has been = removed about 6 years ago. The sendto(2) extended functionality is one = of the last parts that persisted and remained around living a zombie = life. >>=20 >> I want to remove it now because it is totally non-portable, has no = known users and complicates the TCP send path. The patch is attached. >>=20 >> If you have any objections speak up now. >=20 > I'm not entirely comfortable with this change, and would like a chance = to cogitate on it a bit more. While I'm not aware of any applications = depending on the semantic for TCP, I know that we do use it for UNIX = domain sockets. Since it's a documented API, if we are going to remove = it, then we need to go through a deprecation process, not least by = marking it as a deprecated API in 8.x before having it vanish in 9.0. sendto() is also used for SCTP SOCK_STREAMS and SOCK_SEQPACKET = sockets... Best regards Michael >=20 > (I won't be sorry to see the complexity go, but I'm not sure I have = all the implications in mind as yet...) >=20 > Robert > _______________________________________________ > 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" >=20 From owner-freebsd-net@FreeBSD.ORG Tue Aug 31 13:15:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3148910656BB for ; Tue, 31 Aug 2010 13:15:54 +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 7E33A8FC19 for ; Tue, 31 Aug 2010 13:15:53 +0000 (UTC) Received: (qmail 71122 invoked from network); 31 Aug 2010 13:13:29 -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 ; 31 Aug 2010 13:13:29 -0000 Message-ID: <4C7D0089.1020104@freebsd.org> Date: Tue, 31 Aug 2010 15:15:53 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Robert Watson References: <4C7A7B25.9040300@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 13:15:54 -0000 On 31.08.2010 12:04, Robert Watson wrote: > > On Sun, 29 Aug 2010, Andre Oppermann wrote: > >> When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago the semantics of >> sendto(2) with regard to TCP sockets were changed. >> >> It became possible directly do a sendto(2) call with the target address in the *to argument >> instead of doing a connect(2) first and subsequent write(2) or send(2) calls as the standard TCP >> API specifies. Optionally MSG_EOR could be specified to close the connection again right again >> after the data has been sent out. >> >> This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, Solaris, HP-UX) ever >> supported this functionality for TCP sockets. FreeBSD was the only OS to ever ship this. >> >> T/TCP was ill-defined and had major security issues and never gained any support. It has been >> defunct in FreeBSD and most code has been removed about 6 years ago. The sendto(2) extended >> functionality is one of the last parts that persisted and remained around living a zombie life. >> >> I want to remove it now because it is totally non-portable, has no known users and complicates the >> TCP send path. The patch is attached. >> >> If you have any objections speak up now. > > I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit more. > While I'm not aware of any applications depending on the semantic for TCP, I know that we do use it > for UNIX domain sockets. I don't have any plans to remove the implied connect support from the socket layer or other protocols, only from TCP. > Since it's a documented API, if we are going to remove it, then we need to > go through a deprecation process, not least by marking it as a deprecated API in 8.x before having > it vanish in 9.0. > > (I won't be sorry to see the complexity go, but I'm not sure I have all the implications in mind as > yet...) The only implication would be a FreeBSD-only application (since nobody else ever supported it) that depends on the TCP implied connect. While not impossible it is unlikely for such an application to exist. For deprecating this part of the TCP API there is no documentation to the implied connect in tcp(4). In sendto(2) it doesn't differentiate between protocols and simply says: "... sendto() and sendmsg() may be used at any time." For MSG_EOF it says that is only supported for SOCK_STREAM sockets in the PF_INET protocol family. These sentences have to be corrected. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Aug 31 13:25:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1196C10656A6 for ; Tue, 31 Aug 2010 13:25:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 78EA08FC22 for ; Tue, 31 Aug 2010 13:25:15 +0000 (UTC) Received: (qmail 71211 invoked from network); 31 Aug 2010 13:22:52 -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 ; 31 Aug 2010 13:22:52 -0000 Message-ID: <4C7D02BB.40300@freebsd.org> Date: Tue, 31 Aug 2010 15:25:15 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <4C7A7B25.9040300@freebsd.org> <7B42D7FB-B782-4EE9-8813-BF7D3ED3274B@lurchi.franken.de> In-Reply-To: <7B42D7FB-B782-4EE9-8813-BF7D3ED3274B@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 13:25:16 -0000 On 31.08.2010 15:01, Michael Tüxen wrote: > On Aug 31, 2010, at 12:04 PM, Robert Watson wrote: >> On Sun, 29 Aug 2010, Andre Oppermann wrote: >>> When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago the semantics of >>> sendto(2) with regard to TCP sockets were changed. >>> >>> It became possible directly do a sendto(2) call with the target address in the *to argument >>> instead of doing a connect(2) first and subsequent write(2) or send(2) calls as the standard >>> TCP API specifies. Optionally MSG_EOR could be specified to close the connection again right >>> again after the data has been sent out. >>> >>> This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, Solaris, HP-UX) ever >>> supported this functionality for TCP sockets. FreeBSD was the only OS to ever ship this. >>> >>> T/TCP was ill-defined and had major security issues and never gained any support. It has been >>> defunct in FreeBSD and most code has been removed about 6 years ago. The sendto(2) extended >>> functionality is one of the last parts that persisted and remained around living a zombie >>> life. >>> >>> I want to remove it now because it is totally non-portable, has no known users and >>> complicates the TCP send path. The patch is attached. >>> >>> If you have any objections speak up now. >> >> I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit >> more. While I'm not aware of any applications depending on the semantic for TCP, I know that >> we do use it for UNIX domain sockets. Since it's a documented API, if we are going to remove >> it, then we need to go through a deprecation process, not least by marking it as a deprecated >> API in 8.x before having it vanish in 9.0. > > sendto() is also used for SCTP SOCK_STREAMS and SOCK_SEQPACKET sockets... sendto() will not be touched or modified. It's just that on a TCP socket the tcp protocol will not perform an implied connect anymore. The only thing that changes is TCP dropping a deprecated and experimental extension and behaving like every other UNIXy OS. sendto() will continue to work for UDP, SCTP and Domain sockets and whoever else currently supports it, except TCP. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Aug 31 18:57:12 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDD4810656BC; Tue, 31 Aug 2010 18:57:12 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id A3E3B8FC16; Tue, 31 Aug 2010 18:57:12 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id o7VIUB2I022099; Tue, 31 Aug 2010 14:30:11 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id o7VIUBig022098; Tue, 31 Aug 2010 14:30:11 -0400 (EDT) (envelope-from wollman) Date: Tue, 31 Aug 2010 14:30:11 -0400 (EDT) From: Garrett Wollman Message-Id: <201008311830.o7VIUBig022098@hergotha.csail.mit.edu> To: andre@freebsd.org In-Reply-To: References: <4C7A7B25.9040300@freebsd.org> <4C7D02BB.40300@freebsd.org> <7B42D7FB-B782-4EE9-8813-BF7D3ED3274B@lurchi.franken.de> Organization: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 31 Aug 2010 14:30:11 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hergotha.csail.mit.edu Cc: net@freebsd.org Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 18:57:13 -0000 In article <4C7D02BB.40300@freebsd.org> andre@freebsd.org writes: >sendto() will not be touched or modified. It's just that on a TCP socket >the tcp protocol will not perform an implied connect anymore. The only thing >that changes is TCP dropping a deprecated and experimental extension and >behaving like every other UNIXy OS. That's a little bit disingenuous, methinks. Support for the "deprecated and experimental extension" -- RFC 1644 -- was dropped a number of years ago. (Longer ago than I can easily recall.) The implict open/close mechanism is orthogonal to the long-gone support for RFC 1644. There may be good reasons to remove it anyway, but please don't claim that the status of RFC 1644 has anyting to do with it. -GAWollman From owner-freebsd-net@FreeBSD.ORG Tue Aug 31 21:32:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0E301065674; Tue, 31 Aug 2010 21:32:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C8F2E8FC13; Tue, 31 Aug 2010 21:32:56 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6FBEC46B51; Tue, 31 Aug 2010 17:32:56 -0400 (EDT) Date: Tue, 31 Aug 2010 22:32:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <4C7D0089.1020104@freebsd.org> Message-ID: References: <4C7A7B25.9040300@freebsd.org> <4C7D0089.1020104@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 21:32:57 -0000 On Tue, 31 Aug 2010, Andre Oppermann wrote: >> I'm not entirely comfortable with this change, and would like a chance to >> cogitate on it a bit more. While I'm not aware of any applications >> depending on the semantic for TCP, I know that we do use it for UNIX domain >> sockets. > > I don't have any plans to remove the implied connect support from the socket > layer or other protocols, only from TCP. Right -- the implicit question is: why should TCP be the only stream protocol in our stack *not* to support implied connection, when we plan to continue to support it for all other protocols? > For deprecating this part of the TCP API there is no documentation to the > implied connect in tcp(4). In sendto(2) it doesn't differentiate between > protocols and simply says: "... sendto() and sendmsg() may be used at any > time." For MSG_EOF it says that is only supported for SOCK_STREAM sockets > in the PF_INET protocol family. These sentences have to be corrected. In general, deprecating is taken to mean providing significant and explicit advance warning of removal -- for example, updating the 8.x man page to point out that the feature is deprecated and it will not appear in future releases of FreeBSD. Robert From owner-freebsd-net@FreeBSD.ORG Wed Sep 1 05:50:05 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40856106564A; Wed, 1 Sep 2010 05:50:05 +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 1802E8FC16; Wed, 1 Sep 2010 05:50:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o815o4Dw032941; Wed, 1 Sep 2010 05:50:04 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o815o4a0032937; Wed, 1 Sep 2010 05:50:04 GMT (envelope-from remko) Date: Wed, 1 Sep 2010 05:50:04 GMT Message-Id: <201009010550.o815o4a0032937@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/150052: wi(4) driver does not work with wlan(4) driver for Lucent Orinoco Cards 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, 01 Sep 2010 05:50:05 -0000 Synopsis: wi(4) driver does not work with wlan(4) driver for Lucent Orinoco Cards Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Sep 1 05:49:49 UTC 2010 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=150052 From owner-freebsd-net@FreeBSD.ORG Wed Sep 1 08:10:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 683EF106564A for ; Wed, 1 Sep 2010 08:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 55B1B8FC0A for ; Wed, 1 Sep 2010 08:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o818A4Na006682 for ; Wed, 1 Sep 2010 08:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o818A4Am006681; Wed, 1 Sep 2010 08:10:04 GMT (envelope-from gnats) Date: Wed, 1 Sep 2010 08:10:04 GMT Message-Id: <201009010810.o818A4Am006681@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?iso-8859-1?Q?Ren=E9?= Rietz Cc: Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?Q?Ren=E9?= Rietz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 08:10:04 -0000 The following reply was made to PR kern/149306; it has been noted by GNATS. From: =?iso-8859-1?Q?Ren=E9?= Rietz To: bug-followup@FreeBSD.org, aksenzov@gmail.com Cc: Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet Date: Wed, 1 Sep 2010 09:42:26 +0200 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Can someone assign this bug to acpi? According to the driver developer, this seems to be an acpi problem: http://forums.freebsd.org/showthread.php?t=16186 Bug #149373 seems to be related to the same problem. --cNdxnHkX5QqsyA0e Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIISqwYJKoZIhvcNAQcCoIISnDCCEpgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D54wggVaMIIEQqADAgECAgQLie+tMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMw EQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVy ZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMDcxMjIwMTM0NjA2WhcNMTkwNjMwMDAwMDAwWjCB yTELMAkGA1UEBhMCREUxFDASBgNVBAgTC0JyYW5kZW5idXJnMRAwDgYDVQQHEwdDb3R0YnVz MTkwNwYDVQQKEzBCcmFuZGVuYnVyZ2lzY2hlIFRlY2huaXNjaGUgVW5pdmVyc2l0YWV0IENv dHRidXMxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xGjAYBgNVBAMTEUJUVS1DQSAoRzAxIDIw MDgpMSMwIQYJKoZIhvcNAQkBFhRjYS1idHVAdHUtY290dGJ1cy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALtCHiiZ9xL7pJCDfykBz8QUFPqPvdQoFG2fh+NsvIEId6vz adydM95kVniA/dkAfUW4sMGCb8wElKPihwJQ2R+SdMf4dL2vQBnwyT+hasrBYRaVj6sGgUKD 8yxxdF7UkY4WWeVjg03I4HCeFjiRWLfeDPY98mXko9NqguOIP00tbU7HCwbJ9cckLt6fds8J dKeyxrSFvNFVc5xwZlaGGYGcw/sqLGXeOoaISA/5Anb/pg7uWdpxtjzkChGhVTkSHTZ0DIBv lV5BvmiO5xA/oDvOoGz9bz/vuBUMDVNzZZy4EQFDDlSKAg+/+ptur8r4WfoIlohWL2UVyjO7 jdY4bsMCAwEAAaOCAbYwggGyMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0G A1UdDgQWBBRYHbJqrZIxc6XbOTlSZxpEBto+FjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp 9/EKcD7eZDAfBgNVHREEGDAWgRRjYS1idHVAdHUtY290dGJ1cy5kZTCBiAYDVR0fBIGAMH4w PaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9j YWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUFBwEBBIGVMIGSMEcGCCsGAQUFBzAChjtodHRw Oi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNy dDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAA1vZXHoiKaPyfy0JY7Z s5HgWS2ecQSmBoNaHR3vfMXJai8RbU9+a31bP8RuimTZ/hvv57bj49qopAeby6NClDVJWE3O SAOEZgG0x3sYfObJyuV+SZs0oOoXqyTJHpGRqrBVpUHIB3xUKzT0o3A+BDSyhxY6JJjef2q0 KX9Lbcw6j9SA/xv/IRCEAtUjTGEJCUTxJroVy7TIvV7G7TrCtw8MwIQClL8UMsD9iXvYfISE aJDmWLFlv0hLG0XdTLFxLiXDelx3oVhg4CQhguksupmdWx2twMSlQmMOFk/u69FFQ/tbXeSq 5oA8pam1Pf3DoODxtYZ/wnb6BFyCgOza4mwwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0B AQUFADBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0G A1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtv bSBSb290IENBIDIwHhcNMDYxMjE5MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQG EwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMb REZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAo I4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgA mu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0Qkj KpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZW Q8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4HZ MIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9jZ2ktYmluL3Nl cnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1ZXI9RFRf Uk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQx w3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys 5/JdGTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6Ef GOKUhT0/M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+x hoXxdIVW5cP4XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEs N1cAZ6sjaI1jpe+Za1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zO SWOoAPfyHDCCBhcwggT/oAMCAQICBA7S9T0wDQYJKoZIhvcNAQEFBQAwgckxCzAJBgNVBAYT AkRFMRQwEgYDVQQIEwtCcmFuZGVuYnVyZzEQMA4GA1UEBxMHQ290dGJ1czE5MDcGA1UEChMw QnJhbmRlbmJ1cmdpc2NoZSBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBDb3R0YnVzMRYwFAYD VQQLEw1SZWNoZW56ZW50cnVtMRowGAYDVQQDExFCVFUtQ0EgKEcwMSAyMDA4KTEjMCEGCSqG SIb3DQEJARYUY2EtYnR1QHR1LWNvdHRidXMuZGUwHhcNMDkwOTE4MTIwNjA2WhcNMTIwOTE3 MTIwNjA2WjCB6TELMAkGA1UEBhMCREUxFDASBgNVBAgTC0JyYW5kZW5idXJnMRAwDgYDVQQH EwdDb3R0YnVzMTkwNwYDVQQKEzBCcmFuZGVuYnVyZ2lzY2hlIFRlY2huaXNjaGUgVW5pdmVy c2l0YWV0IENvdHRidXMxMjAwBgNVBAsTKUxTIFJlY2huZXJuZXR6ZSB1bmQgS29tbXVuaWth dGlvbnNzeXN0ZW1lMRMwEQYDVQQDEwpSZW5lIFJpZXR6MS4wLAYJKoZIhvcNAQkBFh9ycmll dHpAaW5mb3JtYXRpay50dS1jb3R0YnVzLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3gSr5iaJtuQeJoO31OekQDDptiI5pWBl3UQw719nJ6peDbqofyKxINmy+H+4Da4Z 4/UqG6JSmWQEQtttI6vCzQrkho76a3bp4sXMTCA7Ow8ImBB0tS2J9VzDoK1qsYsm+HjI/Edx 4SsDTVhYUsZhq3Lqx6UHgYs7evFq5HoQpS7NuA4aj3B4T968FV9pW3QtyA4sZUqmFIEmhP6+ eoqXspr5ON8hKLcWGNd21xJU4zXdSULVTt65YCFnvPwrS5RPxgGtIUwO3qaOjBOI6/lmpOiH hqtk08p+qKqmqMVjK7NyF/5i0WHQrBJ4NcNK3GujlQxJ2nPInI2O06cDIgJi5wIDAQABo4IB 4zCCAd8wCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsG AQUFBwMEBgorBgEEAYI3FAICMB0GA1UdDgQWBBTIRRXeq9ijqEh6KjV19tuezDG42DAfBgNV HSMEGDAWgBRYHbJqrZIxc6XbOTlSZxpEBto+FjAqBgNVHREEIzAhgR9ycmlldHpAaW5mb3Jt YXRpay50dS1jb3R0YnVzLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNh LmRmbi5kZS9idHUtY290dGJ1cy1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDov L2NkcDIucGNhLmRmbi5kZS9idHUtY290dGJ1cy1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYI KwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvYnR1 LWNvdHRidXMtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL2J0dS1jb3R0YnVzLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDAN BgkqhkiG9w0BAQUFAAOCAQEAGsmRTRyyQLUBeVaEp5CrS2qiZECrQG1UrkfVtznDf4l5FQKw hA7KhPBdLEW/wamvlQS3Zg18OcZZ4+IYHQPdQrEurXLcCYEQn1tt1Sj8iQh+4QqhiY7ppKLg Amy1txMhnw0KgiTOs4dpyx9ANbS4rTpA1qGsit5cjRA5CwcAhqvBDZp6XbfpQ9OBU0p292c2 pJufZvcEUf1Qm7krgZURZwOoAvH+1CmN+mYg6XqoD7K74/FsBSAbeT63lr2jgGb3Ac6C9kLz z2aJz7BYJU+xbjyfk5LXsCIfAz4VXE5f2ndq6qPtD5XknssrGzM8UCmZEkkhCLIzlgqq645P hxyKqDGCAtUwggLRAgEBMIHSMIHJMQswCQYDVQQGEwJERTEUMBIGA1UECBMLQnJhbmRlbmJ1 cmcxEDAOBgNVBAcTB0NvdHRidXMxOTA3BgNVBAoTMEJyYW5kZW5idXJnaXNjaGUgVGVjaG5p c2NoZSBVbml2ZXJzaXRhZXQgQ290dGJ1czEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEaMBgG A1UEAxMRQlRVLUNBIChHMDEgMjAwOCkxIzAhBgkqhkiG9w0BCQEWFGNhLWJ0dUB0dS1jb3R0 YnVzLmRlAgQO0vU9MAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTAwOTAxMDc0MjI2WjAjBgkqhkiG9w0BCQQxFgQUlS9bjZETvf0a KAozF6QOGkSzCJUweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEW MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAtTeYOooE89CN 4mp6fGR7ksD9KKAafrbMwjuuwkz/bDbYan3Pv97Fyn9C1sT7xkBti6cLeGLlKqsj2mjwBzz7 7Zx4Su3BPt7a1np6MKomYba/WUEs0XuvkYxj9P5WfLtryZ+8H6pTGZPmNIppnjMJ3CqzaLF8 WdUlrXc5+tbIQK8nHx1MG4r2MQYScKsgDgDBEjzJgQGYKNC2Wu6L/vGR8GfAfPtI95f6+NLA Xk20VyYmCKXQEm7KETIRkct+sLW/BRdhuq0+PgwEsg9Tq3t/2E8liPRlybDhms1RzIQ+BpVo vTByotJtRqu4OhvVQKB4Smx123nelEXkCrr64fVpKQ== --cNdxnHkX5QqsyA0e-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 2 08:56:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECD0E1065743 for ; Thu, 2 Sep 2010 08:56:24 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0EE8FC20 for ; Thu, 2 Sep 2010 08:56:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:Mime-Version:To:Message-Id:Date:Content-Transfer-Encoding:Content-Type:From; bh=CnrUwDQhwQL2MZWyMHxY+krLTX5loQV9gcdYnCoyyZ8=; b=bj5nVVcq8ZSotqdQwvwNLNE2BY5MlyMqRYKZlubHwfEL2taWWk7sB5uGYnS1kwc+uOnP26ZVTk7vSTzJrJPEhO1vOrxUCzmHwZ+tBOhkAfPA286mSx5epNX9nEXocmml; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.47]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Or4vg-000HP4-1h for freebsd-net@freebsd.org; Thu, 02 Sep 2010 09:13:54 +0100 From: Melissa Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Sep 2010 09:13:46 +0100 Message-Id: <5C261F16-6530-47EE-B1C1-BA38CD6D8B01@littlebluecar.co.uk> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Subject: NFE adapter 'hangs' 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, 02 Sep 2010 08:56:25 -0000 Hiya, I've been having trouble with two different machines (FBSD 8.0p3 & FBSD = 7.0p5) using the NFE network adapter. The machines are, respectively, = Sun X2200 (AMD64) and a Sun X2100M2 (AMD64) and both are running the = amd64 kernel.=20 Basically what appears to happen is that traffic stops flowing through = the interface and 'No buffer space available' error messages are = produced when trying to send icmp packets. All establish connections = appear to hang. The machines are running as packet routers, and nfe0 is acting as the = 'lan' side. PF is being used for filtering, NAT, BINAT and RDR. The = same PF configuration works correctly on two other servers using = different network adapters. One of them is configured with pfsync & = CARP, but the other one isn't. The problem seems to happen under fairly light number of sessions ( < = 100 active states in PF) though the more states the quicker it occurs. = It is possible it's related to packet rates as putting on high bandwidth = clients seems to produce the problem very quickly (several minutes) This = is reinforced by the fact that the problem first manifested when we = upgraded one of the leased lines. Executing ifconfig nfe0 down && ifconfig nfe0 up will restart traffic = flow. =20 Neither box is very highly loaded, generally around ~ 1.5 Mb/s. This = doesn't appear to be related to the amount of traffic as I have tried = re-routing 95% of traffic around the server without any improvement in = performance. The traffic profile is fairly random - a mix of TCP and = UDP, mostly flowing OUT of nfe0. It is all L3 and there are less than = 5 hosts on the segment attached to the nfe interface. Both boxes are in different locations and are connected to different = types of Cisco switches. Both appear to autonegotiate correctly and the = switch ports show no status changes. It appears that PFSync, CARP & a GRE tunnel works correctly over the NFE = interface for long periods of time (weeks +) And that it is something to = do adding other traffic to the mix that is resulting in the interface = 'hanging'. If I move the traffic from NFE to the other BGE interface (the one = shared with the LOM) everything is stable and works correctly. I have = not been able to reproduce this using test loads, and the interface = worked correctly with iperf testing prior to deployment. I = unfortunately (legal reasons) can't provide a traffic trace up to the = time it occurs though everything looks normal to me. The FreeBSD 7 X2100 lists the following from PCI conf: nfe0@pci0:0:8:0: class=3D0x068000 card=3D0x534c108e = chip=3D0x037310de rev=3D0xa3 hdr=3D0x00 vendor =3D 'Nvidia Corp' device =3D 'MCP55 Ethernet' class =3D bridge nfe1@pci0:0:9:0: class=3D0x068000 card=3D0x534c108e = chip=3D0x037310de rev=3D0xa3 hdr=3D0x00 vendor =3D 'Nvidia Corp' device =3D 'MCP55 Ethernet' class =3D bridge The FreeBSD 8 X2200 lists the same thing: nfe0@pci0:0:8:0: class=3D0x068000 card=3D0x534b108e = chip=3D0x037310de rev=3D0xa3 hdr=3D0x00 vendor =3D 'Nvidia Corp' device =3D 'MCP55 Ethernet' class =3D bridge nfe1@pci0:0:9:0: class=3D0x068000 card=3D0x534b108e = chip=3D0x037310de rev=3D0xa3 hdr=3D0x00 vendor =3D 'Nvidia Corp' device =3D 'MCP55 Ethernet' class =3D bridge Here are the two obvious tests (both from the FreeBSD 7 box), but the = icmp response & the mbuf stats are very much the same on both boxes. ping 172.31.3.129 PING 172.31.3.129 (172.31.3.129): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ^C -- 172.31.3.129 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss netstat -m 852/678/1530 mbufs in use (current/cache/total) 818/448/1266/25600 mbuf clusters in use (current/cache/total/max) 817/317 mbuf+clusters out of packet secondary zone in use = (current/cache) 0/362/362/12800 4k (page size) jumbo clusters in use = (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 1879K/2513K/4392K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines =46rom the other machine, after the problem has occurred & and ifconfig = down/up cycle has been done (ie when the interface is working) vmstat -z=20 mbuf_packet: 256, 0, 1033, 1783, 330792410, = 0 mbuf: 256, 0, 5, 1664, 395145472, = 0 mbuf_cluster: 2048, 25600, 2818, 1690, 13234653, = 0 mbuf_jumbo_page: 4096, 12800, 0, 336, 297749, = 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, = 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, = 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, = 0 Although I failed to keep a copy I don't believe there is a kmem problem I'm at a complete loss as to what to try next :( =20 All suggestions very gratefully received!!! The 7.0 box is live so = can't really be played with but I can occasionally run tests on the = other box Thank you :) Mel From owner-freebsd-net@FreeBSD.ORG Thu Sep 2 19:50:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB8D10656FB for ; Thu, 2 Sep 2010 19:50:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07E4B8FC0A for ; Thu, 2 Sep 2010 19:50:20 +0000 (UTC) Received: by pvg4 with SMTP id 4so384651pvg.13 for ; Thu, 02 Sep 2010 12:50:20 -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=zZhONB7iTn7sR0rJpOVvsHQksN8BMZQmKnTYHOpci1M=; b=c1TVI3IAWbx0AQoay9EqpJwkrXtAnsApW9ms/GptUNiMKqpaV2DsxPqxZPVw+mvW9U XM6bwxsfSMDsmjtdrOewFeDZ12uFWoKwQORtVWh6ASqCRL7P5SFYQaSJ/GDvrysJw/u7 cZmHBJEEBhScPP6QH4IiFT+5euBxUJ8fcOTAI= 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=gQFekYSMsk7+efmizfd9erdqdmKmYpvetmHjA8RN2V+umpRG1Qsq7/TaZRzeU75gJ6 utAOHqC8H8Ob1Q4uA+31anPrAvEL6zi/4ftnH7jRBlKwmvT9J0PeR+nPBWHo4MZme0Uz Ck/RSstm/Rp9iJ4zX79AT1z1dYrUtXiPkv/1Y= Received: by 10.114.25.5 with SMTP id 5mr271467way.137.1283457005859; Thu, 02 Sep 2010 12:50:05 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c10sm1667344wam.1.2010.09.02.12.50.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Sep 2010 12:50:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 2 Sep 2010 12:49:40 -0700 From: Pyun YongHyeon Date: Thu, 2 Sep 2010 12:49:40 -0700 To: Melissa Jenkins Message-ID: <20100902194940.GH21940@michelle.cdnetworks.com> References: <5C261F16-6530-47EE-B1C1-BA38CD6D8B01@littlebluecar.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C261F16-6530-47EE-B1C1-BA38CD6D8B01@littlebluecar.co.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: NFE adapter 'hangs' 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: Thu, 02 Sep 2010 19:50:21 -0000 On Thu, Sep 02, 2010 at 09:13:46AM +0100, Melissa Jenkins wrote: > Hiya, > > I've been having trouble with two different machines (FBSD 8.0p3 & FBSD 7.0p5) using the NFE network adapter. The machines are, respectively, Sun X2200 (AMD64) and a Sun X2100M2 (AMD64) and both are running the amd64 kernel. > > Basically what appears to happen is that traffic stops flowing through the interface and 'No buffer space available' error messages are produced when trying to send icmp packets. All establish connections appear to hang. > > The machines are running as packet routers, and nfe0 is acting as the 'lan' side. PF is being used for filtering, NAT, BINAT and RDR. The same PF configuration works correctly on two other servers using different network adapters. One of them is configured with pfsync & CARP, but the other one isn't. > > The problem seems to happen under fairly light number of sessions ( < 100 active states in PF) though the more states the quicker it occurs. It is possible it's related to packet rates as putting on high bandwidth clients seems to produce the problem very quickly (several minutes) This is reinforced by the fact that the problem first manifested when we upgraded one of the leased lines. > > Executing ifconfig nfe0 down && ifconfig nfe0 up will restart traffic flow. > > Neither box is very highly loaded, generally around ~ 1.5 Mb/s. This doesn't appear to be related to the amount of traffic as I have tried re-routing 95% of traffic around the server without any improvement in performance. The traffic profile is fairly random - a mix of TCP and UDP, mostly flowing OUT of nfe0. It is all L3 and there are less than 5 hosts on the segment attached to the nfe interface. > > Both boxes are in different locations and are connected to different types of Cisco switches. Both appear to autonegotiate correctly and the switch ports show no status changes. > > It appears that PFSync, CARP & a GRE tunnel works correctly over the NFE interface for long periods of time (weeks +) And that it is something to do adding other traffic to the mix that is resulting in the interface 'hanging'. > > If I move the traffic from NFE to the other BGE interface (the one shared with the LOM) everything is stable and works correctly. I have not been able to reproduce this using test loads, and the interface worked correctly with iperf testing prior to deployment. I unfortunately (legal reasons) can't provide a traffic trace up to the time it occurs though everything looks normal to me. > > The FreeBSD 7 X2100 lists the following from PCI conf: > nfe0@pci0:0:8:0: class=0x068000 card=0x534c108e chip=0x037310de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 Ethernet' > class = bridge > nfe1@pci0:0:9:0: class=0x068000 card=0x534c108e chip=0x037310de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 Ethernet' > class = bridge > > The FreeBSD 8 X2200 lists the same thing: > nfe0@pci0:0:8:0: class=0x068000 card=0x534b108e chip=0x037310de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 Ethernet' > class = bridge > nfe1@pci0:0:9:0: class=0x068000 card=0x534b108e chip=0x037310de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 Ethernet' > class = bridge > > > Here are the two obvious tests (both from the FreeBSD 7 box), but the icmp response & the mbuf stats are very much the same on both boxes. > > ping 172.31.3.129 > PING 172.31.3.129 (172.31.3.129): 56 data bytes > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ^C > > -- 172.31.3.129 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > > netstat -m > 852/678/1530 mbufs in use (current/cache/total) > 818/448/1266/25600 mbuf clusters in use (current/cache/total/max) > 817/317 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/362/362/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 1879K/2513K/4392K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > From the other machine, after the problem has occurred & and ifconfig down/up cycle has been done (ie when the interface is working) > vmstat -z > mbuf_packet: 256, 0, 1033, 1783, 330792410, 0 > mbuf: 256, 0, 5, 1664, 395145472, 0 > mbuf_cluster: 2048, 25600, 2818, 1690, 13234653, 0 > mbuf_jumbo_page: 4096, 12800, 0, 336, 297749, 0 > mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 > > > Although I failed to keep a copy I don't believe there is a kmem problem > > I'm at a complete loss as to what to try next :( > > All suggestions very gratefully received!!! The 7.0 box is live so can't really be played with but I can occasionally run tests on the other box > First of all, if you have 'route-to' rules in pf please disable TSO on nfe(4). This is a known pf(4) issue for handling TSO frames. If this is not the case, would you show me the output of "sysctl dev.nfe.0.stats"? Can you see these statistics are still updated at the time of hang? Also I'd like to know whether both RX and TX are dead or only one RX/TX path is hung. Can you see incoming traffic with tcpdump when you think the controller is in stuck? By chance, are you using polling(4) or VLAN on nfe(4)? From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 01:12:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE063106579B for ; Fri, 3 Sep 2010 01:12:25 +0000 (UTC) (envelope-from RCharlet@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A2F8A8FC18 for ; Fri, 3 Sep 2010 01:12:25 +0000 (UTC) X-ASG-Debug-ID: 1283474108-5061b8680001-QdxwpM Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id Z0o27lca9TF365Zs; Thu, 02 Sep 2010 17:35:08 -0700 (PDT) X-Barracuda-Envelope-From: RCharlet@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Thu, 2 Sep 2010 17:35:08 -0700 From: "Ricky Charlet" X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: "freebsd-security@freebsd.org" , "freebsd-net@freebsd.org" Date: Thu, 2 Sep 2010 17:35:06 -0700 X-ASG-Orig-Subj: seeking current supported crypto co-processors Thread-Topic: seeking current supported crypto co-processors Thread-Index: ActK/9sFqcM9akWxSiKA96ymOzPvMA== Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1283474108 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: Subject: seeking current supported crypto co-processors 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, 03 Sep 2010 01:12:25 -0000 Howdy, I'm seeking current cryptographic coprocessors supported in FreeBSD= 8.x. By perusing through the crypto-dev (and subsequently referenced) man= page(s) I found this list: Hifn 7751/7951/7811/7955/7956 crypto accelerator SafeNet 1141/1741 Bluesteel 5501/5601 Broadcom bcm5801/5802/5805/5820/5821/5822/5823/5825 Those are all pretty old (and in some cases, no longer existent). I= 'm surveying these lists to see if anyone knows of more modern chips workin= g with FreeBSD 8.x. Or if you feel some chip on the list above is up to the= task of near about 1 Gb throughput across a PCIe and has friendly vendor s= upport for FreeBSD, I'd sure like to hear about that too. --- Ricky Charlet Adara Networks USA 408-433-4942 From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 06:07:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6DE91065880 for ; Fri, 3 Sep 2010 06:07:11 +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 488318FC17 for ; Fri, 3 Sep 2010 06:07:11 +0000 (UTC) Received: (qmail 22018 invoked from network); 3 Sep 2010 06:04:16 -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 ; 3 Sep 2010 06:04:16 -0000 Message-ID: <4C80908D.9030106@freebsd.org> Date: Fri, 03 Sep 2010 08:07:09 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ricky Charlet References: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" , "freebsd-net@freebsd.org" Subject: Re: seeking current supported crypto co-processors 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, 03 Sep 2010 06:07:12 -0000 On 03.09.2010 02:35, Ricky Charlet wrote: > Howdy, > > I'm seeking current cryptographic coprocessors supported in FreeBSD 8.x. By perusing through the > crypto-dev (and subsequently referenced) man page(s) I found this list: Hifn > 7751/7951/7811/7955/7956 crypto accelerator SafeNet 1141/1741 Bluesteel 5501/5601 Broadcom > bcm5801/5802/5805/5820/5821/5822/5823/5825 > > Those are all pretty old (and in some cases, no longer existent). I'm surveying these lists to > see if anyone knows of more modern chips working with FreeBSD 8.x. Or if you feel some chip on > the list above is up to the task of near about 1 Gb throughput across a PCIe and has friendly > vendor support for FreeBSD, I'd sure like to hear about that too. What cypto algorithms do you need? Stream encryption and/or PKI KEX? For AES stream encrpytion there are some CPU's that directly support the crypto primitives on the silicon. For newer x86/amd64 CPU's see: http://en.wikipedia.org/wiki/AES_instruction_set A number of VIA x86 CPU's have supported a set of crypto algorithms inlcuding stream cyphers, cryptographic hashing and RSA for quite some time on their silicon. http://www.via.com.tw/en/initiatives/padlock/hardware.jsp Other than that there are some embedded crypto engines with their own (mostly MIPS based) single and multi-core CPU's. AKAIK they have a FreeBSD API and the FreeBSD MIPS port should work on at least some of them: http://www.caviumnetworks.com/ Cavium also has some plug-in crypto accelerator cards under the brand name Nitrox. IIRC they have some drivers for FreeBSD available. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 06:59:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03903106570F for ; Fri, 3 Sep 2010 06:59:37 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id E7EFE8FC1A for ; Fri, 3 Sep 2010 06:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Mime-Version:Content-Type; bh=fHRpTrkrUCuaat1uHBBuHO8qmE9mEYJXkcSHMC8YuaY=; b=QctlV0FcknNNXmkj4Vc8aX2QzygB9iy4AChHsifkIy/vWMqfCLMq4Z/X9fYu7M5zBeahuuvk5l1+378kGRTLMx2b4xNH6XUBcLC0nxOSWZL6M5qoneQXmk+gS9FWZiEQ; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.47]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OrQFH-000Po2-RB for freebsd-net@freebsd.org; Fri, 03 Sep 2010 07:59:34 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Melissa Jenkins In-Reply-To: <20100902194940.GH21940@michelle.cdnetworks.com> Date: Fri, 3 Sep 2010 07:59:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C261F16-6530-47EE-B1C1-BA38CD6D8B01@littlebluecar.co.uk> <20100902194940.GH21940@michelle.cdnetworks.com> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Subject: Re: NFE adapter 'hangs' 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, 03 Sep 2010 06:59:37 -0000 Thank you for your very quick response :) >First of all, if you have 'route-to' rules in pf please disable TSO >on nfe(4). This is a known pf(4) issue for handling TSO frames. There is route-to in the PF ruleset but it is not evaluated, and I've = confirmed the rules is not matched @0 pass in on nfe0 route-to (gif1000 X) inet from X/26 to ! = flags S/SA keep state [ Evaluations: 126538 Packets: 0 Bytes: 0 States: = 0 ] [ Inserted: uid 0 pid 79327 ] >If this is not the case, would you show me the output of >"sysctl dev.nfe.0.stats"? Can you see these statistics are still >updated at the time of hang? Before: M [root@X:~]# sysctl dev.nfe.0.stats dev.nfe.0.stats.rx.frame_errors: 0 dev.nfe.0.stats.rx.extra_bytes: 0 dev.nfe.0.stats.rx.late_cols: 0 dev.nfe.0.stats.rx.runts: 0 dev.nfe.0.stats.rx.jumbos: 0 dev.nfe.0.stats.rx.fifo_overuns: 0 dev.nfe.0.stats.rx.crc_errors: 0 dev.nfe.0.stats.rx.fae: 0 dev.nfe.0.stats.rx.len_errors: 0 dev.nfe.0.stats.rx.unicast: 0 dev.nfe.0.stats.rx.multicast: 0 dev.nfe.0.stats.rx.broadcast: 0 dev.nfe.0.stats.rx.octets: 53488472383 dev.nfe.0.stats.rx.pause: 0 dev.nfe.0.stats.rx.drops: 0 dev.nfe.0.stats.tx.octets: 7480691065 dev.nfe.0.stats.tx.zero_rexmits: 68040095 dev.nfe.0.stats.tx.one_rexmits: 0 dev.nfe.0.stats.tx.multi_rexmits: 0 dev.nfe.0.stats.tx.late_cols: 0 dev.nfe.0.stats.tx.fifo_underuns: 0 dev.nfe.0.stats.tx.carrier_losts: 0 dev.nfe.0.stats.tx.excess_deferrals: 0 dev.nfe.0.stats.tx.retry_errors: 0 dev.nfe.0.stats.tx.deferrals: 0 dev.nfe.0.stats.tx.frames: 68040095 dev.nfe.0.stats.tx.pause: 0 After: M [root@X:~]# sysctl dev.nfe.0.stats dev.nfe.0.stats.rx.frame_errors: 0 dev.nfe.0.stats.rx.extra_bytes: 0 dev.nfe.0.stats.rx.late_cols: 0 dev.nfe.0.stats.rx.runts: 0 dev.nfe.0.stats.rx.jumbos: 0 dev.nfe.0.stats.rx.fifo_overuns: 0 dev.nfe.0.stats.rx.crc_errors: 0 dev.nfe.0.stats.rx.fae: 0 dev.nfe.0.stats.rx.len_errors: 0 dev.nfe.0.stats.rx.unicast: 0 dev.nfe.0.stats.rx.multicast: 0 dev.nfe.0.stats.rx.broadcast: 0 dev.nfe.0.stats.rx.octets: 53488985199 dev.nfe.0.stats.rx.pause: 0 dev.nfe.0.stats.rx.drops: 0 dev.nfe.0.stats.tx.octets: 7480798032 dev.nfe.0.stats.tx.zero_rexmits: 68041016 dev.nfe.0.stats.tx.one_rexmits: 0 dev.nfe.0.stats.tx.multi_rexmits: 0 dev.nfe.0.stats.tx.late_cols: 0 dev.nfe.0.stats.tx.fifo_underuns: 0 dev.nfe.0.stats.tx.carrier_losts: 0 dev.nfe.0.stats.tx.excess_deferrals: 0 dev.nfe.0.stats.tx.retry_errors: 0 dev.nfe.0.stats.tx.deferrals: 0 dev.nfe.0.stats.tx.frames: 68041016 dev.nfe.0.stats.tx.pause: 0 M [root@X:~]# sysctl dev.nfe.0.stats dev.nfe.0.stats.rx.frame_errors: 0 dev.nfe.0.stats.rx.extra_bytes: 0 dev.nfe.0.stats.rx.late_cols: 0 dev.nfe.0.stats.rx.runts: 0 dev.nfe.0.stats.rx.jumbos: 0 dev.nfe.0.stats.rx.fifo_overuns: 0 dev.nfe.0.stats.rx.crc_errors: 0 dev.nfe.0.stats.rx.fae: 0 dev.nfe.0.stats.rx.len_errors: 0 dev.nfe.0.stats.rx.unicast: 0 dev.nfe.0.stats.rx.multicast: 0 dev.nfe.0.stats.rx.broadcast: 0 dev.nfe.0.stats.rx.octets: 53489024128 dev.nfe.0.stats.rx.pause: 0 dev.nfe.0.stats.rx.drops: 0 dev.nfe.0.stats.tx.octets: 7480798032 dev.nfe.0.stats.tx.zero_rexmits: 68041016 dev.nfe.0.stats.tx.one_rexmits: 0 dev.nfe.0.stats.tx.multi_rexmits: 0 dev.nfe.0.stats.tx.late_cols: 0 dev.nfe.0.stats.tx.fifo_underuns: 0 dev.nfe.0.stats.tx.carrier_losts: 0 dev.nfe.0.stats.tx.excess_deferrals: 0 dev.nfe.0.stats.tx.retry_errors: 0 dev.nfe.0.stats.tx.deferrals: 0 dev.nfe.0.stats.tx.frames: 68041016 dev.nfe.0.stats.tx.pause: 0 >Also I'd like to know whether both RX and TX are dead or only one >RX/TX path is hung. Can you see incoming traffic with tcpdump when >you think the controller is in stuck? Yes, though not very much. The traffic to 4800 is every second so you = can see in the following trace when it stops 07:10:42.287163 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:42.911995 07:10:43.112073 STP 802.1d, Config, Flags [Topology change], bridge-id = 8000.c4:7d:4f:a9:ac:30.8008, length 43 07:10:43.148659 IP 192.168.1.203.57026 > 192.168.1.255.4800: UDP, length = 60 07:10:43.148684 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.129.4800: UDP, length 60 07:10:43.148689 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.1.4800: UDP, length 60 07:10:43.148918 IP 192.168.1.213.40677 > 192.168.1.255.4800: UDP, length = 48 07:10:43.329272 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:44.151762 IP 192.168.1.203.57026 > 192.168.1.255.4800: UDP, length = 60 07:10:44.151787 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.129.4800: UDP, length 60 07:10:44.151791 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.1.4800: UDP, length 60 07:10:44.152043 IP 192.168.1.213.40677 > 192.168.1.255.4800: UDP, length = 48 07:10:44.371387 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:45.154868 IP 192.168.1.203.57026 > 192.168.1.255.4800: UDP, length = 60 07:10:45.154892 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.129.4800: UDP, length 60 07:10:45.154896 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.1.4800: UDP, length 60 07:10:45.155146 IP 192.168.1.213.40677 > 192.168.1.255.4800: UDP, length = 48 07:10:45.413495 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:45.513130 IP 192.168.1.213 > 224.0.0.240: pfsync 196 07:10:46.157973 IP 192.168.1.203.57026 > 192.168.1.255.4800: UDP, length = 60 07:10:46.157997 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.129.4800: UDP, length 60 07:10:46.158002 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.1.4800: UDP, length 60 07:10:46.158222 IP 192.168.1.213.40677 > 192.168.1.255.4800: UDP, length = 48 07:10:46.455622 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:47.497702 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:48.108787 STP 802.1d, Config, Flags [Topology change], bridge-id = 8000.c4:7d:4f:a9:ac:30.8008, length 43 07:10:48.150038 IP 192.168.1.213 > 224.0.0.240: pfsync 108 07:10:48.539811 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:49.581924 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:49.869585 07:10:50.154224 IP 192.168.1.213 > 224.0.0.240: pfsync 108 07:10:50.624031 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:51.666137 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:52.156425 IP 192.168.1.213 > 224.0.0.240: pfsync 108 07:10:52.708257 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:53.105667 STP 802.1d, Config, Flags [Topology change], bridge-id = 8000.c4:7d:4f:a9:ac:30.8008, length 43 07:10:53.712615 IP 192.168.1.213 > 224.0.0.240: pfsync 284 07:10:53.750351 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:54.792460 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:54.996715 IP 192.168.1.213 > 224.0.0.240: pfsync 36 07:10:55.160134 IP 192.168.1.213 > 224.0.0.240: pfsync 68 07:10:55.834569 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:56.160794 IP 192.168.1.213 > 224.0.0.240: pfsync 108 07:10:56.876680 IP 192.168.1.203 > 224.0.0.240: pfsync 108 07:10:57.918791 IP 192.168.1.203 > 224.0.0.240: pfsync 108 a bit later on, still broken, a slight odd message: 07:11:43.079720 IP 172.31.1.129 > 172.31.1.213: GREv0, length 52: IP = 192.168.1.129.60446 > 192.168.1.213.179: tcp 12 [bad hdr length 16 - = too short, < 20] 07:11:44.210794 IP 172.31.1.129 > 172.31.1.203: GREv0, length 84: IP = 192.168.1.129.64744 > 192.168.1.203.4800: UDP, length 52 07:11:44.210831 IP 172.31.1.129 > 172.31.1.213: GREv0, length 84: IP = 192.168.1.129.64744 > 192.168.1.213.4800: UDP, length 52 Now this really is odd, I don't recognise either of those MAC addresses, = though the SQL shown is used on this machine ( 07:12:13.054393 45:43:54:20:41:63 > 00:00:03:53:45:4c, ethertype Unknown = (0x6374), length 60: 0x0000: 556e 6971 7565 4964 2046 524f 4d20 7261 = UniqueId.FROM.ra 0x0010: 6461 6363 7420 2057 4845 5245 2043 616c = dacct..WHERE.Cal 0x0020: 6c69 6e67 5374 6174 696f 6e49 6420 lingStationId. 07:12:13.229942 ARP, Request who-has 172.31.1.129 tell 172.31.1.213, = length 28 07:12:13.229969 ARP, Request who-has 172.31.1.129 tell 172.31.1.213, = length 28 07:12:14.600212 IP 172.31.1.213 > 224.0.0.18: VRRPv2, Advertisement, = vrid 1, prio 240, authtype none, intvl 1s, length 36 07:12:14.600234 ARP, Request who-has 172.31.1.193 tell 172.31.1.193, = length 28 07:12:15.643450 IP 172.31.1.213 > 224.0.0.18: VRRPv2, Advertisement, = vrid 1, prio 240, authtype none, intvl 1s, length 36 07:12:16.261215 ARP, Request who-has 172.31.1.129 tell 172.31.1.213, = length 28 07:12:17.583475 IP 172.31.1.213 > 224.0.0.18: VRRPv2, Advertisement, = vrid 1, prio 240, authtype none, intvl 1s, length 36 07:12:18.051111 41:54:45:20:74:72 > 00:00:03:55:50:44, ethertype Unknown = (0x616e), length 60: 0x0000: 7369 656e 742e 7261 6469 7070 6f6f 6c20 = sient.radippool. 0x0010: 5345 5420 6e61 7369 7061 6464 7265 7373 = SET.nasipaddress 0x0020: 203d 2027 3137 322e 3331 2e33 2e31 .=3D.'172.30.0.1= I then restarted the interface (nfe down/up, route restart) =46rom dmesg at the time (slight obfuscated) Sep 3 07:10:19 manch2 bgpd[89612]: neighbor XX: received notification: = HoldTimer expired, unknown subcode 0 Sep 3 07:10:49 manch2 bgpd[89612]: neighbor XX connect: Host is down # at this point I took the interface down & up and reloaded the routing = tables Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN Sep 3 07:12:07 manch2 kernel: nfe0: link state changed to DOWN Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN Sep 3 07:12:11 manch2 kernel: nfe0: link state changed to UP =20 Sep 3 07:12:11 manch2 kernel: carp0: link state changed to DOWN Sep 3 07:12:14 manch2 kernel: carp0: link state changed to UP Sep 3 07:13:09 manch2 bgpd[89612]: neighbor YYY: socket error: = Operation timed out And a while later M [root@manch2:~]# sysctl dev.nfe.0.stats dev.nfe.0.stats.rx.frame_errors: 0 dev.nfe.0.stats.rx.extra_bytes: 0 dev.nfe.0.stats.rx.late_cols: 0 dev.nfe.0.stats.rx.runts: 0 dev.nfe.0.stats.rx.jumbos: 0 dev.nfe.0.stats.rx.fifo_overuns: 0 dev.nfe.0.stats.rx.crc_errors: 0 dev.nfe.0.stats.rx.fae: 0 dev.nfe.0.stats.rx.len_errors: 0 dev.nfe.0.stats.rx.unicast: 0 dev.nfe.0.stats.rx.multicast: 0 dev.nfe.0.stats.rx.broadcast: 0 dev.nfe.0.stats.rx.octets: 53502234479 dev.nfe.0.stats.rx.pause: 0 dev.nfe.0.stats.rx.drops: 0 dev.nfe.0.stats.tx.octets: 7482784573 dev.nfe.0.stats.tx.zero_rexmits: 68060063 dev.nfe.0.stats.tx.one_rexmits: 0 dev.nfe.0.stats.tx.multi_rexmits: 0 dev.nfe.0.stats.tx.late_cols: 0 dev.nfe.0.stats.tx.fifo_underuns: 0 dev.nfe.0.stats.tx.carrier_losts: 0 dev.nfe.0.stats.tx.excess_deferrals: 0 dev.nfe.0.stats.tx.retry_errors: 0 dev.nfe.0.stats.tx.deferrals: 0 dev.nfe.0.stats.tx.frames: 68060063 dev.nfe.0.stats.tx.pause: 0 >By chance, are you using polling(4) or VLAN on nfe(4)? No Also, I tried turning TSO off and the same behaviour happened though = over a slightly longer period of time (could be co-incidence) (with TSO off) nfe0: flags=3D8943 = metric 0 mtu 1500 options=3D9b ether 00:26:9e:9b:a6:14 inet 172.31.1.213 netmask 0xffffff80 broadcast 172.31.1.255 media: Ethernet autoselect (1000baseT ) status: active Mel From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 09:58:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDFE010656BF for ; Fri, 3 Sep 2010 09:58:50 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id D49288FC17 for ; Fri, 3 Sep 2010 09:58:48 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 3BE4739868; Fri, 3 Sep 2010 11:58:46 +0200 (SAST) Date: Fri, 3 Sep 2010 11:58:46 +0200 From: John Hay To: Jack Vogel Message-ID: <20100903095846.GA7044@zibbi.meraka.csir.co.za> References: <20100723074047.GA47514@zibbi.meraka.csir.co.za> <20100820140421.GA54097@zibbi.meraka.csir.co.za> 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: packet loss on ixgbe using vlans and routing 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, 03 Sep 2010 09:58:51 -0000 Hi Jack, Have you found anything yet? The box is not in production yet, so I can run test code if you need it. John On Fri, Aug 20, 2010 at 10:39:47AM -0700, Jack Vogel wrote: > OK, am setting up the hardware to look into this John. > > Jack > > > On Fri, Aug 20, 2010 at 7:04 AM, John Hay wrote: > > > Hi Jack, > > > > Have you had a chance to look at it yet? I would love to get these > > network cards working. :-) > > > > John > > > > On Fri, Jul 23, 2010 at 01:36:10AM -0700, Jack Vogel wrote: > > > Yes, I am here, I have been reading this, but I am also very busy with a > > > couple of things, please be patient, I will get on this asap. > > > > > > Cheers, > > > > > > Jack > > > > > > > > > On Fri, Jul 23, 2010 at 12:40 AM, John Hay wrote: > > > > > > > Hi, > > > > > > > > (Jack any chance that you can look at this please?) > > > > > > > > It looks like there are 2 problems with the ixgbe driver on FreeBSD-8. > > > > I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port > > Intel > > > > 82599 cards). It is running FreeBSD RELENG_8. > > > > > > > > 1 - When routing (using vlans) there is heavy packet loss that go away > > > > when you do "ifconfig ix2 -rxcsum". The packet loss seems to be on the > > > > receive side because I do not see them on the receiving interface with > > > > tcpdump. This seems to impact both ipv4 and ipv6. > > > > > > > > My test setup is the Dell T710 with its ix2 connected to a 10G port of > > > > a Nortel 4526GTX. On that port I have 2 vlans configured with half of > > > > the 1G ports in the one vlan and the other half in the other vlan. > > > > > > > > If I test with iperf from one of the machines on a 1G port to the T710, > > > > I get 920Mbit/s. If I do it simultaneously from a few machines > > connected > > > > to the 1G ports, all of them basically saturate their 1G links. > > > > > > > > If I now try to route from the one vlan to the other, ie. doing an > > iperf > > > > from a 1G connected machine, through the T710, to another 1G connected > > > > machine, I see packet loss, sometimes iperf is only able to do > > 100kbits/s. > > > > (Configuring a tcp relay, like socat, on the T710, and working through > > it, > > > > I again get 900Mbit/s and more.) > > > > > > > > So it seems that as long as the T710 with the 10G card is the start or > > > > end point of the connection, I get no packet loss, but as soon as it > > > > has to route, something go wrong. > > > > > > > > 2 - I see packet loss (0 - 40%) on IPv6 packets in vlans, when the > > > > machine is not the originator of the packets. This happen even with > > > > the "ifconfig ix2 -rxcsum". > > > > > > > > Let me try to describe a little more. If a neigbouring machine ping6 > > it, > > > > there will be packet loss. If it act as a router for ipv6, there will > > be > > > > packet loss. This happen even when the network is pretty idle and with > > > > different switches (Nortel and Cisco equipment). The packet loss is > > > > very fluctuating. Pinging 1000 packets might loose 1% one time and the > > > > next time 30%. Looking with tcpdump, I can see the packets arriving and > > > > going out, but the packet never arrive at the next machine. (My feeling > > is > > > > that they get lost inside the card.) The error counters on the switch > > > > does not increment. > > > > > > > > I do not see packet loss if the machine originate the packets, for > > example > > > > ping6 from the machine. Also ipv4 packets do not have any packets loss. > > If > > > > I do not use vlans, I don't see packet loss with ipv6 either. > > > > > > > > The machine also have bce 1G interfaces and I do not see the packet > > loss > > > > on them. > > > > > > > > Here is some info about the machine / setup. The numbers are pretty low > > > > because I rebooted after compiling a kernel with IPFIREWALL, > > ROUTETABLES, > > > > MROUTING and FLOWTABLE removed. I'll add my kernel config file with > > empty > > > > and commented out lines removed. > > > > > > > > pciconf -lvc > > > > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 > > > > rev=0x01 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > class = network > > > > subclass = ethernet > > > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > > > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 > > > > rev=0x01 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > class = network > > > > subclass = ethernet > > > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > > > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 > > > > rev=0x01 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > class = network > > > > subclass = ethernet > > > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > > > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 > > > > rev=0x01 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > class = network > > > > subclass = ethernet > > > > cap 01[40] = powerspec 3 supports D0 D3 current D0 > > > > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > > > > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > > > > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > > > > > > > output of vmstat -i > > > > > > > > interrupt total rate > > > > irq19: ehci0 28371 0 > > > > irq21: uhci2 uhci4+ 48 0 > > > > irq23: atapci0 46 0 > > > > irq34: mpt0 146954 2 > > > > cpu0: timer 112205297 1999 > > > > irq256: bce0 52063 0 > > > > irq257: bce1 1 0 > > > > irq258: bce2 1 0 > > > > irq259: bce3 1 0 > > > > irq260: ix0:que 0 142258 2 > > > > irq261: ix0:que 1 56464 1 > > > > irq262: ix0:que 2 56199 1 > > > > irq263: ix0:que 3 56198 1 > > > > irq264: ix0:que 4 66569 1 > > > > irq265: ix0:que 5 56148 1 > > > > irq266: ix0:que 6 56217 1 > > > > irq267: ix0:que 7 56311 1 > > > > irq268: ix0:que 8 56169 1 > > > > irq269: ix0:que 9 69485 1 > > > > irq270: ix0:que 10 56176 1 > > > > irq271: ix0:que 11 56205 1 > > > > irq272: ix0:que 12 56281 1 > > > > irq273: ix0:que 13 56359 1 > > > > irq274: ix0:que 14 56292 1 > > > > irq275: ix0:que 15 56197 1 > > > > irq276: ix0:link 2 0 > > > > irq277: ix1:que 0 107873 1 > > > > irq278: ix1:que 1 56094 0 > > > > irq279: ix1:que 2 56097 0 > > > > irq280: ix1:que 3 56096 0 > > > > irq281: ix1:que 4 65439 1 > > > > irq282: ix1:que 5 56091 0 > > > > irq283: ix1:que 6 56092 0 > > > > irq284: ix1:que 7 56098 0 > > > > irq285: ix1:que 8 56091 0 > > > > irq286: ix1:que 9 56096 0 > > > > irq287: ix1:que 10 56093 0 > > > > irq288: ix1:que 11 56091 0 > > > > irq289: ix1:que 12 56096 0 > > > > irq290: ix1:que 13 56095 0 > > > > irq291: ix1:que 14 57125 1 > > > > irq292: ix1:que 15 56093 0 > > > > irq293: ix1:link 1 0 > > > > irq294: ix2:que 0 231250 4 > > > > irq295: ix2:que 1 57784 1 > > > > irq296: ix2:que 2 69956 1 > > > > irq297: ix2:que 3 59498 1 > > > > irq298: ix2:que 4 58201 1 > > > > irq299: ix2:que 5 58599 1 > > > > irq300: ix2:que 6 57813 1 > > > > irq301: ix2:que 7 60075 1 > > > > irq302: ix2:que 8 68639 1 > > > > irq303: ix2:que 9 58194 1 > > > > irq304: ix2:que 10 60752 1 > > > > irq305: ix2:que 11 57628 1 > > > > irq306: ix2:que 12 66796 1 > > > > irq307: ix2:que 13 63307 1 > > > > irq308: ix2:que 14 60788 1 > > > > irq309: ix2:que 15 59102 1 > > > > irq310: ix2:link 5 0 > > > > irq311: ix3:que 0 56090 0 > > > > irq312: ix3:que 1 56090 0 > > > > irq313: ix3:que 2 56090 0 > > > > irq314: ix3:que 3 56090 0 > > > > irq315: ix3:que 4 56090 0 > > > > irq316: ix3:que 5 56090 0 > > > > irq317: ix3:que 6 56090 0 > > > > irq318: ix3:que 7 56090 0 > > > > irq319: ix3:que 8 56090 0 > > > > irq320: ix3:que 9 56090 0 > > > > irq321: ix3:que 10 56090 0 > > > > irq322: ix3:que 11 56090 0 > > > > irq323: ix3:que 12 56090 0 > > > > irq324: ix3:que 13 56090 0 > > > > irq325: ix3:que 14 56090 0 > > > > irq326: ix3:que 15 56090 0 > > > > cpu1: timer 112196134 1999 > > > > cpu10: timer 112196179 1999 > > > > cpu3: timer 112196135 1999 > > > > cpu8: timer 112196108 1999 > > > > cpu4: timer 112196161 1999 > > > > cpu11: timer 112196179 1999 > > > > cpu5: timer 112196161 1999 > > > > cpu13: timer 112196179 1999 > > > > cpu6: timer 112196161 1999 > > > > cpu14: timer 112196179 1999 > > > > cpu2: timer 112196106 1999 > > > > cpu12: timer 112196179 1999 > > > > cpu7: timer 112196161 1999 > > > > cpu9: timer 112196155 1999 > > > > cpu15: timer 112196179 1999 > > > > Total 1799390156 32072 > > > > > > > > netstat -m > > > > > > > > 133178/4042/137220 mbufs in use (current/cache/total) > > > > 133112/2062/135174/262144 mbuf clusters in use > > (current/cache/total/max) > > > > 133112/2056 mbuf+clusters out of packet secondary zone in use > > > > (current/cache) > > > > 0/20/20/131072 4k (page size) jumbo clusters in use > > > > (current/cache/total/max) > > > > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > > > > 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) > > > > 299518K/5214K/304733K bytes allocated to network (current/cache/total) > > > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > > > 0/0/0 sfbufs in use (current/peak/max) > > > > 0 requests for sfbufs denied > > > > 0 requests for sfbufs delayed > > > > 0 requests for I/O initiated by sendfile > > > > 0 calls to protocol drain routines > > > > > > > > kernel config file, basically started with 64 bit and removed the stuff > > > > I do not need. > > > > > > > > cpu HAMMER > > > > ident SEEKAT > > > > device ipmi > > > > makeoptions DEBUG=-g # Build kernel with gdb(1) > > debug > > > > symbols > > > > options SCHED_ULE # ULE scheduler > > > > options PREEMPTION # Enable kernel thread > > preemption > > > > options INET # InterNETworking > > > > options INET6 # IPv6 communications protocols > > > > options SCTP # Stream Control Transmission > > > > Protocol > > > > options FFS # Berkeley Fast Filesystem > > > > options SOFTUPDATES # Enable FFS soft updates > > support > > > > options UFS_DIRHASH # Improve performance on big > > > > directories > > > > options CD9660 # ISO 9660 Filesystem > > > > options PROCFS # Process filesystem (requires > > > > PSEUDOFS) > > > > options PSEUDOFS # Pseudo-filesystem framework > > > > options GEOM_PART_GPT # GUID Partition Tables. > > > > options GEOM_LABEL # Provides labelization > > > > options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) > > > > options COMPAT_IA32 # Compatible with i386 binaries > > > > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > > > > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > > > > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > > > > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > > > > options KTRACE # ktrace(1) support > > > > options STACK # stack(9) support > > > > options SYSVSHM # SYSV-style shared memory > > > > options SYSVMSG # SYSV-style message queues > > > > options SYSVSEM # SYSV-style semaphores > > > > options P1003_1B_SEMAPHORES # POSIX-style semaphores > > > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > > > > extensions > > > > options PRINTF_BUFR_SIZE=128 # Prevent printf output being > > > > interspersed. > > > > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > > > > options HWPMC_HOOKS # Necessary kernel hooks for > > > > hwpmc(4) > > > > options INCLUDE_CONFIG_FILE # Include this file in kernel > > > > options SMP # Symmetric MultiProcessor > > Kernel > > > > device cpufreq > > > > device acpi > > > > device pci > > > > device ata > > > > device atapicd # ATAPI CDROM drives > > > > device mpt # LSI-Logic MPT-Fusion > > > > device scbus # SCSI bus (required for SCSI) > > > > device da # Direct Access (disks) > > > > device pass # Passthrough device (direct SCSI > > access) > > > > device atkbdc # AT keyboard controller > > > > device atkbd # AT keyboard > > > > device psm # PS/2 mouse > > > > device kbdmux # keyboard multiplexer > > > > device vga # VGA video card driver > > > > device splash # Splash screen and screen saver > > support > > > > device sc > > > > device agp # support several AGP chipsets > > > > device uart # Generic UART driver > > > > device loop # Network loopback > > > > device random # Entropy device > > > > device ether # Ethernet support > > > > device pty # BSD-style compatibility pseudo ttys > > > > device bpf # Berkeley packet filter > > > > device uhci # UHCI PCI->USB interface > > > > device ehci # EHCI PCI->USB interface (USB 2.0) > > > > device usb # USB Bus (required) > > > > device uhid # "Human Interface Devices" > > > > device ukbd # Keyboard > > > > device umass # Disks/Mass storage - Requires scbus > > and > > > > da > > > > device ums # Mouse > > > > > > > > kldstat > > > > Id Refs Address Size Name > > > > 1 55 0xffffffff80100000 6ea290 kernel > > > > 2 1 0xffffffff807eb000 19e088 zfs.ko > > > > 3 2 0xffffffff8098a000 3860 opensolaris.ko > > > > 4 2 0xffffffff8098e000 20448 krpc.ko > > > > 5 1 0xffffffff809af000 21100 geom_mirror.ko > > > > 6 1 0xffffffff809d1000 66c0 if_vlan.ko > > > > 7 1 0xffffffff809d8000 506c8 if_bce.ko > > > > 8 2 0xffffffff80a29000 3ec20 miibus.ko > > > > 9 1 0xffffffff80a68000 243e0 if_ixgbe.ko > > > > 10 1 0xffffffff80a8d000 1e08 coretemp.ko > > > > > > > > ifconfig ix2 (with -rxcsum and global addrs modified) > > > > ix2: flags=8843 metric 0 mtu > > 1500 > > > > > > options=5b8 > > > > ether 00:1b:21:57:ef:7c > > > > inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 > > > > nd6 options=3 > > > > media: Ethernet autoselect (10Gbase-SR ) > > > > status: active > > > > ifconfig ix2.1 > > > > ix2.1: flags=8843 metric 0 mtu > > 1500 > > > > ether 00:1b:21:57:ef:7c > > > > inet 10.0.28.2 netmask 0xffffff00 broadcast 10.0.28.255 > > > > inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0x9 > > > > inet6 2001:0:0:3:21b:21ff:fe57:b420 prefixlen 64 > > > > inet6 2001:0:0:3:: prefixlen 64 anycast > > > > nd6 options=3 > > > > media: Ethernet autoselect (10Gbase-SR ) > > > > status: active > > > > vlan: 1 parent interface: ix2 > > > > ifconfig ix2.8 > > > > ix2.8: flags=8843 metric 0 mtu > > 1500 > > > > ether 00:1b:21:57:ef:7c > > > > inet 10.0.8.50 netmask 0xffffff00 broadcast 10.0.8.255 > > > > inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xa > > > > inet6 2001:0:0:1:21b:21ff:fe57:b420 prefixlen 64 > > > > inet6 2001:0:0:1:: prefixlen 64 anycast > > > > nd6 options=3 > > > > media: Ethernet autoselect (10Gbase-SR ) > > > > status: active > > > > vlan: 8 parent interface: ix2 > > > > > > > > John > > > > -- > > > > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 10:03:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A536106585C for ; Fri, 3 Sep 2010 10:03:57 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id F2C198FC19 for ; Fri, 3 Sep 2010 10:03:56 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OrStC-0001zv-4K for freebsd-net@freebsd.org; Fri, 03 Sep 2010 11:48:54 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Sep 2010 11:48:54 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Sep 2010 11:48:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 03 Sep 2010 11:48:44 +0200 Lines: 19 Message-ID: References: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> X-Enigmail-Version: 1.0.1 Cc: freebsd-security@freebsd.org Subject: Re: seeking current supported crypto co-processors 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, 03 Sep 2010 10:03:57 -0000 On 09/03/10 02:35, Ricky Charlet wrote: > Howdy, > > > I'm seeking current cryptographic coprocessors supported in FreeBSD 8.x. By perusing through the crypto-dev (and subsequently referenced) man page(s) I found this list: > Hifn 7751/7951/7811/7955/7956 crypto accelerator > SafeNet 1141/1741 > Bluesteel 5501/5601 > Broadcom bcm5801/5802/5805/5820/5821/5822/5823/5825 > > Those are all pretty old (and in some cases, no longer existent). I'm surveying these lists to see if anyone knows of more modern chips working with FreeBSD 8.x. Or if you feel some chip on the list above is up to the task of near about 1 Gb throughput across a PCIe and has friendly vendor support for FreeBSD, I'd sure like to hear about that too. > I'm not saying they are useless but are you really sure you need them? Even on the last generation of CPUs without AES instructions you can easily get 125 MB/s of AES-128 encryption and 300 MB/s of RC4 per CPU core, so even one core can saturate a 1 Gbit/s link. You can setup a cheap box to be a SSL proxy in front of the real web servers to offload SSL. From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 18:01:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9FCC106574E for ; Fri, 3 Sep 2010 18:01:58 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay1.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6F23E8FC26 for ; Fri, 3 Sep 2010 18:01:57 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id o83I1uSY026586 for ; Fri, 3 Sep 2010 21:01:56 +0300 (EEST) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id o83I1u4S026585 for freebsd-net@freebsd.org; Fri, 3 Sep 2010 21:01:56 +0300 (EEST) Date: Fri, 3 Sep 2010 21:01:56 +0300 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20100903180156.GA20682@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: mac address cleaning ignored ... 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, 03 Sep 2010 18:01:59 -0000 Hi All, i have faced some "weird" mac address caching issue ... need help to understand who is who :( i have box A: FreeBSD 8.1-STABLE #2 amd64 and box B: FreeBSD 8.1-STABLE #3 amd64 both are connected to TP Link switch TL-SG5426 after nic change on box B i can ping box B from box A but i can not ping A from B ... i see the box A continue to reply to the box B old nic mac address ... how can it be possible if i have made: - arp cleaning on box A after what arp shows correct mac for host B -- pf reload/restart - arp cleaning on box B after what arp shows correct mac for host B -- pf reload/restart -- cold reboot - host/dns/mac cleaning on switch after what mac table contains correct mac for host B -- switch soft reload on box A i have quagga running ... can it cach mac addresses? the nic change was needed due to the heavy onboard nic re(4) card=0x83a31043 chip=0x816810ec Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c) flapping really i have no idea what to do except cold reboot of box A ... but who can to continue to remembers box B old nic mac address after all of that cleanings? thanks in advance -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 18:57:57 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9342D1065695; Fri, 3 Sep 2010 18:57:57 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 333618FC0A; Fri, 3 Sep 2010 18:57:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o83IvvpQ026547; Fri, 3 Sep 2010 18:57:57 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o83Ivvqs026543; Fri, 3 Sep 2010 18:57:57 GMT (envelope-from vwe) Date: Fri, 3 Sep 2010 18:57:57 GMT Message-Id: <201009031857.o83Ivvqs026543@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: misc/150249: [ixgbe] Media type detection broken 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, 03 Sep 2010 18:57:57 -0000 Synopsis: [ixgbe] Media type detection broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Fri Sep 3 18:57:36 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150249 From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 18:58:29 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420F710656C8; Fri, 3 Sep 2010 18:58:29 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 192958FC0A; Fri, 3 Sep 2010 18:58:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o83IwSl6026617; Fri, 3 Sep 2010 18:58:28 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o83IwSaZ026613; Fri, 3 Sep 2010 18:58:28 GMT (envelope-from vwe) Date: Fri, 3 Sep 2010 18:58:28 GMT Message-Id: <201009031858.o83IwSaZ026613@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: misc/150251: [patch] [ixgbe] Late cable insertion broken 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, 03 Sep 2010 18:58:29 -0000 Old Synopsis: [ixgbe] Late cable insertion broken New Synopsis: [patch] [ixgbe] Late cable insertion broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Fri Sep 3 18:58:05 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150251 From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 21:16:28 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 103F6106571B for ; Fri, 3 Sep 2010 21:16:28 +0000 (UTC) (envelope-from RCharlet@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E42DC8FC0A for ; Fri, 3 Sep 2010 21:16:27 +0000 (UTC) X-ASG-Debug-ID: 1283548587-5061c0170001-QdxwpM Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id VpPuKBkhgGmVJ37J; Fri, 03 Sep 2010 14:16:27 -0700 (PDT) X-Barracuda-Envelope-From: RCharlet@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Fri, 3 Sep 2010 14:16:27 -0700 From: "Ricky Charlet" X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: Andre Oppermann Date: Fri, 3 Sep 2010 14:16:22 -0700 X-ASG-Orig-Subj: RE: seeking current supported crypto co-processors Thread-Topic: seeking current supported crypto co-processors Thread-Index: ActLLj/z32zc9IazR5KSgaZujRSA/QAezwqw Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C8DE0F2@SJ-EXCH-1.adaranet.com> References: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> <4C80908D.9030106@freebsd.org> In-Reply-To: <4C80908D.9030106@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1283548587 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: "freebsd-security@freebsd.org" , "freebsd-net@freebsd.org" Subject: RE: seeking current supported crypto co-processors 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, 03 Sep 2010 21:16:28 -0000 Thanks Andre, I'm hoping not to get too distracted by which algorithms I want sup= ported. To answer directly, I want the FIPS-140-2 algorithms in block modes= and optionally the Suite-B NSA stuff too. http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml But the main thrust of my question is not what algs are supported b= y what parts... but instead, are their PCIe attachable crypto co-processors= with current vendor support for FreeBSD8.x? I appreciated your pointers to VIA and various MIPS and specificall= y octeon processors. And I am newly enlightened by your pointers to very ne= w Intel parts coming out with cipher/hash support... that may help me in th= e near future. But at the moment, I am currently bound to Intel parts witho= ut the AES feature set. If anyone else reading this thread want's to chime in with info abo= ut current supported crypto co-processors that plug in via PCIe, please dro= p a note. --- Ricky Charlet Adara Networks USA 408-433-4942 -----Original Message----- From: Andre Oppermann [mailto:andre@freebsd.org] Sent: Thursday, September 02, 2010 11:07 PM To: Ricky Charlet Cc: freebsd-security@freebsd.org; freebsd-net@freebsd.org Subject: Re: seeking current supported crypto co-processors On 03.09.2010 02:35, Ricky Charlet wrote: > Howdy, > > I'm seeking current cryptographic coprocessors supported in FreeBSD 8.x. = By perusing through the > crypto-dev (and subsequently referenced) man page(s) I found this list: H= ifn > 7751/7951/7811/7955/7956 crypto accelerator SafeNet 1141/1741 Bluesteel 5= 501/5601 Broadcom > bcm5801/5802/5805/5820/5821/5822/5823/5825 > > Those are all pretty old (and in some cases, no longer existent). I'm sur= veying these lists to > see if anyone knows of more modern chips working with FreeBSD 8.x. Or if = you feel some chip on > the list above is up to the task of near about 1 Gb throughput across a P= CIe and has friendly > vendor support for FreeBSD, I'd sure like to hear about that too. What cypto algorithms do you need? Stream encryption and/or PKI KEX? For AES stream encrpytion there are some CPU's that directly support the crypto primitives on the silicon. For newer x86/amd64 CPU's see: http://en.wikipedia.org/wiki/AES_instruction_set A number of VIA x86 CPU's have supported a set of crypto algorithms inlcuding stream cyphers, cryptographic hashing and RSA for quite some time on their silicon. http://www.via.com.tw/en/initiatives/padlock/hardware.jsp Other than that there are some embedded crypto engines with their own (mostly MIPS based) single and multi-core CPU's. AKAIK they have a FreeBSD API and the FreeBSD MIPS port should work on at least some of them: http://www.caviumnetworks.com/ Cavium also has some plug-in crypto accelerator cards under the brand name Nitrox. IIRC they have some drivers for FreeBSD available. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 21:27:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B961110656BD for ; Fri, 3 Sep 2010 21:27:08 +0000 (UTC) (envelope-from RCharlet@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4568FC1E for ; Fri, 3 Sep 2010 21:27:08 +0000 (UTC) X-ASG-Debug-ID: 1283549199-5061c03f0001-QdxwpM Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id FPcIvvxlSBeOKnKq; Fri, 03 Sep 2010 14:26:39 -0700 (PDT) X-Barracuda-Envelope-From: RCharlet@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Fri, 3 Sep 2010 14:26:39 -0700 From: "Ricky Charlet" X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: Ivan Voras , "freebsd-net@freebsd.org" Date: Fri, 3 Sep 2010 14:26:37 -0700 X-ASG-Orig-Subj: RE: seeking current supported crypto co-processors Thread-Topic: seeking current supported crypto co-processors Thread-Index: ActLT2FbXLoDehatRd2+DONQA7bToQAXeP2A Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C8DE0F5@SJ-EXCH-1.adaranet.com> References: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1283549199 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: "freebsd-security@freebsd.org" Subject: RE: seeking current supported crypto co-processors 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, 03 Sep 2010 21:27:08 -0000 VGhhbmtzIEl2YW4sDQoNCiAgICAgICAgWW91IGhhdmUgc29tZSB2YWxpZCBwb2ludHMgYWJvdXQg cGVyZm9ybWFuY2UuIEkgd2FzIGhvcGluZyBub3QgdG8gZ2V0IGRpc3RyYWN0ZWQgZnJvbSB0aGUg bWFpbiB0aHJ1c3Qgb2YgbXkgcXVlc3Rpb24gYnkgcGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnMg dGhvdWdoLg0KDQogICAgICAgIEFyZSB0aGVpciBQQ0llIGF0dGFjaGFibGUgY3J5cHRvIGNvLXBy b2Nlc3NvcnMgd2l0aCBjdXJyZW50IHZlbmRvciBzdXBwb3J0IGZvciBGcmVlQlNEOC54PyAgSWYg YW55b25lIGVsc2UgcmVhZGluZyB0aGlzIHRocmVhZCB3YW50J3MgdG8gY2hpbWUgaW4gd2l0aCBp bmZvIGFib3V0IGN1cnJlbnQgc3VwcG9ydGVkIGNyeXB0byBjby1wcm9jZXNzb3JzIHRoYXQgcGx1 ZyBpbiB2aWEgUENJZSwgcGxlYXNlIGRyb3AgYSBub3RlLg0KDQoNCiAgICAgICAgSG93ZXZlciwg SSB0aGluayB5b3UgZG8gZGVzZXJ2ZSBhIHJlcGx5IG9uIHRoZSBwZXJmb3JtYW5jZSB0b3BpYy4u Lg0KDQogICAgICAgIEkgYW0gY2xvc2UgZW5vdWdoIHRvIGFncmVlaW5nIHdpdGggeW91IHRvIG5v dCBhcmd1ZSBtdWNoIGFib3V0IHdoZXRoZXIgbW9kZXJuIENQVSBwYXJ0cyBjYW4gc2F0dXJhdGUg YSAxIEdiIGxpbmsgd2l0aCBjcnlwdG8gZGF0YS4gVGhlIENQVSBwYXJ0IEkgYW0gY3VycmVudGx5 IG1hcnJpZWQgdG8gKGEgdG91Y2ggb2xkIGJ1dCBub3QgdGhhdCBiYWQpLCBzZWVtcyB0byBiZSBh YmxlIHRvIHRocm91Z2ggYXJvdW5kIDIwME1iIG9mIElQLUVTUCBkYXRhIGFyb3VuZC4gSG93ZXZl ciwgaW4gc3BpdGUgb2YgdGhlc2Ugb2JzZXJ2YXRpb25zLCBJIHdvdWxkIHByZWZlciBpZiBteSBz eXN0ZW0gY291bGQgaGFuZGxlIHRoYXQgdGhyb3VnaHB1dCBsb2FkIGFuZCB5ZXQgaGF2ZSBDUFUg cG93ZXIgbGVmdCBvdmVyIGZvciBvdGhlciB0YXNrcy4NCg0KICAgICAgICBJJ20gdmVyeSBhdHRy YWN0ZWQgdG8gQW5kcmUncyBtZW50aW9uIG9mICJuZXdlciB4ODYvYW1kNjQgQ1BVJ3Mgc2VlOg0K ICBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0FFU19pbnN0cnVjdGlvbl9zZXQiLiBEb2Vz IGFueW9uZSBrbm93IGlmIEZyZWVCU0Qgc3VwcG9ydHMgb3Igd2lsbCBzdXBwb3J0IHRoaXMgdGhy b3VnaCBlaXRoZXIgL2Rldi9jcnlwdG8gb3IgdGhyb3VnaCBvcGVuc3NsIChvciBhbnkgb3RoZXIg bWVjaGFuaXNtIEkgZ3Vlc3MpPw0KDQoNCg0KDQotLS0NClJpY2t5IENoYXJsZXQNCkFkYXJhIE5l dHdvcmtzDQpVU0EgNDA4LTQzMy00OTQyDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogb3duZXItZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcgW21haWx0bzpvd25l ci1mcmVlYnNkLW5ldEBmcmVlYnNkLm9yZ10gT24gQmVoYWxmIE9mIEl2YW4gVm9yYXMNClNlbnQ6 IEZyaWRheSwgU2VwdGVtYmVyIDAzLCAyMDEwIDI6NDkgQU0NClRvOiBmcmVlYnNkLW5ldEBmcmVl YnNkLm9yZw0KQ2M6IGZyZWVic2Qtc2VjdXJpdHlAZnJlZWJzZC5vcmcNClN1YmplY3Q6IFJlOiBz ZWVraW5nIGN1cnJlbnQgc3VwcG9ydGVkIGNyeXB0byBjby1wcm9jZXNzb3JzDQoNCk9uIDA5LzAz LzEwIDAyOjM1LCBSaWNreSBDaGFybGV0IHdyb3RlOg0KPiBIb3dkeSwNCj4gICAgIDx0aGlzIG1l c3NhZ2VzIGlzIGNyb3NzIHBvc3RlZCBpbiBmcmVlYnNkLXNlY3VyaXR5IGFuZCBmcmVlYnNkLW5l dD4NCj4NCj4gICAgICAgICAgSSdtIHNlZWtpbmcgY3VycmVudCBjcnlwdG9ncmFwaGljIGNvcHJv Y2Vzc29ycyBzdXBwb3J0ZWQgaW4gRnJlZUJTRCA4LnguICBCeSBwZXJ1c2luZyB0aHJvdWdoIHRo ZSBjcnlwdG8tZGV2IChhbmQgc3Vic2VxdWVudGx5IHJlZmVyZW5jZWQpIG1hbiBwYWdlKHMpIEkg Zm91bmQgdGhpcyBsaXN0Og0KPiBIaWZuIDc3NTEvNzk1MS83ODExLzc5NTUvNzk1NiBjcnlwdG8g YWNjZWxlcmF0b3INCj4gU2FmZU5ldCAxMTQxLzE3NDENCj4gQmx1ZXN0ZWVsIDU1MDEvNTYwMQ0K PiBCcm9hZGNvbSBiY201ODAxLzU4MDIvNTgwNS81ODIwLzU4MjEvNTgyMi81ODIzLzU4MjUNCj4N Cj4gICAgICAgICAgVGhvc2UgYXJlIGFsbCBwcmV0dHkgb2xkIChhbmQgaW4gc29tZSBjYXNlcywg bm8gbG9uZ2VyIGV4aXN0ZW50KS4gSSdtIHN1cnZleWluZyB0aGVzZSBsaXN0cyB0byBzZWUgaWYg YW55b25lIGtub3dzIG9mIG1vcmUgbW9kZXJuIGNoaXBzIHdvcmtpbmcgd2l0aCBGcmVlQlNEIDgu eC4gT3IgaWYgeW91IGZlZWwgc29tZSBjaGlwIG9uIHRoZSBsaXN0IGFib3ZlIGlzIHVwIHRvIHRo ZSB0YXNrIG9mIG5lYXIgYWJvdXQgMSBHYiB0aHJvdWdocHV0IGFjcm9zcyBhIFBDSWUgYW5kIGhh cyBmcmllbmRseSB2ZW5kb3Igc3VwcG9ydCBmb3IgRnJlZUJTRCwgSSdkIHN1cmUgbGlrZSB0byBo ZWFyIGFib3V0IHRoYXQgdG9vLg0KPg0KDQpJJ20gbm90IHNheWluZyB0aGV5IGFyZSB1c2VsZXNz IGJ1dCBhcmUgeW91IHJlYWxseSBzdXJlIHlvdSBuZWVkIHRoZW0/DQpFdmVuIG9uIHRoZSBsYXN0 IGdlbmVyYXRpb24gb2YgQ1BVcyB3aXRob3V0IEFFUyBpbnN0cnVjdGlvbnMgeW91IGNhbg0KZWFz aWx5IGdldCAxMjUgTUIvcyBvZiBBRVMtMTI4IGVuY3J5cHRpb24gYW5kIDMwMCBNQi9zIG9mIFJD NCBwZXIgQ1BVDQpjb3JlLCBzbyBldmVuIG9uZSBjb3JlIGNhbiBzYXR1cmF0ZSBhIDEgR2JpdC9z IGxpbmsuIFlvdSBjYW4gc2V0dXAgYQ0KY2hlYXAgYm94IHRvIGJlIGEgU1NMIHByb3h5IGluIGZy b250IG9mIHRoZSByZWFsIHdlYiBzZXJ2ZXJzIHRvIG9mZmxvYWQgU1NMLg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpmcmVlYnNkLW5ldEBmcmVl YnNkLm9yZyBtYWlsaW5nIGxpc3QNCmh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ZyZWVic2QtbmV0DQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJl ZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-net@FreeBSD.ORG Fri Sep 3 21:55:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D1E610656A4; Fri, 3 Sep 2010 21:55:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CAFD88FC14; Fri, 3 Sep 2010 21:55:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o83LhMrs083932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Sep 2010 00:43:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o83LhMkS033722; Sat, 4 Sep 2010 00:43:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o83LhM4F033721; Sat, 4 Sep 2010 00:43:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Sep 2010 00:43:22 +0300 From: Kostik Belousov To: Ricky Charlet Message-ID: <20100903214322.GU2396@deviant.kiev.zoral.com.ua> References: <32AB5C9615CC494997D9ABB1DB12783C024C8DE03A@SJ-EXCH-1.adaranet.com> <32AB5C9615CC494997D9ABB1DB12783C024C8DE0F5@SJ-EXCH-1.adaranet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HpNsou9EUJHn1L/v" Content-Disposition: inline In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C8DE0F5@SJ-EXCH-1.adaranet.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "freebsd-net@freebsd.org" , Ivan Voras , "freebsd-security@freebsd.org" Subject: Re: seeking current supported crypto co-processors 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, 03 Sep 2010 21:55:11 -0000 --HpNsou9EUJHn1L/v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 03, 2010 at 02:26:37PM -0700, Ricky Charlet wrote: > Thanks Ivan, >=20 > You have some valid points about performance. I was hoping not to= get distracted from the main thrust of my question by performance consider= ations though. >=20 > Are their PCIe attachable crypto co-processors with current vendo= r support for FreeBSD8.x? If anyone else reading this thread want's to chi= me in with info about current supported crypto co-processors that plug in v= ia PCIe, please drop a note. >=20 >=20 > However, I think you do deserve a reply on the performance topic.= .. >=20 > I am close enough to agreeing with you to not argue much about wh= ether modern CPU parts can saturate a 1 Gb link with crypto data. The CPU p= art I am currently married to (a touch old but not that bad), seems to be a= ble to through around 200Mb of IP-ESP data around. However, in spite of the= se observations, I would prefer if my system could handle that throughput l= oad and yet have CPU power left over for other tasks. >=20 > I'm very attracted to Andre's mention of "newer x86/amd64 > CPU's see: http://en.wikipedia.org/wiki/AES_instruction_set". Does > anyone know if FreeBSD supports or will support this through either > /dev/crypto or through openssl (or any other mechanism I guess)? I believe recent OpenSSL 1.x supports AESNI in usermode. For the AES acceleration in the kernel and /dev/crypto support see the aesni driver in the recent HEAD, working both on i386 and amd64 architectures. I had a plan to merge the driver into RELENG_8, but it is stalled due to some issues (not related to the driver quality). --HpNsou9EUJHn1L/v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyBa/oACgkQC3+MBN1Mb4hzagCfQwfaUXSrtGyvMnfKhFKt1nyW qNEAoIjEPKRs2rqgeh690BXCda/qnmrX =xjfx -----END PGP SIGNATURE----- --HpNsou9EUJHn1L/v-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 4 00:54:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9680F1065696 for ; Sat, 4 Sep 2010 00:54:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63DEA8FC14 for ; Sat, 4 Sep 2010 00:54:14 +0000 (UTC) Received: by pwi8 with SMTP id 8so468968pwi.13 for ; Fri, 03 Sep 2010 17:54:13 -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=effxGjtLR5cciZRxUg629NJOkIpAaiIIW0iXehwNYVg=; b=QMbrHCEL9MLKp3lrJqSCJvXZj9Yjy1TPsMEQEhhv5hYhMWYccSKg15uZrUzY+IcXV+ ALgomn3ZB7Fp2iuDLEFydRRNzHMTE2LYoHIxoGX6kU6ZoGF+RpyAWcyWEbHuMtTouhQP XRoL9aAX85v8tsxfZYf2QYbypUNGbrwF0JtM0= 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=sP92O0Kk9iJowl5u7idFxZwFmTcTEdEFCNueo6jhtmeLFWn1uAL7HbF3x1H4x76x58 tYS5zKaDIbHdusJNWhjKN39Ml9RvHj67rcuM57Y99Y46aRcp0v8E1WFvl7UplqSqua9T R50qmjriCtZrEEIH8mNA6Liuf/qPZN53Qpu7s= Received: by 10.114.77.11 with SMTP id z11mr352959waa.112.1283561653814; Fri, 03 Sep 2010 17:54:13 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d38sm4866806wam.20.2010.09.03.17.54.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 17:54:12 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 3 Sep 2010 17:53:49 -0700 From: Pyun YongHyeon Date: Fri, 3 Sep 2010 17:53:49 -0700 To: Melissa Jenkins Message-ID: <20100904005349.GP21940@michelle.cdnetworks.com> References: <5C261F16-6530-47EE-B1C1-BA38CD6D8B01@littlebluecar.co.uk> <20100902194940.GH21940@michelle.cdnetworks.com> 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 adapter 'hangs' 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: Sat, 04 Sep 2010 00:54:14 -0000 On Fri, Sep 03, 2010 at 07:59:26AM +0100, Melissa Jenkins wrote: > > Thank you for your very quick response :) > [...] > >Also I'd like to know whether both RX and TX are dead or only one > >RX/TX path is hung. Can you see incoming traffic with tcpdump when > >you think the controller is in stuck? > > Yes, though not very much. The traffic to 4800 is every second so you can see in the following trace when it stops > > 07:10:42.287163 IP 192.168.1.203 > 224.0.0.240: pfsync 108 > 07:10:42.911995 > 07:10:43.112073 STP 802.1d, Config, Flags [Topology change], bridge-id 8000.c4:7d:4f:a9:ac:30.8008, length 43 > 07:10:43.148659 IP 192.168.1.203.57026 > 192.168.1.255.4800: UDP, length 60 > 07:10:43.148684 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP 192.168.1.203.57026 > 192.168.1.129.4800: UDP, length 60 > 07:10:43.148689 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP 192.168.1.203.57026 > 192.168.1.1.4800: UDP, length 60 > 07:10:43.148918 IP 192.168.1.213.40677 > 192.168.1.255.4800: UDP, length 48 [...] > a bit later on, still broken, a slight odd message: > 07:11:43.079720 IP 172.31.1.129 > 172.31.1.213: GREv0, length 52: IP 192.168.1.129.60446 > 192.168.1.213.179: tcp 12 [bad hdr length 16 - too short, < 20] > 07:11:44.210794 IP 172.31.1.129 > 172.31.1.203: GREv0, length 84: IP 192.168.1.129.64744 > 192.168.1.203.4800: UDP, length 52 > 07:11:44.210831 IP 172.31.1.129 > 172.31.1.213: GREv0, length 84: IP 192.168.1.129.64744 > 192.168.1.213.4800: UDP, length 52 > > Now this really is odd, I don't recognise either of those MAC addresses, though the SQL shown is used on this machine ( > 07:12:13.054393 45:43:54:20:41:63 > 00:00:03:53:45:4c, ethertype Unknown (0x6374), length 60: > 0x0000: 556e 6971 7565 4964 2046 524f 4d20 7261 UniqueId.FROM.ra > 0x0010: 6461 6363 7420 2057 4845 5245 2043 616c dacct..WHERE.Cal > 0x0020: 6c69 6e67 5374 6174 696f 6e49 6420 lingStationId. Hmm, it seems you're using really complex setup. It's very hard to narrow down guilty ones under these environments. Could you setup simple network configuration that reproduces the issue? One of possible cause would be wrong(garbled) data might be passed up to upper stack. But I have no idea why you see GRE packets with truncated TCP header(172.31.1.129 > 172.31.1.213). How about disabling TX/RX checksum offloading as well as TSO? [...] > > I then restarted the interface (nfe down/up, route restart) > > From dmesg at the time (slight obfuscated) > Sep 3 07:10:19 manch2 bgpd[89612]: neighbor XX: received notification: HoldTimer expired, unknown subcode 0 > Sep 3 07:10:49 manch2 bgpd[89612]: neighbor XX connect: Host is down > # at this point I took the interface down & up and reloaded the routing tables > Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN > Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN > Sep 3 07:12:07 manch2 kernel: nfe0: link state changed to DOWN > Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN > Sep 3 07:12:11 manch2 kernel: nfe0: link state changed to UP > Sep 3 07:12:11 manch2 kernel: carp0: link state changed to DOWN > Sep 3 07:12:14 manch2 kernel: carp0: link state changed to UP Hmm, it does not look right, carp0 showed link DOWN message four times in a row. By the way, are you using IPMI on MCP55? nfe(4) is not ready to handle MAC operation with IPMI. From owner-freebsd-net@FreeBSD.ORG Sat Sep 4 06:38:36 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D881010656BA for ; Sat, 4 Sep 2010 06:38:36 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay1.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 41CA58FC16 for ; Sat, 4 Sep 2010 06:38:35 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id o846cYVv058286 for ; Sat, 4 Sep 2010 09:38:34 +0300 (EEST) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id o846cWWC058285 for freebsd-net@freebsd.org; Sat, 4 Sep 2010 09:38:32 +0300 (EEST) Date: Sat, 4 Sep 2010 09:38:32 +0300 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20100904063832.GA26594@relay.ibs.dn.ua> References: <20100903180156.GA20682@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20100903180156.GA20682@relay.ibs.dn.ua> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: mac address cleaning ignored ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus.panchenko@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 06:38:36 -0000 cold reboot of box A helped ... why only cold? :( -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Sat Sep 4 09:30:27 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6FB10656D8; Sat, 4 Sep 2010 09:30:27 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 010758FC19; Sat, 4 Sep 2010 09:30:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o849UQ1U058059; Sat, 4 Sep 2010 09:30:26 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o849UQCO058049; Sat, 4 Sep 2010 09:30:26 GMT (envelope-from vwe) Date: Sat, 4 Sep 2010 09:30:26 GMT Message-Id: <201009040930.o849UQCO058049@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/150257: [msk] watchdog timeout 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, 04 Sep 2010 09:30:27 -0000 Old Synopsis: msk watchdog timeout New Synopsis: [msk] watchdog timeout Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sat Sep 4 09:29:35 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150257 From owner-freebsd-net@FreeBSD.ORG Sat Sep 4 16:06:12 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73D0510656A8 for ; Sat, 4 Sep 2010 16:06:12 +0000 (UTC) (envelope-from FreeBSD@insightbb.com) Received: from mxsf11.insightbb.com (mxsf11.insightbb.com [74.128.0.93]) by mx1.freebsd.org (Postfix) with ESMTP id 43FDA8FC08 for ; Sat, 4 Sep 2010 16:06:11 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.56,318,1280721600"; d="scan'208";a="196032923" Received: from unknown (HELO asav00.insightbb.com) ([172.31.249.123]) by mxsf11.insightbb.com with ESMTP; 04 Sep 2010 11:37:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aqc8AD8EgkxKgCiCPGdsb2JhbACEE4NWjAkBAY0nDAEBAQE1Lbp+hT0E X-IronPort-AV: E=Sophos;i="4.56,318,1280721600"; d="scan'208";a="41738655" Received: from 74-128-40-130.dhcp.insightbb.com (HELO laptop2.stevenfriedrich.org) ([74.128.40.130]) by asavout00.insightbb.com with ESMTP; 04 Sep 2010 11:37:32 -0400 To: freebsd-net@freebsd.org From: Steven Friedrich Date: Sat, 4 Sep 2010 11:37:30 -0400 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009041137.31219.FreeBSD@insightbb.com> Subject: New bwn driver 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, 04 Sep 2010 16:06:12 -0000 I have an HP pavilion zd825us which has a Broadcom ethernet that appears to be supported by the new bwn driver. I have, for several years now, been using the NDIS driver based on Project Evil. Since bwn came out in 8.1, I tried it and it pretty much works but I get a couple errors sporadically. Here are the dmesgs: Aug 21 11:39:29 laptop2 kernel: siba_bwn0: mem 0xc8206000-0xc8207fff irq 17 at device 3.0 on pci11 Aug 21 11:39:29 laptop2 kernel: bwn0 on siba_bwn0 Aug 21 11:39:29 laptop2 kernel: bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO (manuf 0x17f ver 0x2050 rev 8) Aug 21 11:39:29 laptop2 kernel: bwn0: DMA (32 bits) Aug 21 11:39:29 laptop2 kernel: bwn0: [FILTER] Aug 21 11:39:29 laptop2 kernel: bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) Aug 21 11:39:29 laptop2 kernel: bwn0: need multicast update callback Aug 20 17:01:37 laptop2 kernel: bwn0: RX decryption attempted (old 0 keyidx 0x2) Occasionally, a message appears on the console indicating that mDNSResponder had an issue: Aug 20 19:45:42 laptop2 mDNSResponder: mDNSPlatformSendUDP got error 51 (Network is unreachable) sending packet to 224.0.0.251 on interface 127.0.0.1/lo0/2 Aug 21 11:39:56 laptop2 mDNSResponder: mDNSResponder (Engineering Build) (Aug 4 2010 09:50:01) starting And when I use the NDIS driver, I see this lock not held... Aug 21 11:39:56 laptop2 mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0) From owner-freebsd-net@FreeBSD.ORG Sat Sep 4 19:23:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DEC2106567A for ; Sat, 4 Sep 2010 19:23:37 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 240A48FC12 for ; Sat, 4 Sep 2010 19:23:36 +0000 (UTC) Received: by vws7 with SMTP id 7so2548001vws.13 for ; Sat, 04 Sep 2010 12:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=WF25H/Jt/QycxBJyHHKGnI7MBpQd3vYHsx6MkrkPMPM=; b=EdwnnL/5/B4p5yNO5miwS0rFf9SG0cZcwAqKNJTXp7fMhtwx8JILlcrEHtcJH4yTuc pYbloQftfAYuUU9YiliiG6Tg9iO8vweDTG8/cyBz9WkXkrjgPlVjgRwPPQm6WMWwUb9p btmvX/Eh8O4Cjzij4OEy9Nlc7nyvBS9kXDoCA= 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=FbFKnKJ1ZmWeFNVSrjohemvR7JpDRbER2E/RxrhD6x7Lb0ZEiJACoPwnmWcIDMMu5z 4vGoEIkv88W0YWHrmn37akKlg4oHLoO7+dBxHFcml0JE7A6iAxukvP7MTN9/hNl6OTkX EmxDuK1eAZlbs1RNTxGxr1WB2Nz25odfPKpYQ= MIME-Version: 1.0 Received: by 10.220.61.199 with SMTP id u7mr857959vch.0.1283626787596; Sat, 04 Sep 2010 11:59:47 -0700 (PDT) Received: by 10.220.192.194 with HTTP; Sat, 4 Sep 2010 11:59:47 -0700 (PDT) In-Reply-To: <03D4AA6F-2851-45EF-8A2D-C368917FBD11@ntop.org> References: <03D4AA6F-2851-45EF-8A2D-C368917FBD11@ntop.org> Date: Sat, 4 Sep 2010 14:59:47 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Fwd: [Ntop-misc] [Announce] 10 Gbit Hardware Packet Filtering Using Commodity Network Adapters 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, 04 Sep 2010 19:23:37 -0000 fyi for possible porters... ---------- Forwarded message ---------- From: Luca Deri Date: Sep 4, 2010 8:17 AM Subject: [Ntop-misc] [Announce] 10 Gbit Hardware Packet Filtering Using Commodity Network Adapters To: ntop@unipi.it, ntop-misc@listgateway.unipi.it The promise of filtering packets in hardware is not new. Unfortunately filtering network adapters are pretty expensive, not to mention if they run at 10 Gbit. Furthermore many commercial FPGA-based NICs feature hardware packet filtering, but often require card reconfiguration whenever flow rules are added/removed and have a limited set of rules that can be configured. The release of Intel X520, the first NIC based on the 82599-controller, has triggered my interest as this controller is much more powerful than what Linux can do with it. Thanks to support from Intel and in particular Joseph Gasparakis of Intel Shannon, I have jointly developed an extension to the ixgbe driver (used to drive 82599-based NICs) for adding hardware packet filtering support. Thanks to this work, users can specify up to 32K (yes thirty-two thousand) filters that can be added on the fly without any hardware reconfiguration. And if you want the cherry on top, the cost per port of X520 is well below 1000$. So you now have no reason for not jumping on the 10 Gbit wagon. The enhanced driver is released free of charge as part of the PF_RING distribution (inside PF_RING/drivers/intel). If you also want packet capture acceleration in addition to hardware filtering you can use TNAPI that now supports hardware packet filtering too. You can find more information about this work at this page: http://www.ntop.org/blog/?p=192 Enjoy Luca --- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan _______________________________________________ Ntop-misc mailing list Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc From owner-freebsd-net@FreeBSD.ORG Sat Sep 4 21:22:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60F3210656C9; Sat, 4 Sep 2010 21:22:00 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 360CE8FC1E; Sat, 4 Sep 2010 21:22:00 +0000 (UTC) Received: from [192.168.2.105] (host81-159-163-98.range81-159.btcentralplus.com [81.159.163.98]) by cyrus.watson.org (Postfix) with ESMTPSA id 0FBB946B35; Sat, 4 Sep 2010 17:21:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4C7D02BB.40300@freebsd.org> Date: Sat, 4 Sep 2010 22:21:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A1BD1ED-B55D-43A5-8D91-DD243A48F1AE@freebsd.org> References: <4C7A7B25.9040300@freebsd.org> <7B42D7FB-B782-4EE9-8813-BF7D3ED3274B@lurchi.franken.de> <4C7D02BB.40300@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1081) Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , freebsd-net@freebsd.org Subject: Re: Removal of deprecated implied connect for TCP 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, 04 Sep 2010 21:22:00 -0000 On 31 Aug 2010, at 14:25, Andre Oppermann wrote: >>> I'm not entirely comfortable with this change, and would like a = chance to cogitate on it a bit >>> more. While I'm not aware of any applications depending on the = semantic for TCP, I know that >>> we do use it for UNIX domain sockets. Since it's a documented API, = if we are going to remove >>> it, then we need to go through a deprecation process, not least by = marking it as a deprecated >>> API in 8.x before having it vanish in 9.0. > > >> sendto() is also used for SCTP SOCK_STREAMS and SOCK_SEQPACKET = sockets... >=20 > sendto() will not be touched or modified. It's just that on a TCP = socket > the tcp protocol will not perform an implied connect anymore. The = only thing > that changes is TCP dropping a deprecated and experimental extension = and > behaving like every other UNIXy OS. >=20 > sendto() will continue to work for UDP, SCTP and Domain sockets and = whoever > else currently supports it, except TCP. Right -- I think you're missing the thrust of this objection: it's a = standard part of the FreeBSD API that sendto(2) with an address = implicitly connects across all over our protocols, so making TCP be the = only exception seems counter-productive. What is it that will actually = be accomplished by removing this functionality, other than reducing the = number of lines of code in tcp_usr_send by a couple of dozen? Robert=