From owner-freebsd-net@FreeBSD.ORG Sun Jun 14 04:28:51 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46734106566C for ; Sun, 14 Jun 2009 04:28:51 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mx.npubs.com (mail.npubs.com [94.75.203.100]) by mx1.freebsd.org (Postfix) with ESMTP id C74ED8FC0A for ; Sun, 14 Jun 2009 04:28:50 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mx.npubs.com (avhost [94.75.203.103]) by mx.npubs.com (Postfix) with ESMTP id BCD2617057C for ; Sun, 14 Jun 2009 03:59:00 +0000 (UTC) Received: from sqlserver1 (unknown [74.82.45.12]) by mx.npubs.com (Postfix) with ESMTP id A057517056D for ; Sun, 14 Jun 2009 03:58:59 +0000 (UTC) From: Stef Walter User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" Content-Type: multipart/mixed; boundary="------------080508060506040100070903" Message-Id: <20090614035859.A057517056D@mx.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Sun, 14 Jun 2009 03:59:00 +0000 (UTC) Subject: 32 bit compatibility for getifaddrs() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 04:28:51 -0000 This is a multi-part message in MIME format. --------------080508060506040100070903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've started running 64-bit FreeBSD (version 7.2) in production. I have a lot of old 6.3 32-bit jails I need to run as is for now. One problem I ran into is 32-bit getifaddrs() would crash accessing a 64-bit kernel via the sysctl NET_RT_IFLIST method. Attached is a patch that adds 32-bit compatibility to the rtsock.c route messages. Who would I work with to get this (or something like it) committed? Cheers, Stef --------------080508060506040100070903 Content-Type: text/x-diff; name="getifaddrs-rtsock-compat32.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="getifaddrs-rtsock-compat32.patch" --- sys/net/rtsock.c.orig 2009-06-13 19:51:29.000000000 +0000 +++ sys/net/rtsock.c 2009-06-13 20:44:35.000000000 +0000 @@ -1199,6 +1199,251 @@ netisr_queue(NETISR_ROUTE, m); /* mbuf is free'd on failure. */ } +#ifdef SCTL_MASK32 + +/* 32-bit structure definitions */ +struct timeval32 { + int32_t tv_sec; + int32_t tv_usec; +}; + +struct if_data32 { + u_int8_t ifi_type; + u_int8_t ifi_physical; + u_int8_t ifi_addrlen; + u_int8_t ifi_hdrlen; + u_int8_t ifi_link_state; + u_int8_t ifi_recvquota; + u_int8_t ifi_xmitquota; + u_int8_t ifi_datalen; + u_int32_t ifi_mtu; + u_int32_t ifi_metric; + u_int32_t ifi_baudrate; + u_int32_t ifi_ipackets; + u_int32_t ifi_ierrors; + u_int32_t ifi_opackets; + u_int32_t ifi_oerrors; + u_int32_t ifi_collisions; + u_int32_t ifi_ibytes; + u_int32_t ifi_obytes; + u_int32_t ifi_imcasts; + u_int32_t ifi_omcasts; + u_int32_t ifi_iqdrops; + u_int32_t ifi_noproto; + u_int32_t ifi_hwassist; + int32_t ifi_epoch; + struct timeval32 ifi_lastchange; +}; + +struct rt_metrics32 { + u_int32_t rmx_locks; + u_int32_t rmx_mtu; + u_int32_t rmx_hopcount; + u_int32_t rmx_expire; + u_int32_t rmx_recvpipe; + u_int32_t rmx_sendpipe; + u_int32_t rmx_ssthresh; + u_int32_t rmx_rtt; + u_int32_t rmx_rttvar; + u_int32_t rmx_pksent; + u_int32_t rmx_filler[4]; +}; + +struct rt_msghdr32 { + u_int16_t rtm_msglen; + u_int8_t rtm_version; + u_int8_t rtm_type; + u_int16_t rtm_index; + int32_t rtm_flags; + int32_t rtm_addrs; + int32_t rtm_pid; + int32_t rtm_seq; + int32_t rtm_errno; + int32_t rtm_fmask; + u_int32_t rtm_inits; + struct rt_metrics32 rtm_rmx; +}; + +struct if_msghdr32 { + u_int16_t ifm_msglen; + u_int8_t ifm_version; + u_int8_t ifm_type; + int32_t ifm_addrs; + int32_t ifm_flags; + u_int16_t ifm_index; + struct if_data32 ifm_data; +}; + +struct ifa_msghdr32 { + u_int16_t ifam_msglen; + u_int8_t ifam_version; + u_int8_t ifam_type; + int32_t ifam_addrs; + int32_t ifam_flags; + u_int16_t ifam_index; + int32_t ifam_metric; +}; + +struct ifma_msghdr32 { + u_int16_t ifmam_msglen; + u_int8_t ifmam_version; + u_int8_t ifmam_type; + int32_t ifmam_addrs; + int32_t ifmam_flags; + u_int16_t ifmam_index; +}; + +struct if_announcemsghdr32 { + u_int16_t ifan_msglen; + u_int8_t ifan_version; + u_int8_t ifan_type; + u_int16_t ifan_index; + char ifan_name[IFNAMSIZ]; + u_int16_t ifan_what; +}; + +#endif + +/* + * Output route message to sysctl for 64 or 32-bit + */ +static int +rt_sysctl_out(struct sysctl_req *req, const void *data, size_t len) +{ + const struct rt_msghdr *rtm = data; + int error; + +#ifdef SCTL_MASK32 + if (req->flags & SCTL_MASK32) { + switch (rtm->rtm_type) { + case RTM_IFINFO: + { + const struct if_msghdr *ifm = data; + struct if_msghdr32 ifm32; + data = ((const u_char*)data) + sizeof (*ifm); + len -= sizeof (*ifm); + ifm32.ifm_msglen = sizeof (ifm32) + len; + ifm32.ifm_version = ifm->ifm_version; + ifm32.ifm_type = ifm->ifm_type; + ifm32.ifm_addrs = ifm->ifm_addrs; + ifm32.ifm_flags = ifm->ifm_flags; + ifm32.ifm_index = ifm->ifm_index; + ifm32.ifm_data.ifi_type = ifm->ifm_data.ifi_type; + ifm32.ifm_data.ifi_physical = ifm->ifm_data.ifi_physical; + ifm32.ifm_data.ifi_addrlen = ifm->ifm_data.ifi_addrlen; + ifm32.ifm_data.ifi_hdrlen = ifm->ifm_data.ifi_hdrlen; + ifm32.ifm_data.ifi_link_state = ifm->ifm_data.ifi_link_state; + ifm32.ifm_data.ifi_recvquota = 0; + ifm32.ifm_data.ifi_xmitquota = 0; + ifm32.ifm_data.ifi_datalen = ifm->ifm_data.ifi_datalen; + ifm32.ifm_data.ifi_mtu = ifm->ifm_data.ifi_mtu; + ifm32.ifm_data.ifi_metric = ifm->ifm_data.ifi_metric; + ifm32.ifm_data.ifi_baudrate = ifm->ifm_data.ifi_baudrate; + ifm32.ifm_data.ifi_ipackets = ifm->ifm_data.ifi_ipackets; + ifm32.ifm_data.ifi_ierrors = ifm->ifm_data.ifi_ierrors; + ifm32.ifm_data.ifi_opackets = ifm->ifm_data.ifi_opackets; + ifm32.ifm_data.ifi_oerrors = ifm->ifm_data.ifi_oerrors; + ifm32.ifm_data.ifi_collisions = ifm->ifm_data.ifi_collisions; + ifm32.ifm_data.ifi_ibytes = ifm->ifm_data.ifi_ibytes; + ifm32.ifm_data.ifi_obytes = ifm->ifm_data.ifi_obytes; + ifm32.ifm_data.ifi_imcasts = ifm->ifm_data.ifi_imcasts; + ifm32.ifm_data.ifi_omcasts = ifm->ifm_data.ifi_omcasts; + ifm32.ifm_data.ifi_iqdrops = ifm->ifm_data.ifi_iqdrops; + ifm32.ifm_data.ifi_noproto = ifm->ifm_data.ifi_noproto; + ifm32.ifm_data.ifi_hwassist = ifm->ifm_data.ifi_hwassist; + ifm32.ifm_data.ifi_epoch = ifm->ifm_data.ifi_epoch; + ifm32.ifm_data.ifi_lastchange.tv_sec = ifm->ifm_data.ifi_lastchange.tv_sec; + ifm32.ifm_data.ifi_lastchange.tv_usec = ifm->ifm_data.ifi_lastchange.tv_usec; + error = SYSCTL_OUT(req, &ifm32, sizeof (ifm32)); + break; + } + case RTM_NEWADDR: + case RTM_DELADDR: + { + const struct ifa_msghdr *ifam = data; + struct ifa_msghdr32 ifam32; + data = ((const u_char*)data) + sizeof (*ifam); + len -= sizeof (*ifam); + ifam32.ifam_msglen = sizeof (ifam32) + len; + ifam32.ifam_version = ifam->ifam_version; + ifam32.ifam_type = ifam->ifam_type; + ifam32.ifam_addrs = ifam->ifam_addrs; + ifam32.ifam_flags = ifam->ifam_flags; + ifam32.ifam_index = ifam->ifam_index; + ifam32.ifam_metric = ifam->ifam_metric; + error = SYSCTL_OUT(req, &ifam32, sizeof (ifam32)); + break; + } + case RTM_NEWMADDR: + case RTM_DELMADDR: + { + const struct ifma_msghdr *ifmam = data; + struct ifma_msghdr32 ifmam32; + data = ((const u_char*)data) + sizeof (*ifmam); + len -= sizeof (*ifmam); + ifmam32.ifmam_msglen = sizeof (ifmam32) + len; + ifmam32.ifmam_version = ifmam->ifmam_version; + ifmam32.ifmam_type = ifmam->ifmam_type; + ifmam32.ifmam_addrs = ifmam->ifmam_addrs; + ifmam32.ifmam_flags = ifmam->ifmam_flags; + ifmam32.ifmam_index = ifmam->ifmam_index; + error = SYSCTL_OUT(req, &ifmam32, sizeof (ifmam32)); + break; + } + case RTM_IFANNOUNCE: + { + const struct if_announcemsghdr *ifan = data; + struct if_announcemsghdr32 ifan32; + data = ((const u_char*)data) + sizeof (*ifan); + len -= sizeof (*ifan); + ifan32.ifan_msglen = sizeof (ifan32) + len; + ifan32.ifan_version = ifan->ifan_version; + ifan32.ifan_type = ifan->ifan_type; + ifan32.ifan_index = ifan->ifan_index; + bcopy(&ifan->ifan_name, &ifan32.ifan_name, sizeof (ifan32.ifan_name)); + ifan32.ifan_what = ifan->ifan_what; + error = SYSCTL_OUT(req, &ifan32, sizeof (ifan32)); + break; + } + default: + { + struct rt_msghdr32 rtm32; + data = ((const u_char*)data) + sizeof (*rtm); + len -= sizeof (*rtm); + rtm32.rtm_msglen = sizeof (rtm32) + len; + rtm32.rtm_version = rtm->rtm_version; + rtm32.rtm_type = rtm->rtm_type; + rtm32.rtm_index = rtm->rtm_index; + rtm32.rtm_flags = rtm->rtm_flags; + rtm32.rtm_addrs = rtm->rtm_addrs; + rtm32.rtm_pid = rtm->rtm_pid; + rtm32.rtm_seq = rtm->rtm_seq; + rtm32.rtm_errno = rtm->rtm_errno; + rtm32.rtm_use = rtm->rtm_use; + rtm32.rtm_inits = rtm->rtm_inits; + rtm32.rtm_rmx.rmx_locks = rtm->rtm_rmx.rmx_locks; + rtm32.rtm_rmx.rmx_mtu = rtm->rtm_rmx.rmx_mtu; + rtm32.rtm_rmx.rmx_hopcount = rtm->rtm_rmx.rmx_hopcount; + rtm32.rtm_rmx.rmx_expire = rtm->rtm_rmx.rmx_expire; + rtm32.rtm_rmx.rmx_recvpipe = rtm->rtm_rmx.rmx_recvpipe; + rtm32.rtm_rmx.rmx_sendpipe = rtm->rtm_rmx.rmx_sendpipe; + rtm32.rtm_rmx.rmx_ssthresh = rtm->rtm_rmx.rmx_ssthresh; + rtm32.rtm_rmx.rmx_rtt = rtm->rtm_rmx.rmx_rtt; + rtm32.rtm_rmx.rmx_rttvar = rtm->rtm_rmx.rmx_rttvar; + rtm32.rtm_rmx.rmx_pksent = rtm->rtm_rmx.rmx_pksent; + error = SYSCTL_OUT(req, &rtm32, sizeof (rtm32)); + break; + } + } + + if (error) + return error; + } +#endif /* SCTL_MASK32 */ + error = SYSCTL_OUT(req, data, len); + return error; +} + /* * This is used in dumping the kernel table via sysctl(). */ @@ -1237,7 +1482,7 @@ rtm->rtm_index = rt->rt_ifp->if_index; rtm->rtm_errno = rtm->rtm_pid = rtm->rtm_seq = 0; rtm->rtm_addrs = info.rti_addrs; - error = SYSCTL_OUT(w->w_req, (caddr_t)rtm, size); + error = rt_sysctl_out(w->w_req, (caddr_t)rtm, size); return (error); } return (error); @@ -1268,7 +1513,7 @@ ifm->ifm_flags = ifp->if_flags | ifp->if_drv_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = info.rti_addrs; - error = SYSCTL_OUT(w->w_req,(caddr_t)ifm, len); + error = rt_sysctl_out(w->w_req,(caddr_t)ifm, len); if (error) goto done; } @@ -1290,7 +1535,7 @@ ifam->ifam_flags = ifa->ifa_flags; ifam->ifam_metric = ifa->ifa_metric; ifam->ifam_addrs = info.rti_addrs; - error = SYSCTL_OUT(w->w_req, w->w_tmem, len); + error = rt_sysctl_out(w->w_req, w->w_tmem, len); if (error) goto done; } @@ -1338,7 +1583,7 @@ ifmam->ifmam_index = ifma->ifma_ifp->if_index; ifmam->ifmam_flags = 0; ifmam->ifmam_addrs = info.rti_addrs; - error = SYSCTL_OUT(w->w_req, w->w_tmem, len); + error = rt_sysctl_out(w->w_req, w->w_tmem, len); if (error) { IF_ADDR_UNLOCK(ifp); goto done; --------------080508060506040100070903-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 14 08:50:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98BA1106566B for ; Sun, 14 Jun 2009 08:50:22 +0000 (UTC) (envelope-from marco.borsatino@poste.it) Received: from relay-pt1.poste.it (relay-pt1.poste.it [62.241.4.164]) by mx1.freebsd.org (Postfix) with ESMTP id 579FA8FC14 for ; Sun, 14 Jun 2009 08:50:22 +0000 (UTC) (envelope-from marco.borsatino@poste.it) Received: from poste.it (192.168.44.50) by relay-pt1.poste.it (7.3.122) id 4A343DCF00001343 for freebsd-net@freebsd.org; Sun, 14 Jun 2009 10:29:22 +0200 Date: Sun, 14 Jun 2009 10:29:21 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 From: "marco\.borsatino\@poste\.it" To: freebsd-net@freebsd.org X-XaM3-API-Version: 5.0(R1) X-SenderIP: 79.30.227.228 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NFS - exports syntax X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 08:50:22 -0000 Hi to all.=0AMy problem concerns NFS configuration. I'm trying to simulat= e a little network using Sun VirtualBox in a Windows host and most of ope= rations work fine, but I've some problems with /etc/exports syntax.=0AThi= s is my current exports file:=0A--=0A/cond1 /cond2 -mapall=3Duser1 pc01 p= c02=0A/usr/home -alldirs pc01 pc02=0A---=0AWhen I type:=0A#showmount -e=0A= I get=0A/usr/home=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 pc02 pc02=0A= /cond1=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc01 pc02=0A= /cond2=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc01 pc02=0A= which is ok. But I wold like to use different "mapall" options for differ= ent filesystems; for example, something like this:=0A/usr/home -alldirs=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc02 pc02=0A/cond1 -mapall=3Duser2 /co= nd2 -mapall=3Duser1 pc01 pc02=0Awhich does not work: only /usr/home is ex= ported. Or=0A/usr/home=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc02 pc02=0A/= cond1 -mapall=3Duser2 pc01 pc02=0A/cond2 -mapall=3Duser1 pc01 pc02=0AOnly= /usr/home and /cond1 are exported.=0AFreeBSD exports man page states:=0A= "Each line in the file (other than comment lines that begin with a #) spe= cifies the mount point(s) and export flags within one local server file s= ystem for one or more hosts.". So, is it impossible to export different d= irectories to different users using mapping?=0AThanks. Sorry for my bad e= nglish.=0AMarco=0A From owner-freebsd-net@FreeBSD.ORG Sun Jun 14 18:20:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58D441065676 for ; Sun, 14 Jun 2009 18:20:34 +0000 (UTC) (envelope-from prvs=1409b8d12a=brian@Awfulhak.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id B15B98FC0A for ; Sun, 14 Jun 2009 18:20:32 +0000 (UTC) (envelope-from prvs=1409b8d12a=brian@Awfulhak.org) Received: from pd7ml2no-ssvc.prod.shaw.ca ([10.0.153.162]) by pd5mo1no-svcs.prod.shaw.ca with ESMTP; 14 Jun 2009 11:52:38 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=k78ZXbaa_ND9M4scsLIA:9 a=S5MntBbpyKNdlwdx6NChBOOLUzcA:4 a=WJ3hkfHDukgA:10 a=SV7veod9ZcQA:10 Received: from unknown (HELO store.lan.Awfulhak.org) ([174.7.23.140]) by pd7ml2no-dmz.prod.shaw.ca with ESMTP; 14 Jun 2009 11:52:38 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 45F5FC433AC_A353908B; Sun, 14 Jun 2009 17:53:12 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id A61A6C460FC_A3538FBF; Sun, 14 Jun 2009 17:52:59 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n5EHqNNr002957; Sun, 14 Jun 2009 10:52:24 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Sun, 14 Jun 2009 10:52:23 -0700 From: Brian Somers To: "marco\.borsatino\@poste\.it" Message-ID: <20090614105223.4f859708@dev.lan.Awfulhak.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: NFS - exports syntax X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 18:20:35 -0000 On Sun, 14 Jun 2009 10:29:21 +0200 "marco\.borsatino\@poste\.it" wrote: > Hi to all. > My problem concerns NFS configuration. I'm trying to simulate a little ne= twork using Sun VirtualBox in a Windows host and most of operations work fi= ne, but I've some problems with /etc/exports syntax. > This is my current exports file: > -- > /cond1 /cond2 -mapall=3Duser1 pc01 pc02 > /usr/home -alldirs pc01 pc02 > --- > When I type: > #showmount -e > I get > /usr/home=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 pc02 pc02 > /cond1=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc01 pc02 > /cond2=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc01 pc02 > which is ok. But I wold like to use different "mapall" options for differ= ent filesystems; for example, something like this: > /usr/home -alldirs=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc02 pc02 > /cond1 -mapall=3Duser2 /cond2 -mapall=3Duser1 pc01 pc02 > which does not work: only /usr/home is exported. Or > /usr/home=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc02 pc02 > /cond1 -mapall=3Duser2 pc01 pc02 > /cond2 -mapall=3Duser1 pc01 pc02 > Only /usr/home and /cond1 are exported. > FreeBSD exports man page states: > "Each line in the file (other than comment lines that begin with a #) spe= cifies the mount point(s) and export flags within one local server file sys= tem for one or more hosts.". So, is it impossible to export different direc= tories to different users using mapping? > Thanks. Sorry for my bad english. > Marco FreeBSD's exports implementation will only allow you to associate mount options per local filesystem per remote machine, so this version: > /usr/home=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc02 pc02 > /cond1 -mapall=3Duser2 pc01 pc02 > /cond2 -mapall=3Duser1 pc01 pc02 is correct, but only if /cond1 and /cond2 are different filesystems. If they're the same, this won't work. Maybe you do something clever with exporting nullfs versions of them and adding those to exports, but I haven't tried that. --=20 Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Mon Jun 15 07:44:17 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18460106564A for ; Mon, 15 Jun 2009 07:44:17 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: from web8320.mail.in.yahoo.com (web8320.mail.in.yahoo.com [202.43.219.75]) by mx1.freebsd.org (Postfix) with SMTP id E28858FC08 for ; Mon, 15 Jun 2009 07:44:15 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: (qmail 81898 invoked by uid 60001); 15 Jun 2009 07:44:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1245051853; bh=wjpb/LFXMaKSy269MqpL9zGR6M6+Ii98YRyzhGTgHKo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Z4caUA4ZhrAPghq59uPC0uy5wBRYTdY6z9B/JX05wtGUSFTVHAdC13psc99bCa+qkRiiXJxcYb13I3L5quGYGB3zLt1FjQyU/J1nokHg/N8FXo38qnbo1SI4XKmfBU3zyV1zYEuxQSnf4rn4hKS/95buTsX3UZuJt8opRpHRGi4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=dft1IXrAFz59phK8D/NW6fe1iiz/5YRPXwoOx1gViH2obpIIHHC7yM+qUJYhuDroIBDZFR4X+inpB4FFSUfD6tRf/kWkB32gzUNiFZopsERIG7jq4FEuC6hH8ErOAZnNacvT5VC/vQ3b4WOGIQsZk0EvnChs12p/n6rQ2uEq4Fc=; Message-ID: <882612.80583.qm@web8320.mail.in.yahoo.com> X-YMail-OSG: 9.GCwRkVM1lutkOQfuP9kSfIaPgQJT4Zyoo2.B2qh4fXJyDOdJcwDNdgLDBfuTt4eBjdprhG8.DiuSTDs6BiZP4xojSzaF7TUaqf.gcnrbm7V59YQEc.EIGtazeIRJ6onGLelHhaTjxdZJJx0aTVRWaifbIGkr_fJsTm4lr1WbmhPlj.zcTVpApIxjvzFO6aB6PxspE4zXrbrzvG7Kj0aqLinPdQC1Qp3_Oq4z1_eD1ljZIBHw-- Received: from [125.22.253.101] by web8320.mail.in.yahoo.com via HTTP; Mon, 15 Jun 2009 13:14:13 IST X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Mon, 15 Jun 2009 13:14:13 +0530 (IST) From: saravana perumal To: Louis Mamakos MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Subject: Re: TCP Free-BSD setup behaviour. 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, 15 Jun 2009 07:44:17 -0000 Hi Louie , =A0 =A0 Thanks for the Response on my Queries. =A0 For QUERY 3,=20 ACTIVE open frm Free BSD end: =A0 =A0=A0=A0=A0=A0=A0 FREE BSD=A0=A0=A0=A0=A0=A0=A0=A0=A0 APPLICATION =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Send ---------> syn =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Receive <-------- SYN =A0 Expect SYN & ACK-------------> Getting only ACK in this Scenario, =A0Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sen= ding only ACK message as the response. 4=A0=A0=A0 .When checking the State - TIME-WAIT=A0=A0=A0=A0Sending FIN and = expecting the ACK ;Getting the ACK properly.=A0=A0=A0Sending Data Segment a= nd Expecting the RST signal not getting the RST ; Instead DUT is sending th= e Last TCP packet.=A0Issue seen only in Free BSD =A0 =A0 For this Issue mentioned above, Last TCP packet is jst a Testing packet wit= h the=20 following Field set=A0 in TIME-WAIT state , =A0 =A0 TCP: ---- TCP Packet ---- TCP: TCP: Source Port=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 16815 (16815) TCP: Destination Port=A0=A0=A0=A0=A0 =3D 16816 (16816) TCP: Sequence Number=A0=A0=A0=A0=A0=A0 =3D 3865716731 (0xE66A27FB) TCP: Acknowledgment Number =3D 0 (0x00000000)=20 TCP: Data Offset=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 5 (20 bytes) TCP: Reserved=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0=20 TCP: Control Bits=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0x10 TCP:=A0 |543210 TCP:=A0 |0.....=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D Urgent Pointer I= sn't Significant TCP:=A0 |.1....=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D Acknowledgment I= s Significant TCP:=A0 |..0...=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D No Push Function TCP:=A0 |...0..=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D No Reset Connect= ion TCP:=A0 |....0.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D No Synchronize S= equence Numbers TCP:=A0 |.....0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D More Data From S= ender TCP: Window=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 32752 bytes TCP: Checksum=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0x41A0 (Correct) TCP: Urgent Pointer=A0=A0=A0=A0=A0=A0=A0 =3D 0 (Not Significant) TCP: TCP: --- Trailing Data [12 bytes] --- TCP:=A0 53 61 6D 70 6C 65 20 44 61 74 61 00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Sample Data. TCP: --- Trailing Data End --- >From machine Sending=A0 to the FREE BSD machine, =A0 This is to verify that Free BSD is in TIME-WAIT state. =A0 =A0 Thanks, Saravanan --- On Sat, 6/13/09, Louis Mamakos wrote: From: Louis Mamakos Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Date: Saturday, June 13, 2009, 10:54 PM On Jun 10, 2009, at 9:47 AM, saravana perumal wrote: >=A0 Hi , >=20 >=A0=A0=A0Have some behaviour change=A0 with FREEBSD=A0 compared to=A0 LINU= X . You probably ought to verify the behavior against the protocol specificatio= ns, and not what some other TCP implementation happens to to. >=20 > 1. When sending the Same=A0 TCP packet once again [ Retranmission of TCP = packet ] Whether the Same Identification field [ IP packet]used or not . > but when seeing that thru packet capture, Free BSD sending the differnt o= ne [ increases sequentially IP Identification] The IPID header field is used for reassembly of IP fragments, and is not of= consequence to TCP.=A0 If the protocol stack absolutely knows that a TCP r= etransmission is identical to the previous segment, then in theory, it coul= d use the same IPID fields to increase the chance that a previously fragmen= ted TCP segment with a lost segment could get reassembled with fragments fr= om the retransmission.=A0 Since there's much work done to avoid fragmentati= on in the first place (e.g., using Path MTU discovery), this "feature" prob= ably never gets used. This behavior makes more sense if the TCP implementation keeps around a ret= ransmit queue of previously sent packets, rather than simply generating new= TCP segments with whatever data happens to be in the TCP send window at th= e time of the retransmission attempt. >=20 > 2.Retranmission Time is not increasing Linearly with Respect to BSD. not = keeping more time interval . AS per RFC > expecting Retransmission timeout should=A0 increase Linearly. Issue is no= t seen with Linux Setup Retransmission time is highly dependent on many factors, like the implement= ation of TCP slow-start, what the TCP stack has estimated as the round-trip= time, etc.=A0 In the general case, over the span of many retransmissions, = the sending TCP stack should back-off the retransmit times. >=20 > 3. Active SYN open state in FREE BSD setup , Does not reach Syn-received = State. When Sending syn packet to DUT but=A0 for that FreeBSD is not sendin= g back > SYN/ACK .=A0 Issue is with Free BSD Setup.Linux works fine, If the FreeBSD system is doing a TCP active open (e.g., a connect() system = call), then it sends a SYN to the remote TCP, and expects a SYN/ACK back fr= om the remote system.=A0 At that point, since the remote has ACK'd the SYN,= it should correctly respond with simply an ACK of the remote TCP's SYN, an= d perhaps any data that might have been piggybacked in the ACK segment.=A0 = There's no need to retransmit the SYN. Or is the remote system doing the active open to the FreeBSD system?=A0 It'= s hard to believe that the FreeBSD TCP can't respond to an incoming TCP seg= ment to a listening socket carrying a SYN segment? >=20 > 4.When checking the State - TIME-WAIT >=A0=A0=A0Sending FIN and expecting the ACK ;Getting the ACK properly. >=A0=A0=A0Sending Data Segment and Expecting the RST signal not getting the= RST ; Instead DUT is sending the Last TCP packet. >=20 > Issue seen only in Free BSD. I may be misunderstanding.=A0 When in TIME-WAIT state, the local TCP is wai= ting for a bit in case the "final" ACK of the remote TCP's FIN got lost, an= d the remote retransmits the FIN (and perhaps any data that might have been= in the window along with the FIN).=A0 The local TCP shouldn't generate a R= ST assuming that the remote's retransmitted TCP segment is still within the= window.=A0 I'm not sure what's in the "Last TCP packet." >=20 > Same issue in FIN-WAIT2=A0 & FIN-WAIT1 State also . >=A0=A0=A0Sending FIN and Expect the ACK : Getting the ACK >=A0=A0=A0Sending Data segment with Data : Expecting the RST signal from DU= T ; but got Last transmitted TCP packet[ FIN -ACK] >=20 Ditto. > Any idea about the above scenario would be helpful >=20 > Thanks, > Saravanan. The TCP in Linux is hardly the reference implementation; with the TCP stack= in various 4.xBSD varients preceeding it by many years, not to mention man= y others implementations in other platforms.=A0 I'm not sure looking for va= riances between some random Linux TCP stack is really the right way to appr= oach testing. louie =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Mon Jun 15 11:07:00 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5776F106564A for ; Mon, 15 Jun 2009 11:07:00 +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 440C58FC16 for ; Mon, 15 Jun 2009 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5FB70ef077016 for ; Mon, 15 Jun 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5FB6xjf077012 for freebsd-net@FreeBSD.org; Mon, 15 Jun 2009 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jun 2009 11:06:59 GMT Message-Id: <200906151106.n5FB6xjf077012@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, 15 Jun 2009 11:07:00 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 307 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 15 16:46:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A8B1065672 for ; Mon, 15 Jun 2009 16:46:39 +0000 (UTC) (envelope-from marco.borsatino@poste.it) Received: from relay-pt3.poste.it (relay-pt3.poste.it [62.241.4.129]) by mx1.freebsd.org (Postfix) with ESMTP id 274558FC15 for ; Mon, 15 Jun 2009 16:46:38 +0000 (UTC) (envelope-from marco.borsatino@poste.it) Received: from poste.it (192.168.44.18) by relay-pt3.poste.it (7.3.122) id 4A35817000006301; Mon, 15 Jun 2009 18:46:35 +0200 Date: Mon, 15 Jun 2009 18:46:35 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 From: "marco\.borsatino\@poste\.it" To: brian@Awfulhak.org X-XaM3-API-Version: 5.0(R1) X-SenderIP: 79.40.212.138 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: NFS - exports syntax X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 16:46:39 -0000 First, thank you for your help.=0A=0A=0A=0A>=0A> FreeBSD's exports implem= entation will only allow you to associate=0A> mount options per local fil= esystem per remote machine, so this=0A> version:=0A>=0A> > /usr/home=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc02 pc02=0A> > /cond1 -mapall=3Duser2 pc= 01 pc02=0A> > /cond2 -mapall=3Duser1 pc01 pc02=0A>=0A> is correct, but on= ly if /cond1 and /cond2 are different filesystems.=0A> If they're the sam= e, this won't work.=0A> =0A=0A/cond1 and /cond2 are folders under root on= /dev/ad0s1a; this is the reason whi my exports does not work.=0ASo shoul= d I do something like this:=0A#mkdir /usr/shared/cond1=0A#mkdir /usr/shar= ed/cond2=0A(this is, I think, a better choice also from different points = of view).=0A(exports)=0A/usr/shared -alldirs pc01 pc02 (or -network 192.1= 68.0)=0A(mount for different users)=0A#mount _nfs server:/usr/shared/cond= 1 /mnt/for-user-1=0A#mount _nfs server:/usr/shared/cond2 /mnt/for-user-2=0A= =0ABut, if this sintax is correct, how can I use mapall option?=0A=C2=A0=0A= > Maybe you do something clever with exporting nullfs versions=0A> of the= m and adding those to exports, but I haven't tried that.=0A>=0AThis will = be the next step.=0AThank you.=0AMarco From owner-freebsd-net@FreeBSD.ORG Mon Jun 15 21:36:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D2271065675 for ; Mon, 15 Jun 2009 21:36:02 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 351618FC1E for ; Mon, 15 Jun 2009 21:36:02 +0000 (UTC) (envelope-from louie@transsys.com) Received: from PM-G5.transsys.com (c-69-141-150-106.hsd1.nj.comcast.net [69.141.150.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 27E575C04; Mon, 15 Jun 2009 17:36:01 -0400 (EDT) Message-Id: From: Louis Mamakos To: saravana perumal In-Reply-To: <882612.80583.qm@web8320.mail.in.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 17:35:59 -0400 References: <882612.80583.qm@web8320.mail.in.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Subject: Re: TCP Free-BSD setup behaviour. 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, 15 Jun 2009 21:36:02 -0000 On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > Hi Louie , > > > Thanks for the Response on my Queries. > > For QUERY 3, > ACTIVE open frm Free BSD end: > > FREE BSD APPLICATION > Send ---------> syn > Receive <-------- SYN > > Expect SYN & ACK-------------> Getting only ACK in this Scenario, > > Now Expects FREE BSD to respond back with the SYN & ACK , but BSD > is sending only ACK message as the response. There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN. Once the SYN has been ACK'd, there's no reason to resend it. I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? > 4 .When checking the State - TIME-WAIT Sending FIN and > expecting the ACK ;Getting the ACK properly. Sending Data Segment > and Expecting the RST signal not getting the RST ; Instead DUT is > sending the Last TCP packet. Issue seen only in Free BSD > > > For this Issue mentioned above, Last TCP packet is jst a Testing > packet with the > following Field set in TIME-WAIT state , > > > TCP: ---- TCP Packet ---- > TCP: > TCP: Source Port = 16815 (16815) > TCP: Destination Port = 16816 (16816) > TCP: Sequence Number = 3865716731 (0xE66A27FB) > TCP: Acknowledgment Number = 0 (0x00000000) > TCP: Data Offset = 5 (20 bytes) > TCP: Reserved = 0 > TCP: Control Bits = 0x10 > TCP: |543210 > TCP: |0..... = Urgent Pointer Isn't Significant > TCP: |.1.... = Acknowledgment Is Significant > TCP: |..0... = No Push Function > TCP: |...0.. = No Reset Connection > TCP: |....0. = No Synchronize Sequence Numbers > TCP: |.....0 = More Data From Sender > TCP: Window = 32752 bytes > TCP: Checksum = 0x41A0 (Correct) > TCP: Urgent Pointer = 0 (Not Significant) > TCP: > TCP: --- Trailing Data [12 bytes] --- > TCP: 53 61 6D 70 6C 65 20 44 61 74 61 00 Sample Data. > TCP: --- Trailing Data End --- > From machine Sending to the FREE BSD machine, > > This is to verify that Free BSD is in TIME-WAIT state. Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus. Perhaps that the send sequence is outside the window. If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no good reason? louie From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 09:45:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1F041065674 for ; Tue, 16 Jun 2009 09:45:48 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: from web8320.mail.in.yahoo.com (web8320.mail.in.yahoo.com [202.43.219.75]) by mx1.freebsd.org (Postfix) with SMTP id 99B028FC13 for ; Tue, 16 Jun 2009 09:45:47 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: (qmail 70790 invoked by uid 60001); 16 Jun 2009 09:45:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1245145545; bh=2P+InR79MqDo7ZTa9CyeXSL7Gdo4Wp69nqpXs2GlGOg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=253bfwmI3og7FtXr0Ndhf4jSmXU6qL0+99nSYIEuYRv5LYq2y9X4vWWXj7U2ASAsX7vef+qP7VAyMVAj8vUCWWqy11Wg9AGvXuWVoov77eVhrDM+qCNvKT5xBdV0cZHZMOKDuJ7C/T6a0KiPyJVKNVoAn23J8dpG/qK1LW8Y1bI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=tDOSrvC8FQMbiz5MdkNEZfAajnFmXssxqYALarunVKiwW6ljmg2lGaxrPKuh9gRclNmEuBPOpn/x8310lIN/0RZ2s4RL3GcR3SysxFittrQN/jz02G7QDyxEA4UtymFBu653cPInIqDAXtR2YpqY5JnisJKgWyMk6vjL9CDwEeM=; Message-ID: <690988.68233.qm@web8320.mail.in.yahoo.com> X-YMail-OSG: o_N0tKkVM1ljjImxZwDwDlU8.TWSnU58Go21NmyyGQnt2VHBTKl36OgZjUOq1O9l_ROY6.jA6xhGawZBZxXxF6Vcl0sb68yG9yIA_0f7dPLIFZAr6PPFoVABrq4yWGcHnVN9nVaN2SUgRgfhOpWGa7h2wPAUFUCq4NvlfzsN8Uqj2xmsFw1jYYPFk9ZlqD9DNLBwa.SR4JvTK77FiuGiwUrasQ6xAxvPB5rq4wRMgB9yyyLSuQ-- Received: from [125.22.253.101] by web8320.mail.in.yahoo.com via HTTP; Tue, 16 Jun 2009 15:15:45 IST X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Tue, 16 Jun 2009 15:15:45 +0530 (IST) From: saravana perumal To: Louis Mamakos MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Mailer List Subject: Re: TCP Free-BSD setup behaviour. 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, 16 Jun 2009 09:45:49 -0000 Hi Louie =A0 =A0We are trying to make Active Sync Received state. =A0 As per our testing we are trying to received Syn packet from APPLICATION en= d and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-R= ECEIVED state. =A0 So initially make the application to send SYN sending the Initial SYN and o= nce Received the SYN packet , expecting the Device to Send SYN & ACK =A0 I hope the expectation should be rite in case of ACTIVE-SYN received State. =A0 Thanks. Saravanan =A0 --- On Tue, 6/16/09, Louis Mamakos wrote: From: Louis Mamakos Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Date: Tuesday, June 16, 2009, 3:05 AM On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > Hi Louie , >=20 >=20 > Thanks for the Response on my Queries. >=20 > For QUERY 3, > ACTIVE open frm Free BSD end: >=20 >=A0 =A0 =A0 =A0 FREE BSD=A0 =A0 =A0 =A0 =A0 APPLICATION >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Send ---------> syn >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Receive <-------- SYN >=20 > Expect SYN & ACK-------------> Getting only ACK in this Scenario, >=20 >=A0 Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is s= ending only ACK message as the response. There's no reason why the FreeBSD host would send another SYN; presumably t= he "APPLICATION" host received the SYN and responds back with SYN of it's o= wn and ACK of the FreeBSD host's SYN.=A0 Once the SYN has been ACK'd, there= 's no reason to resend it.=A0 I suppose I wonder why you expect the FreeBSD= system to retransmit it's SYN? > 4=A0 =A0 .When checking the State - TIME-WAIT=A0 =A0 Sending FIN and expe= cting the ACK ;Getting the ACK properly.=A0=A0=A0Sending Data Segment and E= xpecting the RST signal not getting the RST ; Instead DUT is sending the La= st TCP packet. Issue seen only in Free BSD >=20 >=20 > For this Issue mentioned above, Last TCP packet is jst a Testing packet w= ith the > following Field set=A0 in TIME-WAIT state , >=20 >=20 > TCP: ---- TCP Packet ---- > TCP: > TCP: Source Port=A0 =A0 =A0 =A0 =A0=A0=A0=3D 16815 (16815) > TCP: Destination Port=A0 =A0 =A0 =3D 16816 (16816) > TCP: Sequence Number=A0 =A0 =A0=A0=A0=3D 3865716731 (0xE66A27FB) > TCP: Acknowledgment Number =3D 0 (0x00000000) > TCP: Data Offset=A0 =A0 =A0 =A0 =A0=A0=A0=3D 5 (20 bytes) > TCP: Reserved=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 > TCP: Control Bits=A0 =A0 =A0 =A0 =A0 =3D 0x10 > TCP:=A0 |543210 > TCP:=A0 |0.....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Urgent Pointer Isn't Signi= ficant > TCP:=A0 |.1....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Acknowledgment Is Signific= ant > TCP:=A0 |..0...=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Push Function > TCP:=A0 |...0..=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Reset Connection > TCP:=A0 |....0.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Synchronize Sequence Nu= mbers > TCP:=A0 |.....0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D More Data From Sender > TCP: Window=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 32752 bytes > TCP: Checksum=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0x41A0 (Correct) > TCP: Urgent Pointer=A0 =A0 =A0 =A0 =3D 0 (Not Significant) > TCP: > TCP: --- Trailing Data [12 bytes] --- > TCP:=A0 53 61 6D 70 6C 65 20 44 61 74 61 00=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0= =A0Sample Data. > TCP: --- Trailing Data End --- > From machine Sending=A0 to the FREE BSD machine, >=20 > This is to verify that Free BSD is in TIME-WAIT state. Not sure what good this packet trace is; the only reason the TCP would resp= ond with a RST segment is if the segment it receives is somehow bogus.=A0 P= erhaps that the send sequence is outside the window.=A0 If the data is with= in the window, it might be considered an "old" segment that happens to arri= ve, perhaps out-of-order; why would the local TCP reset the connection for = no good reason? louie =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 11:07:36 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B8B71065674 for ; Tue, 16 Jun 2009 11:07:36 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: from web8315.mail.in.yahoo.com (web8315.mail.in.yahoo.com [202.43.219.9]) by mx1.freebsd.org (Postfix) with SMTP id D5E8B8FC12 for ; Tue, 16 Jun 2009 11:07:34 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: (qmail 71924 invoked by uid 60001); 16 Jun 2009 11:07:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1245150452; bh=Rt/oBnBpAWBDWlUzdDJcGLLqfi1DnoiFPjizV6j+APc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=ycR8LcbTBm+4/KVDshmW0q6FZGQjWdfHiCyGiaINX6VNSpkzvohWQ5gradU18IRFxAS8n5s0ddkU9CYe0xznKipbIZIB+ssteSOjAL6Ki6567Sr0X6rtw4qyVeCTXa09+jGjtDhDZlQ3+Em2nAqu4NcIUBLXCOjig5p+GsSVAm0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=pHu0r9H3Wzkv4aILS3NZ3X5thLK+jXP1vdX/gXvm+eLu7KbrVqulKgF1NIahloGfqzCd5sKRE9rNM8UXq6/BdvTZCQL4TKaVGmifmVEIiX57JK5PGUlDmat6S9Z8LqNzUA58fnOgJk0IBXpwEJJ4Ml36iUhUEXls+J2JS+Pcbso=; Message-ID: <925929.71164.qm@web8315.mail.in.yahoo.com> X-YMail-OSG: iTpAFjoVM1m0fj93GEc_GUykBmKgqMBNNY2RHqvYwUKLEmqykxgZriT4HURHPZf_GKRom52bvsrQjC.r_y4ZVCOiMiLAxmY1T_1fJA5LTl6_5PhBgRv3QpLXpsNex8.aG7kAmcsUPYgw0EneWARXa.RD_fG0haOUUkhqAPCuL2Ao9z1gJV9q7oe7JPtHDAsHiLvSEVmNq5OWhYALggDitbw3OC98gjXesFIh3PxsmzQTRYWcSA-- Received: from [125.22.253.101] by web8315.mail.in.yahoo.com via HTTP; Tue, 16 Jun 2009 16:37:32 IST X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Tue, 16 Jun 2009 16:37:32 +0530 (IST) From: saravana perumal To: Louis Mamakos MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Mailer List Subject: Re: TCP Free-BSD setup behaviour. 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, 16 Jun 2009 11:07:37 -0000 Hi=A0 Louie. =A0 As per Testing=20 =A0 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] 2. Then Expects to RECEIVE SYN packet and=20 3. To Send SYN & ACK=A0 to reach=A0 SYN-RCVD state. =A0 In Free BSD active SYN-RCVD state is not happening . =A0 In TCP state tranistion my expectation is represented for SYN_RCVD state. =A0 =A0 Thanks. Saravanan --- On Tue, 6/16/09, saravana perumal wrote: From: saravana perumal Subject: Re: TCP Free-BSD setup behaviour. To: "Louis Mamakos" Cc: "FreeBSD Mailer List" Date: Tuesday, June 16, 2009, 3:15 PM Hi Louie =A0 =A0We are trying to make Active Sync Received state. =A0 As per our testing we are trying to received Syn packet from APPLICATION en= d and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-R= ECEIVED state. =A0 So initially make the application to send SYN sending the Initial SYN and o= nce Received the SYN packet , expecting the Device to Send SYN & ACK =A0 I hope the expectation should be rite in case of ACTIVE-SYN received State. =A0 Thanks. Saravanan =A0 --- On Tue, 6/16/09, Louis Mamakos wrote: From: Louis Mamakos Subject: Re: TCP Free-BSD setup behaviour. To: "saravana perumal" Cc: freebsd-net@freebsd.org, sarbalas@gmail.com Date: Tuesday, June 16, 2009, 3:05 AM On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > Hi Louie , >=20 >=20 > Thanks for the Response on my Queries. >=20 > For QUERY 3, > ACTIVE open frm Free BSD end: >=20 >=A0 =A0 =A0 =A0 FREE BSD=A0 =A0 =A0 =A0 =A0 APPLICATION >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Send ---------> syn >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Receive <-------- SYN >=20 > Expect SYN & ACK-------------> Getting only ACK in this Scenario, >=20 >=A0 Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is s= ending only ACK message as the response. There's no reason why the FreeBSD host would send another SYN; presumably t= he "APPLICATION" host received the SYN and responds back with SYN of it's o= wn and ACK of the FreeBSD host's SYN.=A0 Once the SYN has been ACK'd, there= 's no reason to resend it.=A0 I suppose I wonder why you expect the FreeBSD= system to retransmit it's SYN? > 4=A0 =A0 .When checking the State - TIME-WAIT=A0 =A0 Sending FIN and expe= cting the ACK ;Getting the ACK properly.=A0=A0=A0Sending Data Segment and E= xpecting the RST signal not getting the RST ; Instead DUT is sending the La= st TCP packet. Issue seen only in Free BSD >=20 >=20 > For this Issue mentioned above, Last TCP packet is jst a Testing packet w= ith the > following Field set=A0 in TIME-WAIT state , >=20 >=20 > TCP: ---- TCP Packet ---- > TCP: > TCP: Source Port=A0 =A0 =A0 =A0 =A0=A0=A0=3D 16815 (16815) > TCP: Destination Port=A0 =A0 =A0 =3D 16816 (16816) > TCP: Sequence Number=A0 =A0 =A0=A0=A0=3D 3865716731 (0xE66A27FB) > TCP: Acknowledgment Number =3D 0 (0x00000000) > TCP: Data Offset=A0 =A0 =A0 =A0 =A0=A0=A0=3D 5 (20 bytes) > TCP: Reserved=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 > TCP: Control Bits=A0 =A0 =A0 =A0 =A0 =3D 0x10 > TCP:=A0 |543210 > TCP:=A0 |0.....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Urgent Pointer Isn't Signi= ficant > TCP:=A0 |.1....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Acknowledgment Is Signific= ant > TCP:=A0 |..0...=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Push Function > TCP:=A0 |...0..=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Reset Connection > TCP:=A0 |....0.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Synchronize Sequence Nu= mbers > TCP:=A0 |.....0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D More Data From Sender > TCP: Window=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 32752 bytes > TCP: Checksum=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0x41A0 (Correct) > TCP: Urgent Pointer=A0 =A0 =A0 =A0 =3D 0 (Not Significant) > TCP: > TCP: --- Trailing Data [12 bytes] --- > TCP:=A0 53 61 6D 70 6C 65 20 44 61 74 61 00=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0= =A0Sample Data. > TCP: --- Trailing Data End --- > From machine Sending=A0 to the FREE BSD machine, >=20 > This is to verify that Free BSD is in TIME-WAIT state. Not sure what good this packet trace is; the only reason the TCP would resp= ond with a RST segment is if the segment it receives is somehow bogus.=A0 P= erhaps that the send sequence is outside the window.=A0 If the data is with= in the window, it might be considered an "old" segment that happens to arri= ve, perhaps out-of-order; why would the local TCP reset the connection for = no good reason? louie =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 11:52:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F6AD106564A for ; Tue, 16 Jun 2009 11:52:33 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED468FC19 for ; Tue, 16 Jun 2009 11:52:32 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:59115 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MGWyM-0000YN-6T for freebsd-net@freebsd.org; Tue, 16 Jun 2009 13:37:04 +0200 Received: (qmail 25250 invoked from network); 16 Jun 2009 13:36:59 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 16 Jun 2009 13:36:59 +0200 Received: (qmail 21144 invoked by uid 1001); 16 Jun 2009 13:36:59 +0200 Date: Tue, 16 Jun 2009 13:36:59 +0200 From: Erik Trulsson To: saravana perumal Message-ID: <20090616113659.GA99604@owl.midgard.homeip.net> References: <925929.71164.qm@web8315.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <925929.71164.qm@web8315.mail.in.yahoo.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1MGWyM-0000YN-6T. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1MGWyM-0000YN-6T 060ddc1a04a3af5989fa9e6fc9690e4e Cc: FreeBSD Mailer List Subject: Re: TCP Free-BSD setup behaviour. 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, 16 Jun 2009 11:52:33 -0000 On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: > Hi=A0 Louie. > =A0 > As per Testing=20 > =A0 > 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] > 2. Then Expects to RECEIVE SYN packet and=20 > 3. To Send SYN & ACK=A0 to reach=A0 SYN-RCVD state. That does not sound quite correct. The normal sequence for the TCP three-way handshake is: -----> SYN <----- SYN+ACK -----> ACK while you for some reason seem to be expecting -----> SYN <----- SYN -----> SYN+ACK which is not what I would expect. > =A0 > In Free BSD active SYN-RCVD state is not happening . > =A0 > In TCP state tranistion my expectation is represented for SYN_RCVD state. > =A0 > =A0 > Thanks. > Saravanan >=20 >=20 > --- On Tue, 6/16/09, saravana perumal wrote: >=20 >=20 > From: saravana perumal > Subject: Re: TCP Free-BSD setup behaviour. > To: "Louis Mamakos" > Cc: "FreeBSD Mailer List" > Date: Tuesday, June 16, 2009, 3:15 PM >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hi Louie > =A0 > =A0We are trying to make Active Sync Received state. > =A0 > As per our testing we are trying to received Syn packet from APPLICATION = end and to send syn & ACK from Device END and hence reaching the ACTIVE SYN= -RECEIVED state. > =A0 > So initially make the application to send SYN sending the Initial SYN and= once Received the SYN packet , expecting the Device to Send SYN & ACK > =A0 > I hope the expectation should be rite in case of ACTIVE-SYN received Stat= e. > =A0 > Thanks. > Saravanan > =A0 >=20 >=20 > --- On Tue, 6/16/09, Louis Mamakos wrote: >=20 >=20 > From: Louis Mamakos > Subject: Re: TCP Free-BSD setup behaviour. > To: "saravana perumal" > Cc: freebsd-net@freebsd.org, sarbalas@gmail.com > Date: Tuesday, June 16, 2009, 3:05 AM >=20 >=20 >=20 > On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: >=20 > > Hi Louie , > >=20 > >=20 > > Thanks for the Response on my Queries. > >=20 > > For QUERY 3, > > ACTIVE open frm Free BSD end: > >=20 > >=A0 =A0 =A0 =A0 FREE BSD=A0 =A0 =A0 =A0 =A0 APPLICATION > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Send ---------> syn > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Receive <-------- SYN > >=20 > > Expect SYN & ACK-------------> Getting only ACK in this Scenario, > >=20 > >=A0 Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is= sending only ACK message as the response. >=20 > There's no reason why the FreeBSD host would send another SYN; presumably= the "APPLICATION" host received the SYN and responds back with SYN of it's= own and ACK of the FreeBSD host's SYN.=A0 Once the SYN has been ACK'd, the= re's no reason to resend it.=A0 I suppose I wonder why you expect the FreeB= SD system to retransmit it's SYN? >=20 > > 4=A0 =A0 .When checking the State - TIME-WAIT=A0 =A0 Sending FIN and ex= pecting the ACK ;Getting the ACK properly.=A0=A0=A0Sending Data Segment and= Expecting the RST signal not getting the RST ; Instead DUT is sending the = Last TCP packet. Issue seen only in Free BSD > >=20 > >=20 > > For this Issue mentioned above, Last TCP packet is jst a Testing packet= with the > > following Field set=A0 in TIME-WAIT state , > >=20 > >=20 > > TCP: ---- TCP Packet ---- > > TCP: > > TCP: Source Port=A0 =A0 =A0 =A0 =A0=A0=A0=3D 16815 (16815) > > TCP: Destination Port=A0 =A0 =A0 =3D 16816 (16816) > > TCP: Sequence Number=A0 =A0 =A0=A0=A0=3D 3865716731 (0xE66A27FB) > > TCP: Acknowledgment Number =3D 0 (0x00000000) > > TCP: Data Offset=A0 =A0 =A0 =A0 =A0=A0=A0=3D 5 (20 bytes) > > TCP: Reserved=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 > > TCP: Control Bits=A0 =A0 =A0 =A0 =A0 =3D 0x10 > > TCP:=A0 |543210 > > TCP:=A0 |0.....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Urgent Pointer Isn't Sig= nificant > > TCP:=A0 |.1....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Acknowledgment Is Signif= icant > > TCP:=A0 |..0...=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Push Function > > TCP:=A0 |...0..=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Reset Connection > > TCP:=A0 |....0.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Synchronize Sequence = Numbers > > TCP:=A0 |.....0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D More Data From Sender > > TCP: Window=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 32752 bytes > > TCP: Checksum=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0x41A0 (Correct) > > TCP: Urgent Pointer=A0 =A0 =A0 =A0 =3D 0 (Not Significant) > > TCP: > > TCP: --- Trailing Data [12 bytes] --- > > TCP:=A0 53 61 6D 70 6C 65 20 44 61 74 61 00=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=A0Sample Data. > > TCP: --- Trailing Data End --- > > From machine Sending=A0 to the FREE BSD machine, > >=20 > > This is to verify that Free BSD is in TIME-WAIT state. >=20 > Not sure what good this packet trace is; the only reason the TCP would re= spond with a RST segment is if the segment it receives is somehow bogus.=A0= Perhaps that the send sequence is outside the window.=A0 If the data is wi= thin the window, it might be considered an "old" segment that happens to ar= rive, perhaps out-of-order; why would the local TCP reset the connection fo= r no good reason? >=20 > louie >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 12:16:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EDDB106568E for ; Tue, 16 Jun 2009 12:16:28 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp3.dlr.de (smtp3.dlr.de [129.247.252.33]) by mx1.freebsd.org (Postfix) with ESMTP id D3D3C8FC08 for ; Tue, 16 Jun 2009 12:16:27 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:16:26 +0200 Date: Tue, 16 Jun 2009 14:17:16 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Erik Trulsson In-Reply-To: <20090616113659.GA99604@owl.midgard.homeip.net> Message-ID: <20090616141644.L82919@beagle.kn.op.dlr.de> References: <925929.71164.qm@web8315.mail.in.yahoo.com> <20090616113659.GA99604@owl.midgard.homeip.net> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1964543108-1775022277-1245154636=:82919" X-OriginalArrivalTime: 16 Jun 2009 12:16:26.0255 (UTC) FILETIME=[454931F0:01C9EE7C] Cc: FreeBSD Mailer List , saravana perumal Subject: Re: TCP Free-BSD setup behaviour. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 12:16:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1964543108-1775022277-1245154636=:82919 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 Jun 2009, Erik Trulsson wrote: ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: ET>> Hi=9A Louie. ET>> =9A ET>> As per Testing=20 ET>> =9A ET>> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] ET>> 2. Then Expects to RECEIVE SYN packet and=20 ET>> 3. To Send SYN & ACK=9A to reach=9A SYN-RCVD state. ET> ET>That does not sound quite correct. The normal sequence for the TCP ET>three-way handshake is: ET> ET> -----> SYN ET> <----- SYN+ACK ET> -----> ACK ET> ET>while you for some reason seem to be expecting ET> ET> -----> SYN ET> <----- SYN ET> -----> SYN+ACK ET> ET>which is not what I would expect. Wouldn't that be a correct simultaneous setup? harti ET> ET> ET>> =9A ET>> In Free BSD active SYN-RCVD state is not happening . ET>> =9A ET>> In TCP state tranistion my expectation is represented for SYN_RCVD sta= te. ET>> =9A ET>> =9A ET>> Thanks. ET>> Saravanan ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, saravana perumal wrote= : ET>>=20 ET>>=20 ET>> From: saravana perumal ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "Louis Mamakos" ET>> Cc: "FreeBSD Mailer List" ET>> Date: Tuesday, June 16, 2009, 3:15 PM ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>> Hi Louie ET>> =9A ET>> =9AWe are trying to make Active Sync Received state. ET>> =9A ET>> As per our testing we are trying to received Syn packet from APPLICATI= ON end and to send syn & ACK from Device END and hence reaching the ACTIVE = SYN-RECEIVED state. ET>> =9A ET>> So initially make the application to send SYN sending the Initial SYN = and once Received the SYN packet , expecting the Device to Send SYN & ACK ET>> =9A ET>> I hope the expectation should be rite in case of ACTIVE-SYN received S= tate. ET>> =9A ET>> Thanks. ET>> Saravanan ET>> =9A ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, Louis Mamakos wrote: ET>>=20 ET>>=20 ET>> From: Louis Mamakos ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "saravana perumal" ET>> Cc: freebsd-net@freebsd.org, sarbalas@gmail.com ET>> Date: Tuesday, June 16, 2009, 3:05 AM ET>>=20 ET>>=20 ET>>=20 ET>> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: ET>>=20 ET>> > Hi Louie , ET>> >=20 ET>> >=20 ET>> > Thanks for the Response on my Queries. ET>> >=20 ET>> > For QUERY 3, ET>> > ACTIVE open frm Free BSD end: ET>> >=20 ET>> >=9A =9A =9A =9A FREE BSD=9A =9A =9A =9A =9A APPLICATION ET>> >=9A =9A =9A =9A =9A =9A =9A =9A=9A=9ASend ---------> syn ET>> >=9A =9A =9A =9A =9A =9A =9A =9A=9A=9AReceive <-------- SYN ET>> >=20 ET>> > Expect SYN & ACK-------------> Getting only ACK in this Scenario, ET>> >=20 ET>> >=9A Now Expects FREE BSD to respond back with the SYN & ACK , but BSD= is sending only ACK message as the response. ET>>=20 ET>> There's no reason why the FreeBSD host would send another SYN; presuma= bly the "APPLICATION" host received the SYN and responds back with SYN of i= t's own and ACK of the FreeBSD host's SYN.=9A Once the SYN has been ACK'd, = there's no reason to resend it.=9A I suppose I wonder why you expect the Fr= eeBSD system to retransmit it's SYN? ET>>=20 ET>> > 4=9A =9A .When checking the State - TIME-WAIT=9A =9A Sending FIN and= expecting the ACK ;Getting the ACK properly.=9A=9A=9ASending Data Segment = and Expecting the RST signal not getting the RST ; Instead DUT is sending t= he Last TCP packet. Issue seen only in Free BSD ET>> >=20 ET>> >=20 ET>> > For this Issue mentioned above, Last TCP packet is jst a Testing pac= ket with the ET>> > following Field set=9A in TIME-WAIT state , ET>> >=20 ET>> >=20 ET>> > TCP: ---- TCP Packet ---- ET>> > TCP: ET>> > TCP: Source Port=9A =9A =9A =9A =9A=9A=9A=3D 16815 (16815) ET>> > TCP: Destination Port=9A =9A =9A =3D 16816 (16816) ET>> > TCP: Sequence Number=9A =9A =9A=9A=9A=3D 3865716731 (0xE66A27FB) ET>> > TCP: Acknowledgment Number =3D 0 (0x00000000) ET>> > TCP: Data Offset=9A =9A =9A =9A =9A=9A=9A=3D 5 (20 bytes) ET>> > TCP: Reserved=9A =9A =9A =9A =9A =9A =9A =3D 0 ET>> > TCP: Control Bits=9A =9A =9A =9A =9A =3D 0x10 ET>> > TCP:=9A |543210 ET>> > TCP:=9A |0.....=9A =9A =9A =9A =9A =9A =9A =3D Urgent Pointer Isn't = Significant ET>> > TCP:=9A |.1....=9A =9A =9A =9A =9A =9A =9A =3D Acknowledgment Is Sig= nificant ET>> > TCP:=9A |..0...=9A =9A =9A =9A =9A =9A =9A =3D No Push Function ET>> > TCP:=9A |...0..=9A =9A =9A =9A =9A =9A =9A =3D No Reset Connection ET>> > TCP:=9A |....0.=9A =9A =9A =9A =9A =9A =9A =3D No Synchronize Sequen= ce Numbers ET>> > TCP:=9A |.....0=9A =9A =9A =9A =9A =9A =9A =3D More Data From Sender ET>> > TCP: Window=9A =9A =9A =9A =9A =9A =9A =9A =3D 32752 bytes ET>> > TCP: Checksum=9A =9A =9A =9A =9A =9A =9A =3D 0x41A0 (Correct) ET>> > TCP: Urgent Pointer=9A =9A =9A =9A =3D 0 (Not Significant) ET>> > TCP: ET>> > TCP: --- Trailing Data [12 bytes] --- ET>> > TCP:=9A 53 61 6D 70 6C 65 20 44 61 74 61 00=9A =9A =9A =9A =9A =9A = =9A=9A=9ASample Data. ET>> > TCP: --- Trailing Data End --- ET>> > From machine Sending=9A to the FREE BSD machine, ET>> >=20 ET>> > This is to verify that Free BSD is in TIME-WAIT state. ET>>=20 ET>> Not sure what good this packet trace is; the only reason the TCP would= respond with a RST segment is if the segment it receives is somehow bogus.= =9A Perhaps that the send sequence is outside the window.=9A If the data is= within the window, it might be considered an "old" segment that happens to= arrive, perhaps out-of-order; why would the local TCP reset the connection= for no good reason? ET>>=20 ET>> louie ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>> _______________________________________________ ET>> freebsd-net@freebsd.org mailing list ET>> http://lists.freebsd.org/mailman/listinfo/freebsd-net ET>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ET> ET> --1964543108-1775022277-1245154636=:82919-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 14:14:40 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3DCB10656C5 for ; Tue, 16 Jun 2009 14:14:40 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: from web8318.mail.in.yahoo.com (web8318.mail.in.yahoo.com [202.43.219.53]) by mx1.freebsd.org (Postfix) with SMTP id 6AC718FC52 for ; Tue, 16 Jun 2009 14:14:39 +0000 (UTC) (envelope-from seesaravanan@yahoo.co.in) Received: (qmail 59980 invoked by uid 60001); 16 Jun 2009 14:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1245161677; bh=CFP5O+WPCokLpEEr2wBeLqk/yLXRxSy2Fh2bE+Qm/7k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=oADB2xdyHIpMwuoX683XN5H7BbpBzEEXGLbAQmYFX8hHdImee6v88oCmSvvfK7Dqj2KtEykE1jXH4P7dbLgt9sEhFWuC3PY+vbmv6ns6zgyKl7sqvNx4Biui1uFvF3BecPREzEf3VB/LkMfhQn8NRTEfyskihXGdWQg1xwXge+o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=PE1D3JNE/ctJU8fJy5PHVZDKf4846R7Wpm2X1yl0hi+yTN1x+pP1a2dyPcV7NwXjebr5AacfF5porT0quZL/VV6O2U8PPvlYTaDUE94drzbLBbpoPiYKudqqnSWirXUB6hfHFrSwIF+lNmziTl2X/RocApt0sR/J6eOiVcq0Lhs=; Message-ID: <576824.58716.qm@web8318.mail.in.yahoo.com> X-YMail-OSG: Fu9LOjwVM1kZXhpZVYHSIMK4hCjCbrEcleOvxD_n66mwzZXbCY7rrRudQoIlnjJArD6mPuDYT7a34Rqfq.vGZAl912ljylW3XTeVOZroPRZwpZ1ffQPcrIv1hzh_LcWd33Z8sm5U7SNSB7be6SayCM58gqsEzS2ulplxCgpbUOBm8kuj1bdGqAzovufQOMvInSYiT4uY3vn_qDay3ELg3FP0yNiH3lhSOUF6QdJTZw-- Received: from [125.22.253.101] by web8318.mail.in.yahoo.com via HTTP; Tue, 16 Jun 2009 19:44:37 IST X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Tue, 16 Jun 2009 19:44:37 +0530 (IST) From: saravana perumal To: Erik Trulsson , Harti Brandt MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Mailer List Subject: Re: TCP Free-BSD setup behaviour. 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, 16 Jun 2009 14:14:51 -0000 Hi Erik =A0 =A0 Have a look into the below link =A0 http://www.jxos.org/Projects/TCP/tcpstate.html =A0 See how from CLOSED----------> SYN sent ---------> syn Received=A0 state. =A0 Let me know if anything I am missing here. =A0 Thanks. Saravanan --- On Tue, 6/16/09, Harti Brandt wrote: From: Harti Brandt Subject: Re: TCP Free-BSD setup behaviour. To: "Erik Trulsson" Cc: "saravana perumal" , "FreeBSD Mailer List" Date: Tuesday, June 16, 2009, 5:47 PM On Tue, 16 Jun 2009, Erik Trulsson wrote: ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: ET>> Hi=A0 Louie. ET>> =A0 ET>> As per Testing=20 ET>> =A0 ET>> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] ET>> 2. Then Expects to RECEIVE SYN packet and=20 ET>> 3. To Send SYN & ACK=A0 to reach=A0 SYN-RCVD state. ET> ET>That does not sound quite correct.=A0 The normal sequence for the TCP ET>three-way handshake is: ET> ET>=A0 =A0 -----> SYN ET>=A0 =A0 <----- SYN+ACK ET>=A0 =A0 -----> ACK ET> ET>while you for some reason seem to be expecting ET> ET>=A0 =A0 -----> SYN ET>=A0 =A0 <----- SYN ET>=A0 =A0 -----> SYN+ACK ET> ET>which is not what I would expect. Wouldn't that be a correct simultaneous setup? harti ET> ET> ET>> =A0 ET>> In Free BSD active SYN-RCVD state is not happening . ET>> =A0 ET>> In TCP state tranistion my expectation is represented for SYN_RCVD sta= te. ET>> =A0 ET>> =A0 ET>> Thanks. ET>> Saravanan ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, saravana perumal wrote= : ET>>=20 ET>>=20 ET>> From: saravana perumal ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "Louis Mamakos" ET>> Cc: "FreeBSD Mailer List" ET>> Date: Tuesday, June 16, 2009, 3:15 PM ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>> Hi Louie ET>> =A0 ET>> =A0We are trying to make Active Sync Received state. ET>> =A0 ET>> As per our testing we are trying to received Syn packet from APPLICATI= ON end and to send syn & ACK from Device END and hence reaching the ACTIVE = SYN-RECEIVED state. ET>> =A0 ET>> So initially make the application to send SYN sending the Initial SYN = and once Received the SYN packet , expecting the Device to Send SYN & ACK ET>> =A0 ET>> I hope the expectation should be rite in case of ACTIVE-SYN received S= tate. ET>> =A0 ET>> Thanks. ET>> Saravanan ET>> =A0 ET>>=20 ET>>=20 ET>> --- On Tue, 6/16/09, Louis Mamakos wrote: ET>>=20 ET>>=20 ET>> From: Louis Mamakos ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "saravana perumal" ET>> Cc: freebsd-net@freebsd.org, sarbalas@gmail.com ET>> Date: Tuesday, June 16, 2009, 3:05 AM ET>>=20 ET>>=20 ET>>=20 ET>> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: ET>>=20 ET>> > Hi Louie , ET>> >=20 ET>> >=20 ET>> > Thanks for the Response on my Queries. ET>> >=20 ET>> > For QUERY 3, ET>> > ACTIVE open frm Free BSD end: ET>> >=20 ET>> >=A0 =A0 =A0 =A0 FREE BSD=A0 =A0 =A0 =A0 =A0 APPLICATION ET>> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Send ---------> syn ET>> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0Receive <-------- SYN ET>> >=20 ET>> > Expect SYN & ACK-------------> Getting only ACK in this Scenario, ET>> >=20 ET>> >=A0 Now Expects FREE BSD to respond back with the SYN & ACK , but BSD= is sending only ACK message as the response. ET>>=20 ET>> There's no reason why the FreeBSD host would send another SYN; presuma= bly the "APPLICATION" host received the SYN and responds back with SYN of i= t's own and ACK of the FreeBSD host's SYN.=A0 Once the SYN has been ACK'd, = there's no reason to resend it.=A0 I suppose I wonder why you expect the Fr= eeBSD system to retransmit it's SYN? ET>>=20 ET>> > 4=A0 =A0 .When checking the State - TIME-WAIT=A0 =A0 Sending FIN and= expecting the ACK ;Getting the ACK properly.=A0=A0=A0Sending Data Segment = and Expecting the RST signal not getting the RST ; Instead DUT is sending t= he Last TCP packet. Issue seen only in Free BSD ET>> >=20 ET>> >=20 ET>> > For this Issue mentioned above, Last TCP packet is jst a Testing pac= ket with the ET>> > following Field set=A0 in TIME-WAIT state , ET>> >=20 ET>> >=20 ET>> > TCP: ---- TCP Packet ---- ET>> > TCP: ET>> > TCP: Source Port=A0 =A0 =A0 =A0 =A0=A0=A0=3D 16815 (16815) ET>> > TCP: Destination Port=A0 =A0 =A0 =3D 16816 (16816) ET>> > TCP: Sequence Number=A0 =A0 =A0=A0=A0=3D 3865716731 (0xE66A27FB) ET>> > TCP: Acknowledgment Number =3D 0 (0x00000000) ET>> > TCP: Data Offset=A0 =A0 =A0 =A0 =A0=A0=A0=3D 5 (20 bytes) ET>> > TCP: Reserved=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0 ET>> > TCP: Control Bits=A0 =A0 =A0 =A0 =A0 =3D 0x10 ET>> > TCP:=A0 |543210 ET>> > TCP:=A0 |0.....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Urgent Pointer Isn't = Significant ET>> > TCP:=A0 |.1....=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D Acknowledgment Is Sig= nificant ET>> > TCP:=A0 |..0...=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Push Function ET>> > TCP:=A0 |...0..=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Reset Connection ET>> > TCP:=A0 |....0.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D No Synchronize Sequen= ce Numbers ET>> > TCP:=A0 |.....0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D More Data From Sender ET>> > TCP: Window=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 32752 bytes ET>> > TCP: Checksum=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0x41A0 (Correct) ET>> > TCP: Urgent Pointer=A0 =A0 =A0 =A0 =3D 0 (Not Significant) ET>> > TCP: ET>> > TCP: --- Trailing Data [12 bytes] --- ET>> > TCP:=A0 53 61 6D 70 6C 65 20 44 61 74 61 00=A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0=A0Sample Data. ET>> > TCP: --- Trailing Data End --- ET>> > From machine Sending=A0 to the FREE BSD machine, ET>> >=20 ET>> > This is to verify that Free BSD is in TIME-WAIT state. ET>>=20 ET>> Not sure what good this packet trace is; the only reason the TCP would= respond with a RST segment is if the segment it receives is somehow bogus.= =A0 Perhaps that the send sequence is outside the window.=A0 If the data is= within the window, it might be considered an "old" segment that happens to= arrive, perhaps out-of-order; why would the local TCP reset the connection= for no good reason? ET>>=20 ET>> louie ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>>=20 ET>> _______________________________________________ ET>> freebsd-net@freebsd.org mailing list ET>> http://lists.freebsd.org/mailman/listinfo/freebsd-net ET>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ET> ET>=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 17:00:14 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DFE010656F0 for ; Tue, 16 Jun 2009 17:00:14 +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 6069E8FC25 for ; Tue, 16 Jun 2009 17:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5GH0EGb004799 for ; Tue, 16 Jun 2009 17:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5GH0ERq004798; Tue, 16 Jun 2009 17:00:14 GMT (envelope-from gnats) Date: Tue, 16 Jun 2009 17:00:14 GMT Message-Id: <200906161700.n5GH0ERq004798@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Joseph Lee Cc: Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Lee List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:00:16 -0000 The following reply was made to PR kern/124753; it has been noted by GNATS. From: Joseph Lee To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early Date: Tue, 16 Jun 2009 09:34:11 -0700 Seems to be FINALLY noticed and fixed by http://thread.gmane.org/gmane.os.freebsd.current/110707 Thanks. From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 21:30:10 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C60F106564A; Tue, 16 Jun 2009 21:30:10 +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 31EA98FC08; Tue, 16 Jun 2009 21:30:10 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5GLUAs6014716; Tue, 16 Jun 2009 21:30:10 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5GLUAfc014693; Tue, 16 Jun 2009 21:30:10 GMT (envelope-from vwe) Date: Tue, 16 Jun 2009 21:30:10 GMT Message-Id: <200906162130.n5GLUAfc014693@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/135502: [periodic] Warning message raised by rtfree function in kernel logs 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, 16 Jun 2009 21:30:10 -0000 Synopsis: [periodic] Warning message raised by rtfree function in kernel logs Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Tue Jun 16 21:26:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). This may happen for gif tunnels and v6 interfaces as cscope suggests there're direct calls to rtfree() from in6_gif.c, in6_ifattach.c and nd6_nbr.c http://www.freebsd.org/cgi/query-pr.cgi?pr=135502 From owner-freebsd-net@FreeBSD.ORG Tue Jun 16 21:55:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1E231065672 for ; Tue, 16 Jun 2009 21:55:08 +0000 (UTC) (envelope-from prvs=1411f0a503=brian@Awfulhak.org) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id AB7408FC1A for ; Tue, 16 Jun 2009 21:55:08 +0000 (UTC) (envelope-from prvs=1411f0a503=brian@Awfulhak.org) Received: from pd4ml2so-ssvc.prod.shaw.ca ([10.0.141.136]) by pd4mo1so-svcs.prod.shaw.ca with ESMTP; 16 Jun 2009 15:26:44 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=QZtpE4IASS50N7JhAPwA:9 a=_PN535u-yFKTGKNWdaQnWXomf04A:4 a=WJ3hkfHDukgA:10 a=SV7veod9ZcQA:10 Received: from unknown (HELO store.lan.Awfulhak.org) ([174.7.23.140]) by pd4ml2so-dmz.prod.shaw.ca with ESMTP; 16 Jun 2009 15:26:44 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C76F6C433AC_A380E38B; Tue, 16 Jun 2009 21:27:20 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id 84F8DC460FA_A380E36F; Tue, 16 Jun 2009 21:27:18 +0000 (GMT) Received: from localhost (brian@gw.lan.Awfulhak.org [172.16.0.1]) by gw.Awfulhak.org (8.14.3/8.14.3) with ESMTP id n5GLQebM070173; Tue, 16 Jun 2009 14:26:41 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Tue, 16 Jun 2009 14:26:46 -0700 From: Brian Somers To: Marco Borsatino Message-ID: <20090616142646.173b092d@Awfulhak.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: NFS - exports syntax X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 21:55:09 -0000 On Mon, 15 Jun 2009 18:46:35 +0200, "marco\.borsatino\@poste\.it" wrote: > First, thank you for your help. >=20 >=20 >=20 > > > > FreeBSD's exports implementation will only allow you to associate > > mount options per local filesystem per remote machine, so this > > version: > > > > > /usr/home=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pc02 pc02 > > > /cond1 -mapall=3Duser2 pc01 pc02 > > > /cond2 -mapall=3Duser1 pc01 pc02 > > > > is correct, but only if /cond1 and /cond2 are different filesystems. > > If they're the same, this won't work. > >=20 >=20 > /cond1 and /cond2 are folders under root on /dev/ad0s1a; this is the reas= on whi my exports does not work. Yes. > So should I do something like this: > #mkdir /usr/shared/cond1 > #mkdir /usr/shared/cond2 > (this is, I think, a better choice also from different points of view). > (exports) > /usr/shared -alldirs pc01 pc02 (or -network 192.168.0) > (mount for different users) > #mount _nfs server:/usr/shared/cond1 /mnt/for-user-1 > #mount _nfs server:/usr/shared/cond2 /mnt/for-user-2 >=20 > But, if this sintax is correct, how can I use mapall option? Your exports file should say: /usr/shared/cond1 -maproot=3Dwhatever pc01 /usr/shared/cond2 -maproot=3Dsomethingelse pc02 The two entries for the same physical filesystem are fine as long as you don't atempt to duplicate the remote host. --=20 Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Wed Jun 17 05:16:17 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65648106564A for ; Wed, 17 Jun 2009 05:16:17 +0000 (UTC) (envelope-from bob@veznat.com) Received: from mail.ttora.com (mail.ttora.com [208.75.243.236]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8FD8FC16 for ; Wed, 17 Jun 2009 05:16:17 +0000 (UTC) (envelope-from bob@veznat.com) DomainKey-Signature: s=two; d=veznat.com; c=nofws; q=dns; h=X-MID:X-IronPort-AV:X-IronPort-AV:Received:User-Agent: Date:Subject:From:To:Message-ID:Thread-Topic:Thread-Index: Mime-version:Content-type:Content-transfer-encoding; b=cj+bOzy7uUJXADnaAOX2aDkOnT1fzaW3P0fvDvzD0EmVqP6oVppsNcp2 FPZK5OOcKNdzLEVuooZ3nOa4z4+/4twk9AKSVR16nlgDAaSb83p0IKSfp uzU6HpD0CKid8BXVWyo5x4/vkaxNATNQNI8PyGQgpkRlQhWgPrIg50B1I c=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=veznat.com; i=bob@veznat.com; q=dns/txt; s=one; t=1245215777; x=1276751777; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Bob=20Van=20Zant=20|Subject:=20D ebugging=20a=20netgraph=20node|Date:=20Tue,=2016=20Jun=20 2009=2021:47:21=20-0700|Message-ID:=20|To:=20 |Mime-version:=201.0|Content-transfer-encoding:=207bit; bh=oiG9hElQZhEbTCJjgohlBpzNB3XxkaBJvcMhs3Y2r7E=; b=QUWM1WnyP5rFECaGvNvaUfPNItofQ1iIc6JPQrNJdV7OVlDFUW/AFnU0 Xq01YVe4np+26wmi098Na5WF3d4IwlNvehpV8UNsU55fVmr7rgghD9fs7 a2pqOb3Vcpcz9zd24IuVeW8deRrukLZMQntBab1donD8TjapOnWJzs2Kw k=; X-MID: 1506126 X-IronPort-AV: E=McAfee;i="5300,2777,5648"; a="1506126" X-IronPort-AV: E=Sophos;i="4.42,234,1243839600"; d="scan'208";a="1506126" Received: from c-24-5-4-92.hsd1.ca.comcast.net (HELO [192.168.1.200]) ([24.5.4.92]) by mail.ttora.com with ESMTP/TLS/DES-CBC3-SHA; 16 Jun 2009 21:47:24 -0700 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 16 Jun 2009 21:47:21 -0700 From: Bob Van Zant To: Message-ID: Thread-Topic: Debugging a netgraph node Thread-Index: AcnvBrMTmY8hkrdTRkOTW9YaYT+XBQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Debugging a netgraph node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 05:16:17 -0000 I'm experimenting with netgraph to try to implement an IPv6 -> IPv4 gateway, as specified here: http://tools.ietf.org/html/draft-xli-behave-ivi-02 This is my first time ever working with netgraph and I admit to being a bit lost. I have a netgraph node that gets wired up with an ng_ether node. My lower hook gets wired to the ng_ether lower hook and my upper to his upper. It's receiving IPv6 + UDP packets, creating IPv4 + UDP packets and then writing the new packets out with NG_FWD_NEW_DATA. I'm perfectly willing to waste time making stupid mistakes on this project, however, right now I'm stuck. I can't "find" the translated packets I'm writing anywhere to see what, if anything, is wrong with them. They don't show up in tcpdump on the local machine (I've tried writing to both the upper and lower hook). They don't show up in tcpdump on other machines on the network. I tried attaching nghook to the "orphans" hook of the ng_ether node but it doesn't appear to be seeing any data. netstat -s -p udp doesn't show any packets when my node is enabled (I think this means my node is effectively swallowing them). I've tried to figure out how to wire in an ng_tee node but I'm a little lost as to how to do this (I still haven't figured out the ngctl syntax). Any tips for figuring out what I'm doing wrong? Debug options to enable that will show me more information about what's happening after I call NG_FWD_NEW_DATA? If I got ng_tee wired in would it's tap hooks show me what I want? A better way to try to tee the data? Thanks, Bob From owner-freebsd-net@FreeBSD.ORG Wed Jun 17 06:24:20 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3DF1065672 for ; Wed, 17 Jun 2009 06:24:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id D33478FC14 for ; Wed, 17 Jun 2009 06:24:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B9D6BB094E; Tue, 16 Jun 2009 23:24:20 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 0741F2D600E; Tue, 16 Jun 2009 23:24:19 -0700 (PDT) Message-ID: <4A388C13.8050700@elischer.org> Date: Tue, 16 Jun 2009 23:24:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bob Van Zant , FreeBSD Net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Debugging a netgraph node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 06:24:21 -0000 Bob Van Zant wrote: > I'm experimenting with netgraph to try to implement an IPv6 -> IPv4 gateway, > as specified here: > > http://tools.ietf.org/html/draft-xli-behave-ivi-02 hi bob, I can give you a hand if you want.. I'm busy tomorrow Morning but I can give you a call tomorrow afternoon if you like.. also, Joe in India has been using netgraph.. > > This is my first time ever working with netgraph and I admit to being a bit > lost. I have a netgraph node that gets wired up with an ng_ether node. My > lower hook gets wired to the ng_ether lower hook and my upper to his upper. > It's receiving IPv6 + UDP packets, creating IPv4 + UDP packets and then > writing the new packets out with NG_FWD_NEW_DATA. > > I'm perfectly willing to waste time making stupid mistakes on this project, > however, right now I'm stuck. I can't "find" the translated packets I'm > writing anywhere to see what, if anything, is wrong with them. They don't > show up in tcpdump on the local machine (I've tried writing to both the > upper and lower hook). They don't show up in tcpdump on other machines on > the network. > > I tried attaching nghook to the "orphans" hook of the ng_ether node but it > doesn't appear to be seeing any data. add a tee node between your node and the ether hook to see what you are sending. > > netstat -s -p udp doesn't show any packets when my node is enabled (I think > this means my node is effectively swallowing them). probably > > I've tried to figure out how to wire in an ng_tee node but I'm a little lost > as to how to do this (I still haven't figured out the ngctl syntax). ahh #add a tee to the ethernet lower hook ngctl mkpeer em3: tee lower left ngctl name em3:lower lowertee #then add your node to the right hook of the tee. ngctl mkpeer lowertee: mytype right lower ngctl name lowertee:right mynode #similar for the upper hook except that you use connect instead of #mkpeer for the last step as your node already exists. ngctl mkpeer em3: tee upper left mgctl name em3:upper uppertee ngctl connect uppertee: mynode: upper upper ------- now you can examine traffic on the two tee nodes let2right hook and rigt2left hook > > Any tips for figuring out what I'm doing wrong? Debug options to enable that > will show me more information about what's happening after I call > NG_FWD_NEW_DATA? If I got ng_tee wired in would it's tap hooks show me what > I want? A better way to try to tee the data? > > Thanks, > > Bob > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jun 17 14:39:13 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7547F1065672 for ; Wed, 17 Jun 2009 14:39:13 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id 313888FC12 for ; Wed, 17 Jun 2009 14:39:13 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 8885 invoked by uid 60001); 17 Jun 2009 14:39:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245249552; bh=0MpXwQX7V2Tz4QT5aAOIppZKS8cUo6ZryAQUMJmf4ME=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=baEOiVaB5IG5axhBkQ/NeeaVNKo6nKeUveGcp17OQcNisxvbxFjc5tRe2eD+zy7BqrNp4LbTY+vsMJHhmcXD7r77jfisenZbKcYS+LdCjxCI2JI2EtvtRBdDoXWD7uLIB4NQopfhmZNW+ET5yOZNtThCODXN81Bss1s8PT6OSCI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N9x8q1zPERXMfRPJ4E7zNm/ekrwjk4Dmk2yitITssgntdNw9Ztuo7bgbVfos7P5ly3Tl0IQT3Jo7vA6g90k8GU254xax+Of3QFnpJp933IqHXRCeUDX179Swa4jhhxpOq0+rAVa1S8CymtgoQpGaWr1OOySWI/Jbg5n/gtuz6Hk=; Message-ID: <714551.8026.qm@web63902.mail.re1.yahoo.com> X-YMail-OSG: vDXHQLwVM1kgL27kWKPbIozQqVOmh3d_17.GeNH0qp0SM8CKyltNcRryUOjKMcuJmVQcQT0nUIn0LpI7bNg2tC4qasGVyy2_I9O1MrDImsRW7k1Sx7p9RoNndHI_VE7Eb3dpPNN18zPcrEJYIM_qyvVLab1dt_9gdoH2827qZuBGttf9lj1JZ7OcJBPWH5SuP2_AE_OFmydTppXBYO6kRQNj416ltjoEUAsmJ_caDoA6ziElW7VmXoxvw5oHuP1dFgD9OUwv3yLUX9fB35vcNqwnSf9WSUsEL6fkjJ2HOQcWFH_1GU2TbA-- Received: from [66.176.162.245] by web63902.mail.re1.yahoo.com via HTTP; Wed, 17 Jun 2009 07:39:12 PDT X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Wed, 17 Jun 2009 07:39:12 -0700 (PDT) From: Barney Cordoba To: freebsd-net@FreeBSD.org, Michael MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:39:13 -0000 =0A=0A--- On Fri, 6/12/09, Michael wrote:=0A=0A> Fr= om: Michael =0A> Subject: Re: kern/135222: [igb] low= speed routing between two igb interfaces=0A> To: freebsd-net@FreeBSD.org= =0A> Date: Friday, June 12, 2009, 5:50 AM=0A> The following reply was made = to PR=0A> kern/135222; it has been noted by GNATS.=0A> =0A> From: Michael <= freebsdusb@bindone.de>=0A> To: Cc: freebsd-gnats-submit@FreeBSD.org=0A> Sub= ject: Re: kern/135222: [igb] low speed routing between=0A> two igb interfac= es=0A> Date: Fri, 12 Jun 2009 11:45:47 +0200=0A> =0A> The original poster = reported that the suggested fix works=0A> for him:=0A> ---=0A> Hello Mich= ael,=0A> =0A> Thank you. It's working.=0A> =0A> I consider it necessary= to put this into the release=0A> errata.=0A> =0A> =0A> Mishustin Andrew= wrote:=0A> >> Number:=A0 =A0 =A0=0A> =A0=A0=A0135222=0A> >> Category:=A0= =A0 =A0=A0=A0kern=0A> >> Synopsis:=A0 =A0 =A0=A0=A0[igb]=0A> low speed ro= uting between two igb interfaces=0A> >> Confidential:=A0=A0=A0no=0A> >> S= everity:=A0 =A0 =A0=A0=A0serious=0A> >> Priority:=A0 =A0 =A0=A0=A0medium= =0A> >> Responsible:=A0 =A0 freebsd-bugs=0A> >> State:=A0 =A0 =A0 =A0 =A0= open=0A> >> Quarter:=A0 =A0 =A0 =A0 =0A> >> Keywords:=A0 =A0 =A0=A0=A0= =0A> >> Date-Required:=0A> >> Class:=A0 =A0 =A0 =A0 =A0 sw-bug=0A> >> Su= bmitter-Id:=A0=A0=A0current-users=0A> >> Arrival-Date:=A0=A0=A0Wed Jun 03= =0A> 18:30:01 UTC 2009=0A> >> Closed-Date:=0A> >> Last-Modified:=0A> >> = Originator:=A0 =A0=A0=A0Mishustin=0A> Andrew=0A> >> Release:=A0 =A0 =A0 = =A0 FreeBSD=0A> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64=0A> >> Organi= zation:=0A> > HNT=0A> >> Environment:=0A> > FreeBSD test.hnt 7.2-RELEASE= FreeBSD 7.2-RELEASE #12:=0A> Thu Apr 30 18:28:15 MSD 20=0A> > 09=A0 =A0= =A0=A0admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC=A0=0A> amd64=0A> >= > Description:=0A> > I made a FreeBSD multiprocesor server to act as=0A> s= imple gateway.=0A> > It use onboard Intel 82575EB Dual-Port Gigabit=0A> Et= hernet Controller.=0A> > I observe traffic speed near 400 Kbit/s.=0A> > I= test both interfaces separately -=0A> > ftp client work at speed near 1 G= bit/s in both=0A> directions.=0A> > Then I change NIC to old Intel "em" NI= C - gateway=0A> work at speed near 1 Gbit/s.=0A> > =0A> > Looks like a bu= g in igb driver have an effect upon=0A> forwarded traffic.=0A> > =0A> > I= f you try=0A> > hw.igb.enable_aim=3D0=0A> > The speed is near 1 Mbit/s=0A= > > =0A> > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" has no=0A> effect.=0A>= > =0A> > Nothing in messages.log=0A> > =0A> > netstat -m=0A> > 516/16= 74/2190 mbufs in use (current/cache/total)=0A> > 515/927/1442/66560 mbuf c= lusters in use=0A> (current/cache/total/max)=0A> > 515/893 mbuf+clusters o= ut of packet secondary zone in=0A> use (current/cache)=0A> > 0/44/44/33280= 4k (page size) jumbo clusters in use=0A> (current/cache/total/max)=0A> > = 0/0/0/16640 9k jumbo clusters in use=0A> (current/cache/total/max)=0A> > 0= /0/0/8320 16k jumbo clusters in use=0A> (current/cache/total/max)=0A> > 11= 59K/2448K/3607K bytes allocated to network=0A> (current/cache/total)=0A> >= 0/0/0 requests for mbufs denied=0A> (mbufs/clusters/mbuf+clusters)=0A> > = 0/0/0 requests for jumbo clusters denied (4k/9k/16k)=0A> > 0/0/0 sfbufs in= use (current/peak/max)=0A> > 0 requests for sfbufs denied=0A> > 0 reques= ts for sfbufs delayed=0A> > 0 requests for I/O initiated by sendfile=0A> = > 0 calls to protocol drain routines=0A> > =0A> > I use only IPv4 traffic= .=0A> > =0A> >> How-To-Repeat:=0A> > On machine with two igb interfaces= =0A> > use rc.conf like this:=0A> > =0A> > hostname=3D"test.test"=0A> >= gateway_enable=3D"YES"=0A> > ifconfig_igb0=3D"inet 10.10.10.1/24"=0A> > = ifconfig_igb1=3D"inet 10.10.11.1/24"=0A> > =0A> > And try create heavy tr= affic between two networks.=0A> >> Fix:=0A> > =0A> > =0A> >> Release-No= te:=0A> >> Audit-Trail:=0A> >> Unformatted:=0A> > ______________________= _________________________=0A> > freebsd-bugs@freebsd.org=0A=0A=0AThis is n= ot a bug. Unless you consider poorly written drivers to be bugs. You need t= o provide your tuning parameters for the card as well otherwise there's not= hing to learn.=0A=0AThe issue is that the driver doesn't address the purpos= e of the controller; which is to utilize multiprocessor systems more effect= ively. The effect is that lock contention actually makes things worse than = if you just use a single task as em does. Until the multiqueue drivers are = re-written to manage locks properly you are best advised to save your money= and stick with em.=0A=0AYou should get similar performance using 1 queue a= s with em. You could also force legacy configuration by forcing igb_setup_m= six to return 0. Sadly, this is the best performance you will get from the = stock driver.=0A=0ABarney=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Wed Jun 17 21:53:48 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C4761065670 for ; Wed, 17 Jun 2009 21:53:48 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (mail.bindone.de [80.190.134.51]) by mx1.freebsd.org (Postfix) with SMTP id 5526D8FC0C for ; Wed, 17 Jun 2009 21:53:47 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 4966 invoked by uid 89); 17 Jun 2009 21:28:48 -0000 Received: from unknown (HELO ufo.bindone.de) (mg@bindone.de@87.152.169.30) by mail.bindone.de with ESMTPA; 17 Jun 2009 21:28:48 -0000 Message-ID: <4A395FE6.1040003@bindone.de> Date: Wed, 17 Jun 2009 23:28:06 +0200 From: Michael User-Agent: Thunderbird 2.0.0.17pre (X11/20090202) MIME-Version: 1.0 To: Barney Cordoba References: <714551.8026.qm@web63902.mail.re1.yahoo.com> In-Reply-To: <714551.8026.qm@web63902.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 21:53:48 -0000 Barney Cordoba wrote: > > > --- On Fri, 6/12/09, Michael wrote: > >> From: Michael >> Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces >> To: freebsd-net@FreeBSD.org >> Date: Friday, June 12, 2009, 5:50 AM >> The following reply was made to PR >> kern/135222; it has been noted by GNATS. >> >> From: Michael >> To: Cc: freebsd-gnats-submit@FreeBSD.org >> Subject: Re: kern/135222: [igb] low speed routing between >> two igb interfaces >> Date: Fri, 12 Jun 2009 11:45:47 +0200 >> >> The original poster reported that the suggested fix works >> for him: >> --- >> Hello Michael, >> >> Thank you. It's working. >> >> I consider it necessary to put this into the release >> errata. >> >> >> Mishustin Andrew wrote: >> >> Number: >> 135222 >> >> Category: kern >> >> Synopsis: [igb] >> low speed routing between two igb interfaces >> >> Confidential: no >> >> Severity: serious >> >> Priority: medium >> >> Responsible: freebsd-bugs >> >> State: open >> >> Quarter: >> >> Keywords: >> >> Date-Required: >> >> Class: sw-bug >> >> Submitter-Id: current-users >> >> Arrival-Date: Wed Jun 03 >> 18:30:01 UTC 2009 >> >> Closed-Date: >> >> Last-Modified: >> >> Originator: Mishustin >> Andrew >> >> Release: FreeBSD >> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64 >> >> Organization: >> > HNT >> >> Environment: >> > FreeBSD test.hnt 7.2-RELEASE FreeBSD 7.2-RELEASE #12: >> Thu Apr 30 18:28:15 MSD 20 >> > 09 admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC >> amd64 >> >> Description: >> > I made a FreeBSD multiprocesor server to act as >> simple gateway. >> > It use onboard Intel 82575EB Dual-Port Gigabit >> Ethernet Controller. >> > I observe traffic speed near 400 Kbit/s. >> > I test both interfaces separately - >> > ftp client work at speed near 1 Gbit/s in both >> directions. >> > Then I change NIC to old Intel "em" NIC - gateway >> work at speed near 1 Gbit/s. >> > >> > Looks like a bug in igb driver have an effect upon >> forwarded traffic. >> > >> > If you try >> > hw.igb.enable_aim=0 >> > The speed is near 1 Mbit/s >> > >> > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" has no >> effect. >> > >> > Nothing in messages.log >> > >> > netstat -m >> > 516/1674/2190 mbufs in use (current/cache/total) >> > 515/927/1442/66560 mbuf clusters in use >> (current/cache/total/max) >> > 515/893 mbuf+clusters out of packet secondary zone in >> use (current/cache) >> > 0/44/44/33280 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> > 0/0/0/16640 9k jumbo clusters in use >> (current/cache/total/max) >> > 0/0/0/8320 16k jumbo clusters in use >> (current/cache/total/max) >> > 1159K/2448K/3607K 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 >> > >> > I use only IPv4 traffic. >> > >> >> How-To-Repeat: >> > On machine with two igb interfaces >> > use rc.conf like this: >> > >> > hostname="test.test" >> > gateway_enable="YES" >> > ifconfig_igb0="inet 10.10.10.1/24" >> > ifconfig_igb1="inet 10.10.11.1/24" >> > >> > And try create heavy traffic between two networks. >> >> Fix: >> > >> > >> >> Release-Note: >> >> Audit-Trail: >> >> Unformatted: >> > _______________________________________________ >> > freebsd-bugs@freebsd.org > > > This is not a bug. Unless you consider poorly written drivers to be bugs. You need to provide your tuning parameters for the card as well otherwise there's nothing to learn. > > The issue is that the driver doesn't address the purpose of the controller; which is to utilize multiprocessor systems more effectively. The effect is that lock contention actually makes things worse than if you just use a single task as em does. Until the multiqueue drivers are re-written to manage locks properly you are best advised to save your money and stick with em. > > You should get similar performance using 1 queue as with em. You could also force legacy configuration by forcing igb_setup_msix to return 0. Sadly, this is the best performance you will get from the stock driver. > > Barney > > Barney > > > I tried using 1 queue and it didn't make things any better (actually I'm not sure if that worked at all). If it is considered a bug or not doesn't really matter, what actually matters for users (who cannot always chose which network controller will be on-board) is that they get a least decent performance when doing IP forwarding (and not the 5-50kb/s I've seen). You can get this out of the controller, when disabling lro through the sysctl. That's why I've been asking to put this into the release errata section and/or at least the igb man page, because the sysctl isn't documented anywhere. Also the fact, that tuning the sysctl only affects the behaviour when it's set on boot might be considered problematic. So at the very least, I think the following should be done: 1. Document the sysctl in man igb(4) 2. Put a known issues paragraph to man igb(4) which explains the issue and what to put in sysctl.conf to stop this from happening 3. Add an entry to the release errata page about this issue (like I suggested in one of my earlier emails) and stating something like "see man igb(4) for details) This is not about using the controller to its full potential, but to safe Joe Admin from spending days on figuring out why the machine is forwarding packages slower than his BSD 2.x machine did in the 90s. cheers Michael From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 01:40:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51977106564A for ; Thu, 18 Jun 2009 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 3E67A8FC1C for ; Thu, 18 Jun 2009 01:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5I1e2Iv052321 for ; Thu, 18 Jun 2009 01:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5I1e2Pi052320; Thu, 18 Jun 2009 01:40:02 GMT (envelope-from gnats) Date: Thu, 18 Jun 2009 01:40:02 GMT Message-Id: <200906180140.n5I1e2Pi052320@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Michael Cc: Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 01:40:03 -0000 The following reply was made to PR kern/135222; it has been noted by GNATS. From: Michael To: Barney Cordoba Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces Date: Thu, 18 Jun 2009 03:32:15 +0200 Barney Cordoba wrote: > > > --- On Wed, 6/17/09, Michael wrote: > >> From: Michael >> Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces >> To: "Barney Cordoba" >> Cc: freebsd-net@FreeBSD.org >> Date: Wednesday, June 17, 2009, 5:28 PM >> Barney Cordoba wrote: >>> >>> --- On Fri, 6/12/09, Michael >> wrote: >>>> From: Michael >>>> Subject: Re: kern/135222: [igb] low speed routing >> between two igb interfaces >>>> To: freebsd-net@FreeBSD.org >>>> Date: Friday, June 12, 2009, 5:50 AM >>>> The following reply was made to PR >>>> kern/135222; it has been noted by GNATS. >>>> >>>> From: Michael >>>> To: Cc: freebsd-gnats-submit@FreeBSD.org >>>> Subject: Re: kern/135222: [igb] low speed routing >> between >>>> two igb interfaces >>>> Date: Fri, 12 Jun 2009 11:45:47 +0200 >>>> >>>> The original poster reported that the >> suggested fix works >>>> for him: >>>> --- >>>> Hello Michael, >>>> >>>> Thank you. It's working. >>>> >>>> I consider it necessary to put this into the >> release >>>> errata. >>>> >>>> >>>> Mishustin Andrew wrote: >>>> >> Number: >>>> 135222 >>>> >> Category: >> kern >>>> >> Synopsis: >> [igb] >>>> low speed routing between two igb interfaces >>>> >> Confidential: no >>>> >> Severity: >> serious >>>> >> Priority: >> medium >>>> >> Responsible: >> freebsd-bugs >>>> >> State: >> open >>>> >> Quarter: >>>> >> Keywords: >> >>>> >> Date-Required: >>>> >> Class: >> sw-bug >>>> >> >> Submitter-Id: current-users >>>> >> Arrival-Date: Wed >> Jun 03 >>>> 18:30:01 UTC 2009 >>>> >> Closed-Date: >>>> >> Last-Modified: >>>> >> Originator: >> Mishustin >>>> Andrew >>>> >> Release: >> FreeBSD >>>> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE amd64 >>>> >> Organization: >>>> > HNT >>>> >> Environment: >>>> > FreeBSD test.hnt 7.2-RELEASE FreeBSD >> 7.2-RELEASE #12: >>>> Thu Apr 30 18:28:15 MSD 20 >>>> > 09 admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC >>>> amd64 >>>> >> Description: >>>> > I made a FreeBSD multiprocesor server >> to act as >>>> simple gateway. >>>> > It use onboard Intel 82575EB Dual-Port >> Gigabit >>>> Ethernet Controller. >>>> > I observe traffic speed near 400 >> Kbit/s. >>>> > I test both interfaces separately - >>>> > ftp client work at speed near 1 Gbit/s >> in both >>>> directions. >>>> > Then I change NIC to old Intel "em" NIC >> - gateway >>>> work at speed near 1 Gbit/s. >>>> > >>>> > Looks like a bug in igb driver have an >> effect upon >>>> forwarded traffic. >>>> > >>>> > If you try >>>> > hw.igb.enable_aim=0 >>>> > The speed is near 1 Mbit/s >>>> > >>>> > hw.igb.rxd, hw.igb.txd, "ifconfig -tso" >> has no >>>> effect. >>>> > >>>> > Nothing in messages.log >>>> > >>>> > netstat -m >>>> > 516/1674/2190 mbufs in use >> (current/cache/total) >>>> > 515/927/1442/66560 mbuf clusters in >> use >>>> (current/cache/total/max) >>>> > 515/893 mbuf+clusters out of packet >> secondary zone in >>>> use (current/cache) >>>> > 0/44/44/33280 4k (page size) jumbo >> clusters in use >>>> (current/cache/total/max) >>>> > 0/0/0/16640 9k jumbo clusters in use >>>> (current/cache/total/max) >>>> > 0/0/0/8320 16k jumbo clusters in use >>>> (current/cache/total/max) >>>> > 1159K/2448K/3607K 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 >>>> > >>>> > I use only IPv4 traffic. >>>> > >>>> >> How-To-Repeat: >>>> > On machine with two igb interfaces >>>> > use rc.conf like this: >>>> > >>>> > hostname="test.test" >>>> > gateway_enable="YES" >>>> > ifconfig_igb0="inet 10.10.10.1/24" >>>> > ifconfig_igb1="inet 10.10.11.1/24" >>>> > >>>> > And try create heavy traffic between >> two networks. >>>> >> Fix: >>>> > >>>> > >>>> >> Release-Note: >>>> >> Audit-Trail: >>>> >> Unformatted: >>>> > >> _______________________________________________ >>>> > freebsd-bugs@freebsd.org >>> >>> This is not a bug. Unless you consider poorly written >> drivers to be bugs. You need to provide your tuning >> parameters for the card as well otherwise there's nothing to >> learn. >>> The issue is that the driver doesn't address the >> purpose of the controller; which is to utilize >> multiprocessor systems more effectively. The effect is that >> lock contention actually makes things worse than if you just >> use a single task as em does. Until the multiqueue drivers >> are re-written to manage locks properly you are best advised >> to save your money and stick with em. >>> You should get similar performance using 1 queue as >> with em. You could also force legacy configuration by >> forcing igb_setup_msix to return 0. Sadly, this is the best >> performance you will get from the stock driver. >>> Barney >>> >>> Barney >>> >>> >>> >> I tried using 1 queue and it didn't make things any better >> (actually I'm >> not sure if that worked at all). If it is considered a bug >> or not >> doesn't really matter, what actually matters for users (who >> cannot >> always chose which network controller will be on-board) is >> that they get >> a least decent performance when doing IP forwarding (and >> not the >> 5-50kb/s I've seen). You can get this out of the >> controller, when >> disabling lro through the sysctl. That's why I've been >> asking to put >> this into the release errata section and/or at least the >> igb man page, >> because the sysctl isn't documented anywhere. Also the >> fact, that tuning >> the sysctl only affects the behaviour when it's set on boot >> might be >> considered problematic. >> >> So at the very least, I think the following should be >> done: >> 1. Document the sysctl in man igb(4) >> 2. Put a known issues paragraph to man igb(4) which >> explains the issue >> and what to put in sysctl.conf to stop this from happening >> 3. Add an entry to the release errata page about this issue >> (like I >> suggested in one of my earlier emails) and stating >> something like "see >> man igb(4) for details) >> >> This is not about using the controller to its full >> potential, but to >> safe Joe Admin from spending days on figuring out why the >> machine is >> forwarding packages slower than his BSD 2.x machine did in >> the 90s. >> >> cheers >> Michael > > None of the offload crap should be enabled by default. > > The real point is that "Joe Admin" shouldn't be using controllers that have bad drivers at all. If you have to use whatever hardware you have laying around, and don't have enough flexibility to lay out $100 for a 2 port controller that works to use with your $2000 server, than you need to get your priorities in order. People go out and buy redundant power supplies, high GHZ quad core processors and gobs of memory and then they use whatever crappy onboard controller they get no matter how poorly its suppo rted. Its mindless. > > Barney > > > How should anybody know that the controller is poorly supported if there is nothing in the documentation, release notes, man pages or anywhere else about this? The fact of the matter is that "the offload crap" _is_ enabled by default. The release is out, it claims to support the controller. There _is_ a workaround and I'm asked if somebody could document this so users will have a chance. I'm also not convinced that it is a crappy controller per se, but just poorly supported. We used those a lot before without any issues, unfortunately now we had touse IP forwarding in a machine that has that controller (it has 6 interfaces in total, four em ports and two igb ports, all of them are in use and I don't feel like hooking up the sodering iron). So bottomline: I said, there is a problem with the driver, there is a workaround and it should be documented. You say, the driver is bad and nobody should use it and if they do it's their own damn fault. We won't do anything about it and refuse to tell anybody, because we are the only ones who should know. We don't care if people can actually use our software and still claim the hardware is actually supported. Your attitude is really contra productive (actually googling around I see you made similar statements in the past about stupid people not willing to spend xxx$ on whatever piece of hardware, so maybe you're just trolling). Michael From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 02:06:04 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E3B0106566B for ; Thu, 18 Jun 2009 02:06:04 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA108FC0A for ; Thu, 18 Jun 2009 02:06:03 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 198B517942; Thu, 18 Jun 2009 11:48:38 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-41-14.lns10.syd7.internode.on.net [121.44.41.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 20D2D1721F; Thu, 18 Jun 2009 11:48:34 +1000 (EST) Message-ID: <4A399C7F.4000203@modulus.org> Date: Thu, 18 Jun 2009 11:46:39 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: Michael References: <200906180140.n5I1e2Pi052320@freefall.freebsd.org> In-Reply-To: <200906180140.n5I1e2Pi052320@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 02:06:04 -0000 > The real point is that "Joe Admin" shouldn't be using controllers that have bad drivers at all. If you have to use whatever hardware you have laying around, and don't have enough flexibility to lay out $100 for a 2 port controller that works to use with your $2000 server, than you need to get your priorities in order. Intel 82575EB (and friends) are *the* premier ethernet controllers to use with FreeBSD in a server. igb should be the most stable and supported driver in the whole kernel. I can't think of any other driver and series of controllers I would rather use in a server like this. The "Offload crap" is also rather important for people who want to achieve the full rates of network transfer speeds they are paying for. If the drivers for these chips are now "bad", this is a very sad day for people who wanted to use FreeBSD in their dual socket servers. - Andrew From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 06:59:51 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC9A106566B for ; Thu, 18 Jun 2009 06:59:51 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from mx1.corp.idatanet.com (mx1.corp.idatanet.com [195.244.197.122]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE828FC0A for ; Thu, 18 Jun 2009 06:59:50 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Received: from gibsvwin008.partygaming.local ([10.3.10.32]) by mx1.corp.idatanet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jun 2009 08:59:45 +0200 Received: from SOFSVWIN004X.partygaming.local ([10.4.10.228]) by gibsvwin008.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 08:59:46 +0200 Received: from 10.4.71.11 ([10.4.71.11]) by SOFSVWIN004X.partygaming.local ([10.4.10.230]) via Exchange Front-End Server corp.mail.partygaming.com ([10.3.10.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Jun 2009 06:59:45 +0000 Received: from daemon2.partygaming.local by corp.mail.partygaming.com; 18 Jun 2009 09:59:45 +0300 From: Vladimir Terziev To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Organization: GB Servicves Ltd. Date: Thu, 18 Jun 2009 09:59:44 +0300 Message-ID: <1245308384.28444.14.camel@daemon2.partygaming.local> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-OriginalArrivalTime: 18 Jun 2009 06:59:46.0779 (UTC) FILETIME=[5D8ABAB0:01C9EFE2] Cc: Subject: hostapd with 802.1X EAP-TLS/TTLS support 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, 18 Jun 2009 06:59:51 -0000 Hi, i try to setup wireless access point at home, based on FreeBSD 7.2R-i386, ral(4) wireless card and hostpad(8). I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. I issued a custom SSL certificate for the hostapd(8) and put the following directives in hostapd.conf: eap_server=3D0 ca_cert=3D/usr/local/etc/myCA.crt.pem server_cert=3D/usr/local/etc/hostapd.server.crt.pem private_key=3D/usr/local/etc/hostapd.server.key.pem private_key_passwd=3Dsome_pass When i tried to start the hostapd(8) i got the following errors: Line 15: unknown configuration item 'eap_server' Line 16: unknown configuration item 'ca_cert' Line 17: unknown configuration item 'server_cert' Line 18: unknown configuration item 'private_key' Line 19: unknown configuration item 'private_key_passwd' Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at all and if "not" why ? Regards, --=20 Vladimir Terziev, CISSP This email and any attachments are confidential, and may be legally = privileged and protected by copyright. If you are not the intended = recipient dissemination or copying of this email is prohibited. If you = have received this in error, please notify the sender by replying by = email and then delete the email completely from your system.=20 Any views or opinions are solely those of the sender. This = communication is not intended to form a binding contract unless = expressly indicated to the contrary and properly authorised. Any actions = taken on the basis of this email are at the recipient's own risk. From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 10:55:21 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26AE3106564A for ; Thu, 18 Jun 2009 10:55:21 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id A5EAA8FC12 for ; Thu, 18 Jun 2009 10:55:20 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz27 with SMTP id 27so174772bwz.43 for ; Thu, 18 Jun 2009 03:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P8PRq5Poar01UnWgJSvJlaNxZqd74nPXSIGY93URlng=; b=Szj20cdSIrhnVMom/3c1q1phsWHI5qQNHl3AONkwGJsD6q4HJ/U9nCqzUazOtfO1qx Yga+VUOuomOrZ+2fLF4G2yjVguKmshKEyLaDt8g5oCOGbj7iS3dGa9hsMcXKTjVdo/Jg YdJ08DOJIesR5E4Iyil7br/x41VD6Z1X229h8= 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=a0Dj7YSUs5OcKGzvSPtFPBSIbwSD3lQHmnJ63JL89QwmFsIJ0UaPFp9ZMNznyBNL4L V0Ux/FMqKgE0PH+iuot+AQBRL9SoBJQZCvBwbSPS8fFRtcN+TxET0COFVLEHMUBd6OFc gJW+UN/7+aqRnn25Ia/vy+yTm2citPnB8VQAo= MIME-Version: 1.0 Received: by 10.204.119.71 with SMTP id y7mr1230692bkq.24.1245322519556; Thu, 18 Jun 2009 03:55:19 -0700 (PDT) In-Reply-To: <1245308384.28444.14.camel@daemon2.partygaming.local> References: <1245308384.28444.14.camel@daemon2.partygaming.local> Date: Thu, 18 Jun 2009 12:55:19 +0200 Message-ID: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> From: "Paul B. Mahol" To: Vladimir Terziev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support 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, 18 Jun 2009 10:55:21 -0000 On 6/18/09, Vladimir Terziev wrote: > Hi, > > i try to setup wireless access point at home, based on FreeBSD > 7.2R-i386, ral(4) wireless card and hostpad(8). > > I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. I > issued a custom SSL certificate for the hostapd(8) and put the following > directives in hostapd.conf: > > eap_server=0 > ca_cert=/usr/local/etc/myCA.crt.pem > server_cert=/usr/local/etc/hostapd.server.crt.pem > private_key=/usr/local/etc/hostapd.server.key.pem > private_key_passwd=some_pass > > When i tried to start the hostapd(8) i got the following errors: > > Line 15: unknown configuration item 'eap_server' > Line 16: unknown configuration item 'ca_cert' > Line 17: unknown configuration item 'server_cert' > Line 18: unknown configuration item 'private_key' > Line 19: unknown configuration item 'private_key_passwd' > > Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at all > and if "not" why ? 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). -- Paul From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 11:07:38 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B26931065675 for ; Thu, 18 Jun 2009 11:07:38 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from mx1.corp.idatanet.com (mx1.corp.idatanet.com [85.115.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id 31EFF8FC19 for ; Thu, 18 Jun 2009 11:07:37 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Received: from gibsvwin008.partygaming.local ([10.3.10.32]) by mx1.corp.idatanet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jun 2009 13:07:31 +0200 Received: from GIBSVWIN004X.partygaming.local ([10.3.10.228]) by gibsvwin008.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 13:07:33 +0200 Received: from SOFSVWIN004X.partygaming.local ([10.4.10.228]) by GIBSVWIN004X.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 13:07:32 +0200 Received: from 10.4.71.11 ([10.4.71.11]) by SOFSVWIN004X.partygaming.local ([10.4.10.230]) via Exchange Front-End Server corp.mail.partygaming.com ([10.3.10.32]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Jun 2009 11:07:31 +0000 Received: from daemon2.partygaming.local by corp.mail.partygaming.com; 18 Jun 2009 14:07:30 +0300 From: Vladimir Terziev To: "Paul B. Mahol" In-Reply-To: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> References: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Organization: GB Servicves Ltd. Date: Thu, 18 Jun 2009 14:07:30 +0300 Message-ID: <1245323250.28444.48.camel@daemon2.partygaming.local> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-OriginalArrivalTime: 18 Jun 2009 11:07:32.0723 (UTC) FILETIME=[FA55C430:01C9F004] Cc: freebsd-net@freebsd.org Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support 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, 18 Jun 2009 11:07:38 -0000 Hi Paul, is there some special reason behind this? Why the server is made part of the main distribution with stripped functionality ? Also, how can i enable it ? Thanks, Vladimir On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > On 6/18/09, Vladimir Terziev wrote: > > Hi, > > > > i try to setup wireless access point at home, based on FreeBSD > > 7.2R-i386, ral(4) wireless card and hostpad(8). > > > > I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. > I > > issued a custom SSL certificate for the hostapd(8) and put the > following > > directives in hostapd.conf: > > > > eap_server=3D0 > > ca_cert=3D/usr/local/etc/myCA.crt.pem > > server_cert=3D/usr/local/etc/hostapd.server.crt.pem > > private_key=3D/usr/local/etc/hostapd.server.key.pem > > private_key_passwd=3Dsome_pass > > > > When i tried to start the hostapd(8) i got the following errors: > > > > Line 15: unknown configuration item 'eap_server' > > Line 16: unknown configuration item 'ca_cert' > > Line 17: unknown configuration item 'server_cert' > > Line 18: unknown configuration item 'private_key' > > Line 19: unknown configuration item 'private_key_passwd' > > > > Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > all > > and if "not" why ? >=20 > 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). >=20 > -- > Paul >=20 >=20 This email and any attachments are confidential, and may be legally = privileged and protected by copyright. If you are not the intended = recipient dissemination or copying of this email is prohibited. If you = have received this in error, please notify the sender by replying by = email and then delete the email completely from your system.=20 Any views or opinions are solely those of the sender. This = communication is not intended to form a binding contract unless = expressly indicated to the contrary and properly authorised. Any actions = taken on the basis of this email are at the recipient's own risk. From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 14:24:15 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AD3F1065670 for ; Thu, 18 Jun 2009 14:24:15 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id E28948FC0C for ; Thu, 18 Jun 2009 14:24:14 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 168BC130EF8; Thu, 18 Jun 2009 18:24:14 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by mailrelay1.rambler.ru (Postfix) with ESMTP id BBECF130EF7; Thu, 18 Jun 2009 18:24:13 +0400 (MSD) Date: Thu, 18 Jun 2009 18:19:25 +0400 From: Igor Sysoev To: Bruce Evans Message-ID: <20090618141925.GG60354@rambler-co.ru> References: <20090610123301.GE40250@rambler-co.ru> <20090611114120.I21056@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20090611114120.I21056@delplex.bde.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 18062009 #2361103, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 8780 [Jun 18 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Method: white ip list X-SpamTest-Rate: 0 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: freebsd-net@FreeBSD.org Subject: Re: bge interrupt coalescing sysctls 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, 18 Jun 2009 14:24:15 -0000 On Thu, Jun 11, 2009 at 11:54:29AM +1000, Bruce Evans wrote: > On Wed, 10 Jun 2009, Igor Sysoev wrote: > > >For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: > >http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html > >However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken > >the patch. I'm not sure how to fix the collision, and since I do not > >use dynamic tuning > > That commit looked ugly (lots of internal API changes and bloat in interrupt > handlers in many network drivers to support polling which mostly shouldn't > be supported at all and mostly doesn't use the interrupt handlers). > > >I has left only static coalescing parameters in the patch > >and has added a loader tunable to set number of receive descriptors and > >read only sysctl to read the tunable. I usually use these parameters: > > > >/boot/loader.conf: > >hw.bge.rxd=512 > > > >/etc/sysctl.conf: > >dev.bge.0.rx_coal_ticks=500 > >dev.bge.0.tx_coal_ticks=10000 > >dev.bge.0.rx_max_coal_bds=64 > > These rx settings give to high a latency for me. Probably, however, I use this on a host that has 6000 packets/s. > >dev.bge.0.tx_max_coal_bds=128 > ># apply the above parameters > >dev.bge.0.program_coal=1 > > > >Could anyone commit it ? > > Not me, sorry. > > The patch is quite clean. If I committed then I would commit the > dynamic coalescing configuration separately anyway. So have you any objections if some one else will commit this patch ? > You can probably make hw.bge.rxd a sysctl too (it would take a down/up > to get it changed, but that is already needed for too many parameters > in network drivers anyway). I should use a sysctl for the ifq length > too. This could be done at a high level for each driver. Limiting > queue lengths may be a good way to reduce cache misses, while increasing > them is sometimes good for reducing packet loss. Do you mean simple command sequence: sysctl hw.bge.rxd=512 ifconfig down ifconfig up or SYSCTL_ADD_PROC for hw.bge.rxd ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 16:21:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBE441065670 for ; Thu, 18 Jun 2009 16:21:33 +0000 (UTC) (envelope-from news@markvoxx.com) Received: from mx.netcabo.pt (mx.netcabo.pt [212.113.174.24]) by mx1.freebsd.org (Postfix) with ESMTP id 66DAE8FC16 for ; Thu, 18 Jun 2009 16:21:33 +0000 (UTC) (envelope-from news@markvoxx.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEUAAz/OUpVi14p/2dsb2JhbACBL3krIYtlAYpjqGKQIoQIBYNN Received: from a85-139-94-41.cpe.netcabo.pt (HELO DOMUS) ([85.139.94.41]) by neti03smtpa.hdi.tvcabo with ESMTP; 18 Jun 2009 16:52:29 +0100 From: "news@markvoxx.com" To: freebsd-net@freebsd.org MIME-Version: 1.0 Date: Thu, 18 Jun 2009 16:52:30 +0100 Message-ID: <505656668421844159@smtpa.netcabo.pt> Content-Type: text/plain ; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: PRESSRELEASE MARK VOXX FEAT. MC GRACE =?iso-8859-1?q?=B4=B4_SUBM?= =?iso-8859-1?q?ISSION=B4=B4?= -->> OUTNOW 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, 18 Jun 2009 16:21:34 -0000 Clica na imagem para ir para a loja do BeatPort ! Click on the image to go to BeatPort Shop! www.myspace.com/djmarkvoxxproducer www.myspace.com/themcgracespace =20 To cancel your subscription to this newsletter, please reply to this m= essage with the word REMOVE in the Subject line. Para cancelar a subscri=E7=E3o desta newsletter, por favor responde a = esta mensagem com a palavra REMOVER no assunto.=20 From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 17:36:06 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D65106568D for ; Thu, 18 Jun 2009 17:36:06 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 46C9C8FC2A for ; Thu, 18 Jun 2009 17:36:06 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5IHa4GS088661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 10:36:05 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A3A7B04.2020906@freebsd.org> Date: Thu, 18 Jun 2009 10:36:04 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Vladimir Terziev References: <3a142e750906180355lf9bb1a9vd7133e878e57eff@mail.gmail.com> <1245323250.28444.48.camel@daemon2.partygaming.local> In-Reply-To: <1245323250.28444.48.camel@daemon2.partygaming.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, "Paul B. Mahol" Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support 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, 18 Jun 2009 17:36:07 -0000 EAP/TLS and TTLS should be configured by default in HEAD. Not sure what is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ the functionality you want by definitions to your src.conf: HOSTAPD_CFLAGS HOSTAPD_DPADD HOSTAPD_LDADD (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check usr.sbin/wpa/hostapd/Makefile). As to what should be enabled by default, I can only say that I tried to choose the most common setup as the default. Choosing this configuration also balances between bloat and inclusion of code that might not be as well audited and/or tested as other code. Hence the default setup used to be WPA-PSK only but has since grown to include various EAP flavors. My assumption was that anyone building a system using these tools would want to go through and choose what they wanted anyway so enabling everything was a bad idea. Sam Vladimir Terziev wrote: > Hi Paul, > > is there some special reason behind this? Why the server is made part of > the main distribution with stripped functionality ? > > Also, how can i enable it ? > > Thanks, > > Vladimir > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > >> On 6/18/09, Vladimir Terziev wrote: >> >>> Hi, >>> >>> i try to setup wireless access point at home, based on FreeBSD >>> 7.2R-i386, ral(4) wireless card and hostpad(8). >>> >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. >>> >> I >> >>> issued a custom SSL certificate for the hostapd(8) and put the >>> >> following >> >>> directives in hostapd.conf: >>> >>> eap_server=0 >>> ca_cert=/usr/local/etc/myCA.crt.pem >>> server_cert=/usr/local/etc/hostapd.server.crt.pem >>> private_key=/usr/local/etc/hostapd.server.key.pem >>> private_key_passwd=some_pass >>> >>> When i tried to start the hostapd(8) i got the following errors: >>> >>> Line 15: unknown configuration item 'eap_server' >>> Line 16: unknown configuration item 'ca_cert' >>> Line 17: unknown configuration item 'server_cert' >>> Line 18: unknown configuration item 'private_key' >>> Line 19: unknown configuration item 'private_key_passwd' >>> >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at >>> >> all >> >>> and if "not" why ? >>> >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). >> >> -- >> Paul >> >> >> > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 19:23:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 343551065688 for ; Thu, 18 Jun 2009 19:23:22 +0000 (UTC) (envelope-from axel@freakout.de) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by mx1.freebsd.org (Postfix) with ESMTP id AF61C8FC0A for ; Thu, 18 Jun 2009 19:23:21 +0000 (UTC) (envelope-from axel@freakout.de) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1245353000; l=1450; s=domk; d=freakout.de; h=Content-Type:Content-Transfer-Encoding:MIME-Version:Date:To:Subject: From:X-RZG-CLASS-ID:X-RZG-AUTH; bh=ZPl0HdnEF/MJCkSRLJwwZ/RElIM=; b=IefAwwRykpqRvSS7l08LU9OkF+DMBtXib78//ELZjPAg+pJP9vODieYCmrctYFjjDit tXWwmj9/pEzxdYJa9l5Anik8BlO3mtPLDrDVZANT6TaR8zn9JVMBmfvwlW7/Q/G5gKlAx Ah4StgRvaR/4p1vwb+vfKTz0P3f0iwdOeAk= X-RZG-AUTH: :O2kGeEG7b/pS1EurTn64hihVkLmFZJY7jw1n/V02/ThbTLOu2TLyl4CP2OCy6HE= X-RZG-CLASS-ID: mo00 Received: from freakout.homeip.net (pD9E7F704.dip.t-dialin.net [217.231.247.4]) by post.strato.de (fruni mo35) (RZmta 18.42) with ESMTP id a042bfl5IIEG3c for ; Thu, 18 Jun 2009 21:11:22 +0200 (MEST) Received: (from axel@localhost) by bongo.freakout.de (8.14.3/8.14.3) id n5IJAJ2u007974 for freebsd-net@freebsd.org; Thu, 18 Jun 2009 21:10:19 +0200 From: Axel Reinhold Message-Id: <200906181910.n5IJAJ2u007974@bongo.freakout.de> To: freebsd-net@freebsd.org Date: Thu, 18 Jun 2009 21:10:19 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL124c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; format=text; x-action=sign; charset="US-ASCII" X-Logged: Logged by bongo.freakout.de as n5IJAJ2u007974 at Thu Jun 18 21:10:19 2009 Subject: Bridging and using the interfaces concurrently 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, 18 Jun 2009 19:23:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have two FreeBSD-7.1 servers in a data-center hosted. Both servers have two em[01] gigabit network links. First server's (call it "first") em0 is connected to the data-centers internet uplink - the em1 is connected to the seconds servers (call it "second") em1. first's /etc/rc.conf: ifconfig_em0="inet 212.144.103.230 netmask 255.255.254.0" defaultrouter="212.144.102.1" ifconfig_em1="inet 192.168.102.1 netmask 255.255.255.0" seconds's /etc/rc.conf: ifconfig_em1="inet 192.168.102.131 netmask 255.255.255.0" In this way the 192.168.102/24 network is for private connection between the two servers and "second" is not connected to the internet at all. Since i would have to pay extra charges to get the "second" server also connected to the internet, i thought of bridging the em0 and em1 of "first" and to alias another ip for the second server (i have more ip's in the data-center left) on "seconds" em1. Is this possible? What would i have to setup? The private 192.168.102/24 network should remain intakt! I just want to bridge "seconds" em1-MAC to the data-centers switch-port which is connected to "first" em0. Any help? Or is this not possible? Axel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9-PB (GNU/Linux) iD8DBQFKOpEIHQ9JwE2bDw0RAh9mAKCy2R7DAZYzqLfU/wKlwHiZWsQfAwCfUGne 7nsmXfuWgxyo+HAM76VRU6w= =LKp+ -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Jun 18 20:33:53 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0074106564A for ; Thu, 18 Jun 2009 20:33:53 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) by mx1.freebsd.org (Postfix) with ESMTP id 904378FC18 for ; Thu, 18 Jun 2009 20:33:53 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from relay6.relay.iad.emailsrvr.com (localhost [127.0.0.1]) by relay6.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id 3446C7B91BD for ; Thu, 18 Jun 2009 16:18:33 -0400 (EDT) Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 063BD7B72F8; Thu, 18 Jun 2009 16:18:32 -0400 (EDT) Message-ID: <4A3AA118.9020609@xiplink.com> Date: Thu, 18 Jun 2009 16:18:32 -0400 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Pyun YongHyeon Content-Type: multipart/mixed; boundary="------------000603060304010602030605" Cc: freebsd-net@freebsd.org Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering 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, 18 Jun 2009 20:33:54 -0000 This is a multi-part message in MIME format. --------------000603060304010602030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, Concerning this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I have one of those 'strange' silicon here: FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 kernel: mskc2: port 0xee00-0xeeff mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 kernel: msk2: on mskc2 kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 kernel: miibus2: on msk2 kernel: e1000phy2: PHY 0 on miibus2 kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved the problem. But applying the attached patch (written by Pyun I believe) also solved the problem. I think your patch should be committed for others to benefit. Best regards, Karim. --------------000603060304010602030605 Content-Type: text/plain; name="msk_EC.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msk_EC.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 186497) +++ sys/dev/msk/if_msk.c (working copy) @@ -1355,27 +1355,25 @@ CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); /* Set the status list last index. */ CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { - /* WA for dev. #4.3 */ - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); - /* WA for dev. #4.18 */ - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); - } else { - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); - else - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); - } /* - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. + * Interrupt moderation and coalescing frames should be + * controllable with sysctl variables or loader tunables + * but the relationship between status updates and + * interrupt moderation are not clear. Some hardware + * revisions seem to very sensitive to these parameters + * and could be resulted in poor performance as well as + * non-working situation if improper values were chosen. */ + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); + else + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); /* Enable status unit. */ CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); @@ -3586,6 +3584,10 @@ domore = msk_handle_events(sc); if ((status & Y2_IS_STAT_BMU) != 0) CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ); + if (CSR_READ_1(sc, STAT_TX_TIMER_CTRL) == TIM_START) { + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_STOP); + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_START); + } if (ifp0 != NULL && (ifp0->if_drv_flags & IFF_DRV_RUNNING) != 0 && !IFQ_DRV_IS_EMPTY(&ifp0->if_snd)) --------------000603060304010602030605-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 00:32:58 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A451D1065673 for ; Fri, 19 Jun 2009 00:32:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id 72DA28FC1E for ; Fri, 19 Jun 2009 00:32:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pxi41 with SMTP id 41so805939pxi.3 for ; Thu, 18 Jun 2009 17:32:58 -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=HsJ39iszBvwhJXCtDUql4xjAPZ0rhyk4HzzvXuWc8ZA=; b=DI/918GEx5aBceMI+YjzLaoR4zAGmmowgHmT/becUgjLu5DZSON597Mxiqw/YqJRgY /g2LImDbAWPfNJirp4Na17Ndoek8rB0E0SymDqdTRk7iCu8cfwakOQ3RPdkvA8Ay4wDl VN51VpmH8g2ZLnvume3KFq6hbXPQMsnpxibYk= 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=gwHbDGGVjLfSv7unyTK55MHWESqTopxZPmWCl/h3q/4Ajx/8pkmwyXY/C1RTYo1OCZ 1KSHnj1gJia7/KeN+FE5t59tBjR5iAgb8ngQKU4+J+0CdYO5Hj2ebK9AoQfkNw1UewzE 4ktBnbwazFm8FkGfKhoLa8ykp1BdMshzajDas= Received: by 10.115.14.1 with SMTP id r1mr3059542wai.23.1245371578060; Thu, 18 Jun 2009 17:32:58 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id m34sm1806760waf.21.2009.06.18.17.32.56 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 17:32:57 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 19 Jun 2009 09:37:09 +0900 From: Pyun YongHyeon Date: Fri, 19 Jun 2009 09:37:09 +0900 To: Karim Fodil-Lemelin Message-ID: <20090619003709.GF93360@michelle.cdnetworks.co.kr> References: <4A3AA118.9020609@xiplink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3AA118.9020609@xiplink.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [msk] watchdog timeout (missed Tx interrupts) -- recovering 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: Fri, 19 Jun 2009 00:32:58 -0000 On Thu, Jun 18, 2009 at 04:18:32PM -0400, Karim Fodil-Lemelin wrote: > Hello, > Hi, > Concerning this pr: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I > have one of those 'strange' silicon here: > > FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 > > kernel: mskc2: port 0xee00-0xeeff > mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 > kernel: msk2: on > mskc2 > kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 > kernel: miibus2: on msk2 > kernel: e1000phy2: PHY 0 on miibus2 > kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseTX-FDX, auto > > Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved > the problem. But applying the attached patch (written by Pyun I believe) > also solved the problem. > > I think your patch should be committed for others to benefit. > Thanks a lot! I'll write a follow-up mail to the PR. > Best regards, > > Karim. > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 00:40:06 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1470A106566C for ; Fri, 19 Jun 2009 00:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 021EE8FC08 for ; Fri, 19 Jun 2009 00:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5J0e5qW069496 for ; Fri, 19 Jun 2009 00:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5J0e519069495; Fri, 19 Jun 2009 00:40:05 GMT (envelope-from gnats) Date: Fri, 19 Jun 2009 00:40:05 GMT Message-Id: <200906190040.n5J0e519069495@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pyun YongHyeon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 00:40:06 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: Pyun YongHyeon To: Duckhawk Cc: bug-followup@FreeBSD.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Fri, 19 Jun 2009 09:43:05 +0900 --47eKBCiAZYFK5l32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 22, 2009 at 07:50:03AM +0000, Duckhawk wrote: > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Duckhawk > To: bug-followup@FreeBSD.org, skylord@linkline.ru > Cc: > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- > recovering > Date: Sun, 22 Feb 2009 12:26:51 +0500 > > --001636c5a26744f2de04637ccfc6 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > also, same problem. D-Link DGE-560T > > %uname -a > FreeBSD 7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009 > duckhawk@:/usr/obj/usr/src/sys/GENERIC i386 > > %dmesg | grep "msk" > mskc0: port 0x7000-0x70ff mem > 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1 > msk0: on mskc0 > msk0: Ethernet address: 00:1b:11:79:53:eb > miibus0: on msk0 > mskc0: [FILTER] > > %pciconf -lv > mskc0@pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186 > rev=0x13 hdr=0x00 > vendor = 'D-Link System Inc' > device = 'DGE-560T PCIe Gigabit Ethernet Adapter' > class = network > subclass = ethernet Please try the following patch. --47eKBCiAZYFK5l32 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.EC.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 194467) +++ sys/dev/msk/if_msk.c (working copy) @@ -1387,27 +1387,26 @@ CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); /* Set the status list last index. */ CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { - /* WA for dev. #4.3 */ - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); - /* WA for dev. #4.18 */ - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); - } else { - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); - else - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); - } /* - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. + * XXX + * Interrupt moderation and coalescing frames should be + * controllable with sysctl variables or loader tunables + * but the relationship between status updates and + * interrupt moderation are not clear to me. Some hardware + * revisions seem to very sensitive to these parameters + * and could be resulted in poor performance as well as + * non-working situation if improper values were chosen. */ + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); + else + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); /* Enable status unit. */ CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); --47eKBCiAZYFK5l32-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 00:50:06 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460FC106564A for ; Fri, 19 Jun 2009 00:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 33D708FC14 for ; Fri, 19 Jun 2009 00:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5J0o6AX076485 for ; Fri, 19 Jun 2009 00:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5J0o6PN076484; Fri, 19 Jun 2009 00:50:06 GMT (envelope-from gnats) Date: Fri, 19 Jun 2009 00:50:06 GMT Message-Id: <200906190050.n5J0o6PN076484@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pyun YongHyeon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 00:50:06 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: Pyun YongHyeon To: sam Cc: yongari@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Fri, 19 Jun 2009 09:40:46 +0900 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 31, 2008 at 04:06:42PM +0400, sam wrote: > ----------------------------------------------- > Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx > interrupts) -- recovering > Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx > interrupts) -- recovering > ----------------------------------------------- > > ----------------------------------------------- > Jul 29 23:18:28 moon3 kernel: mskc0: Ethernet> port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device > 0.0 on pci2 > Jul 29 23:18:28 moon3 kernel: msk0: Yukon EC Id 0xb6 Rev 0x02> on mskc0 > > Jul 29 23:18:28 moon3 kernel: miibus0: on msk0 > ----------------------------------------------- > > ----------------------------------------------- > FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 > 15:00:14 MSD 2008 root@moon3:/usr/src/sys/i386/compile/MOON3 i386 > ----------------------------------------------- > > I confirm this problem. > > /Vladimir Ermakov > > Would you try attached patch and let me know hot it goes? --pQhZXvAqiZgbeUkD Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.EC.patch" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 194467) +++ sys/dev/msk/if_msk.c (working copy) @@ -1387,27 +1387,26 @@ CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); /* Set the status list last index. */ CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { - /* WA for dev. #4.3 */ - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); - /* WA for dev. #4.18 */ - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); - } else { - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); - else - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); - } /* - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. + * XXX + * Interrupt moderation and coalescing frames should be + * controllable with sysctl variables or loader tunables + * but the relationship between status updates and + * interrupt moderation are not clear to me. Some hardware + * revisions seem to very sensitive to these parameters + * and could be resulted in poor performance as well as + * non-working situation if improper values were chosen. */ + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); + else + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); /* Enable status unit. */ CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); --pQhZXvAqiZgbeUkD-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 07:10:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46347106567D for ; Fri, 19 Jun 2009 07:10: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 1990B8FC17 for ; Fri, 19 Jun 2009 07:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5J7A223078752 for ; Fri, 19 Jun 2009 07:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5J7A2cD078751; Fri, 19 Jun 2009 07:10:02 GMT (envelope-from gnats) Date: Fri, 19 Jun 2009 07:10:02 GMT Message-Id: <200906190710.n5J7A2cD078751@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Daniel Duerr Cc: Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Duerr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 07:10:04 -0000 The following reply was made to PR kern/132107; it has been noted by GNATS. From: Daniel Duerr To: bug-followup@FreeBSD.org, adaugherity@tamu.edu Cc: Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface Date: Thu, 18 Jun 2009 23:51:09 -0700 Having the same issue here and the workaround isn't working for me -- it preserves the advskew but the vpn doesn't seem to work without the devd attach event. Hope someone will fix this soon. From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 08:55:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94867106564A for ; Fri, 19 Jun 2009 08:55:07 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 488BE8FC08 for ; Fri, 19 Jun 2009 08:55:07 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:Sender; b=lKbRcvpS+9c++MlsgLVQ26JUvRKBvVLSEtqVa6E0xG2ErT89DRa867RFpf9YudLODONnVl58NU22f73MXbUGBSm9CnQ7RYiR+3cAn2nUURA8sfeaHDosGnHzJIuFTKUAFkbb+wwinl78rfXYKd4LYKaohteiGTr7y2USBWkw1EA=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MHZsH-0002Ge-PO; Fri, 19 Jun 2009 12:55:05 +0400 Date: Fri, 19 Jun 2009 12:55:03 +0400 From: Eygene Ryabinkin To: Axel Reinhold Message-ID: References: <200906181910.n5IJAJ2u007974@bongo.freakout.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200906181910.n5IJAJ2u007974@bongo.freakout.de> Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@freebsd.org Subject: Re: Bridging and using the interfaces concurrently X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:55:07 -0000 Axel, good day. Thu, Jun 18, 2009 at 09:10:19PM +0200, Axel Reinhold wrote: > Since i would have to pay extra charges to get the "second" > server also connected to the internet, i thought of bridging > the em0 and em1 of "first" and to alias another ip for the > second server (i have more ip's in the data-center left) on > "seconds" em1. > > Is this possible? What would i have to setup? > The private 192.168.102/24 network should remain intakt! NAT the "second" box on your "first" one and that's it. Bridging won't help much here, because your "second"s IPs are unroutable, so someone will still need to translate them. If your intention is to provide only client-level connectivity to the "second" box (when it initiates all connections), simple NAT will work. If you need some port to be opened at the "second" host and the should be reachable =66rom the outside, then you'll additionally need port mirroring. Or, if you really want to spend an extra IP for the second box, then just binat (in the terms of pf.conf(5)) your private address to the second IP on the "first" server. The exact solution for NAT depends on the firewall type you're using on the "first" server. For ipfw you probably should look at the natd(8), for ipfilter -- at ipnat(8), for pf -- at pf(4) and pf.conf(5). May be netgraph(4) will be of some help, but this adds some extra complexity for people who aren't familiar with Netgraph concepts and tools. If you really want bridging, then the easiest thing will be to create two VLAN (if_vlan(4)) interfaces on your link between two servers: one VLAN for the 192.168.102/24 network and one for the public network. After this, packets from 192.168 will flow as they flowed before, and you should bridge your "first"'s external interface with the second VLAN interface on this host. Put your extra external IP to the other side of the VLAN interface and it should do what you need. NAT should be easier, bridging should be faster, but the difference strongly depends on the type of traffic and usage of the inter-server link. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 09:43:36 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22A01065672; Fri, 19 Jun 2009 09:43:36 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-px0-f203.google.com (mail-px0-f203.google.com [209.85.216.203]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1158FC22; Fri, 19 Jun 2009 09:43:36 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by mail-px0-f203.google.com with SMTP id 41so1059597pxi.3 for ; Fri, 19 Jun 2009 02:43:36 -0700 (PDT) Received: by 10.114.157.11 with SMTP id f11mr3715401wae.75.1245402761788; Fri, 19 Jun 2009 02:12:41 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id v32sm5403380wah.13.2009.06.19.02.12.39 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 02:12:40 -0700 (PDT) Date: Thu, 18 Jun 2009 23:12:45 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: net@freebsd.org, current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: mbuf layout optimizations 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, 19 Jun 2009 09:43:37 -0000 http://people.freebsd.org/~jeff/mbuf2.diff Hello, This is a call for testers and feedback on my mbuf layout improvements. I'm trying to decide whether I will push to have these included in 8.0. After reducing the scope slightly from my last patch, I have not encountered any problems. Kip Macy has also been using it for the past few weeks without issue. You should not expect any functional changes from this patch. The goal is mostly to pave the way fors more sensible mbuf handling in the future, although it does offer a few performance benefits. The only issue is that cxgb support requires another set of patches from Kip. If anyone needs those I will prod him to reply with that diff. Thanks, Jeff From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 10:55:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 870BC106566C for ; Fri, 19 Jun 2009 10:55:34 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from mx1.corp.idatanet.com (mx1.corp.idatanet.com [85.115.136.170]) by mx1.freebsd.org (Postfix) with ESMTP id 065178FC16 for ; Fri, 19 Jun 2009 10:55:33 +0000 (UTC) (envelope-from vladimirt@PartyGaming.com) Received: from gibsvwin008.partygaming.local ([10.3.10.32]) by mx1.corp.idatanet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jun 2009 12:55:25 +0200 Received: from GIBSVWIN004X.partygaming.local ([10.3.10.228]) by gibsvwin008.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 12:55:28 +0200 Received: from SOFSVWIN004X.partygaming.local ([10.4.10.228]) by GIBSVWIN004X.partygaming.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 12:55:28 +0200 Received: from 10.4.71.11 ([10.4.71.11]) by SOFSVWIN004X.partygaming.local ([10.4.10.230]) via Exchange Front-End Server corp.mail.partygaming.com ([10.3.10.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Jun 2009 10:55:27 +0000 Received: from daemon2.partygaming.local by corp.mail.partygaming.com; 19 Jun 2009 13:55:26 +0300 From: Vladimir Terziev To: Sam Leffler In-Reply-To: <4A3A7B04.2020906@freebsd.org> References: <4A3A7B04.2020906@freebsd.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: GB Servicves Ltd. Date: Fri, 19 Jun 2009 13:55:26 +0300 Message-Id: <1245408926.31855.26.camel@daemon2.partygaming.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-OriginalArrivalTime: 19 Jun 2009 10:55:28.0123 (UTC) FILETIME=[74DA54B0:01C9F0CC] Cc: freebsd-net@freebsd.org, "Paul B. Mahol" Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support 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, 19 Jun 2009 10:55:34 -0000 Thanks Sam, What should i put for HOSTAPD_CFLAGS, HOSTAPD_DPADD, HOSTAPD_LDADD or WPA_SUPPLICANT_* (not sure which ones i should use) in order to get hostapd rebuilt with the functionality i want ? Regards, Vladimir On Thu, 2009-06-18 at 20:36 +0300, Sam Leffler wrote: > EAP/TLS and TTLS should be configured by default in HEAD. Not sure > what > is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ > the functionality you want by definitions to your src.conf: > > HOSTAPD_CFLAGS > HOSTAPD_DPADD > HOSTAPD_LDADD > > (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check > usr.sbin/wpa/hostapd/Makefile). > > As to what should be enabled by default, I can only say that I tried > to > choose the most common setup as the default. Choosing this > configuration also balances between bloat and inclusion of code that > might not be as well audited and/or tested as other code. Hence the > default setup used to be WPA-PSK only but has since grown to include > various EAP flavors. My assumption was that anyone building a system > using these tools would want to go through and choose what they wanted > anyway so enabling everything was a bad idea. > > Sam > > > Vladimir Terziev wrote: > > Hi Paul, > > > > is there some special reason behind this? Why the server is made > part of > > the main distribution with stripped functionality ? > > > > Also, how can i enable it ? > > > > Thanks, > > > > Vladimir > > > > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > > > >> On 6/18/09, Vladimir Terziev wrote: > >> > >>> Hi, > >>> > >>> i try to setup wireless access point at home, based on FreeBSD > >>> 7.2R-i386, ral(4) wireless card and hostpad(8). > >>> > >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS > authentication. > >>> > >> I > >> > >>> issued a custom SSL certificate for the hostapd(8) and put the > >>> > >> following > >> > >>> directives in hostapd.conf: > >>> > >>> eap_server=0 > >>> ca_cert=/usr/local/etc/myCA.crt.pem > >>> server_cert=/usr/local/etc/hostapd.server.crt.pem > >>> private_key=/usr/local/etc/hostapd.server.key.pem > >>> private_key_passwd=some_pass > >>> > >>> When i tried to start the hostapd(8) i got the following errors: > >>> > >>> Line 15: unknown configuration item 'eap_server' > >>> Line 16: unknown configuration item 'ca_cert' > >>> Line 17: unknown configuration item 'server_cert' > >>> Line 18: unknown configuration item 'private_key' > >>> Line 19: unknown configuration item 'private_key_passwd' > >>> > >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > >>> > >> all > >> > >>> and if "not" why ? > >>> > >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's > hostapd(8). > >> > >> -- > >> Paul > >> > >> > >> > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > > > > > > > > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 12:37:17 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA9F1065670 for ; Fri, 19 Jun 2009 12:37:17 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 115328FC08 for ; Fri, 19 Jun 2009 12:37:17 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 0AA0B2798B8 for ; Fri, 19 Jun 2009 14:37:15 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 2B57017024; Fri, 19 Jun 2009 15:00:41 +0200 (CEST) Date: Fri, 19 Jun 2009 15:00:41 +0200 From: VANHULLEBUS Yvan To: freebsd-net@FreeBSD.org Message-ID: <20090619130040.GA53996@zeninc.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline Cc: Subject: IPsec crash, patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:37:17 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all. We (NETASQ) had some IPsec related kernel crashes, and hunted them, here are some informations and a possible patch: First, problem only occurs when asynchronous crypto is done (hardware encryption such as hifn cards, or software patch to do encryption on a separate kthread when having multiple CPUs). More or less exploitable backtraces always shows a problem with an isr which seems to be used but already freed. While looking at the code, we noticed that there is probably a race condition when using asynchronous crypto: ip_output (well, ip_ipsec_output() now) releases refcnt to the SPD entry when IPsec processing needs to be done, but SPD's isr will still be used by [esp|ah|ipcomp]_output_cb(). The attached patch moves the KEY_FREESP() from ip_ipsec_output() to [esp|ah|ipcomp]_output_cb() when there will be IPsec processing (when ip_ipsec_output()returns -1). (note for George and Bjoern: this is a newer version of the patch, which also fixes a refcnt leak). This patches solves our problem (no more crashes for a week, when we had at least 2-3 crashes / day), and has also successfully passed our non regression testsuite. As it may still have some unexpected impacts on other parts of the code, I'd like to have some feedback on it before commiting it. Thanks, Yvan. --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-xform_cb-freesp Index: netinet/ip_ipsec.c =================================================================== --- netinet/ip_ipsec.c (revision 193698) +++ netinet/ip_ipsec.c (working copy) @@ -405,8 +405,6 @@ done: KEY_FREESP(&sp); return 0; reinjected: - if (sp != NULL) - KEY_FREESP(&sp); return -1; bad: if (sp != NULL) Index: netipsec/xform_esp.c =================================================================== --- netipsec/xform_esp.c (revision 193698) +++ netipsec/xform_esp.c (working copy) @@ -979,11 +979,15 @@ esp_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ipcomp.c =================================================================== --- netipsec/xform_ipcomp.c (revision 193698) +++ netipsec/xform_ipcomp.c (working copy) @@ -588,11 +588,15 @@ ipcomp_output_cb(struct cryptop *crp) error = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); return error; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ah.c =================================================================== --- netipsec/xform_ah.c (revision 193698) +++ netipsec/xform_ah.c (working copy) @@ -1210,11 +1210,15 @@ ah_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + if(isr->sp != NULL) /* should NEVER be NULL !!! */ + KEY_FREESP(isr->sp); if (m) m_freem(m); free(tc, M_XDATA); --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-xform_freespfix-3 Index: netinet/ip_ipsec.c =================================================================== --- netinet/ip_ipsec.c (revision 194337) +++ netinet/ip_ipsec.c (working copy) @@ -347,6 +347,11 @@ ip_ipsec_output(struct mbuf **m, struct /* NB: callee frees mbuf */ *error = ipsec4_process_packet(*m, sp->req, *flags, 0); + + /* Release SP now if an error occured (including acquire) */ + if(error) + KEY_FREESP(&sp); + if (*error == EJUSTRETURN) { /* * We had a SP with a level of 'use' and no SA. We @@ -358,6 +363,7 @@ ip_ipsec_output(struct mbuf **m, struct ip->ip_off = ntohs(ip->ip_off); goto done; } + /* * Preserve KAME behaviour: ENOENT can be returned * when an SA acquire is in progress. Don't propagate @@ -405,8 +411,6 @@ done: KEY_FREESP(&sp); return 0; reinjected: - if (sp != NULL) - KEY_FREESP(&sp); return -1; bad: if (sp != NULL) Index: netipsec/xform_esp.c =================================================================== --- netipsec/xform_esp.c (revision 194337) +++ netipsec/xform_esp.c (working copy) @@ -979,11 +979,15 @@ esp_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ipcomp.c =================================================================== --- netipsec/xform_ipcomp.c (revision 194337) +++ netipsec/xform_ipcomp.c (working copy) @@ -588,11 +588,15 @@ ipcomp_output_cb(struct cryptop *crp) error = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); return error; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); if (m) m_freem(m); free(tc, M_XDATA); Index: netipsec/xform_ah.c =================================================================== --- netipsec/xform_ah.c (revision 194337) +++ netipsec/xform_ah.c (working copy) @@ -1210,11 +1210,15 @@ ah_output_cb(struct cryptop *crp) err = ipsec_process_done(m, isr); KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); return err; bad: if (sav) KEY_FREESAV(&sav); IPSECREQUEST_UNLOCK(isr); + IPSEC_ASSERT(isr->sp != NULL, ("NULL isr->sp")); + KEY_FREESP(&isr->sp); if (m) m_freem(m); free(tc, M_XDATA); --82I3+IH0IqGh5yIs-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 12:38:54 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387F1106566C for ; Fri, 19 Jun 2009 12:38:54 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id EE39C8FC15 for ; Fri, 19 Jun 2009 12:38:53 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 467172798B8 for ; Fri, 19 Jun 2009 14:38:53 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 7693617024; Fri, 19 Jun 2009 15:02:19 +0200 (CEST) Date: Fri, 19 Jun 2009 15:02:19 +0200 From: VANHULLEBUS Yvan To: freebsd-net@FreeBSD.org Message-ID: <20090619130219.GB53996@zeninc.net> References: <20090619130040.GA53996@zeninc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090619130040.GA53996@zeninc.net> User-Agent: All mail clients suck. This one just sucks less. Cc: Subject: Re: IPsec crash, patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:38:54 -0000 Sorry, I made a mistake and send both an older version and the latest version of the patch. The good one is patch-xform_freespfix-3 Yvan. From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 14:56:02 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6803B1065688 for ; Fri, 19 Jun 2009 14:56:02 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63904.mail.re1.yahoo.com (web63904.mail.re1.yahoo.com [69.147.97.119]) by mx1.freebsd.org (Postfix) with SMTP id EC3E48FC08 for ; Fri, 19 Jun 2009 14:56:01 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 18682 invoked by uid 60001); 19 Jun 2009 14:56:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245423361; bh=HIjBsBlWA083HrJ6pYHe5T5VUqMyx11A+b1Cju7fSu4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5S01+L3WDBiNOr4jIaYeXPbPjafd/x2nrQZj/JIhWQdRYudjB/sgcCWrm4Mn26Z89/Rkfn/RgS3FkJu43E0sejnFU5AIwqQIcGCf7MSC2jP040eKOhZv463zUTiJTjnJkp8ES+7UA6ltjKmgcoo27pdzlSxm72SvcAGJ8Sf7wRg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3DZxNQpg9RgHacSXg7FqWkhKz7rXb5I+kl66rioddjuF59Zu9WvTRvHmnLAvu94+d6APQhvMWkueHEAVHa6N0Bf+bG9y77b4EsmQeqjUJDLTKEW0+dgWACxJafwx+s+l4pS8ZV8aQzOScl/wRd02K23dizNAkgMFbpajwDEkz78=; Message-ID: <436489.18496.qm@web63904.mail.re1.yahoo.com> X-YMail-OSG: PYmr2ZIVM1lsel7fvE8OIyoBBDPt3DZ3Ki4oymK6PtasvK50iy2XwEVcxhzmM2.R6W.vWAFSkKK4obOeGcZT0X1flLGqb5I9Ty_KRxgrDL59v7_E8Sww1w0PH5_DnOo9pIiGRQDogv7WbisW0A7j.jcRAd_CuJVujhGvj_U2Q9Y7dvCZiI.eSbGYSqVdqbg.neOcEKl2B46cesDfE1aj40niJ9oaZbtfC7qgP9YFntGUVzgAwwQ9JN8bw__g3qgZVYcecPmIjOFftMo93Ogwm86_BTjrjcPBW04pqzJwDBhglBgNWCcvubq1vRL1h4Jc2bTLESqRXdzMT8bjMWa6lvs- Received: from [66.176.162.245] by web63904.mail.re1.yahoo.com via HTTP; Fri, 19 Jun 2009 07:56:00 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Fri, 19 Jun 2009 07:56:00 -0700 (PDT) From: Barney Cordoba To: freebsd-net@FreeBSD.org, Michael MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 14:56:02 -0000 =0A=0A--- On Wed, 6/17/09, Michael wrote:=0A=0A> Fr= om: Michael =0A> Subject: Re: kern/135222: [igb] low= speed routing between two igb interfaces=0A> To: freebsd-net@FreeBSD.org= =0A> Date: Wednesday, June 17, 2009, 9:40 PM=0A> The following reply was ma= de to PR=0A> kern/135222; it has been noted by GNATS.=0A> =0A> From: Michae= l =0A> To: Barney Cordoba = =0A> Cc: freebsd-gnats-submit@FreeBSD.org=0A> Subject: Re: kern/135222: [ig= b] low speed routing between=0A> two igb interfaces=0A> Date: Thu, 18 Jun 2= 009 03:32:15 +0200=0A> =0A> Barney Cordoba wrote:=0A> > =0A> > =0A> > -= -- On Wed, 6/17/09, Michael =0A> wrote:=0A> > =0A> = >> From: Michael =0A> >> Subject: Re: kern/135222:= [igb] low speed routing=0A> between two igb interfaces=0A> >> To: "Barney= Cordoba" =0A> >> Cc: freebsd-net@FreeBSD.org=0A= > >> Date: Wednesday, June 17, 2009, 5:28 PM=0A> >> Barney Cordoba wrote:= =0A> >>>=0A> >>> --- On Fri, 6/12/09, Michael =0A>= >> wrote:=0A> >>>> From: Michael =0A> >>>> Subje= ct: Re: kern/135222: [igb] low speed=0A> routing=0A> >> between two igb in= terfaces=0A> >>>> To: freebsd-net@FreeBSD.org=0A> >>>> Date: Friday, June= 12, 2009, 5:50 AM=0A> >>>> The following reply was made to PR=0A> >>>> k= ern/135222; it has been noted by GNATS.=0A> >>>>=0A> >>>> From: Michael <= freebsdusb@bindone.de>=0A> >>>> To: Cc: freebsd-gnats-submit@FreeBSD.org= =0A> >>>> Subject: Re: kern/135222: [igb] low speed=0A> routing=0A> >> be= tween=0A> >>>> two igb interfaces=0A> >>>> Date: Fri, 12 Jun 2009 11:45:4= 7 +0200=0A> >>>>=0A> >>>>=A0=A0=A0The original poster=0A> reported that t= he=0A> >> suggested fix works=0A> >>>> for him:=0A> >>>>=A0=A0=A0---=0A>= >>>>=A0=A0=A0Hello Michael,=0A> >>>>=A0=A0=A0=0A> >>>>=A0=A0=A0Thank yo= u. It's=0A> working.=0A> >>>>=A0=A0=A0=0A> >>>>=A0=A0=A0I consider it nec= essary=0A> to put this into the=0A> >> release=0A> >>>> errata.=0A> >>>>= =A0=A0=A0=0A> >>>>=A0=A0=A0=0A> >>>>=A0=A0=A0Mishustin Andrew wrote:=0A> = >>>>=A0=A0=A0>> Number:=A0=0A> =A0=A0=A0=0A> >>>>=A0 =A0=A0=A0135222=0A> = >>>>=A0=A0=A0>>=0A> Category:=A0=A0=A0=0A> >>=A0 =A0 kern=0A> >>>>=A0=A0= =A0>>=0A> Synopsis:=A0=A0=A0=0A> >>=A0 =A0 [igb]=0A> >>>> low speed routi= ng between two igb=0A> interfaces=0A> >>>>=A0=A0=A0>>=0A> Confidential:=A0= =A0=A0no=0A> >>>>=A0=A0=A0>>=0A> Severity:=A0=A0=A0=0A> >>=A0 =A0 serious= =0A> >>>>=A0=A0=A0>>=0A> Priority:=A0=A0=A0=0A> >>=A0 =A0 medium=0A> >>>= >=A0=A0=A0>>=0A> Responsible:=A0=A0=A0=0A> >> freebsd-bugs=0A> >>>>=A0=A0= =A0>> State:=A0=0A> =A0 =A0=A0=A0=0A> >>=A0=A0=A0open=0A> >>>>=A0=A0=A0>>= Quarter:=A0=0A> =A0 =A0=A0=A0=0A> >>>>=A0=A0=A0>>=0A> Keywords:=A0=A0=A0= =0A> >>=A0 =A0 =0A> >>>>=A0=A0=A0>> Date-Required:=0A> >>>>=A0=A0=A0>> C= lass:=A0=0A> =A0 =A0=A0=A0=0A> >>=A0=A0=A0sw-bug=0A> >>>>=A0=A0=A0>>=0A> = >> Submitter-Id:=A0=A0=A0current-users=0A> >>>>=A0=A0=A0>>=0A> Arrival-Da= te:=A0=A0=A0Wed=0A> >> Jun 03=0A> >>>> 18:30:01 UTC 2009=0A> >>>>=A0=A0= =A0>> Closed-Date:=0A> >>>>=A0=A0=A0>> Last-Modified:=0A> >>>>=A0=A0=A0>>= Originator: =0A> >>=A0 =A0 Mishustin=0A> >>>> Andrew=0A> >>>>=A0=A0=A0>= > Release:=A0=0A> =A0 =A0=A0=A0=0A> >> FreeBSD=0A> >>>> 7.1-RELEASE amd64= , FreeBSD 7.2-RELEASE=0A> amd64=0A> >>>>=A0=A0=A0>> Organization:=0A> >>>= >=A0=A0=A0> HNT=0A> >>>>=A0=A0=A0>> Environment:=0A> >>>>=A0=A0=A0> FreeB= SD test.hnt=0A> 7.2-RELEASE FreeBSD=0A> >> 7.2-RELEASE #12:=0A> >>>> Thu = Apr 30 18:28:15 MSD 20=0A> >>>>=A0=A0=A0> 09=A0=0A> =A0=A0=A0admin@test.hn= t:/usr/src/sys/amd64/compile/GENERIC=0A> >>>> amd64=0A> >>>>=A0=A0=A0>> D= escription:=0A> >>>>=A0=A0=A0> I made a FreeBSD=0A> multiprocesor server= =0A> >> to act as=0A> >>>> simple gateway.=0A> >>>>=A0=A0=A0> It use onb= oard=0A> Intel 82575EB Dual-Port=0A> >> Gigabit=0A> >>>> Ethernet Control= ler.=0A> >>>>=A0=A0=A0> I observe traffic=0A> speed near 400=0A> >> Kbit/= s.=0A> >>>>=A0=A0=A0> I test both=0A> interfaces separately -=0A> >>>>=A0= =A0=A0> ftp client work at=0A> speed near 1 Gbit/s=0A> >> in both=0A> >>>= > directions.=0A> >>>>=A0=A0=A0> Then I change NIC=0A> to old Intel "em" N= IC=0A> >> - gateway=0A> >>>> work at speed near 1 Gbit/s.=0A> >>>>=A0=A0= =A0> =0A> >>>>=A0=A0=A0> Looks like a bug in=0A> igb driver have an=0A> >= > effect upon=0A> >>>> forwarded traffic.=0A> >>>>=A0=A0=A0> =0A> >>>>= =A0=A0=A0> If you try=0A> >>>>=A0=A0=A0>=0A> hw.igb.enable_aim=3D0=0A> >>= >>=A0=A0=A0> The speed is near 1=0A> Mbit/s=0A> >>>>=A0=A0=A0> =0A> >>>>= =A0=A0=A0> hw.igb.rxd,=0A> hw.igb.txd, "ifconfig -tso"=0A> >> has no=0A> = >>>> effect.=0A> >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0> Nothing in=0A> messag= es.log=0A> >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0> netstat -m=0A> >>>>=A0=A0= =A0> 516/1674/2190 mbufs=0A> in use=0A> >> (current/cache/total)=0A> >>>>= =A0=A0=A0> 515/927/1442/66560=0A> mbuf clusters in=0A> >> use=0A> >>>> (c= urrent/cache/total/max)=0A> >>>>=A0=A0=A0> 515/893=0A> mbuf+clusters out o= f packet=0A> >> secondary zone in=0A> >>>> use (current/cache)=0A> >>>>= =A0=A0=A0> 0/44/44/33280 4k=0A> (page size) jumbo=0A> >> clusters in use= =0A> >>>> (current/cache/total/max)=0A> >>>>=A0=A0=A0> 0/0/0/16640 9k=0A>= jumbo clusters in use=0A> >>>> (current/cache/total/max)=0A> >>>>=A0=A0= =A0> 0/0/0/8320 16k=0A> jumbo clusters in use=0A> >>>> (current/cache/tota= l/max)=0A> >>>>=A0=A0=A0> 1159K/2448K/3607K=0A> bytes allocated to=0A> >>= network=0A> >>>> (current/cache/total)=0A> >>>>=A0=A0=A0> 0/0/0 requests= for=0A> mbufs denied=0A> >>>> (mbufs/clusters/mbuf+clusters)=0A> >>>>=A0= =A0=A0> 0/0/0 requests for=0A> jumbo clusters=0A> >> denied (4k/9k/16k)=0A= > >>>>=A0=A0=A0> 0/0/0 sfbufs in use=0A> (current/peak/max)=0A> >>>>=A0= =A0=A0> 0 requests for=0A> sfbufs denied=0A> >>>>=A0=A0=A0> 0 requests for= =0A> sfbufs delayed=0A> >>>>=A0=A0=A0> 0 requests for I/O=0A> initiated by= =0A> >> sendfile=0A> >>>>=A0=A0=A0> 0 calls to protocol=0A> drain routine= s=0A> >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0> I use only IPv4=0A> traffic.=0A>= >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0>> How-To-Repeat:=0A> >>>>=A0=A0=A0> O= n machine with two=0A> igb interfaces=0A> >>>>=A0=A0=A0> use rc.conf like= =0A> this:=0A> >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0>=0A> hostname=3D"test.te= st"=0A> >>>>=A0=A0=A0>=0A> gateway_enable=3D"YES"=0A> >>>>=A0=A0=A0> ifco= nfig_igb0=3D"inet=0A> 10.10.10.1/24"=0A> >>>>=A0=A0=A0> ifconfig_igb1=3D"i= net=0A> 10.10.11.1/24"=0A> >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0> And try cre= ate=0A> heavy traffic between=0A> >> two networks.=0A> >>>>=A0=A0=A0>> Fi= x:=0A> >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0> =0A> >>>>=A0=A0=A0>> Release-N= ote:=0A> >>>>=A0=A0=A0>> Audit-Trail:=0A> >>>>=A0=A0=A0>> Unformatted:=0A= > >>>>=A0=A0=A0>=0A> >> _______________________________________________= =0A> >>>>=A0=A0=A0> freebsd-bugs@freebsd.org=0A> >>>=0A> >>> This is not= a bug. Unless you consider poorly=0A> written=0A> >> drivers to be bugs. = You need to provide your=0A> tuning=0A> >> parameters for the card as well= otherwise there's=0A> nothing to=0A> >> learn.=0A> >>> The issue is that= the driver doesn't address=0A> the=0A> >> purpose of the controller; whic= h is to utilize=0A> >> multiprocessor systems more effectively. The=0A> ef= fect is that=0A> >> lock contention actually makes things worse than=0A> i= f you just=0A> >> use a single task as em does. Until the=0A> multiqueue d= rivers=0A> >> are re-written to manage locks properly you are=0A> best adv= ised=0A> >> to save your money and stick with em.=0A> >>> You should get = similar performance using 1=0A> queue as=0A> >> with em. You could also fo= rce legacy=0A> configuration by=0A> >> forcing igb_setup_msix to return 0.= Sadly, this=0A> is the best=0A> >> performance you will get from the stoc= k driver.=0A> >>> Barney=0A> >>>=0A> >>> Barney=0A> >>>=0A> >>>=0A> >= >>=A0 =A0 =A0 =A0 =0A> >> I tried using 1 queue and it didn't make things= =0A> any better=0A> >> (actually I'm=0A> >> not sure if that worked at al= l). If it is=0A> considered a bug=0A> >> or not=0A> >> doesn't really mat= ter, what actually matters for=0A> users (who=0A> >> cannot=0A> >> always= chose which network controller will be=0A> on-board) is=0A> >> that they = get=0A> >> a least decent performance when doing IP=0A> forwarding (and=0A= > >> not the=0A> >> 5-50kb/s I've seen). You can get this out of the=0A> = >> controller, when=0A> >> disabling lro through the sysctl. That's why I= 've=0A> been=0A> >> asking to put=0A> >> this into the release errata sec= tion and/or at=0A> least the=0A> >> igb man page,=0A> >> because the sysc= tl isn't documented anywhere.=0A> Also the=0A> >> fact, that tuning=0A> >= > the sysctl only affects the behaviour when it's=0A> set on boot=0A> >> m= ight be=0A> >> considered problematic.=0A> >>=0A> >> So at the very leas= t, I think the following=0A> should be=0A> >> done:=0A> >> 1. Document th= e sysctl in man igb(4)=0A> >> 2. Put a known issues paragraph to man igb(4= )=0A> which=0A> >> explains the issue=0A> >> and what to put in sysctl.co= nf to stop this from=0A> happening=0A> >> 3. Add an entry to the release e= rrata page about=0A> this issue=0A> >> (like I=0A> >> suggested in one of= my earlier emails) and=0A> stating=0A> >> something like "see=0A> >> man= igb(4) for details)=0A> >>=0A> >> This is not about using the controller= to its=0A> full=0A> >> potential, but to=0A> >> safe Joe Admin from spen= ding days on figuring out=0A> why the=0A> >> machine is=0A> >> forwarding= packages slower than his BSD 2.x=0A> machine did in=0A> >> the 90s.=0A> = >>=0A> >> cheers=0A> >> Michael=0A> > =0A> > None of the offload crap s= hould be enabled by=0A> default. =0A> > =0A> > The real point is that "Jo= e Admin" shouldn't be using=0A> controllers that have bad drivers at all. I= f you have to use=0A> whatever hardware you have laying around, and don't h= ave=0A> enough flexibility to lay out $100 for a 2 port controller=0A> that= works to use with your $2000 server, than you need to=0A> get your priorit= ies in order. People go out and buy=0A> redundant power supplies, high GHZ = quad core processors and=0A> gobs of memory and then they use whatever crap= py onboard=0A> controller they get no matter how poorly its suppo rted. Its= =0A> mindless.=0A> > =0A> > Barney=0A> > =0A> > =0A> >=A0 =A0 =A0=A0= =A0=0A> =0A> How should anybody know that the controller is poorly=0A> su= pported if there=0A> is nothing in the documentation, release notes, man p= ages=0A> or anywhere=0A> else about this?=0A> =0A> The fact of the matte= r is that "the offload crap" _is_=0A> enabled by=0A> default. The release = is out, it claims to support the=0A> controller. There=0A> _is_ a workarou= nd and I'm asked if somebody could document=0A> this so users=0A> will hav= e a chance. I'm also not convinced that it is a=0A> crappy=0A> controller = per se, but just poorly supported. We used=0A> those a lot before=0A> with= out any issues, unfortunately now we had touse IP=0A> forwarding in a=0A> = machine that has that controller (it has 6 interfaces in=0A> total, four em= =0A> ports and two igb ports, all of them are in use and I=0A> don't feel = like=0A> hooking up the sodering iron).=0A> =0A> So bottomline:=0A> I s= aid, there is a problem with the driver, there is a=0A> workaround and it= =0A> should be documented.=0A> =0A> You say, the driver is bad and nobod= y should use it and if=0A> they do it's=0A> their own damn fault. We won't= do anything about it and=0A> refuse to tell=0A> anybody, because we are t= he only ones who should know. We=0A> don't care if=0A> people can actually= use our software and still claim the=0A> hardware is=0A> actually support= ed.=0A> =0A> Your attitude is really contra productive (actually=0A> goog= ling around I=0A> see=A0 you made similar statements in the past about=0A>= stupid people not=0A> willing to spend xxx$ on whatever piece of hardware= , so=0A> maybe you're=0A> just trolling).=0A> =0A> Michael=0A=0ATuning t= he card to be brain-dead isn't really a workaround. I'm sorry that you're n= ot able to understand, but you can't educate the woodchucks, so carry on an= d feel free to do whatever you wish.=0A=0ABC=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 14:59:55 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AA00106566C for ; Fri, 19 Jun 2009 14:59:55 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 1F0818FC0A for ; Fri, 19 Jun 2009 14:59:54 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 84540 invoked by uid 60001); 19 Jun 2009 14:59:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245423594; bh=CxOF3vcW3kxmgYBIbavgSS9b0MHsYF4Zr1RlCUlYWZM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T6+UiEUzZdHaRvX8p6HiFnbzsFQAS9rnq0xxpHbjLy4TeeIdNVDFARzb8tPOLLNY+cpHmDQFlZOcvA+L7BuB/ogybVbQFvmZT7fz5gzbdah7ZsbjWIj+0vros2vBISysfUq4IjNMQZKoEzMCPxTjTzDID7SwJRkPGYvmiXl+hns= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P9pdzkuGEPeIs+ZvUi1YW67GHxvvZI5Z+ORSeXlhu3WBx5zTwZchd9mfKCTTEtG3XJTen78foMHBsmiij5p3DR3SNhx7c/l2R4m/tSk7LKH9aH3MLMdXySQNMcmCpNo8YR87yE/5PDD84rvVXPKGs59XvM/KerhMtvo6r+1whts=; Message-ID: <603332.84337.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: E5Ef2Z0VM1kotkb2_aL3Vi5ji_aiH3RppHd9Cw6HcMRlA6gdZuINN6wia6af_Euk6.ZK4kM6KyF6FdT.uXcKH9ldMoMzrinygJixfRmsWYKJ6P6c4Zlp8U5_Wa1._SmUfyE2D3b_eAaEp7vcGYZxLrTIqAfOmHO5vI5Oirkq6Y3HMGVIR8DzRqG5f9qXwICIx6HPrhhUKthiBA_WQTlYk0rp3hlGsWRl_V4paFcZIihkqIYCPn7hxUxdLD8r9_sl6biA_4qwgczy4Htt2BQqTOyP30PHTmcgQmVg.W59CnWSFVMx2kwFWGU- Received: from [66.176.162.245] by web63906.mail.re1.yahoo.com via HTTP; Fri, 19 Jun 2009 07:59:54 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Fri, 19 Jun 2009 07:59:54 -0700 (PDT) From: Barney Cordoba To: net@freebsd.org, current@freebsd.org, Jeff Roberson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: mbuf layout optimizations 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, 19 Jun 2009 14:59:55 -0000 =0A=0A--- On Fri, 6/19/09, Jeff Roberson wrote:= =0A=0A> From: Jeff Roberson =0A> Subject: mbuf lay= out optimizations=0A> To: net@freebsd.org, current@freebsd.org=0A> Date: Fr= iday, June 19, 2009, 5:12 AM=0A> http://people.freebsd.org/~jeff/mbuf2.diff= =0A> =0A> Hello,=0A> =0A> This is a call for testers and feedback on my mbu= f layout=0A> improvements. I'm trying to decide whether I will push to=0A> = have these included in 8.0. After reducing the scope=0A> slightly from my l= ast patch, I have not encountered any=0A> problems.=A0 Kip Macy has also be= en using it for the past=0A> few weeks without issue.=0A> =0A> You should n= ot expect any functional changes from this=0A> patch.=A0 The goal is mostly= to pave the way fors more=0A> sensible mbuf handling in the future, althou= gh it does offer=0A> a few performance benefits.=0A> =0A> The only issue is= that cxgb support requires another set of=0A> patches from Kip.=A0 If anyo= ne needs those I will prod=0A> him to reply with that diff.=0A> =0A> Thanks= ,=0A> Jeff=0A=0AI thought that the purpose of m_tags was to keep individual= applications from having to "patch" mbufs. Has that idea proven to be too= =0Aperformance-challenged?=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 15:39:14 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D2C106566C for ; Fri, 19 Jun 2009 15:39:14 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (mail.bindone.de [80.190.134.51]) by mx1.freebsd.org (Postfix) with SMTP id B5FB18FC19 for ; Fri, 19 Jun 2009 15:39:13 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 53798 invoked by uid 89); 19 Jun 2009 15:39:11 -0000 Received: from unknown (HELO ufo.bindone.de) (mg@bindone.de@87.152.191.150) by mail.bindone.de with ESMTPA; 19 Jun 2009 15:39:11 -0000 Message-ID: <4A3BB0F3.80005@bindone.de> Date: Fri, 19 Jun 2009 17:38:27 +0200 From: Michael User-Agent: Thunderbird 2.0.0.17pre (X11/20090202) MIME-Version: 1.0 To: Barney Cordoba References: <436489.18496.qm@web63904.mail.re1.yahoo.com> In-Reply-To: <436489.18496.qm@web63904.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 15:39:15 -0000 Barney Cordoba wrote: > > > --- On Wed, 6/17/09, Michael wrote: > >> From: Michael >> Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces >> To: freebsd-net@FreeBSD.org >> Date: Wednesday, June 17, 2009, 9:40 PM >> The following reply was made to PR >> kern/135222; it has been noted by GNATS. >> >> From: Michael >> To: Barney Cordoba >> Cc: freebsd-gnats-submit@FreeBSD.org >> Subject: Re: kern/135222: [igb] low speed routing between >> two igb interfaces >> Date: Thu, 18 Jun 2009 03:32:15 +0200 >> >> Barney Cordoba wrote: >> > >> > >> > --- On Wed, 6/17/09, Michael >> wrote: >> > >> >> From: Michael >> >> Subject: Re: kern/135222: [igb] low speed routing >> between two igb interfaces >> >> To: "Barney Cordoba" >> >> Cc: freebsd-net@FreeBSD.org >> >> Date: Wednesday, June 17, 2009, 5:28 PM >> >> Barney Cordoba wrote: >> >>> >> >>> --- On Fri, 6/12/09, Michael >> >> wrote: >> >>>> From: Michael >> >>>> Subject: Re: kern/135222: [igb] low speed >> routing >> >> between two igb interfaces >> >>>> To: freebsd-net@FreeBSD.org >> >>>> Date: Friday, June 12, 2009, 5:50 AM >> >>>> The following reply was made to PR >> >>>> kern/135222; it has been noted by GNATS. >> >>>> >> >>>> From: Michael >> >>>> To: Cc: freebsd-gnats-submit@FreeBSD.org >> >>>> Subject: Re: kern/135222: [igb] low speed >> routing >> >> between >> >>>> two igb interfaces >> >>>> Date: Fri, 12 Jun 2009 11:45:47 +0200 >> >>>> >> >>>> The original poster >> reported that the >> >> suggested fix works >> >>>> for him: >> >>>> --- >> >>>> Hello Michael, >> >>>> >> >>>> Thank you. It's >> working. >> >>>> >> >>>> I consider it necessary >> to put this into the >> >> release >> >>>> errata. >> >>>> >> >>>> >> >>>> Mishustin Andrew wrote: >> >>>> >> Number: >> >> >>>> 135222 >> >>>> >> >> Category: >> >> kern >> >>>> >> >> Synopsis: >> >> [igb] >> >>>> low speed routing between two igb >> interfaces >> >>>> >> >> Confidential: no >> >>>> >> >> Severity: >> >> serious >> >>>> >> >> Priority: >> >> medium >> >>>> >> >> Responsible: >> >> freebsd-bugs >> >>>> >> State: >> >> >> open >> >>>> >> Quarter: >> >> >>>> >> >> Keywords: >> >> >> >>>> >> Date-Required: >> >>>> >> Class: >> >> >> sw-bug >> >>>> >> >> >> Submitter-Id: current-users >> >>>> >> >> Arrival-Date: Wed >> >> Jun 03 >> >>>> 18:30:01 UTC 2009 >> >>>> >> Closed-Date: >> >>>> >> Last-Modified: >> >>>> >> Originator: >> >> Mishustin >> >>>> Andrew >> >>>> >> Release: >> >> >> FreeBSD >> >>>> 7.1-RELEASE amd64, FreeBSD 7.2-RELEASE >> amd64 >> >>>> >> Organization: >> >>>> > HNT >> >>>> >> Environment: >> >>>> > FreeBSD test.hnt >> 7.2-RELEASE FreeBSD >> >> 7.2-RELEASE #12: >> >>>> Thu Apr 30 18:28:15 MSD 20 >> >>>> > 09 >> admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC >> >>>> amd64 >> >>>> >> Description: >> >>>> > I made a FreeBSD >> multiprocesor server >> >> to act as >> >>>> simple gateway. >> >>>> > It use onboard >> Intel 82575EB Dual-Port >> >> Gigabit >> >>>> Ethernet Controller. >> >>>> > I observe traffic >> speed near 400 >> >> Kbit/s. >> >>>> > I test both >> interfaces separately - >> >>>> > ftp client work at >> speed near 1 Gbit/s >> >> in both >> >>>> directions. >> >>>> > Then I change NIC >> to old Intel "em" NIC >> >> - gateway >> >>>> work at speed near 1 Gbit/s. >> >>>> > >> >>>> > Looks like a bug in >> igb driver have an >> >> effect upon >> >>>> forwarded traffic. >> >>>> > >> >>>> > If you try >> >>>> > >> hw.igb.enable_aim=0 >> >>>> > The speed is near 1 >> Mbit/s >> >>>> > >> >>>> > hw.igb.rxd, >> hw.igb.txd, "ifconfig -tso" >> >> has no >> >>>> effect. >> >>>> > >> >>>> > Nothing in >> messages.log >> >>>> > >> >>>> > netstat -m >> >>>> > 516/1674/2190 mbufs >> in use >> >> (current/cache/total) >> >>>> > 515/927/1442/66560 >> mbuf clusters in >> >> use >> >>>> (current/cache/total/max) >> >>>> > 515/893 >> mbuf+clusters out of packet >> >> secondary zone in >> >>>> use (current/cache) >> >>>> > 0/44/44/33280 4k >> (page size) jumbo >> >> clusters in use >> >>>> (current/cache/total/max) >> >>>> > 0/0/0/16640 9k >> jumbo clusters in use >> >>>> (current/cache/total/max) >> >>>> > 0/0/0/8320 16k >> jumbo clusters in use >> >>>> (current/cache/total/max) >> >>>> > 1159K/2448K/3607K >> 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 >> >>>> > >> >>>> > I use only IPv4 >> traffic. >> >>>> > >> >>>> >> How-To-Repeat: >> >>>> > On machine with two >> igb interfaces >> >>>> > use rc.conf like >> this: >> >>>> > >> >>>> > >> hostname="test.test" >> >>>> > >> gateway_enable="YES" >> >>>> > ifconfig_igb0="inet >> 10.10.10.1/24" >> >>>> > ifconfig_igb1="inet >> 10.10.11.1/24" >> >>>> > >> >>>> > And try create >> heavy traffic between >> >> two networks. >> >>>> >> Fix: >> >>>> > >> >>>> > >> >>>> >> Release-Note: >> >>>> >> Audit-Trail: >> >>>> >> Unformatted: >> >>>> > >> >> _______________________________________________ >> >>>> > freebsd-bugs@freebsd.org >> >>> >> >>> This is not a bug. Unless you consider poorly >> written >> >> drivers to be bugs. You need to provide your >> tuning >> >> parameters for the card as well otherwise there's >> nothing to >> >> learn. >> >>> The issue is that the driver doesn't address >> the >> >> purpose of the controller; which is to utilize >> >> multiprocessor systems more effectively. The >> effect is that >> >> lock contention actually makes things worse than >> if you just >> >> use a single task as em does. Until the >> multiqueue drivers >> >> are re-written to manage locks properly you are >> best advised >> >> to save your money and stick with em. >> >>> You should get similar performance using 1 >> queue as >> >> with em. You could also force legacy >> configuration by >> >> forcing igb_setup_msix to return 0. Sadly, this >> is the best >> >> performance you will get from the stock driver. >> >>> Barney >> >>> >> >>> Barney >> >>> >> >>> >> >>> >> >> I tried using 1 queue and it didn't make things >> any better >> >> (actually I'm >> >> not sure if that worked at all). If it is >> considered a bug >> >> or not >> >> doesn't really matter, what actually matters for >> users (who >> >> cannot >> >> always chose which network controller will be >> on-board) is >> >> that they get >> >> a least decent performance when doing IP >> forwarding (and >> >> not the >> >> 5-50kb/s I've seen). You can get this out of the >> >> controller, when >> >> disabling lro through the sysctl. That's why I've >> been >> >> asking to put >> >> this into the release errata section and/or at >> least the >> >> igb man page, >> >> because the sysctl isn't documented anywhere. >> Also the >> >> fact, that tuning >> >> the sysctl only affects the behaviour when it's >> set on boot >> >> might be >> >> considered problematic. >> >> >> >> So at the very least, I think the following >> should be >> >> done: >> >> 1. Document the sysctl in man igb(4) >> >> 2. Put a known issues paragraph to man igb(4) >> which >> >> explains the issue >> >> and what to put in sysctl.conf to stop this from >> happening >> >> 3. Add an entry to the release errata page about >> this issue >> >> (like I >> >> suggested in one of my earlier emails) and >> stating >> >> something like "see >> >> man igb(4) for details) >> >> >> >> This is not about using the controller to its >> full >> >> potential, but to >> >> safe Joe Admin from spending days on figuring out >> why the >> >> machine is >> >> forwarding packages slower than his BSD 2.x >> machine did in >> >> the 90s. >> >> >> >> cheers >> >> Michael >> > >> > None of the offload crap should be enabled by >> default. >> > >> > The real point is that "Joe Admin" shouldn't be using >> controllers that have bad drivers at all. If you have to use >> whatever hardware you have laying around, and don't have >> enough flexibility to lay out $100 for a 2 port controller >> that works to use with your $2000 server, than you need to >> get your priorities in order. People go out and buy >> redundant power supplies, high GHZ quad core processors and >> gobs of memory and then they use whatever crappy onboard >> controller they get no matter how poorly its suppo rted. Its >> mindless. >> > >> > Barney >> > >> > >> > >> >> How should anybody know that the controller is poorly >> supported if there >> is nothing in the documentation, release notes, man pages >> or anywhere >> else about this? >> >> The fact of the matter is that "the offload crap" _is_ >> enabled by >> default. The release is out, it claims to support the >> controller. There >> _is_ a workaround and I'm asked if somebody could document >> this so users >> will have a chance. I'm also not convinced that it is a >> crappy >> controller per se, but just poorly supported. We used >> those a lot before >> without any issues, unfortunately now we had touse IP >> forwarding in a >> machine that has that controller (it has 6 interfaces in >> total, four em >> ports and two igb ports, all of them are in use and I >> don't feel like >> hooking up the sodering iron). >> >> So bottomline: >> I said, there is a problem with the driver, there is a >> workaround and it >> should be documented. >> >> You say, the driver is bad and nobody should use it and if >> they do it's >> their own damn fault. We won't do anything about it and >> refuse to tell >> anybody, because we are the only ones who should know. We >> don't care if >> people can actually use our software and still claim the >> hardware is >> actually supported. >> >> Your attitude is really contra productive (actually >> googling around I >> see you made similar statements in the past about >> stupid people not >> willing to spend xxx$ on whatever piece of hardware, so >> maybe you're >> just trolling). >> >> Michael > > Tuning the card to be brain-dead isn't really a workaround. I'm sorry that you're not able to understand, but you can't educate the woodchucks, so carry on and feel free to do whatever you wish. > > BC > > > Without tuning the card: 5kb/s, with tuning the card: 50mb/s That's the definition of a workaround, the fix would be making lro work correctly - in general I prefer a brain-dead card to a brain-dead mailing list subscriber. Welcome to the real world :) Anyway, I'll stop feeding you now, this is getting boring and leads nowhere. I still think that this should be noted somewhere in the docs, whoever has permissions to commit might proceed in doing so... From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 16:01:30 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A743B1065672 for ; Fri, 19 Jun 2009 16:01:30 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id 5930A8FC14 for ; Fri, 19 Jun 2009 16:01:30 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 18821 invoked by uid 60001); 19 Jun 2009 16:01:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245427289; bh=9xosQwHV8m0IACO3Cwbsfj3fRmVMY6d9B/ewtLcoNEc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k+4XpTD9Wl/ktADx9M6NUjXZWcNkFrRs3YEldId7ieEIW2FeUwGSzccnSDXVVkmhWXG9I+yFxJLKYnPJB6Uf0AnfvYcaFUrfaVIwmyPv0+48HTTpLGwiKUzvT7jc0oXCrPzRyAW8lHmPgua45Itbmh5z/jYMgv6i6EqczXN8D4A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qslPFaa20CDj2dtyDc7ACeMbpQW4Ou2X22uWoB4OPAOF3GmLfmru/nQMSnHFmIpQ/uyfMY1/OjBg2XMTSumFHZkQ5Ru4GmbaiFBE5REJfZNcChFzGTgwc1OXjbYSMfSqmdl/QURQwDOHQlzmQ9ZpAXcavOcXtXMhb1PFMww01X0=; Message-ID: <904439.18775.qm@web63908.mail.re1.yahoo.com> X-YMail-OSG: DF_QIe8VM1lRoXCuGLh.SK9Wg9gTldss3QTKs5MW5BjMcrC6jYH_e6KypbAsXU215uoE5MbHFO.lYjyLtxz3vn0K7eMwJEbcmttR7Ql1ejq0zB70miAZ_XpxGHcAo65axQMVQPdufrTxZPZWna4D3rMtb46g4QHJEUM468KTLFaZjuZiDbJisl9FYH33PDPXyjEbMSbDxkO2f6pQoaR3sughQ0wRErwJCVTwvlVcqIE.QVm_wR_0d2AXJxHRkDf9pbzbDR.Eqg1AS9N47yZDCeS8TFTHuVEKEvnVbYN32_YbSrpb2.0MQaWxtjm_0PS7kWb.WQBbbVGgvw-- Received: from [66.176.162.245] by web63908.mail.re1.yahoo.com via HTTP; Fri, 19 Jun 2009 09:01:29 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Fri, 19 Jun 2009 09:01:29 -0700 (PDT) From: Barney Cordoba To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 16:01:30 -0000 =0A=0A--- On Fri, 6/19/09, Michael wrote:=0A=0A> Fr= om: Michael =0A> Subject: Re: kern/135222: [igb] low= speed routing between two igb interfaces=0A> To: "Barney Cordoba" =0A> Cc: freebsd-net@FreeBSD.org=0A> Date: Friday, June 1= 9, 2009, 11:38 AM=0A> Barney Cordoba wrote:=0A> > =0A> > =0A> > --- On Wed,= 6/17/09, Michael =0A> wrote:=0A> > =0A> >> From: Mi= chael =0A> >> Subject: Re: kern/135222: [igb] low sp= eed routing=0A> between two igb interfaces=0A> >> To: freebsd-net@FreeBSD.o= rg=0A> >> Date: Wednesday, June 17, 2009, 9:40 PM=0A> >> The following repl= y was made to PR=0A> >> kern/135222; it has been noted by GNATS.=0A> >>=0A>= >> From: Michael =0A> >> To: Barney Cordoba =0A> >> Cc: freebsd-gnats-submit@FreeBSD.org=0A> >> Subj= ect: Re: kern/135222: [igb] low speed routing=0A> between=0A> >> two igb in= terfaces=0A> >> Date: Thu, 18 Jun 2009 03:32:15 +0200=0A> >>=0A> >>=A0 Barn= ey Cordoba wrote:=0A> >>=A0 > =0A> >>=A0 > =0A> >>=A0 > --- On Wed, 6/17/09= , Michael =0A> >> wrote:=0A> >>=A0 > =0A> >>=A0 >> F= rom: Michael =0A> >>=A0 >> Subject: Re: kern/135222:= [igb] low=0A> speed routing=0A> >> between two igb interfaces=0A> >>=A0 >>= To: "Barney Cordoba" =0A> >>=A0 >> Cc: freebsd-n= et@FreeBSD.org=0A> >>=A0 >> Date: Wednesday, June 17, 2009,=0A> 5:28 PM=0A>= >>=A0 >> Barney Cordoba wrote:=0A> >>=A0 >>>=0A> >>=A0 >>> --- On Fri, 6/1= 2/09, Michael=0A> =0A> >>=A0 >> wrote:=0A> >>=A0 >>>= > From: Michael =0A> >>=A0 >>>> Subject: Re: kern/13= 5222:=0A> [igb] low speed=0A> >> routing=0A> >>=A0 >> between two igb inter= faces=0A> >>=A0 >>>> To: freebsd-net@FreeBSD.org=0A> >>=A0 >>>> Date: Frida= y, June 12,=0A> 2009, 5:50 AM=0A> >>=A0 >>>> The following reply was=0A> ma= de to PR=0A> >>=A0 >>>> kern/135222; it has been=0A> noted by GNATS.=0A> >>= =A0 >>>>=0A> >>=A0 >>>> From: Michael =0A> >>=A0 >>>= > To: Cc: freebsd-gnats-submit@FreeBSD.org=0A> >>=A0 >>>> Subject: Re: kern= /135222:=0A> [igb] low speed=0A> >> routing=0A> >>=A0 >> between=0A> >>=A0 = >>>> two igb interfaces=0A> >>=A0 >>>> Date: Fri, 12 Jun 2009=0A> 11:45:47 = +0200=0A> >>=A0 >>>>=0A> >>=A0 >>>>=A0=A0=A0The=0A> original poster=0A> >> = reported that the=0A> >>=A0 >> suggested fix works=0A> >>=A0 >>>> for him:= =0A> >>=A0 >>>>=A0=A0=A0---=0A> >>=A0 >>>>=A0=A0=A0Hello=0A> Michael,=0A> >= >=A0 >>>>=A0=A0=A0=0A> >>=A0 >>>>=A0=A0=A0Thank you.=0A> It's=0A> >> workin= g.=0A> >>=A0 >>>>=A0=A0=A0=0A> >>=A0 >>>>=A0=A0=A0I consider=0A> it necessa= ry=0A> >> to put this into the=0A> >>=A0 >> release=0A> >>=A0 >>>> errata.= =0A> >>=A0 >>>>=A0=A0=A0=0A> >>=A0 >>>>=A0=A0=A0=0A> >>=A0 >>>>=A0=A0=A0Mis= hustin=0A> Andrew wrote:=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Number: =0A> >>=A0 = =A0 =0A> >>=A0 >>>>=A0=0A> =A0=A0=A0135222=0A> >>=A0 >>>>=A0=A0=A0>>=0A> >>= Category:=A0=A0=A0=0A> >>=A0 >>=A0 =A0 kern=0A> >>=A0 >>>>=A0=A0=A0>>=0A> = >> Synopsis:=A0=A0=A0=0A> >>=A0 >>=A0 =A0 [igb]=0A> >>=A0 >>>> low speed ro= uting between=0A> two igb=0A> >> interfaces=0A> >>=A0 >>>>=A0=A0=A0>>=0A> >= > Confidential:=A0=A0=A0no=0A> >>=A0 >>>>=A0=A0=A0>>=0A> >> Severity:=A0=A0= =A0=0A> >>=A0 >>=A0 =A0 serious=0A> >>=A0 >>>>=A0=A0=A0>>=0A> >> Priority:= =A0=A0=A0=0A> >>=A0 >>=A0 =A0 medium=0A> >>=A0 >>>>=A0=A0=A0>>=0A> >> Respo= nsible:=A0=A0=A0=0A> >>=A0 >> freebsd-bugs=0A> >>=A0 >>>>=A0=A0=A0>>=0A> St= ate: =0A> >>=A0 =A0 =A0 =0A> >>=A0 >>=A0=A0=A0open=0A> >>=A0 >>>>=A0=A0=A0>= >=0A> Quarter: =0A> >>=A0 =A0 =A0 =0A> >>=A0 >>>>=A0=A0=A0>>=0A> >> Keyword= s:=A0=A0=A0=0A> >>=A0 >>=A0 =A0 =0A> >>=A0 >>>>=A0=A0=A0>>=0A> Date-Require= d:=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Class: =0A> >>=A0 =A0 =A0 =0A> >>=A0 >>=A0= =A0=A0sw-bug=0A> >>=A0 >>>>=A0=A0=A0>>=0A> >>=A0 >>=0A> Submitter-Id:=A0=A0= =A0current-users=0A> >>=A0 >>>>=A0=A0=A0>>=0A> >> Arrival-Date:=A0=A0=A0Wed= =0A> >>=A0 >> Jun 03=0A> >>=A0 >>>> 18:30:01 UTC 2009=0A> >>=A0 >>>>=A0=A0= =A0>>=0A> Closed-Date:=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Last-Modified:=0A> >>= =A0 >>>>=A0=A0=A0>>=0A> Originator: =0A> >>=A0 >>=A0 =A0 Mishustin=0A> >>= =A0 >>>> Andrew=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Release: =0A> >>=A0 =A0 =A0 = =0A> >>=A0 >> FreeBSD=0A> >>=A0 >>>> 7.1-RELEASE amd64, FreeBSD=0A> 7.2-REL= EASE=0A> >> amd64=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Organization:=0A> >>=A0 >>>= >=A0=A0=A0> HNT=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Environment:=0A> >>=A0 >>>>= =A0=A0=A0>=0A> FreeBSD test.hnt=0A> >> 7.2-RELEASE FreeBSD=0A> >>=A0 >> 7.2= -RELEASE #12:=0A> >>=A0 >>>> Thu Apr 30 18:28:15 MSD 20=0A> >>=A0 >>>>=A0= =A0=A0> 09 =0A> >>=A0 =A0 admin@test.hnt:/usr/src/sys/amd64/compile/GENERIC= =0A> >>=A0 >>>> amd64=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Description:=0A> >>=A0 = >>>>=A0=A0=A0> I=0A> made a FreeBSD=0A> >> multiprocesor server=0A> >>=A0 >= > to act as=0A> >>=A0 >>>> simple gateway.=0A> >>=A0 >>>>=A0=A0=A0> It=0A> = use onboard=0A> >> Intel 82575EB Dual-Port=0A> >>=A0 >> Gigabit=0A> >>=A0 >= >>> Ethernet Controller.=0A> >>=A0 >>>>=A0=A0=A0> I=0A> observe traffic=0A>= >> speed near 400=0A> >>=A0 >> Kbit/s.=0A> >>=A0 >>>>=A0=A0=A0> I=0A> test= both=0A> >> interfaces separately -=0A> >>=A0 >>>>=A0=A0=A0> ftp=0A> clien= t work at=0A> >> speed near 1 Gbit/s=0A> >>=A0 >> in both=0A> >>=A0 >>>> di= rections.=0A> >>=A0 >>>>=A0=A0=A0> Then=0A> I change NIC=0A> >> to old Inte= l "em" NIC=0A> >>=A0 >> - gateway=0A> >>=A0 >>>> work at speed near 1=0A> G= bit/s.=0A> >>=A0 >>>>=A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0> Looks=0A> like a = bug in=0A> >> igb driver have an=0A> >>=A0 >> effect upon=0A> >>=A0 >>>> fo= rwarded traffic.=0A> >>=A0 >>>>=A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0> If=0A> = you try=0A> >>=A0 >>>>=A0=A0=A0>=0A> >> hw.igb.enable_aim=3D0=0A> >>=A0 >>>= >=A0=A0=A0> The=0A> speed is near 1=0A> >> Mbit/s=0A> >>=A0 >>>>=A0=A0=A0> = =0A> >>=A0 >>>>=A0=A0=A0>=0A> hw.igb.rxd,=0A> >> hw.igb.txd, "ifconfig -tso= "=0A> >>=A0 >> has no=0A> >>=A0 >>>> effect.=0A> >>=A0 >>>>=A0=A0=A0> =0A> = >>=A0 >>>>=A0=A0=A0>=0A> Nothing in=0A> >> messages.log=0A> >>=A0 >>>>=A0= =A0=A0> =0A> >>=A0 >>>>=A0=A0=A0>=0A> netstat -m=0A> >>=A0 >>>>=A0=A0=A0>= =0A> 516/1674/2190 mbufs=0A> >> in use=0A> >>=A0 >> (current/cache/total)= =0A> >>=A0 >>>>=A0=A0=A0>=0A> 515/927/1442/66560=0A> >> mbuf clusters in=0A= > >>=A0 >> use=0A> >>=A0 >>>> (current/cache/total/max)=0A> >>=A0 >>>>=A0= =A0=A0>=0A> 515/893=0A> >> mbuf+clusters out of packet=0A> >>=A0 >> seconda= ry zone in=0A> >>=A0 >>>> use (current/cache)=0A> >>=A0 >>>>=A0=A0=A0>=0A> = 0/44/44/33280 4k=0A> >> (page size) jumbo=0A> >>=A0 >> clusters in use=0A> = >>=A0 >>>> (current/cache/total/max)=0A> >>=A0 >>>>=A0=A0=A0>=0A> 0/0/0/166= 40 9k=0A> >> jumbo clusters in use=0A> >>=A0 >>>> (current/cache/total/max)= =0A> >>=A0 >>>>=A0=A0=A0>=0A> 0/0/0/8320 16k=0A> >> jumbo clusters in use= =0A> >>=A0 >>>> (current/cache/total/max)=0A> >>=A0 >>>>=A0=A0=A0>=0A> 1159= K/2448K/3607K=0A> >> bytes allocated to=0A> >>=A0 >> network=0A> >>=A0 >>>>= (current/cache/total)=0A> >>=A0 >>>>=A0=A0=A0> 0/0/0=0A> requests for=0A> = >> mbufs denied=0A> >>=A0 >>>>=0A> (mbufs/clusters/mbuf+clusters)=0A> >>=A0= >>>>=A0=A0=A0> 0/0/0=0A> requests for=0A> >> jumbo clusters=0A> >>=A0 >> d= enied (4k/9k/16k)=0A> >>=A0 >>>>=A0=A0=A0> 0/0/0=0A> sfbufs in use=0A> >> (= current/peak/max)=0A> >>=A0 >>>>=A0=A0=A0> 0=0A> requests for=0A> >> sfbufs= denied=0A> >>=A0 >>>>=A0=A0=A0> 0=0A> requests for=0A> >> sfbufs delayed= =0A> >>=A0 >>>>=A0=A0=A0> 0=0A> requests for I/O=0A> >> initiated by=0A> >>= =A0 >> sendfile=0A> >>=A0 >>>>=A0=A0=A0> 0=0A> calls to protocol=0A> >> dra= in routines=0A> >>=A0 >>>>=A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0> I use=0A> on= ly IPv4=0A> >> traffic.=0A> >>=A0 >>>>=A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0>>= =0A> How-To-Repeat:=0A> >>=A0 >>>>=A0=A0=A0> On=0A> machine with two=0A> >>= igb interfaces=0A> >>=A0 >>>>=A0=A0=A0> use=0A> rc.conf like=0A> >> this:= =0A> >>=A0 >>>>=A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0>=0A> >> hostname=3D"test= .test"=0A> >>=A0 >>>>=A0=A0=A0>=0A> >> gateway_enable=3D"YES"=0A> >>=A0 >>>= >=A0=A0=A0>=0A> ifconfig_igb0=3D"inet=0A> >> 10.10.10.1/24"=0A> >>=A0 >>>>= =A0=A0=A0>=0A> ifconfig_igb1=3D"inet=0A> >> 10.10.11.1/24"=0A> >>=A0 >>>>= =A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0> And=0A> try create=0A> >> heavy traffi= c between=0A> >>=A0 >> two networks.=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Fix:=0A>= >>=A0 >>>>=A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0> =0A> >>=A0 >>>>=A0=A0=A0>>= =0A> Release-Note:=0A> >>=A0 >>>>=A0=A0=A0>>=0A> Audit-Trail:=0A> >>=A0 >>>= >=A0=A0=A0>>=0A> Unformatted:=0A> >>=A0 >>>>=A0=A0=A0>=0A> >>=A0 >>=0A> ___= ____________________________________________=0A> >>=A0 >>>>=A0=A0=A0> freeb= sd-bugs@freebsd.org=0A> >>=A0 >>>=0A> >>=A0 >>> This is not a bug. Unless y= ou=0A> consider poorly=0A> >> written=0A> >>=A0 >> drivers to be bugs. You = need to=0A> provide your=0A> >> tuning=0A> >>=A0 >> parameters for the card= as well=0A> otherwise there's=0A> >> nothing to=0A> >>=A0 >> learn.=0A> >>= =A0 >>> The issue is that the driver=0A> doesn't address=0A> >> the=0A> >>= =A0 >> purpose of the controller; which is=0A> to utilize=0A> >>=A0 >> mult= iprocessor systems more=0A> effectively. The=0A> >> effect is that=0A> >>= =A0 >> lock contention actually makes=0A> things worse than=0A> >> if you j= ust=0A> >>=A0 >> use a single task as em does. Until=0A> the=0A> >> multiqu= eue drivers=0A> >>=A0 >> are re-written to manage locks=0A> properly you ar= e=0A> >> best advised=0A> >>=A0 >> to save your money and stick with=0A> em= .=0A> >>=A0 >>> You should get similar=0A> performance using 1=0A> >> queue= as=0A> >>=A0 >> with em. You could also force=0A> legacy=0A> >> configurat= ion by=0A> >>=A0 >> forcing igb_setup_msix to return 0.=0A> Sadly, this=0A>= >> is the best=0A> >>=A0 >> performance you will get from the=0A> stock dr= iver.=0A> >>=A0 >>> Barney=0A> >>=A0 >>>=0A> >>=A0 >>> Barney=0A> >>=A0 >>>= =0A> >>=A0 >>>=0A> >>=A0 >>>=A0 =A0 =A0 =A0 =0A> >>=A0 >> I tried using 1 q= ueue and it didn't=0A> make things=0A> >> any better=0A> >>=A0 >> (actually= I'm=0A> >>=A0 >> not sure if that worked at all). If=0A> it is=0A> >> cons= idered a bug=0A> >>=A0 >> or not=0A> >>=A0 >> doesn't really matter, what= =0A> actually matters for=0A> >> users (who=0A> >>=A0 >> cannot=0A> >>=A0 >= > always chose which network=0A> controller will be=0A> >> on-board) is=0A>= >>=A0 >> that they get=0A> >>=A0 >> a least decent performance when=0A> do= ing IP=0A> >> forwarding (and=0A> >>=A0 >> not the=0A> >>=A0 >> 5-50kb/s I'= ve seen). You can get=0A> this out of the=0A> >>=A0 >> controller, when=0A>= >>=A0 >> disabling lro through the sysctl.=0A> That's why I've=0A> >> been= =0A> >>=A0 >> asking to put=0A> >>=A0 >> this into the release errata=0A> s= ection and/or at=0A> >> least the=0A> >>=A0 >> igb man page,=0A> >>=A0 >> b= ecause the sysctl isn't documented=0A> anywhere.=0A> >> Also the=0A> >>=A0 = >> fact, that tuning=0A> >>=A0 >> the sysctl only affects the=0A> behaviour= when it's=0A> >> set on boot=0A> >>=A0 >> might be=0A> >>=A0 >> considered= problematic.=0A> >>=A0 >>=0A> >>=A0 >> So at the very least, I think the= =0A> following=0A> >> should be=0A> >>=A0 >> done:=0A> >>=A0 >> 1. Document= the sysctl in man=0A> igb(4)=0A> >>=A0 >> 2. Put a known issues paragraph = to=0A> man igb(4)=0A> >> which=0A> >>=A0 >> explains the issue=0A> >>=A0 >>= and what to put in sysctl.conf to=0A> stop this from=0A> >> happening=0A> = >>=A0 >> 3. Add an entry to the release=0A> errata page about=0A> >> this i= ssue=0A> >>=A0 >> (like I=0A> >>=A0 >> suggested in one of my earlier=0A> e= mails) and=0A> >> stating=0A> >>=A0 >> something like "see=0A> >>=A0 >> man= igb(4) for details)=0A> >>=A0 >>=0A> >>=A0 >> This is not about using the= =0A> controller to its=0A> >> full=0A> >>=A0 >> potential, but to=0A> >>=A0= >> safe Joe Admin from spending days=0A> on figuring out=0A> >> why the=0A= > >>=A0 >> machine is=0A> >>=A0 >> forwarding packages slower than his=0A> = BSD 2.x=0A> >> machine did in=0A> >>=A0 >> the 90s.=0A> >>=A0 >>=0A> >>=A0 = >> cheers=0A> >>=A0 >> Michael=0A> >>=A0 > =0A> >>=A0 > None of the offload= crap should be=0A> enabled by=0A> >> default. =0A> >>=A0 > =0A> >>=A0 > Th= e real point is that "Joe Admin"=0A> shouldn't be using=0A> >> controllers = that have bad drivers at all. If you=0A> have to use=0A> >> whatever hardwa= re you have laying around, and=0A> don't have=0A> >> enough flexibility to = lay out $100 for a 2 port=0A> controller=0A> >> that works to use with your= $2000 server, than you=0A> need to=0A> >> get your priorities in order. Pe= ople go out and=0A> buy=0A> >> redundant power supplies, high GHZ quad core= =0A> processors and=0A> >> gobs of memory and then they use whatever crappy= =0A> onboard=0A> >> controller they get no matter how poorly its suppo=0A> = rted. Its=0A> >> mindless.=0A> >>=A0 > =0A> >>=A0 > Barney=0A> >>=A0 > =0A>= >>=A0 > =0A> >>=A0 >=A0 =A0 =A0=A0=A0=0A> >>=A0 =0A> >>=A0 How should anyb= ody know that the controller=0A> is poorly=0A> >> supported if there=0A> >>= =A0 is nothing in the documentation, release=0A> notes, man pages=0A> >> or= anywhere=0A> >>=A0 else about this?=0A> >>=A0 =0A> >>=A0 The fact of the m= atter is that "the offload=0A> crap" _is_=0A> >> enabled by=0A> >>=A0 defau= lt. The release is out, it claims to=0A> support the=0A> >> controller. The= re=0A> >>=A0 _is_ a workaround and I'm asked if somebody=0A> could document= =0A> >> this so users=0A> >>=A0 will have a chance. I'm also not convinced= =0A> that it is a=0A> >> crappy=0A> >>=A0 controller per se, but just poorl= y=0A> supported. We used=0A> >> those a lot before=0A> >>=A0 without any is= sues, unfortunately now we had=0A> touse IP=0A> >> forwarding in a=0A> >>= =A0 machine that has that controller (it has 6=0A> interfaces in=0A> >> tot= al, four em=0A> >>=A0 ports and two igb ports, all of them are in=0A> use a= nd I=0A> >> don't feel like=0A> >>=A0 hooking up the sodering iron).=0A> >>= =A0 =0A> >>=A0 So bottomline:=0A> >>=A0 I said, there is a problem with the= driver,=0A> there is a=0A> >> workaround and it=0A> >>=A0 should be docume= nted.=0A> >>=A0 =0A> >>=A0 You say, the driver is bad and nobody should=0A>= use it and if=0A> >> they do it's=0A> >>=A0 their own damn fault. We won't= do anything=0A> about it and=0A> >> refuse to tell=0A> >>=A0 anybody, beca= use we are the only ones who=0A> should know. We=0A> >> don't care if=0A> >= >=A0 people can actually use our software and=0A> still claim the=0A> >> ha= rdware is=0A> >>=A0 actually supported.=0A> >>=A0 =0A> >>=A0 Your attitude = is really contra productive=0A> (actually=0A> >> googling around I=0A> >>= =A0 see=A0 you made similar statements in the=0A> past about=0A> >> stupid = people not=0A> >>=A0 willing to spend xxx$ on whatever piece of=0A> hardwar= e, so=0A> >> maybe you're=0A> >>=A0 just trolling).=0A> >>=A0 =0A> >>=A0 Mi= chael=0A> > =0A> > Tuning the card to be brain-dead isn't really a=0A> work= around. I'm sorry that you're not able to understand,=0A> but you can't edu= cate the woodchucks, so carry on and feel=0A> free to do whatever you wish.= =0A> > =0A> > BC=0A> > =0A> > =0A> >=A0 =A0 =A0=A0=A0=0A> =0A> Without tuni= ng the card: 5kb/s, with tuning the card:=0A> 50mb/s=0A> That's the definit= ion of a workaround, the fix would be=0A> making lro work=0A> correctly - i= n general I prefer a brain-dead card to a=0A> brain-dead=0A> mailing list s= ubscriber. Welcome to the real world :)=0A> =0A> Anyway, I'll stop feeding = you now, this is getting boring=0A> and leads nowhere.=0A> =0A> I still thi= nk that this should be noted somewhere in the=0A> docs, whoever=0A> has per= missions to commit might proceed in doing so...=0A> _______________________= ________________________=0A> freebsd-net@freebsd.org=0A> mailing list=0A> h= ttp://lists.freebsd.org/mailman/listinfo/freebsd-net=0A> To unsubscribe, se= nd any mail to "freebsd-net-unsubscribe@freebsd.org"=0A> =0A=0AIgnorance is= Bliss, as they say.=0A=0ABC=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 17:43:15 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 180BF106567B; Fri, 19 Jun 2009 17:43:15 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id E05488FC1D; Fri, 19 Jun 2009 17:43:14 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id m38so538894waf.27 for ; Fri, 19 Jun 2009 10:43:14 -0700 (PDT) Received: by 10.114.122.9 with SMTP id u9mr4332110wac.206.1245433394547; Fri, 19 Jun 2009 10:43:14 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id j15sm6132110waf.16.2009.06.19.10.43.12 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 10:43:13 -0700 (PDT) Date: Fri, 19 Jun 2009 07:43:19 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Barney Cordoba In-Reply-To: <603332.84337.qm@web63906.mail.re1.yahoo.com> Message-ID: References: <603332.84337.qm@web63906.mail.re1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1022206537-1245433402=:1025" Cc: current@freebsd.org, net@freebsd.org Subject: Re: mbuf layout optimizations 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, 19 Jun 2009 17:43:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1022206537-1245433402=:1025 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 19 Jun 2009, Barney Cordoba wrote: > > > > --- On Fri, 6/19/09, Jeff Roberson wrote: > >> From: Jeff Roberson >> Subject: mbuf layout optimizations >> To: net@freebsd.org, current@freebsd.org >> Date: Friday, June 19, 2009, 5:12 AM >> http://people.freebsd.org/~jeff/mbuf2.diff >> >> Hello, >> >> This is a call for testers and feedback on my mbuf layout >> improvements. I'm trying to decide whether I will push to >> have these included in 8.0. After reducing the scope >> slightly from my last patch, I have not encountered any >> problems.  Kip Macy has also been using it for the past >> few weeks without issue. >> >> You should not expect any functional changes from this >> patch.  The goal is mostly to pave the way fors more >> sensible mbuf handling in the future, although it does offer >> a few performance benefits. >> >> The only issue is that cxgb support requires another set of >> patches from Kip.  If anyone needs those I will prod >> him to reply with that diff. >> >> Thanks, >> Jeff > > I thought that the purpose of m_tags was to keep individual applications from having to "patch" mbufs. Has that idea proven to be too > performance-challenged? m_tags are unrelated to this diff. This addresses the fundamental memory allocation mechanisms and layout of the mbuf. It reduces the amount of book keeping necessary and makes reference counts more pervasive. Thanks, Jeff > > Barney > --2547152148-1022206537-1245433402=:1025-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 17:44:35 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BE88106568E for ; Fri, 19 Jun 2009 17:44:35 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id C81CA8FC2A for ; Fri, 19 Jun 2009 17:44:34 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 19:44:32 +0200 Date: Fri, 19 Jun 2009 19:44:42 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: freebsd-net@freebsd.org Message-ID: <20090619191756.R581@beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Jun 2009 17:44:32.0981 (UTC) FILETIME=[9ABA7050:01C9F105] Cc: FreeBSD/net@dlr.de Subject: TCP bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 17:44:35 -0000 Hi all, one of my TCP test cases breaks in what one could call an edge case: When the TCP is in SYN-SENT state (the user has called connect()) and the peer answers with an almost-lamp test packet which has SYN, FIN, ACK and data larger than the window, TCP ACKs a window full of data, drops the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to me. When dropping the data that is outside the window, it should also drop the FIN. The problem seems to be very old - I found it alread in rev. 1.1 of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of the incoming segment is the next expected one, the reassembly queue is empty and we are in an established state, the segment data is added to the socket buffer and all TCP header flags are cleared except for TH_FIN. Unfortunately here the original header flags are taken instead of the cached version in thflags. Earlier in the processing the out-of-window data and the FIN in thflags were chopped off and now TH_FIN reappears. The fix should be easy: instead of using the original flag byte to get the FIN use the cached copy. Index: tcp_input.c =================================================================== --- tcp_input.c (revision 194499) +++ tcp_input.c (working copy) @@ -2587,7 +2587,7 @@ else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt += tlen; - thflags = th->th_flags & TH_FIN; + thflags &= TH_FIN; TCPSTAT_INC(tcps_rcvpack); TCPSTAT_ADD(tcps_rcvbyte, tlen); ND6_HINT(tp); I wonder, though, why the code is as it is, i.e. why it takes the original FIN flag. Any idea? harti From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 17:58:32 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF38E1065698 for ; Fri, 19 Jun 2009 17:58:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 480F98FC12 for ; Fri, 19 Jun 2009 17:58:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 19:46:28 +0200 Date: Fri, 19 Jun 2009 19:46:37 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: net@freebsd.org Message-ID: <20090619194608.W697@beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Jun 2009 17:46:28.0322 (UTC) FILETIME=[DF7A1420:01C9F105] Cc: Subject: TCP bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 17:58:33 -0000 Hi all, one of my TCP test cases breaks in what one could call an edge case: When the TCP is in SYN-SENT state (the user has called connect()) and the peer answers with an almost-lamp test packet which has SYN, FIN, ACK and data larger than the window, TCP ACKs a window full of data, drops the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to me. When dropping the data that is outside the window, it should also drop the FIN. The problem seems to be very old - I found it alread in rev. 1.1 of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of the incoming segment is the next expected one, the reassembly queue is empty and we are in an established state, the segment data is added to the socket buffer and all TCP header flags are cleared except for TH_FIN. Unfortunately here the original header flags are taken instead of the cached version in thflags. Earlier in the processing the out-of-window data and the FIN in thflags were chopped off and now TH_FIN reappears. The fix should be easy: instead of using the original flag byte to get the FIN use the cached copy. Index: tcp_input.c =================================================================== --- tcp_input.c (revision 194499) +++ tcp_input.c (working copy) @@ -2587,7 +2587,7 @@ else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt += tlen; - thflags = th->th_flags & TH_FIN; + thflags &= TH_FIN; TCPSTAT_INC(tcps_rcvpack); TCPSTAT_ADD(tcps_rcvbyte, tlen); ND6_HINT(tp); I wonder, though, why the code is as it is, i.e. why it takes the original FIN flag. Any idea? harti From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 19:32:58 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EA191065676; Fri, 19 Jun 2009 19:32:58 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 5BABE8FC26; Fri, 19 Jun 2009 19:32:58 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLI009GK0UWXH50@asmtp014.mac.com>; Fri, 19 Jun 2009 11:32:58 -0700 (PDT) Message-id: <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> From: Chuck Swiger To: Harti Brandt In-reply-to: <20090619191756.R581@beagle.kn.op.dlr.de> Date: Fri, 19 Jun 2009 11:32:55 -0700 References: <20090619191756.R581@beagle.kn.op.dlr.de> X-Mailer: Apple Mail (2.935.3) Cc: "freebsd-net@freebsd.org Net" Subject: Re: TCP bug? 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, 19 Jun 2009 19:32:58 -0000 Hi-- On Jun 19, 2009, at 10:44 AM, Harti Brandt wrote: > When the TCP is in SYN-SENT state (the user has called connect()) > and the peer answers with an almost-lamp test packet which has SYN, > FIN, ACK and data larger than the window, TCP ACKs a window full of > data, drops the rest, but processes the FIN - it goes into > CLOSE_WAIT. This looks wrong to me. When dropping the data that is > outside the window, it should also drop the FIN. Clearly, you shouldn't process a FIN which happens outside of the current window: "For sequence number purposes, the SYN is considered to occur before the first actual data octet of the segment in which it occurs, while the FIN is considered to occur after the last actual data octet in a segment in which it occurs." If the socket was in a synchronized state, RFC-793 pg 37 says: "3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state." ...if it's before the connection is fully setup, ie, in SYN-SENT state as you say, then the fact that the packet contains data which does not fit in the window suggests it should be handled by the rules for half- open connections: "As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case." See figure 12-- I think you should be sending a RST back.... Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 19:55:36 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9251065670 for ; Fri, 19 Jun 2009 19:55:36 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp171.dfw.emailsrvr.com (smtp171.dfw.emailsrvr.com [67.192.241.171]) by mx1.freebsd.org (Postfix) with ESMTP id A21108FC08 for ; Fri, 19 Jun 2009 19:55:36 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from relay7.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id DB0D3CE4ECA for ; Fri, 19 Jun 2009 15:37:51 -0400 (EDT) Received: by relay7.relay.dfw.mlsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 63005CE5170; Fri, 19 Jun 2009 15:37:51 -0400 (EDT) Message-ID: <4A3BE910.6080502@xiplink.com> Date: Fri, 19 Jun 2009 15:37:52 -0400 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Harti Brandt References: <20090619194608.W697@beagle.kn.op.dlr.de> In-Reply-To: <20090619194608.W697@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: TCP bug? 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, 19 Jun 2009 19:55:37 -0000 Hi There, Looking at Steven's book TCP/IP Volume 2 (1995 edition) page 988 (Processing and Received Data) they call TCP_REASS(tp, ti, m, so, tiflags) where tiflags is thflags and inside the TCP_REASS macro (page 908), this code is used (where ti is the tcpiphdr pointer): flags = (ti)->ti_flags & TH_FIN; \ Same problem there as well ... Also, looking at tcp_reass(), the same approach of using the header version is used there: flags = q->tqe_th->th_flags & TH_FIN; This seems to work since the data was kept inside the reassembly queue and not dropped If this problem is confirmed you've probably found an original implementation bug. Can you describe better the test condition to reproduce this problem? Cheers, Karim. Harti Brandt wrote: > > Hi all, > > one of my TCP test cases breaks in what one could call an edge case: > > When the TCP is in SYN-SENT state (the user has called connect()) and the > peer answers with an almost-lamp test packet which has SYN, FIN, ACK and > data larger than the window, TCP ACKs a window full of data, drops the > rest, but processes the FIN - it goes into CLOSE_WAIT. This looks > wrong to > me. When dropping the data that is outside the window, it should also > drop > the FIN. > > The problem seems to be very old - I found it alread in rev. 1.1 > of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number > of the incoming segment is the next expected one, the reassembly queue is > empty and we are in an established state, the segment data is added to > the > socket buffer and all TCP header flags are cleared except for TH_FIN. > Unfortunately here the original header flags are taken instead of the > cached version in thflags. Earlier in the processing the out-of-window > data and the FIN in thflags were chopped off and now TH_FIN reappears. > > The fix should be easy: instead of using the original flag byte to get > the > FIN use the cached copy. > > Index: tcp_input.c > =================================================================== > --- tcp_input.c (revision 194499) > +++ tcp_input.c (working copy) > @@ -2587,7 +2587,7 @@ > else > tp->t_flags |= TF_ACKNOW; > tp->rcv_nxt += tlen; > - thflags = th->th_flags & TH_FIN; > + thflags &= TH_FIN; > TCPSTAT_INC(tcps_rcvpack); > TCPSTAT_ADD(tcps_rcvbyte, tlen); > ND6_HINT(tp); > > I wonder, though, why the code is as it is, i.e. why it takes the > original > FIN flag. Any idea? > > harti > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 20:04:52 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475721065675 for ; Fri, 19 Jun 2009 20:04:52 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id D2AA98FC15 for ; Fri, 19 Jun 2009 20:04:51 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 22:04:50 +0200 Date: Fri, 19 Jun 2009 22:05:04 +0200 (CEST) From: Hartmut Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Karim Fodil-Lemelin In-Reply-To: <4A3BE910.6080502@xiplink.com> Message-ID: <20090619215930.V970@beagle.kn.op.dlr.de> References: <20090619194608.W697@beagle.kn.op.dlr.de> <4A3BE910.6080502@xiplink.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Jun 2009 20:04:50.0074 (UTC) FILETIME=[33B4E7A0:01C9F119] Cc: net@freebsd.org Subject: Re: TCP bug? 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, 19 Jun 2009 20:04:52 -0000 Hi, On Fri, 19 Jun 2009, Karim Fodil-Lemelin wrote: KF>Looking at Steven's book TCP/IP Volume 2 (1995 edition) page 988 (Processing KF>and Received Data) they call TCP_REASS(tp, ti, m, so, tiflags) where tiflags KF>is thflags and inside the TCP_REASS macro (page 908), this code is used KF>(where ti is the tcpiphdr pointer): KF> KF>flags = (ti)->ti_flags & TH_FIN; \ KF> KF>Same problem there as well ... KF> KF>Also, looking at tcp_reass(), the same approach of using the header version KF>is used there: KF> KF>flags = q->tqe_th->th_flags & TH_FIN; KF> KF>This seems to work since the data was kept inside the reassembly queue and KF>not dropped KF> KF>If this problem is confirmed you've probably found an original implementation KF>bug. Can you describe better the test condition to reproduce this problem? Sure. I've a test environment for TCP which does for this test the following: - open a TCP socket, set the socket send buffer to 32768 byte - call connect() and expect SYN seq= win=32768 - tester responds with SYN, FIN, ACK= data=(41000 bytes) seq= - expect ACK= seq= - check that TCP is in EsTABLISHED state Everything is fine except that TCP ends up in CLOSE_WAIT. harti KF>Harti Brandt wrote: KF>> KF>> Hi all, KF>> KF>> one of my TCP test cases breaks in what one could call an edge case: KF>> KF>> When the TCP is in SYN-SENT state (the user has called connect()) and the KF>> peer answers with an almost-lamp test packet which has SYN, FIN, ACK and KF>> data larger than the window, TCP ACKs a window full of data, drops the KF>> rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to KF>> me. When dropping the data that is outside the window, it should also drop KF>> the FIN. KF>> KF>> The problem seems to be very old - I found it alread in rev. 1.1 KF>> of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number KF>> of the incoming segment is the next expected one, the reassembly queue is KF>> empty and we are in an established state, the segment data is added to the KF>> socket buffer and all TCP header flags are cleared except for TH_FIN. KF>> Unfortunately here the original header flags are taken instead of the KF>> cached version in thflags. Earlier in the processing the out-of-window KF>> data and the FIN in thflags were chopped off and now TH_FIN reappears. KF>> KF>> The fix should be easy: instead of using the original flag byte to get the KF>> FIN use the cached copy. KF>> KF>> Index: tcp_input.c KF>> =================================================================== KF>> --- tcp_input.c (revision 194499) KF>> +++ tcp_input.c (working copy) KF>> @@ -2587,7 +2587,7 @@ KF>> else KF>> tp->t_flags |= TF_ACKNOW; KF>> tp->rcv_nxt += tlen; KF>> - thflags = th->th_flags & TH_FIN; KF>> + thflags &= TH_FIN; KF>> TCPSTAT_INC(tcps_rcvpack); KF>> TCPSTAT_ADD(tcps_rcvbyte, tlen); KF>> ND6_HINT(tp); KF>> KF>> I wonder, though, why the code is as it is, i.e. why it takes the original KF>> FIN flag. Any idea? KF>> KF>> harti KF>> KF>> _______________________________________________ KF>> freebsd-net@freebsd.org mailing list KF>> http://lists.freebsd.org/mailman/listinfo/freebsd-net KF>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" KF> KF> From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 20:15:42 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82AFB106564A for ; Fri, 19 Jun 2009 20:15:42 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 171608FC18 for ; Fri, 19 Jun 2009 20:15:41 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 22:15:40 +0200 Date: Fri, 19 Jun 2009 22:15:55 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Chuck Swiger In-Reply-To: <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> Message-ID: <20090619220901.Y970@beagle.kn.op.dlr.de> References: <20090619191756.R581@beagle.kn.op.dlr.de> <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Jun 2009 20:15:40.0729 (UTC) FILETIME=[B786FA90:01C9F11A] Cc: "freebsd-net@freebsd.org Net" Subject: Re: TCP bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 20:15:42 -0000 Hi, On Fri, 19 Jun 2009, Chuck Swiger wrote: CS>On Jun 19, 2009, at 10:44 AM, Harti Brandt wrote: CS>> When the TCP is in SYN-SENT state (the user has called connect()) and the CS>> peer answers with an almost-lamp test packet which has SYN, FIN, ACK and CS>> data larger than the window, TCP ACKs a window full of data, drops the CS>> rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to CS>> me. When dropping the data that is outside the window, it should also drop CS>> the FIN. CS> CS>Clearly, you shouldn't process a FIN which happens outside of the current CS>window: "For sequence number purposes, the SYN is considered to occur before CS>the first actual data octet of the segment in which it occurs, while the FIN CS>is considered to occur after the last actual data octet in a segment in which CS>it occurs." CS> CS>If the socket was in a synchronized state, RFC-793 pg 37 says: CS> CS>"3. If the connection is in a synchronized state (ESTABLISHED, CS> FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), CS> any unacceptable segment (out of window sequence number or CS> unacceptible acknowledgment number) must elicit only an empty CS> acknowledgment segment containing the current send-sequence number CS> and an acknowledgment indicating the next sequence number expected CS> to be received, and the connection remains in the same state." CS> CS>...if it's before the connection is fully setup, ie, in SYN-SENT state as you CS>say, then the fact that the packet contains data which does not fit in the CS>window suggests it should be handled by the rules for half-open connections: CS> CS> "As a general rule, reset (RST) must be sent whenever a segment arrives CS> which apparently is not intended for the current connection. A reset CS> must not be sent if it is not clear that this is the case." CS> CS>See figure 12-- I think you should be sending a RST back.... I think this is too drastic. A segment is unacceptable only if it is completly out of the window. Here part is in the window. Also conceptually TCP enters the ESTABLISHED state as soon as it finds that the ACK in the SYN,ACK is correct before it starts to process the data and the FIN (p.68 of RFC793 - first you enter ESTABLISHED and ACK, then you goto step 6). So taking into account the explanation at top of page 70 (which logically belongs to step 6) you just drop everything outside the window - part of the data and the FIN in our case - and proceed. Note, that the data in the SYN,ACK is always partly in the window because this segment contains the IRS, except if the window is 0 and the segment contains data or FIN. harti From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 20:46:22 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5869C106564A for ; Fri, 19 Jun 2009 20:46:22 +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 BB7AD8FC17 for ; Fri, 19 Jun 2009 20:46:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 33054 invoked from network); 19 Jun 2009 20:07:45 -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 ; 19 Jun 2009 20:07:45 -0000 Message-ID: <4A3BF2DF.6080603@freebsd.org> Date: Fri, 19 Jun 2009 22:19:43 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Harti Brandt References: <20090619191756.R581@beagle.kn.op.dlr.de> In-Reply-To: <20090619191756.R581@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD/net@dlr.de, freebsd-net@freebsd.org Subject: Re: TCP bug? 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, 19 Jun 2009 20:46:22 -0000 Harti Brandt wrote: > Hi all, > > one of my TCP test cases breaks in what one could call an edge case: > > When the TCP is in SYN-SENT state (the user has called connect()) and > the peer answers with an almost-lamp test packet which has SYN, FIN, ACK > and data larger than the window, TCP ACKs a window full of data, drops > the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks > wrong to me. When dropping the data that is outside the window, it > should also drop the FIN. Indeed. > The problem seems to be very old - I found it alread in rev. 1.1 of > tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of > the incoming segment is the next expected one, the reassembly queue is > empty and we are in an established state, the segment data is added to > the socket buffer and all TCP header flags are cleared except for > TH_FIN. Unfortunately here the original header flags are taken instead > of the cached version in thflags. Earlier in the processing the > out-of-window data and the FIN in thflags were chopped off and now > TH_FIN reappears. > > The fix should be easy: instead of using the original flag byte to get > the FIN use the cached copy. ... > I wonder, though, why the code is as it is, i.e. why it takes the > original FIN flag. Any idea? I guess there are two, possibly interrelated, explanations for that bug: 1) there are two code paths in TCP input processing depending on the current state of the connection. The header prediction path and the "slow" path. It's not always easy to keep them in sync. Sometimes adjustments or additions are only made to one of them. 2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN combination was a valid one, though not directly intended for SYN/ACK/FIN. It's easily imaginable that a bug or unforeseen interaction could creep in there. Your proposed patch does exactly the right thing by using the cached copy. I don't see any reason why thflags should be derived from th->th_flags way down here again. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 21:35:43 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EBA4106564A for ; Fri, 19 Jun 2009 21:35:43 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6978FC1D for ; Fri, 19 Jun 2009 21:35:43 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 94B51366902; Fri, 19 Jun 2009 17:35:42 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 19 Jun 2009 17:35:42 -0400 X-Sasl-enc: sIq6O7MsQRzF88fSnfdUozu86I/sgGJXMf/upoXD3h7a 1245447342 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id BDAF1193E7; Fri, 19 Jun 2009 17:35:41 -0400 (EDT) Message-ID: <4A3C04A8.101@incunabulum.net> Date: Fri, 19 Jun 2009 22:35:36 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andre Oppermann References: <20090619191756.R581@beagle.kn.op.dlr.de> <4A3BF2DF.6080603@freebsd.org> In-Reply-To: <4A3BF2DF.6080603@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD/net@dlr.de, freebsd-net@freebsd.org, Harti Brandt Subject: Re: TCP bug? 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, 19 Jun 2009 21:35:43 -0000 Andre Oppermann wrote: > ... > 2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN > combination was a valid one, though not directly intended for > SYN/ACK/FIN. T/TCP has been superseded by SCTP, and should be completely deprecated in the stack, IMHO. I believe this has been done, this could well be a corner case exposed by incomplete removal of T/TCP support. thanks BMS From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 21:40:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF81C106564A for ; Fri, 19 Jun 2009 21:40:02 +0000 (UTC) (envelope-from debsmith@juniper.net) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by mx1.freebsd.org (Postfix) with ESMTP id 811F28FC14 for ; Fri, 19 Jun 2009 21:40:02 +0000 (UTC) (envelope-from debsmith@juniper.net) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSjwFqXhcz5clsHRbOm0u6gOG5p1+dGu1@postini.com; Fri, 19 Jun 2009 14:40:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 19 Jun 2009 14:22:02 -0700 From: Debra Smith To: "freebsd-net@freebsd.org" Date: Fri, 19 Jun 2009 14:22:00 -0700 Thread-Topic: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? Thread-Index: AcnxI/vHXfQiCjYkTAecmpu4dXUc8Q== Message-ID: <497B6D90E0023142AF34948DEFFAB38D396A867EEC@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? 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, 19 Jun 2009 21:40:03 -0000 Hello: Is it possible to post this opening with you? Thanks for your time... Software Engineer Layer 2 (Kernel/Networking/TCP/IP) As a key member of team, you will be responsible for developing embedded ne= tworking software for complex networking platforms. Develop detailed softwa= re functional and design specifications and implement the software. Demonstrate good teamwork across various teams. Experience: Requires workin= g knowledge of Layer-2/Layer-3 switching/routing protocols, data forwarding= and embedded systems programming. Strong understanding of routing and swit= ching technologies including TCP/IP, 802.3 protocol understanding - 802.1D,= 802.1w, 802.1q, 802.1p, 802.1x is required. Hands on experience of TCP/IP = stack in linux or BSD kernel. Requires MSEE/MSCS with 5-7 years of related = experience or BSEE/CS with 7-9+ years of related experience. From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 21:43:27 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 838671065676; Fri, 19 Jun 2009 21:43:27 +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 384D68FC15; Fri, 19 Jun 2009 21:43:26 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.2/8.14.2) with ESMTP id n5JLRTbY042618; Fri, 19 Jun 2009 17:27:29 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.2/8.13.8/Submit) id n5JLRTtE042617; Fri, 19 Jun 2009 17:27:29 -0400 (EDT) (envelope-from wollman) Date: Fri, 19 Jun 2009 17:27:29 -0400 (EDT) From: Garrett Wollman Message-Id: <200906192127.n5JLRTtE042617@hergotha.csail.mit.edu> To: andre@freebsd.org X-Newsgroups: mit.lcs.mail.freebsd-net In-Reply-To: <4A3BF2DF.6080603@freebsd.org> References: <20090619191756.R581@beagle.kn.op.dlr.de> Organization: None X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 19 Jun 2009 17:27:29 -0400 (EDT) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hergotha.csail.mit.edu Cc: net@freebsd.org Subject: Re: TCP bug? 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, 19 Jun 2009 21:43:27 -0000 In article <4A3BF2DF.6080603@freebsd.org>, Andre writes: >2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN > combination was a valid one, though not directly intended for SYN/ACK/FIN. It still is valid, and should be possible to generate using sendmsg() and MSG_EOF. Nothing about this depends on T/TCP, which is solely about reducing the three-way handshake to a two-way handshake. -GAWollman From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 21:56:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD294106566C; Fri, 19 Jun 2009 21:56:39 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by mx1.freebsd.org (Postfix) with ESMTP id A7C9C8FC12; Fri, 19 Jun 2009 21:56:39 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLI001HLAAEQS30@asmtp012.mac.com>; Fri, 19 Jun 2009 14:56:39 -0700 (PDT) Message-id: <670B545A-71FD-4591-B466-96B0B8BA046B@mac.com> From: Chuck Swiger To: Harti Brandt In-reply-to: <20090619220901.Y970@beagle.kn.op.dlr.de> Date: Fri, 19 Jun 2009 14:56:38 -0700 References: <20090619191756.R581@beagle.kn.op.dlr.de> <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> <20090619220901.Y970@beagle.kn.op.dlr.de> X-Mailer: Apple Mail (2.935.3) Cc: "freebsd-net@freebsd.org Net" Subject: Re: TCP bug? 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, 19 Jun 2009 21:56:40 -0000 Hi-- On Jun 19, 2009, at 1:15 PM, Harti Brandt wrote: > CS>See figure 12-- I think you should be sending a RST back.... > > I think this is too drastic. A segment is unacceptable only if it is > completly out of the window. Here part is in the window. Well, perhaps you're right that it would be drastic. I'll agree that the start of the segment falls within the window, at least if the window size is greater than 0. If you decide that the incoming segment is "possibly valid", then the conclusion that you should move to ESTABLISHED, accept and ACK the data which lies within the valid window, and drop/ignore the rest including the FIN seems to be a sensible consequence. Moving to CLOSE_WAIT state is not appropriate until you actually accept and process the sequence # which includes that FIN. > Also conceptually TCP enters the ESTABLISHED state as soon as it > finds that the ACK in the > SYN,ACK is correct before it starts to process the data and the FIN > (p.68 > of RFC793 - first you enter ESTABLISHED and ACK, then you goto step > 6). So > taking into account the explanation at top of page 70 (which logically > belongs to step 6) you just drop everything outside the window - > part of > the data and the FIN in our case - and proceed. > > Note, that the data in the SYN,ACK is always partly in the window > because > this segment contains the IRS, except if the window is 0 and the > segment contains data or FIN. If the window size is 0, only acks without any data are acceptable, but your test case seems to have a non-0 initial window size, so we don't need to belabor that point too much. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 23:27:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6FA1065674 for ; Fri, 19 Jun 2009 23:27:33 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id 118CF8FC18 for ; Fri, 19 Jun 2009 23:27:32 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 10233 invoked by uid 60001); 19 Jun 2009 23:27:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245454052; bh=NKkhHRoBQaR4Ui2tNqngAlsYos12OUIVcFITn1TPdXE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=aqj5W+BzOwaXOgQ9u99+u1uC3N54c/LXaCG9ucge5sIgTeFmtTIm3iBHjFmnKZlSXYw0+MrX4AO+hORqoBP+Qh2X6lFo5egQc7tqNLKAEOVwTMlf/wMKFQ+WaXWayAEHIAfOZRedEZBHFMyK3HE9NVpExToV5g1mDUgEhory8j4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=RB6LWhJf3C8gIz/5PphXMBV/egYNbgYqH8rIPMHQHnlrl8vl546lNq70jfQaD09yS0VAS05yYq9wkFWDWKGel/KOHlUSpWgyAaw6ju92ehH1gxx+Sl5VFFu7SNfXur3N5qQ2g9wpIvCtzZW7U5sCU/iKdbvHUD/INaLJ5jBFVds=; Message-ID: <387640.9423.qm@web63908.mail.re1.yahoo.com> X-YMail-OSG: NpJUycAVM1nyVq8qJhZjOUtpOJ86B5P0XSVi15laPUJ_mo1GXnqHGtsXum4Z2eDEwmGMNaBPNiXM9wd.LfyihSZffTIjc695NkcGjfDEY0tUxNc8jFmagcNMLMF67nqJY5gzOrCYg_l9cCp9re86NnpuQzDLwqh16fk.UKIb0YKd7kJ4XxG6yNwofn1sfDPSQDAfodF7wdYVxYFPMnwNfLsS5Ey4ByKcEvF0oDRjQZN7vEIobMnHLijuZaboE1OiXzFtUxLFheWoKJT3EHopuj26Ux6SMpKdZ3iyTGhAxaEh5M8XwJfrL8s- Received: from [66.176.162.245] by web63908.mail.re1.yahoo.com via HTTP; Fri, 19 Jun 2009 16:27:32 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Fri, 19 Jun 2009 16:27:32 -0700 (PDT) From: Barney Cordoba To: "freebsd-net@freebsd.org" , Debra Smith MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? 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, 19 Jun 2009 23:27:33 -0000 --- On Fri, 6/19/09, Debra Smith wrote: > From: Debra Smith > Subject: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? > To: "freebsd-net@freebsd.org" > Date: Friday, June 19, 2009, 5:22 PM > Hello: > > Is it possible to post this opening with you? > > Thanks for your time... > > > Software Engineer Layer 2 (Kernel/Networking/TCP/IP) > > As a key member of team, you will be responsible for > developing embedded networking software for complex > networking platforms. Develop detailed software functional > and design specifications and implement the software. > Demonstrate good teamwork across various teams. Experience: > Requires working knowledge of Layer-2/Layer-3 > switching/routing protocols, data forwarding and embedded > systems programming. Strong understanding of routing and > switching technologies including TCP/IP, 802.3 protocol > understanding - 802.1D, 802.1w, 802.1q, 802.1p, 802.1x is > required. Hands on experience of TCP/IP stack in linux or > BSD kernel. Requires MSEE/MSCS with 5-7 years of related > experience or BSEE/CS with 7-9+ years of related > experience. No, you can't. I love these arbitrary degree+years of experience. Why do they say 7-9+ years, instead of just 7+? Are they trying to confuse us? From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 23:57:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 625D4106564A for ; Fri, 19 Jun 2009 23:57:39 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 110598FC15 for ; Fri, 19 Jun 2009 23:57:38 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from working (pool-72-95-226-5.pitbpa.ftas.verizon.net [72.95.226.5]) (AUTH: LOGIN wmoran, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 19 Jun 2009 19:47:35 -0400 id 00056407.000000004A3C2397.0000517E Date: Fri, 19 Jun 2009 19:47:34 -0400 From: Bill Moran To: "freebsd-net@freebsd.org" Message-Id: <20090619194734.ba0f2e6a.wmoran@collaborativefusion.com> In-Reply-To: <387640.9423.qm@web63908.mail.re1.yahoo.com> References: <387640.9423.qm@web63908.mail.re1.yahoo.com> Organization: Collaborative Fusion Inc. X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: CAN I POST THIS OPENING (TCP/IP, Networking and FreeBSD) TO YOUR LIST? 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, 19 Jun 2009 23:57:39 -0000 Barney Cordoba wrote: > > > experience or BSEE/CS with 7-9+ years of related > > experience. > > No, you can't. > > I love these arbitrary degree+years of experience. Why do they say 7-9+ years, instead of just 7+? Are they trying to confuse us? Up to 30-50% of those requirements are arbitrary anyway ... -- Bill Moran Collaborative Fusion Inc. wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From owner-freebsd-net@FreeBSD.ORG Sat Jun 20 08:48:50 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD01C1065676 for ; Sat, 20 Jun 2009 08:48:50 +0000 (UTC) (envelope-from valeranew@ukr.net) Received: from ffe12.ukr.net (ffe12.ukr.net [195.214.192.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1868FC23 for ; Sat, 20 Jun 2009 08:48:49 +0000 (UTC) (envelope-from valeranew@ukr.net) Received: from mail by ffe12.ukr.net with local ID 1MHvtd-000NNL-AC for freebsd-net@freebsd.org; Sat, 20 Jun 2009 11:25:57 +0300 MIME-Version: 1.0 From: =?WINDOWS-1251?Q?"=D1=E8=F1=F2=E5=EC=ED=FB=E9_=E0=E4=EC=E8=ED=E8?= =?WINDOWS-1251?Q?=F1=F2=F0=E0=F2=EE=F0"?= To: freebsd-net@freebsd.org X-Mailer: freemail.ukr.net mPOP 3.6.1-current X-Life: is great, enjoy it! X-Originating-Ip: [91.203.140.40] X-Browser: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.9) Gecko/2009050519 Iceweasel/3.0.6 (Debian-3.0.6-1) In-Reply-To: <20090619120024.5E1731065688@hub.freebsd.org> References: <20090619120024.5E1731065688@hub.freebsd.org> Message-Id: Date: Sat, 20 Jun 2009 11:25:57 +0300 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd-net Digest, Vol 324, Issue 5 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, 20 Jun 2009 08:48:51 -0000 --- Исходное сообщение --- От кого: freebsd-net-request@freebsd.org Кому: freebsd-net@freebsd.org Дата: Jun 19, 2009 15:00:24 Тема: freebsd-net Digest, Vol 324, Issue 5 Send freebsd-net mailing list submissions to > freebsd-net@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-net > or, via email, send a message with subject or body 'help' to > freebsd-net-request@freebsd.org > > You can reach the person managing the list at > freebsd-net-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-net digest..." > > Today's Topics: > > 1. Re: bge interrupt coalescing sysctls (Igor Sysoev) > 2. PRESSRELEASE MARK VOXX FEAT. MC GRACE ?? SUBMISSION?? -->> > OUTNOW (news@markvoxx.com) > 3. Re: hostapd with 802.1X EAP-TLS/TTLS support (Sam Leffler) > 4. Bridging and using the interfaces concurrently (Axel Reinhold) > 5. [msk] watchdog timeout (missed Tx interrupts) -- recovering > (Karim Fodil-Lemelin) > 6. Re: [msk] watchdog timeout (missed Tx interrupts) -- > recovering (Pyun YongHyeon) > 7. Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering (Pyun YongHyeon) > 8. Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering (Pyun YongHyeon) > 9. Re: kern/132107: [carp] carp(4) advskew setting ignored when > carp IP used on a gif(4) interface (Daniel Duerr) > 10. Re: Bridging and using the interfaces concurrently > (Eygene Ryabinkin) > 11. mbuf layout optimizations (Jeff Roberson) > 12. Re: hostapd with 802.1X EAP-TLS/TTLS support (Vladimir Terziev) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Jun 2009 18:19:25 +0400 > From: Igor Sysoev > Subject: Re: bge interrupt coalescing sysctls > To: Bruce Evans > Cc: freebsd-net@FreeBSD.org > Message-ID: <20090618141925.GG60354@rambler-co.ru> > Content-Type: text/plain; charset=koi8-r > > On Thu, Jun 11, 2009 at 11:54:29AM +1000, Bruce Evans wrote: > > > On Wed, 10 Jun 2009, Igor Sysoev wrote: > > > > >For a long time I used Bruce Evans' patch to tune bge interrupt coalescing: > > >http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html > > >However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken > > >the patch. I'm not sure how to fix the collision, and since I do not > > >use dynamic tuning > > > > That commit looked ugly (lots of internal API changes and bloat in interrupt > > handlers in many network drivers to support polling which mostly shouldn't > > be supported at all and mostly doesn't use the interrupt handlers). > > > > >I has left only static coalescing parameters in the patch > > >and has added a loader tunable to set number of receive descriptors and > > >read only sysctl to read the tunable. I usually use these parameters: > > > > > >/boot/loader.conf: > > >hw.bge.rxd=512 > > > > > >/etc/sysctl.conf: > > >dev.bge.0.rx_coal_ticks=500 > > >dev.bge.0.tx_coal_ticks=10000 > > >dev.bge.0.rx_max_coal_bds=64 > > > > These rx settings give to high a latency for me. > > Probably, however, I use this on a host that has 6000 packets/s. > > > >dev.bge.0.tx_max_coal_bds=128 > > ># apply the above parameters > > >dev.bge.0.program_coal=1 > > > > > >Could anyone commit it ? > > > > Not me, sorry. > > > > The patch is quite clean. If I committed then I would commit the > > dynamic coalescing configuration separately anyway. > > So have you any objections if some one else will commit this patch ? > > > You can probably make hw.bge.rxd a sysctl too (it would take a down/up > > to get it changed, but that is already needed for too many parameters > > in network drivers anyway). I should use a sysctl for the ifq length > > too. This could be done at a high level for each driver. Limiting > > queue lengths may be a good way to reduce cache misses, while increasing > > them is sometimes good for reducing packet loss. > > Do you mean simple command sequence: > > sysctl hw.bge.rxd=512 > ifconfig down > ifconfig up > > or SYSCTL_ADD_PROC for hw.bge.rxd ? > > -- > Igor Sysoev > http://sysoev.ru/en/ > > ------------------------------ > > Message: 2 > Date: Thu, 18 Jun 2009 16:52:30 +0100 > From: "news@markvoxx.com" > Subject: PRESSRELEASE MARK VOXX FEAT. MC GRACE ?? SUBMISSION?? -->> > OUTNOW > To: freebsd-net@freebsd.org > Message-ID: <505656668421844159@smtpa.netcabo.pt> > Content-Type: text/plain ; charset="ISO-8859-1" > > Clica na imagem para ir para a loja do BeatPort ! > Click on the image to go to BeatPort Shop! > > > > > > www.myspace.com/djmarkvoxxproducer > www.myspace.com/themcgracespace > > > > To cancel your subscription to this newsletter, please reply to this message with the word REMOVE in the Subject line. > Para cancelar a subscriзгo desta newsletter, por favor responde a esta mensagem com a palavra REMOVER no assunto. > > ------------------------------ > > Message: 3 > Date: Thu, 18 Jun 2009 10:36:04 -0700 > From: Sam Leffler > Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support > To: Vladimir Terziev > Cc: freebsd-net@freebsd.org, "Paul B. Mahol" > Message-ID: <4A3A7B04.2020906@freebsd.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > EAP/TLS and TTLS should be configured by default in HEAD. Not sure what > is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ > the functionality you want by definitions to your src.conf: > > HOSTAPD_CFLAGS > HOSTAPD_DPADD > HOSTAPD_LDADD > > (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check > usr.sbin/wpa/hostapd/Makefile). > > As to what should be enabled by default, I can only say that I tried to > choose the most common setup as the default. Choosing this > configuration also balances between bloat and inclusion of code that > might not be as well audited and/or tested as other code. Hence the > default setup used to be WPA-PSK only but has since grown to include > various EAP flavors. My assumption was that anyone building a system > using these tools would want to go through and choose what they wanted > anyway so enabling everything was a bad idea. > > Sam > > Vladimir Terziev wrote: > > Hi Paul, > > > > is there some special reason behind this? Why the server is made part of > > the main distribution with stripped functionality ? > > > > Also, how can i enable it ? > > > > Thanks, > > > > Vladimir > > > > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > > > >> On 6/18/09, Vladimir Terziev wrote: > >> > >>> Hi, > >>> > >>> i try to setup wireless access point at home, based on FreeBSD > >>> 7.2R-i386, ral(4) wireless card and hostpad(8). > >>> > >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication. > >>> > >> I > >> > >>> issued a custom SSL certificate for the hostapd(8) and put the > >>> > >> following > >> > >>> directives in hostapd.conf: > >>> > >>> eap_server=0 > >>> ca_cert=/usr/local/etc/myCA.crt.pem > >>> server_cert=/usr/local/etc/hostapd.server.crt.pem > >>> private_key=/usr/local/etc/hostapd.server.key.pem > >>> private_key_passwd=some_pass > >>> > >>> When i tried to start the hostapd(8) i got the following errors: > >>> > >>> Line 15: unknown configuration item 'eap_server' > >>> Line 16: unknown configuration item 'ca_cert' > >>> Line 17: unknown configuration item 'server_cert' > >>> Line 18: unknown configuration item 'private_key' > >>> Line 19: unknown configuration item 'private_key_passwd' > >>> > >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > >>> > >> all > >> > >>> and if "not" why ? > >>> > >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8). > >> > >> -- > >> Paul > >> > >> > >> > > > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. > > > > > > _______________________________________________ > > 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" > > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 18 Jun 2009 21:10:19 +0200 (CEST) > From: Axel Reinhold > Subject: Bridging and using the interfaces concurrently > To: freebsd-net@freebsd.org > Message-ID: <200906181910.n5IJAJ2u007974@bongo.freakout.de> > Content-Type: text/plain; format=text; x-action=sign; > charset="US-ASCII" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have two FreeBSD-7.1 servers in a data-center hosted. > > Both servers have two em[01] gigabit network links. > First server's (call it "first") em0 is connected to the data-centers > internet uplink - the em1 is connected to the seconds servers > (call it "second") em1. > > first's /etc/rc.conf: > ifconfig_em0="inet 212.144.103.230 netmask 255.255.254.0" > defaultrouter="212.144.102.1" > ifconfig_em1="inet 192.168.102.1 netmask 255.255.255.0" > > seconds's /etc/rc.conf: > ifconfig_em1="inet 192.168.102.131 netmask 255.255.255.0" > > In this way the 192.168.102/24 network is for private > connection between the two servers and "second" is not connected > to the internet at all. > > Since i would have to pay extra charges to get the "second" > server also connected to the internet, i thought of bridging > the em0 and em1 of "first" and to alias another ip for the > second server (i have more ip's in the data-center left) on > "seconds" em1. > > Is this possible? What would i have to setup? > The private 192.168.102/24 network should remain intakt! > I just want to bridge "seconds" em1-MAC to the data-centers > switch-port which is connected to "first" em0. > > Any help? Or is this not possible? > > Axel > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9-PB (GNU/Linux) > > iD8DBQFKOpEIHQ9JwE2bDw0RAh9mAKCy2R7DAZYzqLfU/wKlwHiZWsQfAwCfUGne > 7nsmXfuWgxyo+HAM76VRU6w= > =LKp+ > -----END PGP SIGNATURE----- > > ------------------------------ > > Message: 5 > Date: Thu, 18 Jun 2009 16:18:32 -0400 > From: Karim Fodil-Lemelin > Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering > To: Pyun YongHyeon > Cc: freebsd-net@freebsd.org > Message-ID: <4A3AA118.9020609@xiplink.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > Concerning this pr: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I > have one of those 'strange' silicon here: > > FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 > > kernel: mskc2: port 0xee00-0xeeff mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 > kernel: msk2: on mskc2 > kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 > kernel: miibus2: on msk2 > kernel: e1000phy2: PHY 0 on miibus2 > kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto > > Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved > the problem. But applying the attached patch (written by Pyun I believe) > also solved the problem. > > I think your patch should be committed for others to benefit. > > Best regards, > > Karim. > > -------------- next part -------------- > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 186497) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -1355,27 +1355,25 @@ > CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); > /* Set the status list last index. */ > CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); > - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && > - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { > - /* WA for dev. #4.3 */ > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); > - /* WA for dev. #4.18 */ > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); > - } else { > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > - else > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); > - } > /* > - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. > + * Interrupt moderation and coalescing frames should be > + * controllable with sysctl variables or loader tunables > + * but the relationship between status updates and > + * interrupt moderation are not clear. Some hardware > + * revisions seem to very sensitive to these parameters > + * and could be resulted in poor performance as well as > + * non-working situation if improper values were chosen. > */ > + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > + else > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); > + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); > + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); > > /* Enable status unit. */ > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); > @@ -3586,6 +3584,10 @@ > domore = msk_handle_events(sc); > if ((status & Y2_IS_STAT_BMU) != 0) > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ); > + if (CSR_READ_1(sc, STAT_TX_TIMER_CTRL) == TIM_START) { > + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_STOP); > + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_START); > + } > > if (ifp0 != NULL && (ifp0->if_drv_flags & IFF_DRV_RUNNING) != 0 && > !IFQ_DRV_IS_EMPTY(&ifp0->if_snd)) > > ------------------------------ > > Message: 6 > Date: Fri, 19 Jun 2009 09:37:09 +0900 > From: Pyun YongHyeon > Subject: Re: [msk] watchdog timeout (missed Tx interrupts) -- > recovering > To: Karim Fodil-Lemelin > Cc: freebsd-net@freebsd.org > Message-ID: <20090619003709.GF93360@michelle.cdnetworks.co.kr> > Content-Type: text/plain; charset=us-ascii > > On Thu, Jun 18, 2009 at 04:18:32PM -0400, Karim Fodil-Lemelin wrote: > > Hello, > > > > Hi, > > > Concerning this pr: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I > > have one of those 'strange' silicon here: > > > > FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5 > > > > kernel: mskc2: port 0xee00-0xeeff > > mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3 > > kernel: msk2: on > > mskc2 > > kernel: msk2: Ethernet address: 00:03:2d:10:4e:26 > > kernel: miibus2: on msk2 > > kernel: e1000phy2: PHY 0 on miibus2 > > kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > 1000baseTX-FDX, auto > > > > Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved > > the problem. But applying the attached patch (written by Pyun I believe) > > also solved the problem. > > > > I think your patch should be committed for others to benefit. > > > > Thanks a lot! I'll write a follow-up mail to the PR. > > > Best regards, > > > > Karim. > > > > > > ------------------------------ > > Message: 7 > Date: Fri, 19 Jun 2009 00:40:05 GMT > From: Pyun YongHyeon > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering > To: freebsd-net@FreeBSD.org > Message-ID: <200906190040.n5J0e519069495@freefall.freebsd.org> > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Pyun YongHyeon > To: Duckhawk > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering > Date: Fri, 19 Jun 2009 09:43:05 +0900 > > --47eKBCiAZYFK5l32 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Sun, Feb 22, 2009 at 07:50:03AM +0000, Duckhawk wrote: > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > > > From: Duckhawk > > To: bug-followup@FreeBSD.org, skylord@linkline.ru > > Cc: > > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- > > recovering > > Date: Sun, 22 Feb 2009 12:26:51 +0500 > > > > --001636c5a26744f2de04637ccfc6 > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > > > also, same problem. D-Link DGE-560T > > > > %uname -a > > FreeBSD 7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009 > > duckhawk@:/usr/obj/usr/src/sys/GENERIC i386 > > > > %dmesg | grep "msk" > > mskc0: port 0x7000-0x70ff mem > > 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1 > > msk0: on mskc0 > > msk0: Ethernet address: 00:1b:11:79:53:eb > > miibus0: on msk0 > > mskc0: [FILTER] > > > > %pciconf -lv > > mskc0@pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186 > > rev=0x13 hdr=0x00 > > vendor = 'D-Link System Inc' > > device = 'DGE-560T PCIe Gigabit Ethernet Adapter' > > class = network > > subclass = ethernet > > Please try the following patch. > > --47eKBCiAZYFK5l32 > Content-Type: text/x-diff; charset=us-ascii > Content-Disposition: attachment; filename="msk.EC.patch" > > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 194467) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -1387,27 +1387,26 @@ > CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); > /* Set the status list last index. */ > CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); > - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && > - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { > - /* WA for dev. #4.3 */ > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); > - /* WA for dev. #4.18 */ > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); > - } else { > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > - else > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); > - } > /* > - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. > + * XXX > + * Interrupt moderation and coalescing frames should be > + * controllable with sysctl variables or loader tunables > + * but the relationship between status updates and > + * interrupt moderation are not clear to me. Some hardware > + * revisions seem to very sensitive to these parameters > + * and could be resulted in poor performance as well as > + * non-working situation if improper values were chosen. > */ > + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > + else > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); > + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); > + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); > > /* Enable status unit. */ > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); > > --47eKBCiAZYFK5l32-- > > ------------------------------ > > Message: 8 > Date: Fri, 19 Jun 2009 00:50:06 GMT > From: Pyun YongHyeon > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering > To: freebsd-net@FreeBSD.org > Message-ID: <200906190050.n5J0o6PN076484@freefall.freebsd.org> > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Pyun YongHyeon > To: sam > Cc: yongari@freebsd.org, bug-followup@FreeBSD.org > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering > Date: Fri, 19 Jun 2009 09:40:46 +0900 > > --pQhZXvAqiZgbeUkD > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Thu, Jul 31, 2008 at 04:06:42PM +0400, sam wrote: > > ----------------------------------------------- > > Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx > > interrupts) -- recovering > > Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx > > interrupts) -- recovering > > ----------------------------------------------- > > > > ----------------------------------------------- > > Jul 29 23:18:28 moon3 kernel: mskc0: > Ethernet> port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device > > 0.0 on pci2 > > Jul 29 23:18:28 moon3 kernel: msk0: > Yukon EC Id 0xb6 Rev 0x02> on mskc0 > > > > Jul 29 23:18:28 moon3 kernel: miibus0: on msk0 > > ----------------------------------------------- > > > > ----------------------------------------------- > > FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 > > 15:00:14 MSD 2008 root@moon3:/usr/src/sys/i386/compile/MOON3 i386 > > ----------------------------------------------- > > > > I confirm this problem. > > > > /Vladimir Ermakov > > > > > > Would you try attached patch and let me know hot it goes? > > --pQhZXvAqiZgbeUkD > Content-Type: text/x-diff; charset=us-ascii > Content-Disposition: attachment; filename="msk.EC.patch" > > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 194467) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -1387,27 +1387,26 @@ > CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr)); > /* Set the status list last index. */ > CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1); > - if (sc->msk_hw_id == CHIP_ID_YUKON_EC && > - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) { > - /* WA for dev. #4.3 */ > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK); > - /* WA for dev. #4.18 */ > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21); > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07); > - } else { > - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > - if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > - sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > - else > - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190); > - } > /* > - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI. > + * XXX > + * Interrupt moderation and coalescing frames should be > + * controllable with sysctl variables or loader tunables > + * but the relationship between status updates and > + * interrupt moderation are not clear to me. Some hardware > + * revisions seem to very sensitive to these parameters > + * and could be resulted in poor performance as well as > + * non-working situation if improper values were chosen. > */ > + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a); > + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10); > + if (sc->msk_hw_id == CHIP_ID_YUKON_XL && > + sc->msk_hw_rev == CHIP_REV_YU_XL_A0) > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04); > + else > + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10); > CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000)); > + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30)); > + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50)); > > /* Enable status unit. */ > CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON); > > --pQhZXvAqiZgbeUkD-- > > ------------------------------ > > Message: 9 > Date: Fri, 19 Jun 2009 07:10:02 GMT > From: Daniel Duerr > Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when > carp IP used on a gif(4) interface > To: freebsd-net@FreeBSD.org > Message-ID: <200906190710.n5J7A2cD078751@freefall.freebsd.org> > > The following reply was made to PR kern/132107; it has been noted by GNATS. > > From: Daniel Duerr > To: bug-followup@FreeBSD.org, > adaugherity@tamu.edu > Cc: > Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface > Date: Thu, 18 Jun 2009 23:51:09 -0700 > > Having the same issue here and the workaround isn't working for me -- > it preserves the advskew but the vpn doesn't seem to work without the > devd attach event. Hope someone will fix this soon. > > > > > ------------------------------ > > Message: 10 > Date: Fri, 19 Jun 2009 12:55:03 +0400 > From: Eygene Ryabinkin > Subject: Re: Bridging and using the interfaces concurrently > To: Axel Reinhold > Cc: freebsd-net@freebsd.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Axel, good day. > > Thu, Jun 18, 2009 at 09:10:19PM +0200, Axel Reinhold wrote: > > Since i would have to pay extra charges to get the "second" > > server also connected to the internet, i thought of bridging > > the em0 and em1 of "first" and to alias another ip for the > > second server (i have more ip's in the data-center left) on > > "seconds" em1. > > > > Is this possible? What would i have to setup? > > The private 192.168.102/24 network should remain intakt! > > NAT the "second" box on your "first" one and that's it. Bridging > won't help much here, because your "second"s IPs are unroutable, so > someone will still need to translate them. If your intention is to > provide only client-level connectivity to the "second" box (when it > initiates all connections), simple NAT will work. If you need some > port to be opened at the "second" host and the should be reachable > from the outside, then you'll additionally need port mirroring. > > Or, if you really want to spend an extra IP for the second box, then > just binat (in the terms of pf.conf(5)) your private address to the > second IP on the "first" server. > > The exact solution for NAT depends on the firewall type you're using on > the "first" server. For ipfw you probably should look at the natd(8), > for ipfilter -- at ipnat(8), for pf -- at pf(4) and pf.conf(5). May be > netgraph(4) will be of some help, but this adds some extra complexity > for people who aren't familiar with Netgraph concepts and tools. > > If you really want bridging, then the easiest thing will be to create > two VLAN (if_vlan(4)) interfaces on your link between two servers: one > VLAN for the 192.168.102/24 network and one for the public network. > After this, packets from 192.168 will flow as they flowed before, and > you should bridge your "first"'s external interface with the second VLAN > interface on this host. Put your extra external IP to the other side of > the VLAN interface and it should do what you need. > > NAT should be easier, bridging should be faster, but the difference > strongly depends on the type of traffic and usage of the inter-server > link. > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > > ------------------------------ > > Message: 11 > Date: Thu, 18 Jun 2009 23:12:45 -1000 (HST) > From: Jeff Roberson > Subject: mbuf layout optimizations > To: net@freebsd.org, current@freebsd.org > Message-ID: > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > http://people.freebsd.org/~jeff/mbuf2.diff > > Hello, > > This is a call for testers and feedback on my mbuf layout improvements. > I'm trying to decide whether I will push to have these included in 8.0. > After reducing the scope slightly from my last patch, I have not > encountered any problems. Kip Macy has also been using it for the past > few weeks without issue. > > You should not expect any functional changes from this patch. The goal > is mostly to pave the way fors more sensible mbuf handling in the future, > although it does offer a few performance benefits. > > The only issue is that cxgb support requires another set of patches from > Kip. If anyone needs those I will prod him to reply with that diff. > > Thanks, > Jeff > > ------------------------------ > > Message: 12 > Date: Fri, 19 Jun 2009 13:55:26 +0300 > From: Vladimir Terziev > Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support > To: Sam Leffler > Cc: freebsd-net@freebsd.org, "Paul B. Mahol" > Message-ID: <1245408926.31855.26.camel@daemon2.partygaming.local> > Content-Type: text/plain > > Thanks Sam, > > What should i put for HOSTAPD_CFLAGS, HOSTAPD_DPADD, HOSTAPD_LDADD or > WPA_SUPPLICANT_* (not sure which ones i should use) in order to get > hostapd rebuilt with the functionality i want ? > > Regards, > > Vladimir > > On Thu, 2009-06-18 at 20:36 +0300, Sam Leffler wrote: > > EAP/TLS and TTLS should be configured by default in HEAD. Not sure > > what > > is done in RELENG_7. Regardless you can trivially rebuild hostapd w/ > > the functionality you want by definitions to your src.conf: > > > > HOSTAPD_CFLAGS > > HOSTAPD_DPADD > > HOSTAPD_LDADD > > > > (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check > > usr.sbin/wpa/hostapd/Makefile). > > > > As to what should be enabled by default, I can only say that I tried > > to > > choose the most common setup as the default. Choosing this > > configuration also balances between bloat and inclusion of code that > > might not be as well audited and/or tested as other code. Hence the > > default setup used to be WPA-PSK only but has since grown to include > > various EAP flavors. My assumption was that anyone building a system > > using these tools would want to go through and choose what they wanted > > anyway so enabling everything was a bad idea. > > > > Sam > > > > > > Vladimir Terziev wrote: > > > Hi Paul, > > > > > > is there some special reason behind this? Why the server is made > > part of > > > the main distribution with stripped functionality ? > > > > > > Also, how can i enable it ? > > > > > > Thanks, > > > > > > Vladimir > > > > > > > > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote: > > > > > >> On 6/18/09, Vladimir Terziev wrote: > > >> > > >>> Hi, > > >>> > > >>> i try to setup wireless access point at home, based on FreeBSD > > >>> 7.2R-i386, ral(4) wireless card and hostpad(8). > > >>> > > >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS > > authentication. > > >>> > > >> I > > >> > > >>> issued a custom SSL certificate for the hostapd(8) and put the > > >>> > > >> following > > >> > > >>> directives in hostapd.conf: > > >>> > > >>> eap_server=0 > > >>> ca_cert=/usr/local/etc/myCA.crt.pem > > >>> server_cert=/usr/local/etc/hostapd.server.crt.pem > > >>> private_key=/usr/local/etc/hostapd.server.key.pem > > >>> private_key_passwd=some_pass > > >>> > > >>> When i tried to start the hostapd(8) i got the following errors: > > >>> > > >>> Line 15: unknown configuration item 'eap_server' > > >>> Line 16: unknown configuration item 'ca_cert' > > >>> Line 17: unknown configuration item 'server_cert' > > >>> Line 18: unknown configuration item 'private_key' > > >>> Line 19: unknown configuration item 'private_key_passwd' > > >>> > > >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at > > >>> > > >> all > > >> > > >>> and if "not" why ? > > >>> > > >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's > > hostapd(8). > > >> > > >> -- > > >> Paul > > >> > > >> > > >> > > > > > > This email and any attachments are confidential, and may be legally > > privileged and protected by copyright. If you are not the intended > > recipient dissemination or copying of this email is prohibited. If you > > have received this in error, please notify the sender by replying by > > email and then delete the email completely from your system. > > > > > > Any views or opinions are solely those of the sender. This > > communication is not intended to form a binding contract unless > > expressly indicated to the contrary and properly authorised. Any > > actions taken on the basis of this email are at the recipient's own > > risk. > > > > > > > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > ------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > End of freebsd-net Digest, Vol 324, Issue 5 > ******************************************* > > С Уважением, Валерий. Сисадмин: Linux&FreeBSD 4+ mailto: wel@skm.net.ua Я все печатаю в типографии Мадрид Мой провайдер Skyhome From owner-freebsd-net@FreeBSD.ORG Sat Jun 20 10:52:53 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1537C106566C; Sat, 20 Jun 2009 10:52:53 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by mx1.freebsd.org (Postfix) with ESMTP id C8D798FC1B; Sat, 20 Jun 2009 10:52:52 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [62.143.132.243] (helo=localhost) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1MHxvq-00085n-OJ; Sat, 20 Jun 2009 12:36:24 +0200 Date: Sat, 20 Jun 2009 12:36:57 +0200 From: Fabian Keil To: Jeff Roberson Message-ID: <20090620123657.21728020@fabiankeil.de> In-Reply-To: References: X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Df-Sender: 775067 Cc: current@freebsd.org, net@freebsd.org Subject: Re: mbuf layout optimizations 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, 20 Jun 2009 10:52:53 -0000 Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf2.diff > This is a call for testers and feedback on my mbuf layout improvements. > I'm trying to decide whether I will push to have these included in 8.0. > After reducing the scope slightly from my last patch, I have not > encountered any problems. Kip Macy has also been using it for the past > few weeks without issue. > > You should not expect any functional changes from this patch. The goal > is mostly to pave the way fors more sensible mbuf handling in the > future, although it does offer a few performance benefits. So far I haven't been able to reproduce the em-related panic I reported with an earlier version of the patch. I'm not sure if it was reproducible back then, though. Fabian From owner-freebsd-net@FreeBSD.ORG Sat Jun 20 19:22:31 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08EE9106564A; Sat, 20 Jun 2009 19:22:31 +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 D299B8FC16; Sat, 20 Jun 2009 19:22:30 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5KJMUQ9020470; Sat, 20 Jun 2009 19:22:30 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5KJMU5N020466; Sat, 20 Jun 2009 19:22:30 GMT (envelope-from remko) Date: Sat, 20 Jun 2009 19:22:30 GMT Message-Id: <200906201922.n5KJMU5N020466@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/135836: bce BCM5709 Watchdog [i386] after warm boot - ok after cold boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 19:22:31 -0000 Synopsis: bce BCM5709 Watchdog [i386] after warm boot - ok after cold boot Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Jun 20 19:21:52 UTC 2009 Responsible-Changed-Why: reassign to -net team, as this is for the BCE driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=135836 From owner-freebsd-net@FreeBSD.ORG Sat Jun 20 20:46:11 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A66106564A; Sat, 20 Jun 2009 20:46:11 +0000 (UTC) (envelope-from pg@2lazy.ru) Received: from cloud9.2lazy.ru (cloud9.2lazy.ru [88.204.75.147]) by mx1.freebsd.org (Postfix) with ESMTP id 8E0EB8FC08; Sat, 20 Jun 2009 20:46:10 +0000 (UTC) (envelope-from pg@2lazy.ru) Received: from mx.2lazy.ru (localhost [127.0.0.1]) by cloud9.2lazy.ru (8.14.3/8.14.3) with ESMTP id n5KKGmlt050224; Sun, 21 Jun 2009 03:16:48 +0700 (TSD) (envelope-from pg@2lazy.ru) Message-ID: <4A3D43AF.7060009@2lazy.ru> Date: Sun, 21 Jun 2009 00:16:47 +0400 From: Pavel Gubin Organization: Lazy User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.8.1.19) Gecko/20090111 SeaMonkey/1.1.14 MIME-Version: 1.0 To: freebsd-drivers@freebsd.org, freebsd-net@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Wireless, Realtek RTL8185L-based PCI adapter. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pg@2lazy.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 20:46:11 -0000 Hi All, Recently I've got 802.11b/g adapter TL-WN353GD from TP-Link, based on Realtek RTL8185L chip. Seems that there is no support for it in FreeBSD yet, but there are some mentionings about 8185 in /sys/dev/usb/wlan/if_urtw*. Also, Realtek has a Linux driver for it, and this driver is partly based on NetBSD's if_rtw driver for RTL8180 (which seems to be 802.11a/b predecessor of 8185). So, I'm wondering - does someone work already on a driver for this chip, or maybe I should try to write a driver myself? Thanks, -- Pavel Gubin Jabber: xmpp:pg@2lazy.ru / Phone +79218959055 / sip:pg@2lazy.ru