From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 00:35:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90369106566C for ; Sun, 21 Nov 2010 00:35:09 +0000 (UTC) (envelope-from pozar@lns.com) Received: from kumr.lns.com (kumr.lns.com [209.237.227.146]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA6F8FC1C for ; Sun, 21 Nov 2010 00:35:09 +0000 (UTC) Received: from Tim-Pozars-MacBook-Pro-4.local (kumr.lns.com [209.237.227.146]) by kumr.lns.com (8.14.3/8.14.3) with ESMTP id oAL09XGT061029 for ; Sat, 20 Nov 2010 16:09:56 -0800 (PST) (envelope-from pozar@lns.com) Message-ID: <4CE8633D.3020501@lns.com> Date: Sat, 20 Nov 2010 16:09:33 -0800 From: Tim Pozar User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.1.1 OpenPGP: id=83385B04; url=http://www.lns.com/house/pozar/pozar_4096_rsa_public.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on kumr.lns.com Subject: FreeBSD is occasionally not replying to ICMP packets... 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, 21 Nov 2010 00:35:09 -0000 Sending to a FreeBSD 8.0 RELEASE box from a cisco switch that the BSD box is directly connected to... > cs01-200p-sfo#ping netmon repeat 1024 > > Type escape sequence to abort. > Sending 1024, 100-byte ICMP Echos to 207.241.239.174, timeout is 2 seconds: > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! > Success rate is 99 percent (1019/1024), round-trip min/avg/max = 1/2/9 ms > cs01-200p-sfo# On the BSD box I see it not replying every 200 pings.... # tcpdump -i bge0 icmp and host 10.1.0.33 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes 10:55:14.095509 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 0, length 80 10:55:14.095526 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 0, length 80 [...] 10:55:14.658113 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 198, length 80 10:55:14.658119 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 198, length 80 10:55:14.659467 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 199, length 80 10:55:16.663280 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 200, length 80 10:55:16.663291 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 200, length 80 10:55:16.665421 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 201, length 80 [...] 10:55:17.166991 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 398, length 80 10:55:17.167003 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 398, length 80 10:55:17.169476 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 399, length 80 10:55:19.170156 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 400, length 80 10:55:19.170167 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 400, length 80 10:55:19.171675 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 401, length 80 [...] 10:55:19.676469 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 598, length 80 10:55:19.676474 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 598, length 80 10:55:19.679062 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 599, length 80 10:55:21.677805 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 600, length 80 10:55:21.677817 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 600, length 80 10:55:21.683652 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 601, length 80 [...] 10:55:22.170528 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 797, length 80 10:55:22.172653 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 798, length 80 [...] 10:55:24.730624 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 998, length 80 10:55:24.733990 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 999, length 80 10:55:26.736330 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 1000, length 80 10:55:26.736343 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 1000, length 80 10:55:26.739407 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 1001, length 80 10:55:26.739417 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 1001, length 80 [...] 10:55:26.808634 IP 10.1.0.33 > 207.241.239.174: ICMP echo request, id 14, seq 1023, length 80 10:55:26.808643 IP 207.241.239.174 > 10.1.0.33: ICMP echo reply, id 14, seq 1023, length 80 I don't see this behaviour on other non-BSD devices on this network such as a Linux box that is also directly connected to this switch. Thoughts? Thanks... Tim From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 00:45:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1DB3106566C for ; Sun, 21 Nov 2010 00:45:13 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 84A578FC15 for ; Sun, 21 Nov 2010 00:45:13 +0000 (UTC) Received: by ewy3 with SMTP id 3so3339187ewy.13 for ; Sat, 20 Nov 2010 16:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KYi4/uNvXqhE4D2nV8223jOemuPkjo6AoebywtdsyVI=; b=Q3I5Np/b/g/Ugl215zddAAMo30gO5Z4roaS29+57Snb5XSSSaBFsj9wpYiOuGBsHwV 18QVWStugek0idef0YnoHxFZ7rjkyAGhN5K/mzOU9ckPH7FmnLlTvEiNbDf59VFPewl/ u9Uur/cV+czABNnGvex+5pv1/5u2SXZSDFzJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OLtsZuIh+my9lspYuDb3ZTP1OXek8XEX1r8JXbDIFqSVQXkMrj4KGXv59VkvXxiufj QE3zcwKqSPRvfmQ9WbvBMYH010n+waiYzbV7SKeAMHKgHmUOfYZHBcHVLPZ1Q5hj2pFK oe6GTxThg4PWIfi1sBYMDMeM/VGrhwUV/eJXQ= MIME-Version: 1.0 Received: by 10.213.114.75 with SMTP id d11mr3104073ebq.74.1290300312649; Sat, 20 Nov 2010 16:45:12 -0800 (PST) Received: by 10.213.14.138 with HTTP; Sat, 20 Nov 2010 16:45:12 -0800 (PST) In-Reply-To: <4CE8633D.3020501@lns.com> References: <4CE8633D.3020501@lns.com> Date: Sat, 20 Nov 2010 19:45:12 -0500 Message-ID: From: Ryan Stone To: Tim Pozar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD is occasionally not replying to ICMP packets... 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, 21 Nov 2010 00:45:14 -0000 How many packets per second are you sending? By default FreeBSD will only send 200 ICMP responses per second. You can adjust this limit by setting the sysctl net.inet.icmp.icmplim. If you set it to 0 no limit will be enforced. Ryan Stone From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 00:56:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C981065672 for ; Sun, 21 Nov 2010 00:56:34 +0000 (UTC) (envelope-from pozar@lns.com) Received: from kumr.lns.com (kumr.lns.com [209.237.227.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4C58FC16 for ; Sun, 21 Nov 2010 00:56:34 +0000 (UTC) Received: from Tim-Pozars-MacBook-Pro-4.local (kumr.lns.com [209.237.227.146]) by kumr.lns.com (8.14.3/8.14.3) with ESMTP id oAL0uA2u062811; Sat, 20 Nov 2010 16:56:32 -0800 (PST) (envelope-from pozar@lns.com) Message-ID: <4CE86E29.4060003@lns.com> Date: Sat, 20 Nov 2010 16:56:09 -0800 From: Tim Pozar User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ryan Stone References: <4CE8633D.3020501@lns.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=83385B04; url=http://www.lns.com/house/pozar/pozar_4096_rsa_public.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on kumr.lns.com Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD is occasionally not replying to ICMP packets... 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, 21 Nov 2010 00:56:35 -0000 Yup... That was it. Thanks... Tim -- # sysctl -a | grep net.inet.icmp.icmplim net.inet.icmp.icmplim: 200 # sysctl net.inet.icmp.icmplim=0 net.inet.icmp.icmplim: 200 -> 0 # > cs01-200p-sfo#ping 10.1.0.2 repeat 1024 > > Type escape sequence to abort. > Sending 1024, 100-byte ICMP Echos to 10.1.0.2, timeout is 2 seconds: > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > Success rate is 100 percent (1024/1024), round-trip min/avg/max = 1/2/17 ms > cs01-200p-sfo# on 11/20/10 4:45 PM Ryan Stone said the following: > How many packets per second are you sending? By default FreeBSD will > only send 200 ICMP responses per second. You can adjust this limit by > setting the sysctl net.inet.icmp.icmplim. If you set it to 0 no limit > will be enforced. > > Ryan Stone -- GPG Fingerprint: 4821 CFDA 06E7 49F3 BF05 3F02 11E3 390F 8338 5B04 http://www.lns.com/house/pozar/pozar_4096_rsa_public.asc From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 19:18:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABF5F106566C for ; Sun, 21 Nov 2010 19:18:45 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 39BCF8FC12 for ; Sun, 21 Nov 2010 19:18:44 +0000 (UTC) Received: by bwz2 with SMTP id 2so5670594bwz.13 for ; Sun, 21 Nov 2010 11:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:user-agent:mime-version:content-type; bh=NHLGrFonkXKoeiIXP6Xo/k1bJeC3aELJUHfpMzG4RK8=; b=Gj+sORrfUGz+SiXiIEyNPZftbQpR1cYtm3OrX2AaqkK67jxnADrQ6uONUtkLEITEra Vg70ST/LznZhoBcMmdUvxWsbz8gvMYSjyIkm44Lu65JuFYlF6qOS88VBD88EXiJhpzuG qfZ2XCWT3Zt4ok1U9YkTm3feVO288f6LaeI3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; b=FIzKMsVsXKpeiLiEOIHS60xb5O59T2pke+VYdIfZLU2tmdJ1WqFY3np/LjRFGjYYn8 kmAG6Up9rls7gF5Q6JC6yCvedzDfAO43L45JY4PNqcyhpBvKy+k1oC7gwx0aodCejORy U2Oov2yGb9/DUHrdVoDhsjr1FaAGsmoQesMGc= Received: by 10.204.129.210 with SMTP id p18mr4372979bks.85.1290365286559; Sun, 21 Nov 2010 10:48:06 -0800 (PST) Received: from localhost ([95.69.174.185]) by mx.google.com with ESMTPS id p34sm1978764bkf.15.2010.11.21.10.48.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Nov 2010 10:48:05 -0800 (PST) From: Mikolaj Golub To: freebsd-net@FreeBSD.org Date: Sun, 21 Nov 2010 20:48:03 +0200 Message-ID: <86aal28qe4.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Subject: net/if_epair.c: semicolon missed 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, 21 Nov 2010 19:18:45 -0000 --=-=-= Hi, In net/if_epair.c semicolon is missed in epair_nh_drainedcpu() (see the patch below). This shows up when compiling with EPAIR_DEBUG. Also, what was a reason to declare epair_debug mib as XINT? Shouldn't be just INT? -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=if_epair.c.patch Index: sys/net/if_epair.c =================================================================== --- sys/net/if_epair.c (revision 215576) +++ sys/net/if_epair.c (working copy) @@ -305,7 +305,7 @@ epair_nh_drainedcpu(u_int cpuid) if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) != 0) { /* Our "hw"q overflew again. */ - epair_dpcpu->epair_drv_flags |= IFF_DRV_OACTIVE + epair_dpcpu->epair_drv_flags |= IFF_DRV_OACTIVE; DPRINTF("hw queue length overflow at %u\n", epair_nh.nh_qlimit); break; --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 19:34:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CDE11065672 for ; Sun, 21 Nov 2010 19:34:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF238FC15 for ; Sun, 21 Nov 2010 19:34:02 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7F76E41C7A4; Sun, 21 Nov 2010 20:34:00 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id EGiaYFGPY9eS; Sun, 21 Nov 2010 20:33:59 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id CF73F41C7AE; Sun, 21 Nov 2010 20:33:59 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 128EE44490B; Sun, 21 Nov 2010 19:32:13 +0000 (UTC) Date: Sun, 21 Nov 2010 19:32:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mikolaj Golub In-Reply-To: <86aal28qe4.fsf@kopusha.home.net> Message-ID: <20101121192915.P24596@maildrop.int.zabbadoz.net> References: <86aal28qe4.fsf@kopusha.home.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: net/if_epair.c: semicolon missed 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, 21 Nov 2010 19:34:02 -0000 On Sun, 21 Nov 2010, Mikolaj Golub wrote: Hi, > In net/if_epair.c semicolon is missed in epair_nh_drainedcpu() (see the > patch below). This shows up when compiling with EPAIR_DEBUG. Thanks. I'll commit it it in a sec. > Also, what was a reason to declare epair_debug mib as XINT? Shouldn't be just > INT? I changed it to INT as well; initially there was a mask if I don't misremember when I did the driver two years ago before it hit any repo. -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 19:41:01 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C74591065673 for ; Sun, 21 Nov 2010 19:41:01 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 073298FC1F for ; Sun, 21 Nov 2010 19:41:00 +0000 (UTC) Received: (qmail 53599 invoked from network); 21 Nov 2010 19:40:59 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 21 Nov 2010 19:40:59 -0000 Date: Sun, 21 Nov 2010 20:40:59 +0100 (CET) Message-Id: <20101121.204059.41699804.sthaug@nethelp.no> To: bzeeb-lists@lists.zabbadoz.net From: sthaug@nethelp.no In-Reply-To: <20101118152809.C24596@maildrop.int.zabbadoz.net> References: <20101118080153.Y24596@maildrop.int.zabbadoz.net> <20101118.135840.74708328.sthaug@nethelp.no> <20101118152809.C24596@maildrop.int.zabbadoz.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: How to generate IPv6 RA without any prefixes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2010 19:41:01 -0000 > >>> In IPv6 it should be possible to generate a Router Advertisement which > >>> contains no prefix options (the idea being that I want the host to > >>> populate its default router list but nothing else). However, I cannot > >>> seem to get rtadvd to do this. > > Can you open a PR and get it assigned to net@ or bz@, so this won't be > lost? I am not sure I'll be able to look the next 10 days. I have just submitted a PR with the one-line description "rtadvd needs to allow RA without a prefix info option", but haven't yet received a confirmation back. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sun Nov 21 20:16:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBF771065674 for ; Sun, 21 Nov 2010 20:16:00 +0000 (UTC) (envelope-from gabor.radnai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 458198FC08 for ; Sun, 21 Nov 2010 20:15:59 +0000 (UTC) Received: by fxm19 with SMTP id 19so4425057fxm.13 for ; Sun, 21 Nov 2010 12:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=OK+ohVN+pFdYOuk9zhPOp6VrVNSpznwGyDZikbDz/yI=; b=P8qo7CS/eHzav8g8w4o4SqD3yb4/ZkorF6mDNFEafNdoF55z9T22tT3BXckmSnQjvl NnPAYmX5+oe7XGNl363Q0p2T7hXr2EtVmAIy/njhOBY7p7TBlEuIVKWBur2/qJGzXo2F fjW2ZZh5BE1fPROAfSupGbbbd9V6eNLlcyazw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=HurSgW0jHv19oqYZWjwuxr2Vnrr7x99YCaFxwan36t2RIfq4QNTXtIi5Copne7UjeA 4Sqshlcf2B/2VQ/f4KdDR3v84Ww1VStL+8TQtfCrtTxlRT6/PIwR7GISSaT9G8b3g7eR ama47rhRrhBusbFN3X+o820+20ZytTt8lgA2Y= Received: by 10.223.100.15 with SMTP id w15mr2102942fan.121.1290370559085; Sun, 21 Nov 2010 12:15:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.93.138 with HTTP; Sun, 21 Nov 2010 12:15:18 -0800 (PST) In-Reply-To: References: <20101111212648.GF17566@michelle.cdnetworks.com> <20101112225320.GC22460@michelle.cdnetworks.com> From: Gabor Radnai Date: Sun, 21 Nov 2010 21:15:18 +0100 Message-ID: To: pyunyh@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 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, 21 Nov 2010 20:16:00 -0000 > Ok, please try latest re(4) in HEAD. I am noob with this, sorry. Could you please give guidance? If I copy if_re.ko from snapshot image to /boot/kernel/ is it sufficient or have to build a whole new kernel from HEAD source? Can somehow just compile a new driver if copy does not work? Thanks. From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 02:59:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7D01106566C for ; Mon, 22 Nov 2010 02:59:19 +0000 (UTC) (envelope-from siquijorphilips@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6C18FC0A for ; Mon, 22 Nov 2010 02:59:19 +0000 (UTC) Received: by qwi4 with SMTP id 4so324830qwi.13 for ; Sun, 21 Nov 2010 18:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PmhJrwswoZtQmdmdqqQg3mt0niebRRVlZyaPWkdYnE8=; b=PhYF6YTeTdL29ld7Z5AKWIAEBmqVUaAL3Qqm7IF9e5ucAj6tQeu3biH7cGgbfhUZFj Df4p7cHynhA6D5YBgs83i17y0oCIU6kPRjYpe1t2EdsW5Zy9SW7CxVLmZk21vKdDI4tq tLRQpEQ446nhp2rDWSIZaLVkZ75EnZ/Nlk22k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pSmOwseV4Mwo1edxB7SNzDojeu4DSaufRfDzrC9glhUBsUji3dtOaJsV7dQcy68irY N5hzKWd5nngtI3rcp5SpOjdATo295YG3LZo6xYkhyIQxmqFX3ufOELtoUzYJnoWjNCOe AGPJu9p+fITo72DAn08V56fROYzIRAlqMNLB4= MIME-Version: 1.0 Received: by 10.229.224.212 with SMTP id ip20mr4443563qcb.278.1290394758583; Sun, 21 Nov 2010 18:59:18 -0800 (PST) Received: by 10.229.32.140 with HTTP; Sun, 21 Nov 2010 18:59:18 -0800 (PST) In-Reply-To: <20101119.095212.74667071.sthaug@nethelp.no> References: <20101119.095212.74667071.sthaug@nethelp.no> Date: Mon, 22 Nov 2010 10:59:18 +0800 Message-ID: From: Siquijor Philips To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: How to generate IPv6 RA without any prefixes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 02:59:19 -0000 On Fri, Nov 19, 2010 at 4:52 PM, wrote: >> > In IPv6 it should be possible to generate a Router Advertisement which >> > contains no prefix options (the idea being that I want the host to >> > populate its default router list but nothing else). However, I cannot >> > seem to get rtadvd to do this. >> > >> > If I start rtadvd with no /etc/rtadvd.conf file, it sends RAs with a >> > prefix option corresponding to the IPv6 address of the interface. In >> > the /etc/rtadvd.conf I can explicitly specify prefixes ("addr"), but >> > I can't find any way to specify that no prefix options should be sent. >> > >> > Any suggestions? >> >> You mean to say that you want your router to act as the default IPv6 >> gateway only advertising default route via RA and the IPv6 prefixes >> are managed by other means such as DHCPv6 server? > > Correct. > >> Because by its the >> only way I can think of with your case now. You can specify >> 'pinfoflags' with 'l' in the /etc/rtadvd.conf to suppress the prefix >> information option being advertised. > > Specifying a prefix ("addr") and "pinfoflags" with "l" makes rtadvd send > RAs with a prefix info option option which contains the onlink flag. It > certainly does not suppress the prefix info option. > > Specifying a prefix ("addr") and "pinfoflags" without "a" makes rtadvd > send RAs with a prefix info option which does not contain the auto flag > - this prevents SLAAC from taking place. > > I would like to get rtadvd to send RAs completely *without* a prefix > info option. My Juniper routers at work can do this just fine... > Oh I see. I haven't tried this case with FreeBSD configuring RA with default route info only. So, how your Juniper router coordinate your DHCPv6 server to inform the hosts or nodes where to get prefix info since then your router wasn't configured with pinfoflags options? Or the hosts are just configured with DHCPv6 client informing directly the DHCPv6 server for IPv6 address info while its default route is obtainable via RA through SLAAC? > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > > > Regards, Siquijor From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 08:01:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82F7B106566B for ; Mon, 22 Nov 2010 08:01:51 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id B46DF8FC12 for ; Mon, 22 Nov 2010 08:01:49 +0000 (UTC) Received: (qmail 86767 invoked from network); 22 Nov 2010 08:01:47 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Nov 2010 08:01:47 -0000 Date: Mon, 22 Nov 2010 09:01:47 +0100 (CET) Message-Id: <20101122.090147.74675296.sthaug@nethelp.no> To: siquijorphilips@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20101119.095212.74667071.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: How to generate IPv6 RA without any prefixes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 08:01:51 -0000 > > I would like to get rtadvd to send RAs completely *without* a prefix > > info option. My Juniper routers at work can do this just fine... > > Oh I see. I haven't tried this case with FreeBSD configuring RA with > default route info only. So, how your Juniper router coordinate your > DHCPv6 server to inform the hosts or nodes where to get prefix info > since then your router wasn't configured with pinfoflags options? The router sends RAs with the "managed" flag, in the RA header (not connected to any specific prefix). This tells the clients that they should attempt DHCPv6 configuration. > Or > the hosts are just configured with DHCPv6 client informing directly > the DHCPv6 server for IPv6 address info while its default route is > obtainable via RA through SLAAC? The default route and the "managed" flag come from RA. The rest from the DHCPv6 server. Some of us would *like* DHCPv6 to be able to work without RA - but that is a different (religious) discussion. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 11:04:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04331106566C for ; Mon, 22 Nov 2010 11:04:58 +0000 (UTC) (envelope-from siquijorphilips@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1D8C8FC14 for ; Mon, 22 Nov 2010 11:04:57 +0000 (UTC) Received: by qwi4 with SMTP id 4so690585qwi.13 for ; Mon, 22 Nov 2010 03:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jrd8Il948Ca4/QjKEG/urHu7rQ0nGYc4DNrHi9M/WVM=; b=xOnuWkRORMuX1nc/keIGwxa9BrHK+zOjVGMnMtZ2OoGIBuCpO/W1xRAA0uQFENqXc/ ROgK2wbeI51vG2YUD2suULiu4A+aiW+lTtBEu6gwdQr9tPFOdSyfXcDJdbm0LZ0wwSkr YswFlDqRDPoTWreRR0qYrrMswACfUafsM1afE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fLGJCCsgS1mqYG1els2o0l5DjzrkrOPxCXT3w/yN4gwL+RLyz4j3kYUM20arpTxcIr qIsTZmCm7xcwHTqK8d39EJEp/ceOdUYZJ6XYEqgHT8fMBw8MQuVIBkiJuTM7rsIpQRKH XH6cAG+hoF9wMSrBkjlQ25VD3MgIzoH6aHmpQ= MIME-Version: 1.0 Received: by 10.229.87.13 with SMTP id u13mr4880897qcl.202.1290423897029; Mon, 22 Nov 2010 03:04:57 -0800 (PST) Received: by 10.229.32.140 with HTTP; Mon, 22 Nov 2010 03:04:56 -0800 (PST) In-Reply-To: <20101122.090147.74675296.sthaug@nethelp.no> References: <20101119.095212.74667071.sthaug@nethelp.no> <20101122.090147.74675296.sthaug@nethelp.no> Date: Mon, 22 Nov 2010 19:04:56 +0800 Message-ID: From: Siquijor Philips To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: How to generate IPv6 RA without any prefixes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 11:04:58 -0000 On Mon, Nov 22, 2010 at 4:01 PM, wrote: >> > I would like to get rtadvd to send RAs completely *without* a prefix >> > info option. My Juniper routers at work can do this just fine... >> >> Oh I see. I haven't tried this case with FreeBSD configuring RA with >> default route info only. So, how your Juniper router coordinate your >> DHCPv6 server to inform the hosts or nodes where to get prefix info >> since then your router wasn't configured with pinfoflags options? > > The router sends RAs with the "managed" flag, in the RA header (not > connected to any specific prefix). This tells the clients that they > should attempt DHCPv6 configuration. > >> Or >> the hosts are just configured with DHCPv6 client informing directly >> the DHCPv6 server for IPv6 address info while its default route is >> obtainable via RA through SLAAC? > > The default route and the "managed" flag come from RA. The rest from > the DHCPv6 server. > > Some of us would *like* DHCPv6 to be able to work without RA - but that > is a different (religious) discussion. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > Thanks for the explanation Steinar, this is clear to me now. So, as what other folks have suggested, I think you can proceed with issuing a PR to this. From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 11:07:10 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D211065673 for ; Mon, 22 Nov 2010 11:07:10 +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 161C68FC1B for ; Mon, 22 Nov 2010 11:07:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAMB79HM051775 for ; Mon, 22 Nov 2010 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAMB79j1051770 for freebsd-net@FreeBSD.org; Mon, 22 Nov 2010 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Nov 2010 11:07:09 GMT Message-Id: <201011221107.oAMB79j1051770@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, 22 Nov 2010 11:07:10 -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/152411 net [re] network card works only on 1000M o kern/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] encapsulate vlan in ng_ether before output to i o kern/151690 net network connectivity won't work until dhclient is run o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148780 net [panic] mtx_lock() of spin mutex (null) @ /usr/src/sys o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network 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 f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 370 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 11:35:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2352C106566B for ; Mon, 22 Nov 2010 11:35:07 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 5384E8FC0C for ; Mon, 22 Nov 2010 11:35:05 +0000 (UTC) Received: (qmail 22337 invoked from network); 22 Nov 2010 11:35:04 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Nov 2010 11:35:04 -0000 Date: Mon, 22 Nov 2010 12:35:04 +0100 (CET) Message-Id: <20101122.123504.71173505.sthaug@nethelp.no> To: siquijorphilips@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20101122.090147.74675296.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: How to generate IPv6 RA without any prefixes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 11:35:07 -0000 > >> Oh I see. I haven't tried this case with FreeBSD configuring RA with > >> default route info only. So, how your Juniper router coordinate your > >> DHCPv6 server to inform the hosts or nodes where to get prefix info > >> since then your router wasn't configured with pinfoflags options? > > > > The router sends RAs with the "managed" flag, in the RA header (not > > connected to any specific prefix). This tells the clients that they > > should attempt DHCPv6 configuration. > > > >> Or > >> the hosts are just configured with DHCPv6 client informing directly > >> the DHCPv6 server for IPv6 address info while its default route is > >> obtainable via RA through SLAAC? > > > > The default route and the "managed" flag come from RA. The rest from > > the DHCPv6 server. > > > > Some of us would *like* DHCPv6 to be able to work without RA - but that > > is a different (religious) discussion. > > Thanks for the explanation Steinar, this is clear to me now. So, as > what other folks have suggested, I think you can proceed with issuing > a PR to this. http://www.freebsd.org/cgi/query-pr.cgi?pr=152458 Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 23:15:36 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 829941065673 for ; Mon, 22 Nov 2010 23:15:36 +0000 (UTC) (envelope-from kalin@el.net) Received: from mail.el.net (mail.el.net [98.113.181.228]) by mx1.freebsd.org (Postfix) with ESMTP id 177568FC12 for ; Mon, 22 Nov 2010 23:15:35 +0000 (UTC) Received: (qmail 68450 invoked by uid 1008); 23 Nov 2010 00:01:22 -0000 Received: from unknown (HELO kalins-macbook-pro.local) (kalin@el.net@98.113.181.226) by mail.el.net with ESMTPA; 23 Nov 2010 00:01:22 -0000 Message-ID: <4CEAF306.2090705@el.net> Date: Mon, 22 Nov 2010 17:47:34 -0500 From: kalin m User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: card sleeping 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, 22 Nov 2010 23:15:36 -0000 hi all.. recently i had to change the static ip on a machine here at work. nothing wrong with that. what's happening with this new ip (different network) is that for short periods of time sometimes the machine is unpingable. until i try to login ssh. as soon as i do that the ping and the rest of network activity resumes - http. that didn't use to happen on the previous network. the only change was the network information. also a bunch of other machines changed at the same time and none of the others present the same situation. the only entry in the log is: init: can't exec getty '/usr/local/bin/xdm' for port /dev/ttyv8: No such file or directory (if somebody would explain what this is, that would help too. since xdm is not really in use and i can't find anything that would be calling xdm.) not sure if this has any importance but the card itself is BCM5750A1 NetXtreme Gigabit Ethernet PCI Express according to pciconf. the machine is 7.2 release. where do i look? thanks... From owner-freebsd-net@FreeBSD.ORG Mon Nov 22 23:57:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8223E106566B for ; Mon, 22 Nov 2010 23:57:24 +0000 (UTC) (envelope-from Rozhuk_I@mail.ru) Received: from smtp11.mail.ru (smtp11.mail.ru [94.100.176.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF938FC08 for ; Mon, 22 Nov 2010 23:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Reply-To; bh=chvqGeXPtKz3c8WG/++VGxeqFpNra3KWFDJi/hyx3+4=; b=cdmVy/NMOrI1gBVEc+g0QVVzfv2OcTHNs1BZbHBC4Emd6kJKsQvkrmpJE2uxQcdzrpl1jvIW2dViYk7QFuqHScg72kQwxXWkenVh84rW1Dnm1zNwJ5kOi5tb/2F87Ybo; Received: from [92.124.29.114] (port=4327 helo=rimwks1x64) by smtp11.mail.ru with asmtp id 1PKgGA-0005O1-00 for freebsd-net@freebsd.org; Tue, 23 Nov 2010 02:57:22 +0300 From: "Rozhuk Ivan" To: Date: Tue, 23 Nov 2010 07:57:20 +0800 Message-ID: <00ff01cb8aa1$01071440$03153cc0$@ru> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuKoQAPSSMvB6o7TRi2Ig5OwDGFYw== Content-Language: ru X-Mras: Ok Subject: struct sockaddr_in6 ia_net - unused X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk_I@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 23:57:24 -0000 Hi! /usr/src/sys/netinet6/in6_var.h: struct sockaddr_in6 ia_net; = /* network number of interface */ Looks like unused in inet6: defined but never used in code. firewall# grep -r "ia_net" /usr/src/sys grep: warning: /usr/src/sys/modules/netgraph/viface/@: recursive = directory loop /usr/src/sys/netinet/in.c: if ((i & ia->ia_netmask) = =3D=3D ia->ia_net) { /usr/src/sys/netinet/in.c: ia->ia_netmask =3D = IN_CLASSA_NET; /usr/src/sys/netinet/in.c: ia->ia_netmask =3D = IN_CLASSB_NET; /usr/src/sys/netinet/in.c: ia->ia_netmask =3D = IN_CLASSC_NET; /usr/src/sys/netinet/in.c: ia->ia_subnetmask =3D = ia->ia_netmask; /usr/src/sys/netinet/in.c: ia->ia_netmask &=3D = ia->ia_subnetmask; /usr/src/sys/netinet/in.c: ia->ia_net =3D i & ia->ia_netmask; /usr/src/sys/netinet/in.c: ia->ia_netbroadcast.s_addr =3D /usr/src/sys/netinet/in.c: htonl(ia->ia_net | ~ ia->ia_netmask); /usr/src/sys/netinet/in.c: in.s_addr =3D=3D ia->ia_netbroadcast.s_addr || /usr/src/sys/netinet/in.c: t =3D=3D ia->ia_subnet || t = =3D=3D ia->ia_net) && /usr/src/sys/netinet/in_debug.c: IA_DB_RPINTF("0x%08lx", ia_net); /usr/src/sys/netinet/in_debug.c: IA_DB_RPINTF("0x%08lx", = ia_netmask); /usr/src/sys/netinet/in_debug.c: IA_DB_RPINTF("0x%08x", ia_netbroadcast.s_addr); /usr/src/sys/netinet/in_var.h: u_long ia_net; /* = network number of interface */ /usr/src/sys/netinet/in_var.h: u_long ia_netmask; /* mask = of net part */ /usr/src/sys/netinet/in_var.h: struct in_addr ia_netbroadcast; /* to recognize net broadcasts */ /usr/src/sys/netinet/ip_input.c: if (ia->ia_netbroadcast.s_addr =3D=3D ip->ip_dst.s_addr) { /usr/src/sys/netinet6/in6_var.h: struct sockaddr_in6 ia_net; = /* network number of interface */ /usr/src/sys/netipx/ipx_if.h: struct sockaddr_ipx ia_netmask; = /* space for my network mask */ =A0 -- Rozhuk Ivan =A0=20 From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 00:50:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826AF106566B for ; Tue, 23 Nov 2010 00:50:31 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF618FC1B for ; Tue, 23 Nov 2010 00:50:30 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id oAN0WnkD015030; Mon, 22 Nov 2010 17:32:49 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id oAN0WntR015027; Mon, 22 Nov 2010 17:32:49 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 22 Nov 2010 17:32:49 -0700 (MST) From: Warren Block To: kalin m In-Reply-To: <4CEAF306.2090705@el.net> Message-ID: References: <4CEAF306.2090705@el.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Mon, 22 Nov 2010 17:32:49 -0700 (MST) Cc: freebsd-net@freebsd.org Subject: Re: card sleeping 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, 23 Nov 2010 00:50:31 -0000 On Mon, 22 Nov 2010, kalin m wrote: > the only entry in the log is: > init: can't exec getty '/usr/local/bin/xdm' for port /dev/ttyv8: No such file > or directory > > (if somebody would explain what this is, that would help too. since xdm is > not really in use and i can't find anything that would be calling xdm.) Change the ttyv8 line in /etc/ttys that runs xdm to say "off". From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 01:16:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD2191065672 for ; Tue, 23 Nov 2010 01:16:08 +0000 (UTC) (envelope-from kalin@el.net) Received: from mail.el.net (mail.el.net [98.113.181.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7CCDE8FC15 for ; Tue, 23 Nov 2010 01:16:08 +0000 (UTC) Received: (qmail 80583 invoked by uid 1008); 23 Nov 2010 02:29:56 -0000 Received: from unknown (HELO kalins-macbook-pro.local) (kalin@el.net@98.113.181.226) by mail.el.net with ESMTPA; 23 Nov 2010 02:29:56 -0000 Message-ID: <4CEB15D7.6020303@el.net> Date: Mon, 22 Nov 2010 20:16:07 -0500 From: kalin m User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Julian Elischer , freebsd-net@freebsd.org References: <4CEAF306.2090705@el.net> <4CEAFBF3.1040408@freebsd.org> <4CEB0226.1020407@el.net> <4CEB0DFA.4030500@freebsd.org> In-Reply-To: <4CEB0DFA.4030500@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: card sleeping 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, 23 Nov 2010 01:16:08 -0000 On 11/22/10 7:42 PM, Julian Elischer wrote: > On 11/22/10 3:52 PM, kalin m wrote: >> >> >> thanks... got the ttyv8 off... >> >> any idea about the temporary network loss? > > not without more info... > > it might be you machine or the switch it's attached to.. > you may also have a clash with another machine somewhere with the same > IP address. i forgot to mention one important thing... i can always ping the machine from within the same network. so it seems that it's not really the machine itself. the theory about the switch could be - except all the other machines that are on the same network do not have that problem. they are always pingable from the outside, even when the machine in question is not. and of course there is no other machine with the same ip on that network. i did check... thanks.... >> >> >> >> On 11/22/10 6:25 PM, Julian Elischer wrote: >>> On 11/22/10 2:47 PM, kalin m wrote: >>>> >>>> >>>> hi all.. >>>> >>>> recently i had to change the static ip on a machine here at work. >>>> nothing wrong with that. what's happening with this new ip >>>> (different network) is that for short periods of time sometimes the >>>> machine is unpingable. until i try to login ssh. as soon as i do >>>> that the ping and the rest of network activity resumes - http. >>>> >>>> that didn't use to happen on the previous network. the only change >>>> was the network information. also a bunch of other machines changed >>>> at the same time and none of the others present the same situation. >>>> >>>> the only entry in the log is: >>>> init: can't exec getty '/usr/local/bin/xdm' for port /dev/ttyv8: No >>>> such file or directory >>> >>> delete or turn off the line in /etc/ttys for ttyv8 >>> >>>> >>>> (if somebody would explain what this is, that would help too. since >>>> xdm is not really in use and i can't find anything that would be >>>> calling xdm.) >>>> >>>> not sure if this has any importance but the card itself is >>>> BCM5750A1 NetXtreme Gigabit Ethernet PCI Express according to pciconf. >>>> >>>> the machine is 7.2 release. >>>> >>>> where do i look? >>>> >>>> >>>> >>>> thanks... >>>> _______________________________________________ >>>> 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 Tue Nov 23 02:14:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C24E1065674 for ; Tue, 23 Nov 2010 02:14:31 +0000 (UTC) (envelope-from kalin@el.net) Received: from mail.el.net (mail.el.net [98.113.181.228]) by mx1.freebsd.org (Postfix) with ESMTP id B04418FC1D for ; Tue, 23 Nov 2010 02:14:30 +0000 (UTC) Received: (qmail 85128 invoked by uid 1008); 23 Nov 2010 03:28:19 -0000 Received: from unknown (HELO kalins-macbook-pro.local) (kalin@el.net@98.113.181.226) by mail.el.net with ESMTPA; 23 Nov 2010 03:28:19 -0000 Message-ID: <4CEB2385.1010300@el.net> Date: Mon, 22 Nov 2010 21:14:29 -0500 From: kalin m User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Julian Elischer , freebsd-net@freebsd.org References: <4CEAF306.2090705@el.net> <4CEAFBF3.1040408@freebsd.org> <4CEB0226.1020407@el.net> <4CEB0DFA.4030500@freebsd.org> <4CEB15D7.6020303@el.net> <4CEB1C58.7070306@freebsd.org> In-Reply-To: <4CEB1C58.7070306@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: card sleeping 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, 23 Nov 2010 02:14:31 -0000 On 11/22/10 8:43 PM, Julian Elischer wrote: > On 11/22/10 5:16 PM, kalin m wrote: >> >> >> On 11/22/10 7:42 PM, Julian Elischer wrote: >>> On 11/22/10 3:52 PM, kalin m wrote: >>>> >>>> >>>> thanks... got the ttyv8 off... >>>> >>>> any idea about the temporary network loss? >>> >>> not without more info... >>> >>> it might be you machine or the switch it's attached to.. >>> you may also have a clash with another machine somewhere with the >>> same IP address. >> i forgot to mention one important thing... i can always ping the >> machine from within the same network. so it seems that it's not >> really the machine itself. the theory about the switch could be - >> except all the other machines that are on the same network do not >> have that problem. they are always pingable from the outside, even >> when the machine in question is not. >> >> and of course there is no other machine with the same ip on that >> network. i did check... >> > so have you left tcpbump running on the machine looking at the > interface in question? > > tcpdump -i XX0 -p icmp > this should tell you if it's the incoming or outgoing packets that are > getting lost. i did similar stuff. but the thing is it's not only icmp. it's tcp too. basically the machine is unreachable form the outside in any given time. until i ssh into it from inside. http is not responding either. and if i leave the dcpdump dumping - detached from the terminal - it might run out of space.... thanks... > > >> thanks.... >> >> >>>> >>>> >>>> >>>> On 11/22/10 6:25 PM, Julian Elischer wrote: >>>>> On 11/22/10 2:47 PM, kalin m wrote: >>>>>> >>>>>> >>>>>> hi all.. >>>>>> >>>>>> recently i had to change the static ip on a machine here at work. >>>>>> nothing wrong with that. what's happening with this new ip >>>>>> (different network) is that for short periods of time sometimes >>>>>> the machine is unpingable. until i try to login ssh. as soon as i >>>>>> do that the ping and the rest of network activity resumes - http. >>>>>> >>>>>> that didn't use to happen on the previous network. the only >>>>>> change was the network information. also a bunch of other >>>>>> machines changed at the same time and none of the others present >>>>>> the same situation. >>>>>> >>>>>> the only entry in the log is: >>>>>> init: can't exec getty '/usr/local/bin/xdm' for port /dev/ttyv8: >>>>>> No such file or directory >>>>> >>>>> delete or turn off the line in /etc/ttys for ttyv8 >>>>> >>>>>> >>>>>> (if somebody would explain what this is, that would help too. >>>>>> since xdm is not really in use and i can't find anything that >>>>>> would be calling xdm.) >>>>>> >>>>>> not sure if this has any importance but the card itself is >>>>>> BCM5750A1 NetXtreme Gigabit Ethernet PCI Express according to >>>>>> pciconf. >>>>>> >>>>>> the machine is 7.2 release. >>>>>> >>>>>> where do i look? >>>>>> >>>>>> >>>>>> >>>>>> thanks... >>>>>> _______________________________________________ >>>>>> 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 Tue Nov 23 05:50:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81974106566C for ; Tue, 23 Nov 2010 05:50:16 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 624668FC12 for ; Tue, 23 Nov 2010 05:50:16 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAN5oBEP004311; Mon, 22 Nov 2010 21:50:14 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 37AC22D6011; Mon, 22 Nov 2010 21:50:11 -0800 (PST) Message-ID: <4CEB5625.7060601@freebsd.org> Date: Mon, 22 Nov 2010 21:50:29 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: kalin m References: <4CEAF306.2090705@el.net> <4CEAFBF3.1040408@freebsd.org> <4CEB0226.1020407@el.net> <4CEB0DFA.4030500@freebsd.org> <4CEB15D7.6020303@el.net> <4CEB1C58.7070306@freebsd.org> <4CEB2385.1010300@el.net> In-Reply-To: <4CEB2385.1010300@el.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: card sleeping 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, 23 Nov 2010 05:50:16 -0000 On 11/22/10 6:14 PM, kalin m wrote: > > > On 11/22/10 8:43 PM, Julian Elischer wrote: >> On 11/22/10 5:16 PM, kalin m wrote: >>> >>> >>> On 11/22/10 7:42 PM, Julian Elischer wrote: >>>> On 11/22/10 3:52 PM, kalin m wrote: >>>>> >>>>> >>>>> thanks... got the ttyv8 off... >>>>> >>>>> any idea about the temporary network loss? >>>> >>>> not without more info... >>>> >>>> it might be you machine or the switch it's attached to.. >>>> you may also have a clash with another machine somewhere with the >>>> same IP address. >>> i forgot to mention one important thing... i can always ping the >>> machine from within the same network. so it seems that it's not >>> really the machine itself. the theory about the switch could be - >>> except all the other machines that are on the same network do not >>> have that problem. they are always pingable from the outside, even >>> when the machine in question is not. >>> >>> and of course there is no other machine with the same ip on that >>> network. i did check... >>> >> so have you left tcpbump running on the machine looking at the >> interface in question? >> >> tcpdump -i XX0 -p icmp >> this should tell you if it's the incoming or outgoing packets that >> are getting lost. > > i did similar stuff. but the thing is it's not only icmp. it's tcp > too. basically the machine is unreachable form the outside in any > given time. until i ssh into it from inside. http is not responding > either. and if i leave the dcpdump dumping - detached from the > terminal - it might run out of space.... > > but you didn't answer the question... when icmp fails (ping) which packets are seen? > > thanks... > >> >> >>> thanks.... >>> >>> >>>>> >>>>> >>>>> >>>>> On 11/22/10 6:25 PM, Julian Elischer wrote: >>>>>> On 11/22/10 2:47 PM, kalin m wrote: >>>>>>> >>>>>>> >>>>>>> hi all.. >>>>>>> >>>>>>> recently i had to change the static ip on a machine here at >>>>>>> work. nothing wrong with that. what's happening with this new >>>>>>> ip (different network) is that for short periods of time >>>>>>> sometimes the machine is unpingable. until i try to login ssh. >>>>>>> as soon as i do that the ping and the rest of network activity >>>>>>> resumes - http. >>>>>>> >>>>>>> that didn't use to happen on the previous network. the only >>>>>>> change was the network information. also a bunch of other >>>>>>> machines changed at the same time and none of the others >>>>>>> present the same situation. >>>>>>> >>>>>>> the only entry in the log is: >>>>>>> init: can't exec getty '/usr/local/bin/xdm' for port >>>>>>> /dev/ttyv8: No such file or directory >>>>>> >>>>>> delete or turn off the line in /etc/ttys for ttyv8 >>>>>> >>>>>>> >>>>>>> (if somebody would explain what this is, that would help too. >>>>>>> since xdm is not really in use and i can't find anything that >>>>>>> would be calling xdm.) >>>>>>> >>>>>>> not sure if this has any importance but the card itself is >>>>>>> BCM5750A1 NetXtreme Gigabit Ethernet PCI Express according to >>>>>>> pciconf. >>>>>>> >>>>>>> the machine is 7.2 release. >>>>>>> >>>>>>> where do i look? >>>>>>> >>>>>>> >>>>>>> >>>>>>> thanks... >>>>>>> _______________________________________________ >>>>>>> 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 Tue Nov 23 06:06:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A36E6106566C for ; Tue, 23 Nov 2010 06:06:39 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 097FD8FC14 for ; Tue, 23 Nov 2010 06:06:38 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id oAN66aCI089405 for ; Tue, 23 Nov 2010 08:06:36 +0200 (EET) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id oAN66awC089404 for freebsd-net@freebsd.org; Tue, 23 Nov 2010 08:06:36 +0200 (EET) Date: Tue, 23 Nov 2010 08:06:36 +0200 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20101123060636.GD34385@relay.ibs.dn.ua> References: <4CEAF306.2090705@el.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4CEAF306.2090705@el.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: Re: card sleeping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 06:06:39 -0000 kalin m (kalin@el.net) [10.11.23 01:16] wrote: > > > hi all.. > > recently i had to change the static ip on a machine here at work. > nothing wrong with that. what's happening with this new ip (different > network) is that for short periods of time sometimes the machine is > unpingable. until i try to login ssh. as soon as i do that the ping and > the rest of network activity resumes - http. > looks like cached MAC at the router/commutator -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 06:20:49 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0094A106566C for ; Tue, 23 Nov 2010 06:20:49 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 06D718FC28 for ; Tue, 23 Nov 2010 06:20:47 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oAN5puNE094846; Tue, 23 Nov 2010 11:51:56 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CEB567C.9000906@rdtc.ru> Date: Tue, 23 Nov 2010 11:51:56 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jack Vogel References: <20101117070422.GA45678@cabstand.com> <4CE3D097.7030204@grosbein.pp.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Vlad Galu Subject: Re: request for MFC of em/igb drivers 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, 23 Nov 2010 06:20:49 -0000 On 17.11.2010 23:39, Jack Vogel wrote: > Yes, everyone, I plan on updating all the drivers, there has been no > activity > because I've tracking down a couple bugs that are tough, involving days > of testing to reproduce. I know we're getting close and I appreciate any > reports like this before. > > Stay tuned.... > > Jack Thanks for response. Do you play to MFC fixes before 8.2-RELEASE? We are in PRERELEASE state already :-) From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 06:56:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14BD106564A for ; Tue, 23 Nov 2010 06:56:20 +0000 (UTC) (envelope-from kalin@el.net) Received: from mail.el.net (mail.el.net [98.113.181.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFEC8FC0C for ; Tue, 23 Nov 2010 06:56:20 +0000 (UTC) Received: (qmail 6861 invoked by uid 1008); 23 Nov 2010 08:10:09 -0000 Received: from unknown (HELO kalins-macbook-pro.local) (kalin@el.net@98.14.118.19) by mail.el.net with ESMTPA; 23 Nov 2010 08:10:09 -0000 Message-ID: <4CEB6593.6010505@el.net> Date: Tue, 23 Nov 2010 01:56:19 -0500 From: kalin m User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Julian Elischer References: <4CEAF306.2090705@el.net> <4CEAFBF3.1040408@freebsd.org> <4CEB0226.1020407@el.net> <4CEB0DFA.4030500@freebsd.org> <4CEB15D7.6020303@el.net> <4CEB1C58.7070306@freebsd.org> <4CEB2385.1010300@el.net> <4CEB5625.7060601@freebsd.org> In-Reply-To: <4CEB5625.7060601@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: card sleeping 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, 23 Nov 2010 06:56:21 -0000 On 11/23/10 12:50 AM, Julian Elischer wrote: > On 11/22/10 6:14 PM, kalin m wrote: >> >> >> On 11/22/10 8:43 PM, Julian Elischer wrote: >>> On 11/22/10 5:16 PM, kalin m wrote: >>>> >>>> >>>> On 11/22/10 7:42 PM, Julian Elischer wrote: >>>>> On 11/22/10 3:52 PM, kalin m wrote: >>>>>> >>>>>> >>>>>> thanks... got the ttyv8 off... >>>>>> >>>>>> any idea about the temporary network loss? >>>>> >>>>> not without more info... >>>>> >>>>> it might be you machine or the switch it's attached to.. >>>>> you may also have a clash with another machine somewhere with the >>>>> same IP address. >>>> i forgot to mention one important thing... i can always ping the >>>> machine from within the same network. so it seems that it's not >>>> really the machine itself. the theory about the switch could be - >>>> except all the other machines that are on the same network do not >>>> have that problem. they are always pingable from the outside, even >>>> when the machine in question is not. >>>> >>>> and of course there is no other machine with the same ip on that >>>> network. i did check... >>>> >>> so have you left tcpbump running on the machine looking at the >>> interface in question? >>> >>> tcpdump -i XX0 -p icmp >>> this should tell you if it's the incoming or outgoing packets that >>> are getting lost. >> >> i did similar stuff. but the thing is it's not only icmp. it's tcp >> too. basically the machine is unreachable form the outside in any >> given time. until i ssh into it from inside. http is not responding >> either. and if i leave the dcpdump dumping - detached from the >> terminal - it might run out of space.... >> >> > but you didn't answer the question... > when icmp fails (ping) which packets are seen? i don't know. i'm at home right now. it was off again. i had to go ssh into it through another machine on the same network. but the second i do that the ping from outside comes alive. tomorrow at work will wait for this to happened and will run tcpdump off the terminal of the machine itself. will report... right now it just looks like this: ............................................................................................... 01:48:01.719224 IP machine.one.com > machine.two.com: ICMP echo request, id 3386, seq 420, length 64 01:48:01.719250 IP machine.two.com > machine.one.com: ICMP echo reply, id 3386, seq 420, length 64 01:48:02.719065 IP machine.one.com > machine.two.com: ICMP echo request, id 3386, seq 421, length 64 01:48:02.719090 IP machine.two.com > machine.one.com: ICMP echo reply, id 3386, seq 421, length 64 01:48:03.724056 IP machine.one.com > machine.two.com: ICMP echo request, id 3386, seq 422, length 64 01:48:03.724082 IP machine.two.com > machine.one.com: ICMP echo reply, id 3386, seq 422, length 64 .......................................................................................... where machine.two.com is the one that disappears.... thanks... > >> >> thanks... >> >>> >>> >>>> thanks.... >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/22/10 6:25 PM, Julian Elischer wrote: >>>>>>> On 11/22/10 2:47 PM, kalin m wrote: >>>>>>>> >>>>>>>> >>>>>>>> hi all.. >>>>>>>> >>>>>>>> recently i had to change the static ip on a machine here at >>>>>>>> work. nothing wrong with that. what's happening with this new >>>>>>>> ip (different network) is that for short periods of time >>>>>>>> sometimes the machine is unpingable. until i try to login ssh. >>>>>>>> as soon as i do that the ping and the rest of network activity >>>>>>>> resumes - http. >>>>>>>> >>>>>>>> that didn't use to happen on the previous network. the only >>>>>>>> change was the network information. also a bunch of other >>>>>>>> machines changed at the same time and none of the others >>>>>>>> present the same situation. >>>>>>>> >>>>>>>> the only entry in the log is: >>>>>>>> init: can't exec getty '/usr/local/bin/xdm' for port >>>>>>>> /dev/ttyv8: No such file or directory >>>>>>> >>>>>>> delete or turn off the line in /etc/ttys for ttyv8 >>>>>>> >>>>>>>> >>>>>>>> (if somebody would explain what this is, that would help too. >>>>>>>> since xdm is not really in use and i can't find anything that >>>>>>>> would be calling xdm.) >>>>>>>> >>>>>>>> not sure if this has any importance but the card itself is >>>>>>>> BCM5750A1 NetXtreme Gigabit Ethernet PCI Express according to >>>>>>>> pciconf. >>>>>>>> >>>>>>>> the machine is 7.2 release. >>>>>>>> >>>>>>>> where do i look? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> thanks... >>>>>>>> _______________________________________________ >>>>>>>> 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 Tue Nov 23 06:57:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E3211065672 for ; Tue, 23 Nov 2010 06:57:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 261318FC1B for ; Tue, 23 Nov 2010 06:57:01 +0000 (UTC) Received: by wyb35 with SMTP id 35so92012wyb.13 for ; Mon, 22 Nov 2010 22:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=u1JSJKZpEZU4mJ4JsHJxvY/xibRh2qKCE9M5sR9Ixs8=; b=jf3AFS3PlrCTWyF6gp/JjLlTxNvNlZZz7X7a017dxuvTzoegqghPAhwtwl3rjisOge q11lEeDxJdOeNVCzxrUeVAt86lzhW/5h25wrmbvqw57G5bKZeLNx2M0D/DTPgfK0UvGn VNG2XaeZqLVbqevcUwgfR/4U6lmKsapE7Esas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=VU+YH89FvithZS6SpqYslnhUiHe4ZB17iBOD8jIkkcdFfa3ett+bO3k6XldOQfEl8a rUJ/icLkR7rbsaXRrJMeVjDH2BZr+f9pDSVW/6hleEi4NduSBijz46FPdNnSTtHuj2CM z/MpKqyEtqJxGq1WE9c5qwXN6rp6V4UTHPbZQ= MIME-Version: 1.0 Received: by 10.216.157.6 with SMTP id n6mr6147181wek.35.1290493856047; Mon, 22 Nov 2010 22:30:56 -0800 (PST) Received: by 10.216.65.210 with HTTP; Mon, 22 Nov 2010 22:30:56 -0800 (PST) Date: Tue, 23 Nov 2010 14:30:56 +0800 Message-ID: From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo Subject: ipfw and bridge: unaligned payload pointers panicing perfectly performing MIPS boxes 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, 23 Nov 2010 06:57:02 -0000 Hi everyone (and Luigi especially!) I've found that enabling ipfw for bridge interfaces panics my MIPS boards. A bit of digging shows that the payload mbuf isn't aligned as passed into ipfw_chk(), and this is causing aligned access exceptions. It likely isn't a problem on i386/ia64 because they are happy with unaligned access. :-) I'm going to try and patch it locally by copying the mbuf payload into a new, temporary mbuf that's aligned; but I have no idea what the "right" solution for the stack is. Ideas? :) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 07:23:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB101065694 for ; Tue, 23 Nov 2010 07:23:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outr.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id F12A58FC23 for ; Tue, 23 Nov 2010 07:23:17 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oAN7NFQw007832; Mon, 22 Nov 2010 23:23:15 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 0CAF82D6014; Mon, 22 Nov 2010 23:23:14 -0800 (PST) Message-ID: <4CEB6BF5.6080107@freebsd.org> Date: Mon, 22 Nov 2010 23:23:33 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: kalin m References: <4CEAF306.2090705@el.net> <4CEAFBF3.1040408@freebsd.org> <4CEB0226.1020407@el.net> <4CEB0DFA.4030500@freebsd.org> <4CEB15D7.6020303@el.net> <4CEB1C58.7070306@freebsd.org> <4CEB2385.1010300@el.net> <4CEB5625.7060601@freebsd.org> <4CEB6593.6010505@el.net> In-Reply-To: <4CEB6593.6010505@el.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: card sleeping 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, 23 Nov 2010 07:23:18 -0000 On 11/22/10 10:56 PM, kalin m wrote: > > > On 11/23/10 12:50 AM, Julian Elischer wrote: >> On 11/22/10 6:14 PM, kalin m wrote: >>> >>> >>> On 11/22/10 8:43 PM, Julian Elischer wrote: >>>> On 11/22/10 5:16 PM, kalin m wrote: >>>>> >>>>> >>>>> On 11/22/10 7:42 PM, Julian Elischer wrote: >>>>>> On 11/22/10 3:52 PM, kalin m wrote: >>>>>>> >>>>>>> >>>>>>> thanks... got the ttyv8 off... >>>>>>> >>>>>>> any idea about the temporary network loss? >>>>>> >>>>>> not without more info... >>>>>> >>>>>> it might be you machine or the switch it's attached to.. >>>>>> you may also have a clash with another machine somewhere with >>>>>> the same IP address. >>>>> i forgot to mention one important thing... i can always ping >>>>> the machine from within the same network. so it seems that it's >>>>> not really the machine itself. the theory about the switch could >>>>> be - except all the other machines that are on the same network >>>>> do not have that problem. they are always pingable from the >>>>> outside, even when the machine in question is not. >>>>> >>>>> and of course there is no other machine with the same ip on that >>>>> network. i did check... >>>>> >>>> so have you left tcpbump running on the machine looking at the >>>> interface in question? >>>> >>>> tcpdump -i XX0 -p icmp >>>> this should tell you if it's the incoming or outgoing packets >>>> that are getting lost. >>> >>> i did similar stuff. but the thing is it's not only icmp. it's tcp >>> too. basically the machine is unreachable form the outside in any >>> given time. until i ssh into it from inside. http is not >>> responding either. and if i leave the dcpdump dumping - detached >>> from the terminal - it might run out of space.... >>> >>> >> but you didn't answer the question... >> when icmp fails (ping) which packets are seen? > i don't know. i'm at home right now. it was off again. i had to go > ssh into it through another machine on the same network. but the > second i do that the ping from outside comes alive. > tomorrow at work will wait for this to happened and will run tcpdump > off the terminal of the machine itself. will report... > > right now it just looks like this: > > ............................................................................................... > > 01:48:01.719224 IP machine.one.com > machine.two.com: ICMP echo > request, id 3386, seq 420, length 64 > 01:48:01.719250 IP machine.two.com > machine.one.com: ICMP echo > reply, id 3386, seq 420, length 64 > 01:48:02.719065 IP machine.one.com > machine.two.com: ICMP echo > request, id 3386, seq 421, length 64 > 01:48:02.719090 IP machine.two.com > machine.one.com: ICMP echo > reply, id 3386, seq 421, length 64 > 01:48:03.724056 IP machine.one.com > machine.two.com: ICMP echo > request, id 3386, seq 422, length 64 > 01:48:03.724082 IP machine.two.com > machine.one.com: ICMP echo > reply, id 3386, seq 422, length 64 just write it to a file so you cna see what was going on when it was "asleep" I suspect a MAC setting on the switch or something. does the 'ssh' come in on the same interface as the ping? please check the netmasks everywhere on the router, on the machine and on other local machines. > .......................................................................................... > > > where machine.two.com is the one that disappears.... > > thanks... > > >> >>> >>> thanks... >>> >>>> >>>> >>>>> thanks.... >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/22/10 6:25 PM, Julian Elischer wrote: >>>>>>>> On 11/22/10 2:47 PM, kalin m wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> hi all.. >>>>>>>>> >>>>>>>>> recently i had to change the static ip on a machine here at >>>>>>>>> work. nothing wrong with that. what's happening with this >>>>>>>>> new ip (different network) is that for short periods of time >>>>>>>>> sometimes the machine is unpingable. until i try to login >>>>>>>>> ssh. as soon as i do that the ping and the rest of network >>>>>>>>> activity resumes - http. >>>>>>>>> >>>>>>>>> that didn't use to happen on the previous network. the only >>>>>>>>> change was the network information. also a bunch of other >>>>>>>>> machines changed at the same time and none of the others >>>>>>>>> present the same situation. >>>>>>>>> >>>>>>>>> the only entry in the log is: >>>>>>>>> init: can't exec getty '/usr/local/bin/xdm' for port >>>>>>>>> /dev/ttyv8: No such file or directory >>>>>>>> >>>>>>>> delete or turn off the line in /etc/ttys for ttyv8 >>>>>>>> >>>>>>>>> >>>>>>>>> (if somebody would explain what this is, that would help >>>>>>>>> too. since xdm is not really in use and i can't find >>>>>>>>> anything that would be calling xdm.) >>>>>>>>> >>>>>>>>> not sure if this has any importance but the card itself is >>>>>>>>> BCM5750A1 NetXtreme Gigabit Ethernet PCI Express according >>>>>>>>> to pciconf. >>>>>>>>> >>>>>>>>> the machine is 7.2 release. >>>>>>>>> >>>>>>>>> where do i look? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> thanks... >>>>>>>>> _______________________________________________ >>>>>>>>> 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 Tue Nov 23 07:48:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E47EC1065672 for ; Tue, 23 Nov 2010 07:48:19 +0000 (UTC) (envelope-from kalin@el.net) Received: from mail.el.net (mail.el.net [98.113.181.228]) by mx1.freebsd.org (Postfix) with ESMTP id 905DA8FC12 for ; Tue, 23 Nov 2010 07:48:19 +0000 (UTC) Received: (qmail 10833 invoked by uid 1008); 23 Nov 2010 09:02:09 -0000 Received: from unknown (HELO kalins-macbook-pro.local) (kalin@el.net@98.14.118.19) by mail.el.net with ESMTPA; 23 Nov 2010 09:02:09 -0000 Message-ID: <4CEB71C2.7090707@el.net> Date: Tue, 23 Nov 2010 02:48:18 -0500 From: kalin m User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Julian Elischer References: <4CEAF306.2090705@el.net> <4CEAFBF3.1040408@freebsd.org> <4CEB0226.1020407@el.net> <4CEB0DFA.4030500@freebsd.org> <4CEB15D7.6020303@el.net> <4CEB1C58.7070306@freebsd.org> <4CEB2385.1010300@el.net> <4CEB5625.7060601@freebsd.org> <4CEB6593.6010505@el.net> <4CEB6BF5.6080107@freebsd.org> In-Reply-To: <4CEB6BF5.6080107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: card sleeping 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, 23 Nov 2010 07:48:20 -0000 On 11/23/10 2:23 AM, Julian Elischer wrote: > On 11/22/10 10:56 PM, kalin m wrote: >> >> >> On 11/23/10 12:50 AM, Julian Elischer wrote: >>> On 11/22/10 6:14 PM, kalin m wrote: >>>> >>>> >>>> On 11/22/10 8:43 PM, Julian Elischer wrote: >>>>> On 11/22/10 5:16 PM, kalin m wrote: >>>>>> >>>>>> >>>>>> On 11/22/10 7:42 PM, Julian Elischer wrote: >>>>>>> On 11/22/10 3:52 PM, kalin m wrote: >>>>>>>> >>>>>>>> >>>>>>>> thanks... got the ttyv8 off... >>>>>>>> >>>>>>>> any idea about the temporary network loss? >>>>>>> >>>>>>> not without more info... >>>>>>> >>>>>>> it might be you machine or the switch it's attached to.. >>>>>>> you may also have a clash with another machine somewhere with >>>>>>> the same IP address. >>>>>> i forgot to mention one important thing... i can always ping the >>>>>> machine from within the same network. so it seems that it's not >>>>>> really the machine itself. the theory about the switch could be - >>>>>> except all the other machines that are on the same network do not >>>>>> have that problem. they are always pingable from the outside, >>>>>> even when the machine in question is not. >>>>>> >>>>>> and of course there is no other machine with the same ip on that >>>>>> network. i did check... >>>>>> >>>>> so have you left tcpbump running on the machine looking at the >>>>> interface in question? >>>>> >>>>> tcpdump -i XX0 -p icmp >>>>> this should tell you if it's the incoming or outgoing packets that >>>>> are getting lost. >>>> >>>> i did similar stuff. but the thing is it's not only icmp. it's tcp >>>> too. basically the machine is unreachable form the outside in any >>>> given time. until i ssh into it from inside. http is not responding >>>> either. and if i leave the dcpdump dumping - detached from the >>>> terminal - it might run out of space.... >>>> >>>> >>> but you didn't answer the question... >>> when icmp fails (ping) which packets are seen? >> i don't know. i'm at home right now. it was off again. i had to go >> ssh into it through another machine on the same network. but the >> second i do that the ping from outside comes alive. >> tomorrow at work will wait for this to happened and will run tcpdump >> off the terminal of the machine itself. will report... >> >> right now it just looks like this: >> >> ............................................................................................... >> >> 01:48:01.719224 IP machine.one.com > machine.two.com: ICMP echo >> request, id 3386, seq 420, length 64 >> 01:48:01.719250 IP machine.two.com > machine.one.com: ICMP echo >> reply, id 3386, seq 420, length 64 >> 01:48:02.719065 IP machine.one.com > machine.two.com: ICMP echo >> request, id 3386, seq 421, length 64 >> 01:48:02.719090 IP machine.two.com > machine.one.com: ICMP echo >> reply, id 3386, seq 421, length 64 >> 01:48:03.724056 IP machine.one.com > machine.two.com: ICMP echo >> request, id 3386, seq 422, length 64 >> 01:48:03.724082 IP machine.two.com > machine.one.com: ICMP echo >> reply, id 3386, seq 422, length 64 > > just write it to a file so you cna see what was going on when it was > "asleep" ok. just afraid it will run out of space while waiting for this to happen again.... it's running now... > > I suspect a MAC setting on the switch or something. > > does the 'ssh' come in on the same interface as the ping? yes. > > please check the netmasks everywhere on the router, on the machine > and on other local machines. well... "the router" is a actually out of my reach. it's a fios set up. the netmask for all the machines is 255.255.255.0 so the actual router is somewhere in the building. i guess. we just got 13 ips assigned to the office but it's not like a subnet set up. there is a box in the office before the machines but my guess is it's not really a router... i do not have access to it either. does this make any sense? thanks again for sticking with this... > >> .......................................................................................... >> >> >> where machine.two.com is the one that disappears.... >> >> thanks... >> >> >>> >>>> >>>> thanks... >>>> >>>>> >>>>> >>>>>> thanks.... >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/22/10 6:25 PM, Julian Elischer wrote: >>>>>>>>> On 11/22/10 2:47 PM, kalin m wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> hi all.. >>>>>>>>>> >>>>>>>>>> recently i had to change the static ip on a machine here at >>>>>>>>>> work. nothing wrong with that. what's happening with this new >>>>>>>>>> ip (different network) is that for short periods of time >>>>>>>>>> sometimes the machine is unpingable. until i try to login >>>>>>>>>> ssh. as soon as i do that the ping and the rest of network >>>>>>>>>> activity resumes - http. >>>>>>>>>> >>>>>>>>>> that didn't use to happen on the previous network. the only >>>>>>>>>> change was the network information. also a bunch of other >>>>>>>>>> machines changed at the same time and none of the others >>>>>>>>>> present the same situation. >>>>>>>>>> >>>>>>>>>> the only entry in the log is: >>>>>>>>>> init: can't exec getty '/usr/local/bin/xdm' for port >>>>>>>>>> /dev/ttyv8: No such file or directory >>>>>>>>> >>>>>>>>> delete or turn off the line in /etc/ttys for ttyv8 >>>>>>>>> >>>>>>>>>> >>>>>>>>>> (if somebody would explain what this is, that would help too. >>>>>>>>>> since xdm is not really in use and i can't find anything that >>>>>>>>>> would be calling xdm.) >>>>>>>>>> >>>>>>>>>> not sure if this has any importance but the card itself is >>>>>>>>>> BCM5750A1 NetXtreme Gigabit Ethernet PCI Express according to >>>>>>>>>> pciconf. >>>>>>>>>> >>>>>>>>>> the machine is 7.2 release. >>>>>>>>>> >>>>>>>>>> where do i look? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> thanks... >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 Tue Nov 23 08:21:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32FD910656C0 for ; Tue, 23 Nov 2010 08:21:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BABBB8FC12 for ; Tue, 23 Nov 2010 08:21:36 +0000 (UTC) Received: by wyb35 with SMTP id 35so155676wyb.13 for ; Tue, 23 Nov 2010 00:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vPWN0gGyBBahgiaBBSFfjnfBzoIvRb3ordaERuxOFfw=; b=mbr44KbVCGu4LkLsKDUjpQ9o29p6sVUxlHWquSptHrssHnaA98pHgMKke7h3uqDsnA CrON6jUqpqmL3enmAvLcPwOq9d5U9E8cpf06bMF6vx+Wumalo4urz51mCeh4j7s3V6qU A7EyhZ/cAhpYadJH/R2cSUBroIomlOr8ugW7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DMe17KqLxgQjOw9J3TDkY/okj2rW/1fQy9YdqdfOGtRREOmnT5fsNWaAnGJJMthXL6 DRch8qo5+sEM3GeQWdTx7SjdGLSt7ZZfFHuyi+2uWNJPc0QgDeBrQeLg++hmmLIoL+ex egpjmmEeOgp2xC8HLZlB3KxyZ/+W0WpnJhXf4= MIME-Version: 1.0 Received: by 10.216.157.6 with SMTP id n6mr6235910wek.35.1290500495420; Tue, 23 Nov 2010 00:21:35 -0800 (PST) Received: by 10.216.65.210 with HTTP; Tue, 23 Nov 2010 00:21:35 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Nov 2010 16:21:35 +0800 Message-ID: From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo Subject: Re: ipfw and bridge: unaligned payload pointers panicing perfectly performing MIPS boxes 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, 23 Nov 2010 08:21:37 -0000 Hi again, bz and I have done a bit of sleuthing. There's a few problems! Firstly - bridge_pfil() in sys/net/if_bridge.c calls a couple of functions to check the validity and alignment of ipv4/ipv6 packets (ie, bridge_ip_checkbasic() and bridge_ip6_checkbasic().) But bridge_ip6_checkbasic() is only called if the kernel is compiled with INET6. This MIPS platform I'm working on currently doesn't have INET6 compiled in, so: * IPv6 packet arrives in if_bridge * It doesn't get passed to bridge_ip6_checkbasic() * It gets punted to ipfw_chk() (I have net.link.bridge.ipfw set to 1) * ipfw_chk() sees the ethertype being IPv6 so it does the check whether the IP header version is IPv6 = but at that stage (struct ip *) ip is unaligned and an exception occurs. The fix - compile in INET6. :-/ I'd like to not rely on that though! Secondly - other misaligned packets were sneaking in. That's fine for now - the payload shouldn't be being fondled. But the ethertype was garbage. What bz and I found is that it's a SNAP packet (the ethertype being 0x001b) and although if_bridge.c::bridge_pfil() strips the SNAP header from the mbuf, the copy of the ethernet header it passes to ipfw_chk() still has the old ethertype set. Suggestion - when stripping off the SNAP header, set eh2.ether_type to the "correct" ether type, rather than the SNAP length field. 2c, Adrian Adrian From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 09:01:12 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3429E106566B for ; Tue, 23 Nov 2010 09:01:12 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8FFEA8FC15 for ; Tue, 23 Nov 2010 09:01:11 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.27.254]) by work.netasq.com (Postfix) with ESMTPSA id 18BA9740008; Tue, 23 Nov 2010 09:40:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary=Apple-Mail-18-809381120 From: Fabien Thomas In-Reply-To: <4CEB567C.9000906@rdtc.ru> Date: Tue, 23 Nov 2010 09:41:49 +0100 Message-Id: References: <20101117070422.GA45678@cabstand.com> <4CE3D097.7030204@grosbein.pp.ru> <4CEB567C.9000906@rdtc.ru> To: Jack Vogel X-Mailer: Apple Mail (2.1082) Cc: FreeBSD Net , Vlad Galu , Eugene Grosbein Subject: Re: request for MFC of em/igb drivers 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, 23 Nov 2010 09:01:12 -0000 --Apple-Mail-18-809381120 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That fix on ixgbe would also be great to commit on ixgbe before release. This fix a crash on high packet load with bpf (mbuf freed behind bpf = analysis). Fabien --Apple-Mail-18-809381120 Content-Disposition: attachment; filename=patch-ixgbe-bpfcrash Content-Type: application/octet-stream; name="patch-ixgbe-bpfcrash" Content-Transfer-Encoding: 7bit diff --git a/sys/dev/ixgbe/ixgbe.c b/sys/dev/ixgbe/ixgbe.c index 174c08d..073818e 100644 --- a/sys/dev/ixgbe/ixgbe.c +++ b/sys/dev/ixgbe/ixgbe.c @@ -1591,6 +1702,10 @@ ixgbe_xmit(struct tx_ring *txr, struct mbuf **m_headp) m_head = *m_headp; + /* Do a clean if descriptors are low */ + if (txr->tx_avail <= IXGBE_TX_CLEANUP_THRESHOLD) + ixgbe_txeof(txr); + /* Basic descriptor defines */ cmd_type_len = (IXGBE_ADVTXD_DTYP_DATA | IXGBE_ADVTXD_DCMD_IFCS | IXGBE_ADVTXD_DCMD_DEXT); @@ -1740,10 +1855,6 @@ ixgbe_xmit(struct tx_ring *txr, struct mbuf **m_headp) ++txr->total_packets; IXGBE_WRITE_REG(&adapter->hw, IXGBE_TDT(txr->me), i); - /* Do a clean if descriptors are low */ - if (txr->tx_avail <= IXGBE_TX_CLEANUP_THRESHOLD) - ixgbe_txeof(txr); - return (0); xmit_fail: --Apple-Mail-18-809381120 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > On 17.11.2010 23:39, Jack Vogel wrote: >> Yes, everyone, I plan on updating all the drivers, there has been no >> activity >> because I've tracking down a couple bugs that are tough, involving days >> of testing to reproduce. I know we're getting close and I appreciate any >> reports like this before. >> >> Stay tuned.... >> >> Jack > > Thanks for response. Do you play to MFC fixes before 8.2-RELEASE? > We are in PRERELEASE state already :-) > _______________________________________________ > 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" --Apple-Mail-18-809381120-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 11:53:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31CA5106564A for ; Tue, 23 Nov 2010 11:53:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id E2B7B8FC14 for ; Tue, 23 Nov 2010 11:53:21 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5C1F3BDC75 for ; Tue, 23 Nov 2010 03:53:21 -0800 (PST) To: freebsd-net@freebsd.org Date: Tue, 23 Nov 2010 03:53:21 -0800 Message-ID: <41757.1290513201@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 11:53:23 -0000 I just recently re-jigged my main server/workstation so that instead of just having a single interface that talks to the Internet via a single static IP, it now has, in addition to that, one other interface (and card) that's talking to one of those little black&blue Linksys router thingies to which other machines on my local network are connected (all using DHCP which is implemented in the Linksys box). For most stuff the default routing should be out via the original interface (and its static IP) but when the main server/workstation wants to talk to anything in 192.168.1.0/24, it should instead route those packets via the second/newer interface over to the Linksys box, i.e. so that this main machine can talk to other stuff on the local network. So anyway, here's what I have now in my /etc/rc.conf file: defaultrouter="69.62.255.254" network_interfaces="fxp0 rl0 lo0 auto" ifconfig_fxp0="inet 69.62.255.118 netmask 255.255.255.0" ifconfig_rl0="DHCP" This is problematic for several reasons. First, as I have learned, having any interface set to "DHCP" in the /etc/rc.conf file causes all sorts of DHCP magic to happen at startup time, and the end result of all that magic is that two undesirable things happen: 1) The /etc/resolv.conf file gets replaced with something that causes DNS resolutions to go someplace other than where I want them to go, and... 2) the default route that I attempted to set in the /etc/rc.conf file gets clobbered and replaced by a default route obtained from the DHCP negotiation on the second interface. I tried to work around these problems by simply putting code into my /etc/rc.local file that would restore the proper /etc/resolv.conf file and that would also restore the proper default route. That all actually seemed to be working well, _except_ that I just now noticed that, for reasons that are not apparent to me, my ntpd daemon is apparently trying to send its time sync packets out, via the original/ main/default interface, but with the source IP address being the RFC 1918 address that was obtained dynamically for the second interface via DHCP i.e. 192.168.1.101. That creates a definite problem because my IPFW firewall rules were set up to avoid me leaking RFC 1918 IPs out onto the public internet. So anyway, the result is that now my ntpd is utterly failing to communicate with any of the time servers it should be talking to (causing my time to drift slowly out of whack) AND I am now getting a whole lot of message in /var/log/messages like this: Nov 23 03:04:35 segfault kernel: ipfw: 3200 Deny UDP 192.168.1.101:123 128.118.25.3:123 out via fxp0 Nov 23 03:04:35 segfault ntpd[1064]: sendto(128.118.25.3): Permission denied Obviously, none of this is at all good. But where exactly did I go wrong? Why did my ntpd daemon latch on to the 192.168.1.101 IP address? Why is it attempting to originate packets from that IP address, rather than from 69.62.255.118 as it used to do? (And how can I get it to do that Right Thing again?) And why is the kernel now attempting to route those packets out to the net via my main/original interface, fxp0? (THAT is REALLY perplexing!) This is all quite mysterious to me, and I'd appreciate any help. Here is my current routing table, in case that's of any help. The 69.62.255.254 is the gateway address my ISP gave me... you know... to go along with my static IP. P.S. If possible, please answer on-list. Otherwise my geeky spam filter may cause me to miss your reply. Thanks. =================================================================== Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 69.62.255.254 UGS 0 2706435 fxp0 69.62.255.0/24 link#3 UC 0 0 fxp0 69.62.255.118 00:a0:c9:dd:11:7e UHLW 1 123493 lo0 69.62.255.254 00:00:0e:07:ac:00 UHLW 2 9 fxp0 72 127.0.0.1 127.0.0.1 UH 0 11955888 lo0 192.168.1.0/24 link#2 UC 0 0 rl0 192.168.1.1 00:1d:7e:c9:83:03 UHLW 1 1 rl0 1200 192.168.1.101 00:50:bf:43:5a:b9 UHLW 1 8 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#5 UHL lo0 ff01:5::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 12:12:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24D7F106564A for ; Tue, 23 Nov 2010 12:12:50 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 048068FC12 for ; Tue, 23 Nov 2010 12:12:49 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5840BBDC75 for ; Tue, 23 Nov 2010 04:12:49 -0800 (PST) To: freebsd-net@freebsd.org Date: Tue, 23 Nov 2010 04:12:49 -0800 Message-ID: <41880.1290514369@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Implementing a trivial TFTP client? 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, 23 Nov 2010 12:12:50 -0000 I have been attempting to implment a trivial sort of TFTP client from scratch, and its been somewhat of a humbling experience so far, and its taught me that I don't know quite as much about BSD socket programming as I though I did. So anyway, maybe some kind soul here would be willing to help me out and offer me some guidance. I'm not going to go over thet TFTP protocol here. That's well documented elsewhere. My question is really pretty simple: What would be the proper sequence of socket-related kernel calls necessary to implement a TFTP client that just simply connected to a TFTP server, and then sent (wrote) one file consisting of less than 512 bytes of data (i.e. just one packet's worth)? I've been trying the following sequence, and my code is kinda-sorta working, but apparently not quite (because the file never actually gets there): socket() bind() /* grab a fixed local port# */ /* NOTE: sin_addr=INADDR_ANY and sin_port=0 */ sendto() /* send the initial WRQ packet */ recvfrom() /* get the initial ACK packet */ connect() /* now that we know what port# the sever wants to talk to us on, we can "connect" our existing socket to that specific port# on the server's side */ send() /* Send the data packet */ recv() /* receive the data ACK packet */ Obviously, I am leaving out all of the grubby little details. I just want to focus on the proper sequence of socket primitive calls to make a trivial TFTP client. So, ah, does the above sequence look reasonable for that job? If not, where have I gone wrong? It does appear that the initial few calls are doing what they should, and the connection does start up, lickety split. But then after that, ACK responses to the data packets seem to arrive VERY VERY slowly, and although the remote TFTP daemon _does_ create the new output file up on the server (see the tftp "-w" option) the file never seems to get any bigger than 0 bytes in length. :-( My guess is that I'm doing multiple things in a substantially Wrong way. Any guidance would be appreciated. Regards, rfg P.S. If possible, please answer on-list. Otherwise my geeky spam filter may cause me to miss your reply. Thanks. From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 12:29:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0445C106566C for ; Tue, 23 Nov 2010 12:29:24 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 842D88FC12 for ; Tue, 23 Nov 2010 12:29:23 +0000 (UTC) Received: (qmail 93773 invoked from network); 23 Nov 2010 12:02:41 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@96.224.221.101) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 23 Nov 2010 12:02:41 -0000 Message-ID: <4CEBAD46.2070301@acm.poly.edu> Date: Tue, 23 Nov 2010 07:02:14 -0500 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101031 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Ronald F. Guilmette" References: <41757.1290513201@tristatelogic.com> In-Reply-To: <41757.1290513201@tristatelogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 12:29:24 -0000 On 11/23/10 06:53, Ronald F. Guilmette wrote: > I just recently re-jigged my main server/workstation so that instead > of just having a single interface that talks to the Internet via a > single static IP, it now has, in addition to that, one other interface > (and card) that's talking to one of those little black&blue Linksys > router thingies to which other machines on my local network are connected > (all using DHCP which is implemented in the Linksys box). > > For most stuff the default routing should be out via the original interface > (and its static IP) but when the main server/workstation wants to talk > to anything in 192.168.1.0/24, it should instead route those packets > via the second/newer interface over to the Linksys box, i.e. so that > this main machine can talk to other stuff on the local network. > > So anyway, here's what I have now in my /etc/rc.conf file: > > defaultrouter="69.62.255.254" > network_interfaces="fxp0 rl0 lo0 auto" > ifconfig_fxp0="inet 69.62.255.118 netmask 255.255.255.0" > ifconfig_rl0="DHCP" > > This is problematic for several reasons. First, as I have learned, > having any interface set to "DHCP" in the /etc/rc.conf file causes > all sorts of DHCP magic to happen at startup time, and the end result > of all that magic is that two undesirable things happen: > > 1) The /etc/resolv.conf file gets replaced with something that > causes DNS resolutions to go someplace other than where I want > them to go, and... > > 2) the default route that I attempted to set in the /etc/rc.conf > file gets clobbered and replaced by a default route obtained > from the DHCP negotiation on the second interface. > > I tried to work around these problems by simply putting code into my > /etc/rc.local file that would restore the proper /etc/resolv.conf file > and that would also restore the proper default route. > > That all actually seemed to be working well, _except_ that I just now > noticed that, for reasons that are not apparent to me, my ntpd daemon > is apparently trying to send its time sync packets out, via the original/ > main/default interface, but with the source IP address being the RFC 1918 > address that was obtained dynamically for the second interface via DHCP > i.e. 192.168.1.101. That creates a definite problem because my IPFW > firewall rules were set up to avoid me leaking RFC 1918 IPs out onto > the public internet. So anyway, the result is that now my ntpd is > utterly failing to communicate with any of the time servers it should be > talking to (causing my time to drift slowly out of whack) AND I am now > getting a whole lot of message in /var/log/messages like this: > > > Nov 23 03:04:35 segfault kernel: ipfw: 3200 Deny UDP 192.168.1.101:123 128.118.25.3:123 out via fxp0 > Nov 23 03:04:35 segfault ntpd[1064]: sendto(128.118.25.3): Permission denied > > > Obviously, none of this is at all good. But where exactly did I go wrong? > Why did my ntpd daemon latch on to the 192.168.1.101 IP address? Why is > it attempting to originate packets from that IP address, rather than from > 69.62.255.118 as it used to do? (And how can I get it to do that Right Thing > again?) And why is the kernel now attempting to route those packets out to > the net via my main/original interface, fxp0? (THAT is REALLY perplexing!) > > This is all quite mysterious to me, and I'd appreciate any help. > > Here is my current routing table, in case that's of any help. The > 69.62.255.254 is the gateway address my ISP gave me... you know... to > go along with my static IP. > > P.S. If possible, please answer on-list. Otherwise my geeky spam filter > may cause me to miss your reply. Thanks. > > =================================================================== > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 69.62.255.254 UGS 0 2706435 fxp0 > 69.62.255.0/24 link#3 UC 0 0 fxp0 > 69.62.255.118 00:a0:c9:dd:11:7e UHLW 1 123493 lo0 > 69.62.255.254 00:00:0e:07:ac:00 UHLW 2 9 fxp0 72 > 127.0.0.1 127.0.0.1 UH 0 11955888 lo0 > 192.168.1.0/24 link#2 UC 0 0 rl0 > 192.168.1.1 00:1d:7e:c9:83:03 UHLW 1 1 rl0 1200 > 192.168.1.101 00:50:bf:43:5a:b9 UHLW 1 8 lo0 > > Internet6: > Destination Gateway Flags Netif Expire > ::1 ::1 UHL lo0 > fe80::%lo0/64 fe80::1%lo0 U lo0 > fe80::1%lo0 link#5 UHL lo0 > ff01:5::/32 fe80::1%lo0 UC lo0 > ff02::%lo0/32 fe80::1%lo0 UC lo0 > > > _______________________________________________ > 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" Hi. I hypothesize that ntpd is started before your rc.local script is run, so it uses the NAT IP and default route. Take a look at the dhclient.conf man page for how to ignore certain DHCP-provided information for an interface. For example: # cat /etc/dhclient.conf ... interface "wlan0" { supersede domain-name "poly.edu"; supersede domain-name-servers 128.238.9.202; } The above overrides any DHCP-provided domain name and DNS servers with what I have above on the wlan0 interface. -Boris From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 12:35:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C7981065672 for ; Tue, 23 Nov 2010 12:35:43 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id E074F8FC1B for ; Tue, 23 Nov 2010 12:35:42 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 514BEBDC75 for ; Tue, 23 Nov 2010 04:35:42 -0800 (PST) To: freebsd-net@freebsd.org In-Reply-To: <4CEBAD46.2070301@acm.poly.edu> Date: Tue, 23 Nov 2010 04:35:42 -0800 Message-ID: <42097.1290515742@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 12:35:43 -0000 In message <4CEBAD46.2070301@acm.poly.edu>, Boris Kochergin wrote: >Hi. I hypothesize that ntpd is started before your rc.local script is >run, so it uses the NAT IP and default route. Take a look at the >dhclient.conf man page for how to ignore certain DHCP-provided >information for an interface. Thanks Boris. I _did_ actually look over that man page before I posted, but I could not really make heads or tails out of it, due to the lack of any actual examples. >For example: > ># cat /etc/dhclient.conf >... >interface "wlan0" { > supersede domain-name "poly.edu"; > supersede domain-name-servers 128.238.9.202; >} > >The above overrides any DHCP-provided domain name and DNS servers with >what I have above on the wlan0 interface. Whoa! OK, I see now... I failed to take note of the small SEE ALSO annotation down at the bottom of the man page for dhclient.conf(5)... you know... the one that says SEE ALSO dhcp-options(5). Obviously, that's where all of the magic symbols that can be diddled are listed. (And that's the main thing I didn't know.) Well, OK, so now I'll try and see if I can get a proper outcome by using interface "rl0" { supersede routers 69.62.255.254; supersede domain-name-servers 127.0.0.1; } Thanks for giving me something I can work with. I should say however that even this is going to produce a slightly sub-optimal result, because (I guess) the DHCP client is _still_ going to wipe out my eisting /etc/resolve.con file and then write its own. Now that will at least have the proper IP address in it _however_ there does not seem to be any way to entice the DHCP client to place certain "options" into the /etc/resolv.conf file. That's a pity, because I wanted one in there. (Oh well, I guss I can append it from my /etc/rc.local file.) Anyway, thanks again. I should know soon if this fixes that ntpd problem. Regards, rfg From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 12:47:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A7811065675 for ; Tue, 23 Nov 2010 12:47:13 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C3ECA8FC21 for ; Tue, 23 Nov 2010 12:47:12 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PKsH9-0003zD-B3 for freebsd-net@freebsd.org; Tue, 23 Nov 2010 13:47:11 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 13:47:11 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 13:47:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Tue, 23 Nov 2010 13:47:08 +0100 Lines: 13 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 X-Enigmail-Version: 1.1.2 Cc: freebsd-hardware@freebsd.org Subject: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 12:47:13 -0000 It looks like I'm unfortunate enough to have to deploy on a machine which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which apparently has hardware issues, according to this thread: http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 One of the proposed workarounds is disabling "Active State Power Management" in the BIOS and in the OS. I have disabled it in BIOS but I don't know how to disable it in FreeBSD (apparently only disabling it in BIOS isn't enough). Any ideas on how to achieve the effect in FreeBSD? From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 13:03:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5D33106566C; Tue, 23 Nov 2010 13:03:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF5F8FC1F; Tue, 23 Nov 2010 13:03:18 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:49a2:dbc6:564:65a6] ([IPv6:2607:f3e0:0:4:49a2:dbc6:564:65a6]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oAND3GVq077656 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Nov 2010 08:03:16 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CEBBB8F.70400@sentex.net> Date: Tue, 23 Nov 2010 08:03:11 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Jack Vogel , freebsd-hardware@freebsd.org Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 13:03:19 -0000 On 11/23/2010 7:47 AM, Ivan Voras wrote: > It looks like I'm unfortunate enough to have to deploy on a machine > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > apparently has hardware issues, according to this thread: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 > > Interesting, this is the same nic that has been giving me grief! Mine is on an Intel server board (S3420GPX). The symptoms are VERY similar to what the LINUX user sees as well with RX errors and the traffic patterns. ---Mike > One of the proposed workarounds is disabling "Active State Power > Management" in the BIOS and in the OS. > > I have disabled it in BIOS but I don't know how to disable it in FreeBSD > (apparently only disabling it in BIOS isn't enough). > > Any ideas on how to achieve the effect in FreeBSD? > > _______________________________________________ > 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 Tue Nov 23 13:16:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 438B91065673 for ; Tue, 23 Nov 2010 13:16:45 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 90AD18FC25 for ; Tue, 23 Nov 2010 13:16:44 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PKsjj-0001tV-0L for freebsd-net@freebsd.org; Tue, 23 Nov 2010 14:16:43 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 14:16:42 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Nov 2010 14:16:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Tue, 23 Nov 2010 14:16:35 +0100 Lines: 34 Message-ID: References: <4CEBBB8F.70400@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4CEBBB8F.70400@sentex.net> X-Enigmail-Version: 1.1.2 Cc: freebsd-hardware@freebsd.org Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 13:16:45 -0000 On 11/23/10 14:03, Mike Tancsa wrote: > On 11/23/2010 7:47 AM, Ivan Voras wrote: >> It looks like I'm unfortunate enough to have to deploy on a machine >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which >> apparently has hardware issues, according to this thread: >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 >> >> > > Interesting, this is the same nic that has been giving me grief! Mine is > on an Intel server board (S3420GPX). The symptoms are VERY similar to > what the LINUX user sees as well with RX errors and the traffic patterns. I've posted detailed info on this NIC in the thread "em card wedging" - can you compare it with yours? The whole thing looks very sensitive to BIOS settings. I've just toggled something that looked unrelated (don't remember what, I've been toggling BIOS settings all day) and the machine has been doing a flood-ping for 20 minutes without wedging (which doesn't mean it won't wedge as soon as I send this message, it did such things before). One other thing, I don't know if this is normal as I've only just noticed it: flood-pinging a machine (also a FreeBSD machine, on the same switch) and monitoring the packet rates with netstat I see that the rates begin at something like 8,000 PPS (in either direction) and then slowly over a timespan of 5-10 minutes climb to 100,000 PPS (again, in either direction). Since this is gigabit LAN with a Cisco switch, I'd say the 100,000 PPS should be correct. The other machine I'm pinging also has an em card but a "desktop class" one. Is this slow-start expected / normal? From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 13:37:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCBE91065670 for ; Tue, 23 Nov 2010 13:37:35 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [195.9.14.139]) by mx1.freebsd.org (Postfix) with ESMTP id 4D99C8FC1D for ; Tue, 23 Nov 2010 13:37:35 +0000 (UTC) Received: from cicuta.babolo.ru ([194.58.246.5]) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id oANDYcn7066408; Tue, 23 Nov 2010 16:34:46 +0300 (MSK) (envelope-from .@babolo.ru) Received: (nullmailer pid 36358 invoked by uid 136); Tue, 23 Nov 2010 13:38:20 -0000 Date: Tue, 23 Nov 2010 16:38:20 +0300 From: Aleksandr A Babaylov <.@babolo.ru> To: "Ronald F. Guilmette" Message-ID: <20101123133820.GA36224@babolo.ru> References: <4CEBAD46.2070301@acm.poly.edu> <42097.1290515742@tristatelogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42097.1290515742@tristatelogic.com> Cc: freebsd-net@freebsd.org Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:37:35 -0000 On Tue, Nov 23, 2010 at 04:35:42AM -0800, Ronald F. Guilmette wrote: > I should say however that even this is going to produce a slightly sub-optimal > result, because (I guess) the DHCP client is _still_ going to wipe out my > eisting /etc/resolve.con file and then write its own. Now that will at > least have the proper IP address in it _however_ there does not seem to > be any way to entice the DHCP client to place certain "options" into the > /etc/resolv.conf file. That's a pity, because I wanted one in there. > (Oh well, I guss I can append it from my /etc/rc.local file.) Does chflags schg /etc/resolve.conf helps? From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 13:42:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD321106566C for ; Tue, 23 Nov 2010 13:42:00 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [195.9.14.139]) by mx1.freebsd.org (Postfix) with ESMTP id 3F95A8FC14 for ; Tue, 23 Nov 2010 13:41:59 +0000 (UTC) Received: from cicuta.babolo.ru ([194.58.246.5]) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id oANDdCe5067544; Tue, 23 Nov 2010 16:39:12 +0300 (MSK) (envelope-from .@babolo.ru) Received: (nullmailer pid 36391 invoked by uid 136); Tue, 23 Nov 2010 13:42:54 -0000 Date: Tue, 23 Nov 2010 16:42:54 +0300 From: Aleksandr A Babaylov <.@babolo.ru> To: "Ronald F. Guilmette" Message-ID: <20101123134254.GB36224@babolo.ru> References: <41880.1290514369@tristatelogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41880.1290514369@tristatelogic.com> Cc: freebsd-net@freebsd.org Subject: Re: Implementing a trivial TFTP client? 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, 23 Nov 2010 13:42:00 -0000 On Tue, Nov 23, 2010 at 04:12:49AM -0800, Ronald F. Guilmette wrote: > I have been attempting to implment a trivial sort of TFTP client from > scratch, and its been somewhat of a humbling experience so far, and > its taught me that I don't know quite as much about BSD socket programming > as I though I did. > > So anyway, maybe some kind soul here would be willing to help me out and > offer me some guidance. > > I'm not going to go over thet TFTP protocol here. That's well documented > elsewhere. My question is really pretty simple: What would be the proper > sequence of socket-related kernel calls necessary to implement a TFTP > client that just simply connected to a TFTP server, and then sent (wrote) > one file consisting of less than 512 bytes of data (i.e. just one packet's > worth)? > > I've been trying the following sequence, and my code is kinda-sorta working, > but apparently not quite (because the file never actually gets there): > > socket() > bind() /* grab a fixed local port# */ > /* NOTE: sin_addr=INADDR_ANY and sin_port=0 */ > sendto() /* send the initial WRQ packet */ > recvfrom() /* get the initial ACK packet */ > connect() /* now that we know what port# the sever wants to talk > to us on, we can "connect" our existing socket to > that specific port# on the server's side */ > send() /* Send the data packet */ > recv() /* receive the data ACK packet */ > > Obviously, I am leaving out all of the grubby little details. I just want > to focus on the proper sequence of socket primitive calls to make a trivial > TFTP client. > > So, ah, does the above sequence look reasonable for that job? If not, where > have I gone wrong? > > It does appear that the initial few calls are doing what they should, and > the connection does start up, lickety split. But then after that, ACK > responses to the data packets seem to arrive VERY VERY slowly, and although > the remote TFTP daemon _does_ create the new output file up on the server > (see the tftp "-w" option) the file never seems to get any bigger than 0 > bytes in length. :-( > > My guess is that I'm doing multiple things in a substantially Wrong way. > > Any guidance would be appreciated. Try ktrace -i tftp and look at kdump to see how it works From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 14:17:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2D3010656B8; Tue, 23 Nov 2010 14:17:47 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 576108FC14; Tue, 23 Nov 2010 14:17:47 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id C25A9E3F07A; Tue, 23 Nov 2010 14:57:49 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdOufu-MoIkI; Tue, 23 Nov 2010 14:57:47 +0100 (CET) Received: from pluto.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id A51D4E3F079; Tue, 23 Nov 2010 14:57:46 +0100 (CET) Date: Tue, 23 Nov 2010 14:57:44 +0100 From: Joel Dahl To: Ivan Voras Message-ID: <20101123135744.GE12322@pluto.vnode.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 14:17:47 -0000 On 23-11-2010 13:47, Ivan Voras wrote: > It looks like I'm unfortunate enough to have to deploy on a machine > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > apparently has hardware issues, according to this thread: I have a Supermicro X7SPE-HF board with two onboard Intel 82574L nics and I see the same thing. The nics seem to "die" if I push enough data through them and the only way to recover is to reboot. I noticed this a few days ago and I haven't had any time to investigate more, so I guess this is just a "me too"... -- Joel From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 14:45:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7929106564A; Tue, 23 Nov 2010 14:45:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 9762E8FC0C; Tue, 23 Nov 2010 14:45:04 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:49a2:dbc6:564:65a6] ([IPv6:2607:f3e0:0:4:49a2:dbc6:564:65a6]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oANEiu3d097451 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Nov 2010 09:44:56 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CEBD363.2070402@sentex.net> Date: Tue, 23 Nov 2010 09:44:51 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: <4CEBBB8F.70400@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Jack Vogel , freebsd-hardware@freebsd.org Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 14:45:05 -0000 On 11/23/2010 8:16 AM, Ivan Voras wrote: > On 11/23/10 14:03, Mike Tancsa wrote: >> On 11/23/2010 7:47 AM, Ivan Voras wrote: >>> It looks like I'm unfortunate enough to have to deploy on a machine >>> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which >>> apparently has hardware issues, according to this thread: >>> >>> http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 >>> >>> >>> >> >> Interesting, this is the same nic that has been giving me grief! Mine is >> on an Intel server board (S3420GPX). The symptoms are VERY similar to >> what the LINUX user sees as well with RX errors and the traffic patterns. > > I've posted detailed info on this NIC in the thread "em card wedging" - > can you compare it with yours? > > The whole thing looks very sensitive to BIOS settings. I've just toggled > something that looked unrelated (don't remember what, I've been toggling > BIOS settings all day) and the machine has been doing a flood-ping for > 20 minutes without wedging (which doesn't mean it won't wedge as soon as > I send this message, it did such things before). I posted whats in the BIOS at http://www.tancsa.com/82574.html Unfortunately, if I disable the BIOS option highlighted I can no longer netboot the box :( For my production box having the issues, this is not a problem. But it makes it difficult for testing on my lab box. I am not sure if that even really disables IPMI ? Also on this box whats NIC1 and NIC2 is the opposite of what FreeBSD sees as em0 and em1. So far I have tried Driver from HEAD -- This seems to help a bit in that wedges are less disable MSIX - no difference, still hangs It seems the nic will get one error and never recover. There will just be a steady stream of them. On the other onboard nic (a different type of em), the card will see the odd "no_buff" error, but it recovers like all the other em nics. Where as this problem nic, gets errors and they just keep on going up and up. Using the driver from HEAD, I can do an ifconfig em1 down;sleep 1;ifconfig em1 up and that fixes the problem dev.em.1.mac_stats.missed_packets: 1292 dev.em.1.mac_stats.recv_no_buff: 31 where as previous versions of the driver would panic the box doing that. Looking at the driver from HEAD, there does seem to be some mention of ASPM. Is this what the LINUX driver is doing too ? /* PCI-Ex Control Registers */ switch (hw->mac.type) { case e1000_82574: case e1000_82583: reg = E1000_READ_REG(hw, E1000_GCR); reg |= (1 << 22); E1000_WRITE_REG(hw, E1000_GCR, reg); /* * Workaround for hardware errata. * apply workaround for hardware errata documented in errata * docs Fixes issue where some error prone or unreliable PCIe * completions are occurring, particularly with ASPM enabled. * Without fix, issue can cause tx timeouts. */ reg = E1000_READ_REG(hw, E1000_GCR2); reg |= 1; E1000_WRITE_REG(hw, E1000_GCR2, reg); break; default: break; } return; ---Mike From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 14:49:55 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED1591065673 for ; Tue, 23 Nov 2010 14:49:55 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A55848FC19 for ; Tue, 23 Nov 2010 14:49:55 +0000 (UTC) Received: by qwf7 with SMTP id 7so573903qwf.13 for ; Tue, 23 Nov 2010 06:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6Nq6+X3BtecbSqi9aBs71SQpeDP0E28+4KDxcGRi3Yg=; b=wCbEJ9ax9lULG1i9xzqkC5QASAFk19q/R+ChHAGl/GfR5c34E1L1rKmo+ZlObMMvsi fnjofjQ5NdjLZadRtPvsV3ME6S0if8aQO1V+e6ndCgUsXPRb0c0MgZdR6LRrxsc0l1mP w78jrZ4D6po8LIpn2Qz2+og/wdHTISfrFNJwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FDpnk6UqBZ6kz/hhXhrq3AlFCIfteWwLL2cLwphiZAdDCzoBwcezpi/JkLY6k9+VHr cvlzK8VP0pdbxz/FsoiEqFazAQXu4FzcWgG3abrmGCEY+Ggc+/1BiKy2MY9M0vf7SiRk 7lp6Uh8idmGAtDiN1P9jns7wIBpE6bz3fqhiE= MIME-Version: 1.0 Received: by 10.229.183.135 with SMTP id cg7mr2780497qcb.296.1290521966558; Tue, 23 Nov 2010 06:19:26 -0800 (PST) Received: by 10.229.182.18 with HTTP; Tue, 23 Nov 2010 06:19:26 -0800 (PST) In-Reply-To: <42097.1290515742@tristatelogic.com> References: <4CEBAD46.2070301@acm.poly.edu> <42097.1290515742@tristatelogic.com> Date: Tue, 23 Nov 2010 14:19:26 +0000 Message-ID: From: Tom Evans To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:49:56 -0000 On Tue, Nov 23, 2010 at 12:35 PM, Ronald F. Guilmette wrote: > .... >=C2=A0Now that will at > least have the proper IP address in it _however_ there does not seem to > be any way to entice the DHCP client to place certain "options" into the > /etc/resolv.conf file. =C2=A0That's a pity, because I wanted one in there= . > (Oh well, I guss I can append it from my /etc/rc.local file.) > Like what options? Most things can be controlled from dhclient.conf. Cheers Tom From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 15:38:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7967E1065679 for ; Tue, 23 Nov 2010 15:38:39 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id DD7D48FC0A for ; Tue, 23 Nov 2010 15:38:38 +0000 (UTC) Received: (qmail 23214 invoked by uid 1001); 23 Nov 2010 15:11:53 -0000 Date: Tue, 23 Nov 2010 16:11:53 +0100 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20101123151153.GB27694@diehard.n-r-g.com> Mail-Followup-To: freebsd-net@freebsd.org References: <4CEBBB8F.70400@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 15:38:39 -0000 On Tue, Nov 23, 2010 at 02:16:35PM +0100, Ivan Voras wrote: > On 11/23/10 14:03, Mike Tancsa wrote: > >On 11/23/2010 7:47 AM, Ivan Voras wrote: > >>It looks like I'm unfortunate enough to have to deploy on a machine > >>which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > >>apparently has hardware issues, according to this thread: > >> > >>http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 > >> > >> > > > >Interesting, this is the same nic that has been giving me grief! Mine is > >on an Intel server board (S3420GPX). The symptoms are VERY similar to > >what the LINUX user sees as well with RX errors and the traffic patterns. > > I've posted detailed info on this NIC in the thread "em card > wedging" - can you compare it with yours? > > The whole thing looks very sensitive to BIOS settings. I've just > toggled something that looked unrelated (don't remember what, I've > been toggling BIOS settings all day) and the machine has been doing > a flood-ping for 20 minutes without wedging (which doesn't mean it > won't wedge as soon as I send this message, it did such things > before). > > One other thing, I don't know if this is normal as I've only just > noticed it: flood-pinging a machine (also a FreeBSD machine, on the > same switch) and monitoring the packet rates with netstat I see that > the rates begin at something like 8,000 PPS (in either direction) > and then slowly over a timespan of 5-10 minutes climb to 100,000 PPS > (again, in either direction). > > Since this is gigabit LAN with a Cisco switch, I'd say the 100,000 > PPS should be correct. The other machine I'm pinging also has an em > card but a "desktop class" one. Is this slow-start expected / > normal? > Yes, this is how ping -f works. ping -f sends a packet whenever it received a response or when a timer fired (IIRC that one is set to 1ms). So ping -f will not ramp up if the delay is smaller then the internal timer and hover around 1/delay pps until packet loss or bigger delays happen. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 15:41:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C6B0106566C for ; Tue, 23 Nov 2010 15:41:32 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD148FC12 for ; Tue, 23 Nov 2010 15:41:32 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 26622730A4; Tue, 23 Nov 2010 16:38:24 +0100 (CET) Date: Tue, 23 Nov 2010 16:38:24 +0100 From: Luigi Rizzo To: Adrian Chadd Message-ID: <20101123153824.GB48018@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net Subject: Re: ipfw and bridge: unaligned payload pointers panicing perfectly performing MIPS boxes 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, 23 Nov 2010 15:41:32 -0000 On Tue, Nov 23, 2010 at 02:30:56PM +0800, Adrian Chadd wrote: > Hi everyone (and Luigi especially!) > > I've found that enabling ipfw for bridge interfaces panics my MIPS > boards. A bit of digging shows that the payload mbuf isn't aligned as > passed into ipfw_chk(), and this is causing aligned access exceptions. > > It likely isn't a problem on i386/ia64 because they are happy with > unaligned access. :-) > > I'm going to try and patch it locally by copying the mbuf payload into > a new, temporary mbuf that's aligned; but I have no idea what the > "right" solution for the stack is. > > Ideas? :) the copy (especially if you make it conditional on #if NEED_ALIGNED and possibly on actual alignment) sounds good enough and it probably limits the number of changes to code. The drawback is that you might need to copy a lot of stuff unnecessarily. The other option would be to replace all the initial assignments to the copies of the header fields with macros, which then translate into assignments or bcopy depending on the circumstances. I'd go for the former, unless you are really concerned about performance. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 16:28:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C3DF106566C for ; Tue, 23 Nov 2010 16:28:03 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id C30178FC0A for ; Tue, 23 Nov 2010 16:28:02 +0000 (UTC) Received: from [91.193.166.194] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PKvBL-0007Np-Vb; Tue, 23 Nov 2010 17:53:27 +0200 Received: from levsha by laptop.levsha.me with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PKvBL-000M5z-Nc; Tue, 23 Nov 2010 17:53:23 +0200 Date: Tue, 23 Nov 2010 17:53:23 +0200 From: Mykola Dzham To: "Ronald F. Guilmette" Message-ID: <20101123155323.GA51348@laptop.levsha.me> References: <41757.1290513201@tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41757.1290513201@tristatelogic.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 91.193.166.194 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 16:28:03 -0000 Ronald F. Guilmette wrote: > > I just recently re-jigged my main server/workstation so that instead > of just having a single interface that talks to the Internet via a > single static IP, it now has, in addition to that, one other interface > (and card) that's talking to one of those little black&blue Linksys > router thingies to which other machines on my local network are connected > (all using DHCP which is implemented in the Linksys box). > > For most stuff the default routing should be out via the original interface > (and its static IP) but when the main server/workstation wants to talk > to anything in 192.168.1.0/24, it should instead route those packets > via the second/newer interface over to the Linksys box, i.e. so that > this main machine can talk to other stuff on the local network. > > So anyway, here's what I have now in my /etc/rc.conf file: > > defaultrouter="69.62.255.254" > network_interfaces="fxp0 rl0 lo0 auto" > ifconfig_fxp0="inet 69.62.255.118 netmask 255.255.255.0" > ifconfig_rl0="DHCP" > > This is problematic for several reasons. First, as I have learned, > having any interface set to "DHCP" in the /etc/rc.conf file causes > all sorts of DHCP magic to happen at startup time, and the end result > of all that magic is that two undesirable things happen: > > 1) The /etc/resolv.conf file gets replaced with something that > causes DNS resolutions to go someplace other than where I want > them to go, and... > > 2) the default route that I attempted to set in the /etc/rc.conf > file gets clobbered and replaced by a default route obtained > from the DHCP negotiation on the second interface. You can totally disable resolv.conf changing and rote setting: put into /etc/dhclient-enter-hooks file this code: add_new_resolv_conf() { echo "doing nothing to resolv.conf" } add_new_routes() { echo "do not set routes" } -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 17:38:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C19D106566B for ; Tue, 23 Nov 2010 17:38:39 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0CD8FC18 for ; Tue, 23 Nov 2010 17:38:37 +0000 (UTC) Received: by wwc33 with SMTP id 33so1060884wwc.1 for ; Tue, 23 Nov 2010 09:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Up193iv+3iBmiM04FpbG3biZLt8X70oXvcK0owkgJZA=; b=XN5EwPazRASU3MFzc+EQ0ZadN8YaBHfFdVYwbgsJIk3GA3UIVM4ek9E8GjBAZRqJhx NanGBfnNzvLqXwQ/QGcGSO8nZ9Xdf5b/f3BzqmQTr2dwasIR0xHrnUqtbWl3zx79pQ/+ PyPsGgVqTcDig/RPqhwo0MXfUJQsZG9i6hISA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R/2EsUAdxCcfYlQEy1mnEFRaKcC3y3glMcazm3+U3f4xsOEcbZN0WnH9vF+Jqzgpry gmBd/sydBUeefI8ZkSsa24U9BK0sVgUmMfmqyKVxrqpY3ocdZzXBwuwmAAtmcU1B8tUD cc+GgjNHM4fiIlVxXslceuT+Nr2w7XxlfR9LU= MIME-Version: 1.0 Received: by 10.216.50.11 with SMTP id y11mr6938772web.57.1290533915199; Tue, 23 Nov 2010 09:38:35 -0800 (PST) Received: by 10.216.2.206 with HTTP; Tue, 23 Nov 2010 09:38:35 -0800 (PST) In-Reply-To: <4CEB567C.9000906@rdtc.ru> References: <20101117070422.GA45678@cabstand.com> <4CE3D097.7030204@grosbein.pp.ru> <4CEB567C.9000906@rdtc.ru> Date: Tue, 23 Nov 2010 09:38:35 -0800 Message-ID: From: Jack Vogel To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Vlad Galu Subject: Re: request for MFC of em/igb drivers 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, 23 Nov 2010 17:38:39 -0000 Yes, code freeze starts Saturday, there have been issues with igb in HEAD which is why I did not just want to MFC it. I have a driver that now has been surviving long term stress (48+ hours of pounding) so I think its what we should go with, its coming to HEAD today and then PRERELEASE barring any problems before the weekend. Jack On Mon, Nov 22, 2010 at 9:51 PM, Eugene Grosbein wrote: > On 17.11.2010 23:39, Jack Vogel wrote: > > Yes, everyone, I plan on updating all the drivers, there has been no > > activity > > because I've tracking down a couple bugs that are tough, involving days > > of testing to reproduce. I know we're getting close and I appreciate any > > reports like this before. > > > > Stay tuned.... > > > > Jack > > Thanks for response. Do you play to MFC fixes before 8.2-RELEASE? > We are in PRERELEASE state already :-) > From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 17:50:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA81A106567A; Tue, 23 Nov 2010 17:50:20 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id D07618FC1D; Tue, 23 Nov 2010 17:50:20 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id oANHd1jb032813; Tue, 23 Nov 2010 09:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1290533941; bh=CLkFCbrRcwhNTtqsO5gIrJ2CgGoRoW48uReiDSAF0Zs=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=nTM5ntHK2FuaeuRe7/lyLtmnlGwBJxTTBu6dml9tsbnbK+WExwZZsJrb1y2YYugAB C1+pL5nSc5OmWd+4GecqDlgzeOyGR0G/6vRMPexVxBDRTmPJLnc1WvNSM/GpQyFcJq bqSURcd46gKYLRh2Q87OuMX5wCPAzlLdaFDQaQVw= From: Sean Bruno To: Ivan Voras In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 23 Nov 2010 09:39:01 -0800 Message-ID: <1290533941.3173.50.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 17:50:21 -0000 On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > It looks like I'm unfortunate enough to have to deploy on a machine > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > apparently has hardware issues, according to this thread: > > http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 > > One of the proposed workarounds is disabling "Active State Power > Management" in the BIOS and in the OS. > > I have disabled it in BIOS but I don't know how to disable it in FreeBSD > (apparently only disabling it in BIOS isn't enough). > > Any ideas on how to achieve the effect in FreeBSD? > > _______________________________________________ > 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" Can I get an example pciconf -lv off of a couple of machines? I've been seeing some "issues" here at big purple that are similar. Sean mine: igb0@pci0:5:0:0: class=0x020000 card=0x8975152d chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb1@pci0:5:0:1: class=0x020000 card=0x8975152d chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 17:58:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B392106566B for ; Tue, 23 Nov 2010 17:58:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D054F8FC24 for ; Tue, 23 Nov 2010 17:58:34 +0000 (UTC) Received: by wwd20 with SMTP id 20so8588622wwd.31 for ; Tue, 23 Nov 2010 09:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=oBil0llx0qTMfapW0Ye+E1faXH7utB/TloQBYECnhUo=; b=Fauslavuk/yWoL4zxR6njf6HUObuD1ioOIeAxuB5jIblvN07z075wV4c4Kx4CZaC6U a1UqZDLoy6xavF16o09zJEhrNwSNFvumI7UTrg0V0nHMyF8+RU14CjKoTwpd2tQieTl1 2ZvrH4pcxsKH0+Stb+aNXghAbWramQz13ejbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=adiikk0sGyUBkZLD2yEYKi1JPZAZgrWHnTTGXlatvi8+W+g4vd27D9+nCiHLZgNkB3 nhkjoMjtqM7TmI8XPdBGiF2Kntj1finfy+KncnZ9qMWqmfIhhJfSTe+7svjDkwmpw1w0 hxST+nNPCmC7H23Q81wUosiobA+4UmV7XFJIg= MIME-Version: 1.0 Received: by 10.216.59.193 with SMTP id s43mr1349156wec.42.1290535112720; Tue, 23 Nov 2010 09:58:32 -0800 (PST) Received: by 10.216.2.206 with HTTP; Tue, 23 Nov 2010 09:58:32 -0800 (PST) In-Reply-To: <1290533941.3173.50.camel@home-yahoo> References: <1290533941.3173.50.camel@home-yahoo> Date: Tue, 23 Nov 2010 09:58:32 -0800 Message-ID: From: Jack Vogel To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Ivan Voras , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 17:58:35 -0000 Those are 82576, not 82574, totally different hardware. Would you please test the new driver that will be going into HEAD today, I'd like to see testing on it as much as possible for a few days. Cheers, Jack On Tue, Nov 23, 2010 at 9:39 AM, Sean Bruno wrote: > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > > It looks like I'm unfortunate enough to have to deploy on a machine > > which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > > apparently has hardware issues, according to this thread: > > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=2908463&group_id=42302&atid=447449 > > > > One of the proposed workarounds is disabling "Active State Power > > Management" in the BIOS and in the OS. > > > > I have disabled it in BIOS but I don't know how to disable it in FreeBSD > > (apparently only disabling it in BIOS isn't enough). > > > > Any ideas on how to achieve the effect in FreeBSD? > > > > _______________________________________________ > > 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" > > Can I get an example pciconf -lv off of a couple of machines? I've been > seeing some "issues" here at big purple that are similar. > > Sean > > mine: > > igb0@pci0:5:0:0: class=0x020000 card=0x8975152d chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > igb1@pci0:5:0:1: class=0x020000 card=0x8975152d chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > > _______________________________________________ > 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 Tue Nov 23 18:17:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123141065679; Tue, 23 Nov 2010 18:17:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 842E78FC13; Tue, 23 Nov 2010 18:17:52 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:49a2:dbc6:564:65a6] ([IPv6:2607:f3e0:0:4:49a2:dbc6:564:65a6]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oANIHndl038484 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Nov 2010 13:17:50 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CEC0548.1080801@sentex.net> Date: Tue, 23 Nov 2010 13:17:44 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Sean Bruno References: <1290533941.3173.50.camel@home-yahoo> In-Reply-To: <1290533941.3173.50.camel@home-yahoo> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Ivan Voras , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 18:17:53 -0000 On 11/23/2010 12:39 PM, Sean Bruno wrote: > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: >> It looks like I'm unfortunate enough to have to deploy on a machine >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > igb0@pci0:5:0:0: class=0x020000 card=0x8975152d chip=0x10c98086 Strange, the 82574 attaches as em for me, not igb em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffffed68a4 Normally, its msix, but I had disabled that hoping it would fix the problem em1: port 0x2000-0x201f mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at dev ice 0.0 on pci10 em1: Using an MSI interrupt em1: [FILTER] em1: Ethernet address: 00:15:17:ed:68:a4 ---Mike From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 18:36:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB9AC1065672; Tue, 23 Nov 2010 18:36:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0195F8FC1B; Tue, 23 Nov 2010 18:36:14 +0000 (UTC) Received: by wwd20 with SMTP id 20so8622806wwd.31 for ; Tue, 23 Nov 2010 10:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2Uzl3BjTeQRsG15Wq7VftNa2WVzH5Z/yE+v9XR1kEKk=; b=Nxb7kIBgdXO/i//54MMTO7e+8UihrfNZWuAPrQd5HgAA7sR8oZvoTR5GzoOBIn7xkH 1C3udCgv0cmzVoXFetPrfTuaKT2De2ZD4pZkhMFMHkwkvZezy6Ga7tFLTuaC3qU2LCoZ isb581nuDKuQiiXmIyH3l2YBnya7e9zISBR0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Rp4UGR+0TOTnzhtpadowl/GGJdFoTpM2tLaXxyRN7tA0jnFXWyoDiPoG/UJ7trKk9q JB57RgWOr4ix6mlQIYHuZCFy+R6w41Wk6wgPpcRQq01t85sQDsQD+TEw5tgt011pVKA3 dhXSMUUcp4IfRRgwD+y6e2uboAjvfhrziUckQ= MIME-Version: 1.0 Received: by 10.216.59.193 with SMTP id s43mr1400702wec.42.1290537372768; Tue, 23 Nov 2010 10:36:12 -0800 (PST) Received: by 10.216.2.206 with HTTP; Tue, 23 Nov 2010 10:36:12 -0800 (PST) In-Reply-To: <4CEC0548.1080801@sentex.net> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> Date: Tue, 23 Nov 2010 10:36:12 -0800 Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Sean Bruno , Ivan Voras Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 18:36:15 -0000 82574 is supposed to be em, not igb :) Its always had this kind of 'in-between' status, it was targeted as a 'client' or consumer part, but it has MSIX which make it almost like 8257[56]. Mike, there are some further 82574 changes to shared code that I'm looking into today. Jack On Tue, Nov 23, 2010 at 10:17 AM, Mike Tancsa wrote: > On 11/23/2010 12:39 PM, Sean Bruno wrote: > > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: > >> It looks like I'm unfortunate enough to have to deploy on a machine > >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which > > igb0@pci0:5:0:0: class=0x020000 card=0x8975152d chip=0x10c98086 > > Strange, the 82574 attaches as em for me, not igb > > em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected > ecap 0003[140] = Serial 1 001517ffffed68a4 > > Normally, its msix, but I had disabled that hoping it would fix the problem > > em1: port 0x2000-0x201f mem > 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at dev > ice 0.0 on pci10 > em1: Using an MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:15:17:ed:68:a4 > > > ---Mike > _______________________________________________ > 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 Tue Nov 23 18:40:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBDDB106564A; Tue, 23 Nov 2010 18:40:02 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5F68FC18; Tue, 23 Nov 2010 18:40:02 +0000 (UTC) Received: by pzk1 with SMTP id 1so2054873pzk.13 for ; Tue, 23 Nov 2010 10:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=bKThXwRcIjI9U4ZVubY5Z5fTcbTiSlNa2u5ftS3foBI=; b=fecahOTTQmDrp63es28nkpeQLqOVOp5NlqBf5S0ACBzD4fgLd/H13ppWCdMZBGrZf1 xzg1DPJXzl1v4OEzFApfsewHhCH2eF1E7LT1hU2CQg6wdm2wIGhehrAl+PeMChwROKEl zeYBbd/7wfNoLh9vbn0YaemahtjU1FHo36tjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Gqd0WrZEjU9OKHhsJocYXGj2wpkbOEVhK6iVy8tSlDuuX2sjnhTKSL58Id6L6qukqQ BiRGgjnkugECC78LhZIKnE/7CrTBz131nGYHgPujuH/ZPVVvBHZ8gpd43Wc/13PVnxBq CF1Z1OJ1n6YoJRfo0dNnyHjRUoH9CfinE8Er0= Received: by 10.229.212.5 with SMTP id gq5mr6451923qcb.275.1290535824986; Tue, 23 Nov 2010 10:10:24 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Tue, 23 Nov 2010 10:09:44 -0800 (PST) In-Reply-To: <1290533941.3173.50.camel@home-yahoo> References: <1290533941.3173.50.camel@home-yahoo> From: Ivan Voras Date: Tue, 23 Nov 2010 19:09:44 +0100 X-Google-Sender-Auth: afq36kFWTT-UtMtGgJSPQh7LCYs Message-ID: To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Nov 2010 18:40:03 -0000 On 23 November 2010 18:39, Sean Bruno wrote: > On Tue, 2010-11-23 at 04:47 -0800, Ivan Voras wrote: >> It looks like I'm unfortunate enough to have to deploy on a machine >> which has the 82574L Intel NIC chip on a Supermicro X8SIE-F board, which >> apparently has hardware issues, according to this thread: >> >> http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D2908463&gro= up_id=3D42302&atid=3D447449 >> >> One of the proposed workarounds is disabling "Active State Power >> Management" in the BIOS and in the OS. >> >> I have disabled it in BIOS but I don't know how to disable it in FreeBSD >> (apparently only disabling it in BIOS isn't enough). >> >> Any ideas on how to achieve the effect in FreeBSD? > Can I get an example pciconf -lv off of a couple of machines? =C2=A0I've = been > seeing some "issues" here at big purple that are similar. > igb0@pci0:5:0:0: =C2=A0 =C2=A0 =C2=A0 =C2=A0class=3D0x020000 card=3D0x897= 5152d chip=3D0x10c98086 > rev=3D0x01 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Intel Corporation' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D network > =C2=A0 =C2=A0subclass =C2=A0 =3D ethernet > igb1@pci0:5:0:1: =C2=A0 =C2=A0 =C2=A0 =C2=A0class=3D0x020000 card=3D0x897= 5152d chip=3D0x10c98086 > rev=3D0x01 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Intel Corporation' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D network > =C2=A0 =C2=A0subclass =C2=A0 =3D ethernet Not the same card, mine is on the em driver. http://permalink.gmane.org/gmane.os.freebsd.devel.hardware/7584 From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 19:01:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CEA8106566C for ; Tue, 23 Nov 2010 19:01:18 +0000 (UTC) (envelope-from jayb@zoe.braeburn.org) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7988FC14 for ; Tue, 23 Nov 2010 19:01:17 +0000 (UTC) X-VirusChecked: Checked X-Env-Sender: jayb@zoe.braeburn.org X-Msg-Ref: server-11.tower-120.messagelabs.com!1290537141!53630031!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 1861 invoked from network); 23 Nov 2010 18:32:22 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Nov 2010 18:32:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oANIWeZj021787 for ; Tue, 23 Nov 2010 13:32:40 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oANIWak4021711 for ; Tue, 23 Nov 2010 13:32:36 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oANIWGfk028371 for ; Tue, 23 Nov 2010 13:32:17 -0500 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oANIWFAo028357 for ; Tue, 23 Nov 2010 13:32:15 -0500 Received: by oz.mt.att.com (Postfix, from userid 500) id 0EE0F2BF2C; Tue, 23 Nov 2010 13:32:10 -0500 (EST) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19692.2216.189218.547298@oz.mt.att.com> Date: Tue, 23 Nov 2010 13:32:08 -0500 From: Jay Borkenhagen To: freebsd-net@freebsd.org In-Reply-To: References: <20101111212648.GF17566@michelle.cdnetworks.com> <20101112225320.GC22460@michelle.cdnetworks.com> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Sender: jayb@zoe.braeburn.org Cc: Jack Vogel Subject: Problem with em0 (was Re: Problem with re0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jay Borkenhagen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:01:18 -0000 Just a "me too" to echo Gabor's request for guidance for checking out and using new drivers from HEAD. In my case I'd like to try the new em(4) Jack's been talking about. I've been running FreeBSD machines for several years, but this is the first time I've found myself having driver problems On 21-Nov-2010, Gabor Radnai writes: > > Ok, please try latest re(4) in HEAD. > > I am noob with this, sorry. Could you please give guidance? > If I copy if_re.ko from snapshot image to /boot/kernel/ is it > sufficient or have to build a whole new kernel from HEAD source? Can > somehow just compile a new driver if copy does not work? > > Thanks. > _______________________________________________ From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 19:54:12 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9AF71065670 for ; Tue, 23 Nov 2010 19:54:12 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-3.mx.aerioconnect.net [216.240.47.63]) by mx1.freebsd.org (Postfix) with ESMTP id 984FA8FC08 for ; Tue, 23 Nov 2010 19:54:12 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oANJsA2K010961; Tue, 23 Nov 2010 11:54:10 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 62D532D6011; Tue, 23 Nov 2010 11:54:09 -0800 (PST) Message-ID: <4CEC1BF3.7020906@freebsd.org> Date: Tue, 23 Nov 2010 11:54:27 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: kalin m References: <4CEAF306.2090705@el.net> <4CEAFBF3.1040408@freebsd.org> <4CEB0226.1020407@el.net> <4CEB0DFA.4030500@freebsd.org> <4CEB15D7.6020303@el.net> <4CEB1C58.7070306@freebsd.org> <4CEB2385.1010300@el.net> <4CEB5625.7060601@freebsd.org> <4CEB6593.6010505@el.net> <4CEB6BF5.6080107@freebsd.org> <4CEB71C2.7090707@el.net> In-Reply-To: <4CEB71C2.7090707@el.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: card sleeping 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, 23 Nov 2010 19:54:12 -0000 >> >> please check the netmasks everywhere on the router, on the machine >> and on other local machines. > well... "the router" is a actually out of my reach. it's a fios set > up. the netmask for all the machines is 255.255.255.0 so the actual > router is somewhere in the building. i guess. we just got 13 ips > assigned to the office but it's not like a subnet set up. there is a > box in the office before the machines but my guess is it's not > really a router... i do not have access to it either. does this > make any sense? compare the output of arp -a in both states. (you can use a script to capture it while 'asleep') I see two possibilities: 1/ the 'box in the office' needs to be told about your machine or 2/ there is an arp/IP clash or netmask misconfiguration. what is the new IP address you are using (compared to to the old one). it's not .0 or .15 or anything silly right? > > > thanks again for sticking with this... > > From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 20:33:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A761106566B for ; Tue, 23 Nov 2010 20:33:43 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF918FC08 for ; Tue, 23 Nov 2010 20:33:42 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id E0B71BDC75 for ; Tue, 23 Nov 2010 12:33:41 -0800 (PST) To: freebsd-net@freebsd.org In-Reply-To: <20101123133820.GA36224@babolo.ru> Date: Tue, 23 Nov 2010 12:33:41 -0800 Message-ID: <45689.1290544421@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 20:33:43 -0000 In message <20101123133820.GA36224@babolo.ru>, Aleksandr A Babaylov <.@babolo.ru> wrote: >On Tue, Nov 23, 2010 at 04:35:42AM -0800, Ronald F. Guilmette wrote: >> I should say however that even this is going to produce a slightly sub-optim >al >> result, because (I guess) the DHCP client is _still_ going to wipe out my >> eisting /etc/resolve.con file and then write its own. Now that will at >> least have the proper IP address in it _however_ there does not seem to >> be any way to entice the DHCP client to place certain "options" into the >> /etc/resolv.conf file. That's a pity, because I wanted one in there. >> (Oh well, I guss I can append it from my /etc/rc.local file.) >Does >chflags schg /etc/resolve.conf >helps? Humm... I confess that I hadn't even considered trying that. Thanks for the suggestion! I'll try that out. From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 20:41:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6F0106566B for ; Tue, 23 Nov 2010 20:41:47 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 3FEE38FC20 for ; Tue, 23 Nov 2010 20:41:47 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id CAB9EBDC75 for ; Tue, 23 Nov 2010 12:41:46 -0800 (PST) To: freebsd-net@freebsd.org In-Reply-To: <20101123134254.GB36224@babolo.ru> Date: Tue, 23 Nov 2010 12:41:46 -0800 Message-ID: <45743.1290544906@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Re: Implementing a trivial TFTP client? 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, 23 Nov 2010 20:41:47 -0000 In message <20101123134254.GB36224@babolo.ru>, Aleksandr A Babaylov <.@babolo.ru> wrote: >rfg: >> My guess is that I'm doing multiple things in a substantially Wrong way. >> >> Any guidance would be appreciated. >Try >ktrace -i tftp >and look at >kdump >to see how it works Hay! Thanks for another great suggestion! I'm going to try that, just to see how a "normative" tftp client implementation does things, but actually, after I posted last night, I found the stupid programming error that was keeping my code from working (and now it is all working OK). Basically, in the tftp packet headers I had just forgotten to put the block number into proper network byte order. Once I fixed that silly programming error, my trivial tftp client worked perfectly. (You know, it's funny, I don't know what other people's experiences have been, but for me, in about 35 years of programming I've found that about 95% of all buugs in any code I've ever developed or worked on have been due to just silly small programming errors. It's very rare to see any program go haywire because of fundamental underlying conceptual problems. It's almost always just something small and silly.) Regards, rfg From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 20:52:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEEAF106566B for ; Tue, 23 Nov 2010 20:52:52 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id BDAE78FC1A for ; Tue, 23 Nov 2010 20:52:52 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 48169BDC75 for ; Tue, 23 Nov 2010 12:52:52 -0800 (PST) To: freebsd-net@freebsd.org In-Reply-To: <20101123155323.GA51348@laptop.levsha.me> Date: Tue, 23 Nov 2010 12:52:52 -0800 Message-ID: <45858.1290545572@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 20:52:52 -0000 In message <20101123155323.GA51348@laptop.levsha.me>, Mykola Dzham wrote: > Ronald F. Guilmette wrote: >> This is problematic for several reasons. First, as I have learned, >> having any interface set to "DHCP" in the /etc/rc.conf file causes >> all sorts of DHCP magic to happen at startup time, and the end result >> of all that magic is that two undesirable things happen: >> >> 1) The /etc/resolv.conf file gets replaced with something that >> causes DNS resolutions to go someplace other than where I want >> them to go, and... >> >> 2) the default route that I attempted to set in the /etc/rc.conf >> file gets clobbered and replaced by a default route obtained >> from the DHCP negotiation on the second interface. > >You can totally disable resolv.conf changing and rote setting: put into >/etc/dhclient-enter-hooks file this code: > >add_new_resolv_conf() { > echo "doing nothing to resolv.conf" >} > >add_new_routes() { > echo "do not set routes" >} Wow! This is _very_ interesting! How did you know to even suggest this? I mean are these things documented on some man page that I mised? Well, anyway, that first part sure sounds like a perfect fix for the first of the two issues I described. But as regards to that second part, maybe that's doing a but more than what I want. I don't want the DHCP stuff to set -no- routes at all... I still do want it to create a route to 192.168.1.0/24. I just don't want it make any change to the default route that would otherwise be set, you know, as a result of the defaultrouter= statement in my /etc/rc.conf file. So is there a nice clean & simple way to get the DHCP stuff to only create just that route to 192.168.1.0/24 , while leaving the default route alone? Regards, rfg P.S. Oh yea... and one other question... at the top of this new /etc/dhclient-enter-hooks file, should I be putting "#!/bin/sh" ? Is that OK? Is it needed? From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 21:07:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606FC106564A for ; Tue, 23 Nov 2010 21:07:53 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 41F8A8FC0A for ; Tue, 23 Nov 2010 21:07:52 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id B5299BDC75 for ; Tue, 23 Nov 2010 13:07:52 -0800 (PST) To: freebsd-net@freebsd.org In-Reply-To: Date: Tue, 23 Nov 2010 13:07:52 -0800 Message-ID: <46085.1290546472@tristatelogic.com> From: "Ronald F. Guilmette" Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:07:53 -0000 In message , Freddie Cash wrote: >On Tue, Nov 23, 2010 at 12:52 PM, Ronald F. Guilmette > wrote: >> I don't want the DHCP stuff to set -no- routes at all... I still do >> want it to create a route to 192.168.1.0/24. =C2=A0I just don't want it >> make any change to the default route that would otherwise be set, >> you know, as a result of the defaultrouter=3D statement in my /etc/rc.con= >f >> file. >> >> So is there a nice clean & simple way to get the DHCP stuff to only >> create just that route to 192.168.1.0/24 , while leaving the default >> route alone? > >dhclient doesn't set that route. The kernel's networking code >automatically creates a route for the subnet when you add the IP to >the interface. Ah! Yes! Right. The ifconfig. I forgot about that. Thanks. OK, so if I tell the DHCP stuff to set no routes, then the ifconfig will setup the route for 192.168.1.0/24 and all else will remain unmolested. That sounds perfect to me. Thanks. From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 21:21:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8A5410657C2 for ; Tue, 23 Nov 2010 21:21:59 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC5A8FC18 for ; Tue, 23 Nov 2010 21:21:58 +0000 (UTC) Received: from [95.135.77.208] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PL0JH-000CQP-1m for freebsd-net@freebsd.org; Tue, 23 Nov 2010 23:21:58 +0200 Received: from levsha by laptop.levsha.me with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PL0JB-0001vn-95 for freebsd-net@freebsd.org; Tue, 23 Nov 2010 23:21:49 +0200 Date: Tue, 23 Nov 2010 23:21:49 +0200 From: Mykola Dzham To: freebsd-net@freebsd.org Message-ID: <20101123212148.GB4910@laptop.levsha.me> References: <20101123155323.GA51348@laptop.levsha.me> <45858.1290545572@tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45858.1290545572@tristatelogic.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 95.135.77.208 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false X-Spam-Level: -- X-Spam-Report: 1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org. -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 1.3 AWL AWL: From: address is in the auto white-list Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:22:00 -0000 Ronald F. Guilmette wrote: > > In message <20101123155323.GA51348@laptop.levsha.me>, > Mykola Dzham wrote: > > > Ronald F. Guilmette wrote: > >> This is problematic for several reasons. First, as I have learned, > >> having any interface set to "DHCP" in the /etc/rc.conf file causes > >> all sorts of DHCP magic to happen at startup time, and the end result > >> of all that magic is that two undesirable things happen: > >> > >> 1) The /etc/resolv.conf file gets replaced with something that > >> causes DNS resolutions to go someplace other than where I want > >> them to go, and... > >> > >> 2) the default route that I attempted to set in the /etc/rc.conf > >> file gets clobbered and replaced by a default route obtained > >> from the DHCP negotiation on the second interface. > > > >You can totally disable resolv.conf changing and rote setting: put into > >/etc/dhclient-enter-hooks file this code: > > > >add_new_resolv_conf() { > > echo "doing nothing to resolv.conf" > >} > > > >add_new_routes() { > > echo "do not set routes" > >} > > Wow! This is _very_ interesting! How did you know to even suggest this? > I mean are these things documented on some man page that I mised? dhclient-enter-hooks referred in dhclient-script(8), functions add_new_resolv_conf() and add_new_routes() found on /sbin/dhclient-script (this is shell script) > Well, anyway, that first part sure sounds like a perfect fix for the > first of the two issues I described. But as regards to that second > part, maybe that's doing a but more than what I want. > > I don't want the DHCP stuff to set -no- routes at all... I still do > want it to create a route to 192.168.1.0/24. I just don't want it > make any change to the default route that would otherwise be set, > you know, as a result of the defaultrouter= statement in my /etc/rc.conf > file. 192.168.1.0/24 is interface route. This route installed by ifconfig. dhclient-script does not install this route manually. So, replacing add_new_routes() function not affect on 192.168.1.0/24 route. dhclient-enter-hooks file used only by /sbin/dhclient-script , and dhclient-script used only by dhclient. So, this is not affect to settings, set on /etc/rc.conf > So is there a nice clean & simple way to get the DHCP stuff to only > create just that route to 192.168.1.0/24 , while leaving the default > route alone? Can you try my variant? > P.S. Oh yea... and one other question... at the top of this new > /etc/dhclient-enter-hooks file, should I be putting "#!/bin/sh" ? > Is that OK? Is it needed? That is ok, but not needed: file sourced into /sbin/dhclient-script using ``.'' command -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 21:22:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1F2F106564A for ; Tue, 23 Nov 2010 21:22:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC2868FC0A for ; Tue, 23 Nov 2010 21:22:57 +0000 (UTC) Received: by gxk8 with SMTP id 8so181918gxk.13 for ; Tue, 23 Nov 2010 13:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DbEVcsrSHbUL1CWQOXN4siHKlNnLU27rdvYBRXXczQA=; b=FHyzr/ejvjXWpcVG5hnP+T1Hm1pm3/v9r9sNRFoWaIiHmwlhU0+eQ9GR9bQWy0JHTq FzCQmyaEnmSeARcSRPS1v8BZKCJRttF9xe4CvHWFe/Gtg5YNGIEOf6bdMAWLs9F5felK I+5eZtKFNWeoxp+pRS013p95yj63OUxvUptpc= 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=F7InK7bWBOUULLDXPN6105fMAdfD6Hg7OKSDZiadE2XaB8KIJFfPD4C5pwI+QaOuTf U/WihwZBFZz/hgduSTMUfTd26YWufEN+eeRORGD6i+mASrJ8Pl/KXZkFc5ZalUYqmABv g4LorD6VSl5m7GwyHGCHOx1Ukt/RjjMpgm7qw= MIME-Version: 1.0 Received: by 10.90.72.16 with SMTP id u16mr9253490aga.138.1290545860511; Tue, 23 Nov 2010 12:57:40 -0800 (PST) Received: by 10.90.211.7 with HTTP; Tue, 23 Nov 2010 12:57:40 -0800 (PST) In-Reply-To: <45858.1290545572@tristatelogic.com> References: <20101123155323.GA51348@laptop.levsha.me> <45858.1290545572@tristatelogic.com> Date: Tue, 23 Nov 2010 12:57:40 -0800 Message-ID: From: Freddie Cash To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:22:58 -0000 On Tue, Nov 23, 2010 at 12:52 PM, Ronald F. Guilmette wrote: > I don't want the DHCP stuff to set -no- routes at all... I still do > want it to create a route to 192.168.1.0/24. =C2=A0I just don't want it > make any change to the default route that would otherwise be set, > you know, as a result of the defaultrouter=3D statement in my /etc/rc.con= f > file. > > So is there a nice clean & simple way to get the DHCP stuff to only > create just that route to 192.168.1.0/24 , while leaving the default > route alone? dhclient doesn't set that route. The kernel's networking code automatically creates a route for the subnet when you add the IP to the interface. You can check this like so: ifconfig re0 172.20.0.1/24 netstat -rn Replace re0 with your interface. You'll notice that just by adding an IP with a subnet mask to an interface, you get a route for that subnet created. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 21:36:44 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7998D1065674 for ; Tue, 23 Nov 2010 21:36:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 016978FC18 for ; Tue, 23 Nov 2010 21:36:43 +0000 (UTC) Received: (qmail 21934 invoked by uid 399); 23 Nov 2010 21:36:43 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Nov 2010 21:36:43 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CEC33EA.8040004@FreeBSD.org> Date: Tue, 23 Nov 2010 13:36:42 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20101123155323.GA51348@laptop.levsha.me> <45858.1290545572@tristatelogic.com> <20101123212148.GB4910@laptop.levsha.me> In-Reply-To: <20101123212148.GB4910@laptop.levsha.me> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Configuring for 1 static and 1 DHCP interface ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:36:44 -0000 While hacking dhclient-script gets you '1337 points, it's generally a better idea to use dhclient.conf to accomplish the same goals whenever possible. It's also a really bad idea to chflags /etc/resolv.conf (note, it's resolv.conf, not resolve.conf) because that can cause dhclient-script to loop. Perhaps the OP can re-post a description of the problem they are trying to solve at a higher level, rather than focusing on the solutions? Doug From owner-freebsd-net@FreeBSD.ORG Wed Nov 24 13:50:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37EF510656BC for ; Wed, 24 Nov 2010 13:50:45 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 513F68FC19 for ; Wed, 24 Nov 2010 13:50:44 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E48B039825; Wed, 24 Nov 2010 15:50:41 +0200 (SAST) Date: Wed, 24 Nov 2010 15:50:41 +0200 From: John Hay To: Fabien Thomas Message-ID: <20101124135041.GA43753@zibbi.meraka.csir.co.za> References: <20101117070422.GA45678@cabstand.com> <4CE3D097.7030204@grosbein.pp.ru> <4CEB567C.9000906@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Vlad Galu , Jack Vogel , Eugene Grosbein Subject: Re: request for MFC of em/igb drivers 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, 24 Nov 2010 13:50:45 -0000 On Tue, Nov 23, 2010 at 09:41:49AM +0100, Fabien Thomas wrote: > That fix on ixgbe would also be great to commit on ixgbe before release. > This fix a crash on high packet load with bpf (mbuf freed behind bpf analysis). > A fix to ixgbe to fix ipv6 routing would also be great! :-) John > Fabien > > > > > > On 17.11.2010 23:39, Jack Vogel wrote: > >> Yes, everyone, I plan on updating all the drivers, there has been no > >> activity > >> because I've tracking down a couple bugs that are tough, involving days > >> of testing to reproduce. I know we're getting close and I appreciate any > >> reports like this before. > >> > >> Stay tuned.... > >> > >> Jack > > > > Thanks for response. Do you play to MFC fixes before 8.2-RELEASE? > > We are in PRERELEASE state already :-) > > _______________________________________________ > > 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 Nov 24 18:07:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 784101065673 for ; Wed, 24 Nov 2010 18:07:38 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 42B2F8FC19 for ; Wed, 24 Nov 2010 18:07:35 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 24 Nov 2010 12:52:32 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::518 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-net@freebsd.org X-SMFBL: ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc= Message-ID: <4CED50E0.7020205@comcast.net> Date: Wed, 24 Nov 2010 12:52:32 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101109 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org, User Questions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Brian A. Seklecki" Subject: Jail source address selection in 8.1-RELEASE 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, 24 Nov 2010 18:07:38 -0000 Hi, There appears to be a loosely documented sysctl 'security.jail.param.ip4.saddrsel' which should limit source IP selection of jails to their primary jail interface/IP. The sysctl does not appear to do anything, however: # sysctl security.jail.param.ip4.saddrsel=0 -> # echo $? 0 # sysctl security.jail.param.ip4.saddrsel # # sysctl -d security.jail.param.ip4.saddrsel security.jail.param.ip4.saddrsel: Do (not) use IPv4 source address selection rather than the primary jail IPv4 address. Is this tunable only available when VIMAGE jails are built? The 8.1-RELEASE Release Notes suggest it is for VIMAGE jail(8) containers, while 7.3-RELEASE Release Notes suggest that it is available for the entire jail(8) subsystem as 'security.jail.ip4_saddrsel', a different OID. FreeBSD xxxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Aug 3 16:24:09 EDT 2010 root@xxxx:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 00:28:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64BE106566C for ; Thu, 25 Nov 2010 00:28:39 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E9F238FC13 for ; Thu, 25 Nov 2010 00:28:38 +0000 (UTC) Received: by wwd20 with SMTP id 20so299435wwd.31 for ; Wed, 24 Nov 2010 16:28:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.143.9 with SMTP id k9mr3132826wej.64.1290643058764; Wed, 24 Nov 2010 15:57:38 -0800 (PST) Received: by 10.216.39.198 with HTTP; Wed, 24 Nov 2010 15:57:38 -0800 (PST) Date: Wed, 24 Nov 2010 13:57:38 -1000 Message-ID: From: David Cornejo To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: problem with hostapd 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, 25 Nov 2010 00:28:39 -0000 Hi, Today I updated a 9.0-CURRENT system acting as an access point and it stopped working. From a Windows 7 machine it complains that there is a network key mismatch. I've checked it, changed it, and still no dice. I took the debug output from hostapd and find two odd things: first there is a "frame too short for this IEEE 802.1X packet" message, and then I see "ioctl[SIOCS80211]: No such file or directory" messages. The rc.conf and hostapd.conf are copied direct from a similar device compiled in February which works fine. I also used the same wlan_* options from the earlier working version. Any ideas on what might have changed or how I can further debug? thanks, dave c hostapd.conf: interface=wlan0 driver=bsd logger_syslog=-1 logger_syslog_level=0 logger_stdout=-1 logger_stdout_level=0 dump_file=/tmp/hostapd.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=evilthings wpa=1 wpa_passphrase=goodthings wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP output from hostapd: [root@charlie] 133% hostapd -Kdd -P /var/run/hostapd.pid /etc/hostapd.conf Configuration file: /etc/hostapd.conf ctrl_interface_group=0 (from group name 'wheel') bsd_set_iface_flags: flags=0xffffffff BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits) Completing interface initialization Flushing old station entries bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 Deauthenticate all stations bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=2 bsd_set_privacy: enabled=0 bsd_set_key: alg=0 addr=0x0 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:00:00:00:00:00 key_idx=0 bsd_set_key: alg=0 addr=0x0 key_idx=1 set_tx=0 seq_len=0 key_len=0 bsd_del_key: addr=00:00:00:00:00:00 key_idx=1 bsd_set_key: alg=0 addr=0x0 key_idx=2 set_tx=0 seq_len=0 key_len=0 bsd_del_key: addr=00:00:00:00:00:00 key_idx=2 bsd_set_key: alg=0 addr=0x0 key_idx=3 set_tx=0 seq_len=0 key_len=0 bsd_del_key: addr=00:00:00:00:00:00 key_idx=3 bsd_get_ssid: ssid="evilthings" Using interface wlan0 with hwaddr 00:80:48:54:b9:da and ssid 'evilthings' Deriving WPA PSK based on passphrase SSID - hexdump_ascii(len=10): 65 76 69 6c 74 68 69 6e 67 73 evilthings PSK (ASCII passphrase) - hexdump_ascii(len=10): 67 6f 6f 64 74 68 69 6e 67 73 goodthings PSK (from passphrase) - hexdump(len=32): 83 db fa 65 f8 ed 74 40 a6 79 b8 c1 d7 6d a5 a7 07 4d b4 71 44 c5 e2 3e c5 bc 76 63 79 ab 13 d6 bsd_set_ieee8021x: enabled=1 WPA: group state machine entering state GTK_INIT (VLAN-ID 0) GMK - hexdump(len=32): 32 78 22 93 ba 57 ca 6d fb e1 6f dd 30 9c 8d 7e 04 04 98 bb 27 7d db 17 47 a8 d7 1b 86 11 7b 30 GTK - hexdump(len=32): fa 33 d0 55 64 e2 00 e5 56 4c 36 0a 94 61 4d 96 0f fd 09 ba ac 96 0c 1d 1f 3a 9b 12 ed db 65 40 WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) bsd_set_key: alg=2 addr=0x0 key_idx=1 set_tx=1 seq_len=0 key_len=32 bsd_set_privacy: enabled=1 bsd_set_opt_ie: set WPA+RSN ie (len 24) bsd_set_iface_flags: flags=0x1 wlan0: Setup of interface done. Discard routing message to if#0 (not for us 9) wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated STA included WPA IE in (Re)AssocReq New STA wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:21:6a:a9:5e:90 reason 2 bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 ioctl[SIOCS80211]: No such file or directory bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 ioctl[SIOCS80211]: No such file or directory wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local deauth request wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated Disassociation notification for unknown STA 00:21:6a:a9:5e:90 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated STA included WPA IE in (Re)AssocReq New STA wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:21:6a:a9:5e:90 reason 2 bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 ioctl[SIOCS80211]: No such file or directory bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 ioctl[SIOCS80211]: No such file or directory wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local deauth request wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated Disassociation notification for unknown STA 00:21:6a:a9:5e:90 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated STA included WPA IE in (Re)AssocReq New STA wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:21:6a:a9:5e:90 reason 2 bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 ioctl[SIOCS80211]: No such file or directory bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 ioctl[SIOCS80211]: No such file or directory wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local deauth request wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated Disassociation notification for unknown STA 00:21:6a:a9:5e:90 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated STA included WPA IE in (Re)AssocReq New STA wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:21:6a:a9:5e:90 reason 2 bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 ioctl[SIOCS80211]: No such file or directory bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 ioctl[SIOCS80211]: No such file or directory wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local deauth request wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated Disassociation notification for unknown STA 00:21:6a:a9:5e:90 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated STA included WPA IE in (Re)AssocReq New STA wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0) TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b6 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 IEEE 802.1X: version=0 type=128 length=18516 frame too short for this IEEE 802.1X packet wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:21:6a:a9:5e:90 reason 2 bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 ioctl[SIOCS80211]: No such file or directory bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 ioctl[SIOCS80211]: No such file or directory wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local deauth request wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated Disassociation notification for unknown STA 00:21:6a:a9:5e:90 ^CSignal 2 received - terminating Flushing old station entries bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 Deauthenticate all stations bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=2 bsd_set_privacy: enabled=0 bsd_set_opt_ie: set WPA+RSN ie (len 0) bsd_set_ieee8021x: enabled=0 bsd_set_iface_flags: flags=0xffffffff From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 03:20:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC357106566C for ; Thu, 25 Nov 2010 03:20:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E48DC8FC18 for ; Thu, 25 Nov 2010 03:20:53 +0000 (UTC) Received: by wwd20 with SMTP id 20so417138wwd.31 for ; Wed, 24 Nov 2010 19:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WNDdDQJ/Yvs4VCThrgIBgla/aNw2cHt3IWfinkndQgc=; b=ZGJMFRLmgDqi4TeuqEEH+/YCG9Mva77hC+Htc1idq17nTZN5pr9xPf0OAtAcmCcugT 5KL5a6jBblhluQuWNllm7xRudlANjGUBT7J8Fv9la+xMlgJrRG1/18+HYayLFvH34A9x SfXZJfKrTQ9VBnyt+1NMd/VbXfCO1fNVm4FL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=c5jIqxuEfC82Ja/BgywjtVJyr62UJYMJPIIWp4qAi70Kj+f6SRqQwZMBrJBb5ZJdnp qD2w0zNjqBImzOtxPoCqq7piawfa+TUliGmKnpgqrgglaMXJxfc6GOmAhevovVjw0+tE Mn1+b7x7munRlYcpQbzMQ8mAFNVZdBP8QpH1Q= MIME-Version: 1.0 Received: by 10.216.51.21 with SMTP id a21mr166238wec.50.1290655251022; Wed, 24 Nov 2010 19:20:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Wed, 24 Nov 2010 19:20:50 -0800 (PST) In-Reply-To: References: Date: Thu, 25 Nov 2010 11:20:50 +0800 X-Google-Sender-Auth: 8ARNcu24-iIU7nfUk0j0Z5cU-IQ Message-ID: From: Adrian Chadd To: David Cornejo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: problem with hostapd 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, 25 Nov 2010 03:20:54 -0000 Hi, Would you please try -head just before rui committed his wpa/hostapd update and report back to -net and Rui directly? I saw some hostapd broken-ness when I tried -head last week but i haven't had time to dig up details for Rui. It seems you just have. :-) Thanks! ADrian On 25 November 2010 07:57, David Cornejo wrote: > Hi, > > Today I updated a 9.0-CURRENT system acting as an access point and it > stopped working. =A0From a Windows 7 machine it complains that there is a > network key mismatch. =A0I've checked it, changed it, and still no dice. = =A0I > took the debug output from hostapd and find two odd things: =A0first ther= e is > a "frame too short for this IEEE 802.1X packet" message, and then I see > "ioctl[SIOCS80211]: No such file or directory" messages. =A0The rc.conf a= nd > hostapd.conf are copied direct from a similar device compiled in February > which works fine. =A0I also used the same wlan_* options from the earlier > working version. > > Any ideas on what might have changed or how I can further debug? > > thanks, > dave c > > > hostapd.conf: > > interface=3Dwlan0 > driver=3Dbsd > logger_syslog=3D-1 > logger_syslog_level=3D0 > logger_stdout=3D-1 > logger_stdout_level=3D0 > dump_file=3D/tmp/hostapd.dump > ctrl_interface=3D/var/run/hostapd > ctrl_interface_group=3Dwheel > ssid=3Devilthings > wpa=3D1 > wpa_passphrase=3Dgoodthings > wpa_key_mgmt=3DWPA-PSK > wpa_pairwise=3DTKIP > > output from hostapd: > > [root@charlie] 133% hostapd -Kdd -P /var/run/hostapd.pid /etc/hostapd.con= f > Configuration file: /etc/hostapd.conf > ctrl_interface_group=3D0 (from group name 'wheel') > bsd_set_iface_flags: flags=3D0xffffffff > > BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits) > Completing interface initialization > Flushing old station entries > bsd_sta_deauth: addr=3Dff:ff:ff:ff:ff:ff reason_code=3D3 > > Deauthenticate all stations > bsd_sta_deauth: addr=3Dff:ff:ff:ff:ff:ff reason_code=3D2 > > bsd_set_privacy: enabled=3D0 > > bsd_set_key: alg=3D0 addr=3D0x0 key_idx=3D0 set_tx=3D1 seq_len=3D0 key_le= n=3D0 > bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D0 > > bsd_set_key: alg=3D0 addr=3D0x0 key_idx=3D1 set_tx=3D0 seq_len=3D0 key_le= n=3D0 > bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D1 > > bsd_set_key: alg=3D0 addr=3D0x0 key_idx=3D2 set_tx=3D0 seq_len=3D0 key_le= n=3D0 > bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D2 > > bsd_set_key: alg=3D0 addr=3D0x0 key_idx=3D3 set_tx=3D0 seq_len=3D0 key_le= n=3D0 > bsd_del_key: addr=3D00:00:00:00:00:00 key_idx=3D3 > > bsd_get_ssid: ssid=3D"evilthings" > > Using interface wlan0 with hwaddr 00:80:48:54:b9:da and ssid 'evilthings' > Deriving WPA PSK based on passphrase > SSID - hexdump_ascii(len=3D10): > =A0 =A0 65 76 69 6c 74 68 69 6e 67 73 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 evilthings > PSK (ASCII passphrase) - hexdump_ascii(len=3D10): > =A0 =A0 67 6f 6f 64 74 68 69 6e 67 73 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 goodthings > PSK (from passphrase) - hexdump(len=3D32): 83 db fa 65 f8 ed 74 40 a6 79 = b8 c1 > d7 6d a5 a7 07 4d b4 71 44 c5 e2 3e c5 bc 76 63 79 ab 13 d6 > bsd_set_ieee8021x: enabled=3D1 > > WPA: group state machine entering state GTK_INIT (VLAN-ID 0) > GMK - hexdump(len=3D32): 32 78 22 93 ba 57 ca 6d fb e1 6f dd 30 9c 8d 7e = 04 04 > 98 bb 27 7d db 17 47 a8 d7 1b 86 11 7b 30 > GTK - hexdump(len=3D32): fa 33 d0 55 64 e2 00 e5 56 4c 36 0a 94 61 4d 96 = 0f fd > 09 ba ac 96 0c 1d 1f 3a 9b 12 ed db 65 40 > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > bsd_set_key: alg=3D2 addr=3D0x0 key_idx=3D1 set_tx=3D1 seq_len=3D0 key_le= n=3D32 > bsd_set_privacy: enabled=3D1 > > bsd_set_opt_ie: set WPA+RSN ie (len 24) > > bsd_set_iface_flags: flags=3D0x1 > > wlan0: Setup of interface done. > Discard routing message to if#0 (not for us 9) > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > STA included WPA IE in (Re)AssocReq > =A0New STA > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > 00:21:6a:a9:5e:90 reason 2 > bsd_sta_deauth: addr=3D00:21:6a:a9:5e:90 reason_code=3D2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > ioctl[SIOCS80211]: No such file or directory > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > ioctl[SIOCS80211]: No such file or directory > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > deauth request > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > STA included WPA IE in (Re)AssocReq > =A0New STA > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > 00:21:6a:a9:5e:90 reason 2 > bsd_sta_deauth: addr=3D00:21:6a:a9:5e:90 reason_code=3D2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > ioctl[SIOCS80211]: No such file or directory > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > ioctl[SIOCS80211]: No such file or directory > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > deauth request > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > STA included WPA IE in (Re)AssocReq > =A0New STA > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > 00:21:6a:a9:5e:90 reason 2 > bsd_sta_deauth: addr=3D00:21:6a:a9:5e:90 reason_code=3D2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > ioctl[SIOCS80211]: No such file or directory > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > ioctl[SIOCS80211]: No such file or directory > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > deauth request > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > STA included WPA IE in (Re)AssocReq > =A0New STA > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > 00:21:6a:a9:5e:90 reason 2 > bsd_sta_deauth: addr=3D00:21:6a:a9:5e:90 reason_code=3D2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > ioctl[SIOCS80211]: No such file or directory > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > ioctl[SIOCS80211]: No such file or directory > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > deauth request > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > STA included WPA IE in (Re)AssocReq > =A0New STA > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > WPA: Send EAPOL(version=3D1 secure=3D0 mic=3D0 ack=3D1 install=3D0 pairwi= se=3D8 > kde_len=3D0 keyidx=3D0 encr=3D0) > TX EAPOL - hexdump(len=3D113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e = 02 03 > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a b= 6 > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0= 0 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > =A0 IEEE 802.1X: version=3D0 type=3D128 length=3D18516 > =A0 frame too short for this IEEE 802.1X packet > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > 00:21:6a:a9:5e:90 reason 2 > bsd_sta_deauth: addr=3D00:21:6a:a9:5e:90 reason_code=3D2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > bsd_set_key: alg=3D0 addr=3D0x2845b308 key_idx=3D0 set_tx=3D1 seq_len=3D0= key_len=3D0 > bsd_del_key: addr=3D00:21:6a:a9:5e:90 key_idx=3D0 > > ioctl[SIOCS80211]: No such file or directory > bsd_set_sta_authorized: addr=3D00:21:6a:a9:5e:90 authorized=3D0 > > ioctl[SIOCS80211]: No such file or directory > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > deauth request > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > ^CSignal 2 received - terminating > Flushing old station entries > bsd_sta_deauth: addr=3Dff:ff:ff:ff:ff:ff reason_code=3D3 > > Deauthenticate all stations > bsd_sta_deauth: addr=3Dff:ff:ff:ff:ff:ff reason_code=3D2 > > bsd_set_privacy: enabled=3D0 > > bsd_set_opt_ie: set WPA+RSN ie (len 0) > > bsd_set_ieee8021x: enabled=3D0 > > bsd_set_iface_flags: flags=3D0xffffffff > _______________________________________________ > 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 Nov 25 05:29:49 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7E651065674 for ; Thu, 25 Nov 2010 05:29:49 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2598FC14 for ; Thu, 25 Nov 2010 05:29:48 +0000 (UTC) Received: by wwd20 with SMTP id 20so495089wwd.31 for ; Wed, 24 Nov 2010 21:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.35.83 with SMTP id t61mr6376606wea.1.1290662985076; Wed, 24 Nov 2010 21:29:45 -0800 (PST) Received: by 10.216.39.198 with HTTP; Wed, 24 Nov 2010 21:29:45 -0800 (PST) In-Reply-To: References: Date: Wed, 24 Nov 2010 19:29:45 -1000 Message-ID: From: David Cornejo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: problem with hostapd 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, 25 Nov 2010 05:29:49 -0000 are you referring to rev 214734 on Nov 3rd? may not be able to get to the hardware to test until Monday though thanks! On Wed, Nov 24, 2010 at 5:20 PM, Adrian Chadd wrote: > Hi, > > Would you please try -head just before rui committed his wpa/hostapd > update and report back to -net and Rui directly? > > I saw some hostapd broken-ness when I tried -head last week but i > haven't had time to dig up details for Rui. It seems you just have. > :-) > > Thanks! > > > ADrian > > > > On 25 November 2010 07:57, David Cornejo wrote: > > Hi, > > > > Today I updated a 9.0-CURRENT system acting as an access point and it > > stopped working. From a Windows 7 machine it complains that there is a > > network key mismatch. I've checked it, changed it, and still no dice. I > > took the debug output from hostapd and find two odd things: first there > is > > a "frame too short for this IEEE 802.1X packet" message, and then I see > > "ioctl[SIOCS80211]: No such file or directory" messages. The rc.conf and > > hostapd.conf are copied direct from a similar device compiled in February > > which works fine. I also used the same wlan_* options from the earlier > > working version. > > > > Any ideas on what might have changed or how I can further debug? > > > > thanks, > > dave c > > > > > > hostapd.conf: > > > > interface=wlan0 > > driver=bsd > > logger_syslog=-1 > > logger_syslog_level=0 > > logger_stdout=-1 > > logger_stdout_level=0 > > dump_file=/tmp/hostapd.dump > > ctrl_interface=/var/run/hostapd > > ctrl_interface_group=wheel > > ssid=evilthings > > wpa=1 > > wpa_passphrase=goodthings > > wpa_key_mgmt=WPA-PSK > > wpa_pairwise=TKIP > > > > output from hostapd: > > > > [root@charlie] 133% hostapd -Kdd -P /var/run/hostapd.pid > /etc/hostapd.conf > > Configuration file: /etc/hostapd.conf > > ctrl_interface_group=0 (from group name 'wheel') > > bsd_set_iface_flags: flags=0xffffffff > > > > BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits) > > Completing interface initialization > > Flushing old station entries > > bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 > > > > Deauthenticate all stations > > bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=2 > > > > bsd_set_privacy: enabled=0 > > > > bsd_set_key: alg=0 addr=0x0 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:00:00:00:00:00 key_idx=0 > > > > bsd_set_key: alg=0 addr=0x0 key_idx=1 set_tx=0 seq_len=0 key_len=0 > > bsd_del_key: addr=00:00:00:00:00:00 key_idx=1 > > > > bsd_set_key: alg=0 addr=0x0 key_idx=2 set_tx=0 seq_len=0 key_len=0 > > bsd_del_key: addr=00:00:00:00:00:00 key_idx=2 > > > > bsd_set_key: alg=0 addr=0x0 key_idx=3 set_tx=0 seq_len=0 key_len=0 > > bsd_del_key: addr=00:00:00:00:00:00 key_idx=3 > > > > bsd_get_ssid: ssid="evilthings" > > > > Using interface wlan0 with hwaddr 00:80:48:54:b9:da and ssid 'evilthings' > > Deriving WPA PSK based on passphrase > > SSID - hexdump_ascii(len=10): > > 65 76 69 6c 74 68 69 6e 67 73 evilthings > > PSK (ASCII passphrase) - hexdump_ascii(len=10): > > 67 6f 6f 64 74 68 69 6e 67 73 goodthings > > PSK (from passphrase) - hexdump(len=32): 83 db fa 65 f8 ed 74 40 a6 79 b8 > c1 > > d7 6d a5 a7 07 4d b4 71 44 c5 e2 3e c5 bc 76 63 79 ab 13 d6 > > bsd_set_ieee8021x: enabled=1 > > > > WPA: group state machine entering state GTK_INIT (VLAN-ID 0) > > GMK - hexdump(len=32): 32 78 22 93 ba 57 ca 6d fb e1 6f dd 30 9c 8d 7e 04 > 04 > > 98 bb 27 7d db 17 47 a8 d7 1b 86 11 7b 30 > > GTK - hexdump(len=32): fa 33 d0 55 64 e2 00 e5 56 4c 36 0a 94 61 4d 96 0f > fd > > 09 ba ac 96 0c 1d 1f 3a 9b 12 ed db 65 40 > > WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0) > > bsd_set_key: alg=2 addr=0x0 key_idx=1 set_tx=1 seq_len=0 key_len=32 > > bsd_set_privacy: enabled=1 > > > > bsd_set_opt_ie: set WPA+RSN ie (len 24) > > > > bsd_set_iface_flags: flags=0x1 > > > > wlan0: Setup of interface done. > > Discard routing message to if#0 (not for us 9) > > > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > > STA included WPA IE in (Re)AssocReq > > New STA > > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > > 00:21:6a:a9:5e:90 reason 2 > > bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 > > > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > ioctl[SIOCS80211]: No such file or directory > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > ioctl[SIOCS80211]: No such file or directory > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > > deauth request > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > > STA included WPA IE in (Re)AssocReq > > New STA > > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > > 00:21:6a:a9:5e:90 reason 2 > > bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 > > > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > ioctl[SIOCS80211]: No such file or directory > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > ioctl[SIOCS80211]: No such file or directory > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > > deauth request > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > > STA included WPA IE in (Re)AssocReq > > New STA > > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > > 00:21:6a:a9:5e:90 reason 2 > > bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 > > > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > ioctl[SIOCS80211]: No such file or directory > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > ioctl[SIOCS80211]: No such file or directory > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > > deauth request > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > > STA included WPA IE in (Re)AssocReq > > New STA > > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > > 00:21:6a:a9:5e:90 reason 2 > > bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 > > > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > ioctl[SIOCS80211]: No such file or directory > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > ioctl[SIOCS80211]: No such file or directory > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > > deauth request > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: associated > > STA included WPA IE in (Re)AssocReq > > New STA > > wlan0: STA 00:21:6a:a9:5e:90 WPA: event 1 notification > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 WPA: start authentication > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > WPA: 00:21:6a:a9:5e:90 WPA_PTK_GROUP entering state IDLE > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state AUTHENTICATION2 > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITPSK > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 02 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 03 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > wlan0: STA 00:21:6a:a9:5e:90 WPA: sending 1/4 msg of 4-Way Handshake > > WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8 > > kde_len=0 keyidx=0 encr=0) > > TX EAPOL - hexdump(len=113): 00 21 6a a9 5e 90 00 80 48 54 b9 da 88 8e 02 > 03 > > 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 04 6e 23 b1 b1 69 6f bc 93 4a > b6 > > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > IEEE 802.1X: 139 bytes from 00:21:6a:a9:5e:90 > > IEEE 802.1X: version=0 type=128 length=18516 > > frame too short for this IEEE 802.1X packet > > wlan0: STA 00:21:6a:a9:5e:90 WPA: EAPOL-Key timeout > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state PTKSTART > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECT > > hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA > > 00:21:6a:a9:5e:90 reason 2 > > bsd_sta_deauth: addr=00:21:6a:a9:5e:90 reason_code=2 > > > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state DISCONNECTED > > WPA: 00:21:6a:a9:5e:90 WPA_PTK entering state INITIALIZE > > bsd_set_key: alg=0 addr=0x2845b308 key_idx=0 set_tx=1 seq_len=0 key_len=0 > > bsd_del_key: addr=00:21:6a:a9:5e:90 key_idx=0 > > > > ioctl[SIOCS80211]: No such file or directory > > bsd_set_sta_authorized: addr=00:21:6a:a9:5e:90 authorized=0 > > > > ioctl[SIOCS80211]: No such file or directory > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.1X: unauthorizing port > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: deauthenticated due to local > > deauth request > > wlan0: STA 00:21:6a:a9:5e:90 IEEE 802.11: disassociated > > Disassociation notification for unknown STA 00:21:6a:a9:5e:90 > > ^CSignal 2 received - terminating > > Flushing old station entries > > bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 > > > > Deauthenticate all stations > > bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=2 > > > > bsd_set_privacy: enabled=0 > > > > bsd_set_opt_ie: set WPA+RSN ie (len 0) > > > > bsd_set_ieee8021x: enabled=0 > > > > bsd_set_iface_flags: flags=0xffffffff > > _______________________________________________ > > 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 Nov 25 09:05:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08672106566C for ; Thu, 25 Nov 2010 09:05:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1895B8FC16 for ; Thu, 25 Nov 2010 09:05:43 +0000 (UTC) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAP4shX6007996 for ; Thu, 25 Nov 2010 15:54:46 +1100 Received: from c122-106-145-124.carlnfd1.nsw.optusnet.com.au (c122-106-145-124.carlnfd1.nsw.optusnet.com.au [122.106.145.124]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAP4sRMp024817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Nov 2010 15:54:29 +1100 Date: Thu, 25 Nov 2010 15:54:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Claudio Jeker In-Reply-To: <20101123151153.GB27694@diehard.n-r-g.com> Message-ID: <20101125150444.D1713@besplex.bde.org> References: <4CEBBB8F.70400@sentex.net> <20101123151153.GB27694@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 25 Nov 2010 09:05:45 -0000 On Tue, 23 Nov 2010, Claudio Jeker wrote: > On Tue, Nov 23, 2010 at 02:16:35PM +0100, Ivan Voras wrote: >> >> One other thing, I don't know if this is normal as I've only just >> noticed it: flood-pinging a machine (also a FreeBSD machine, on the >> same switch) and monitoring the packet rates with netstat I see that >> the rates begin at something like 8,000 PPS (in either direction) >> and then slowly over a timespan of 5-10 minutes climb to 100,000 PPS >> (again, in either direction). >> >> Since this is gigabit LAN with a Cisco switch, I'd say the 100,000 >> PPS should be correct. The other machine I'm pinging also has an em >> card but a "desktop class" one. Is this slow-start expected / >> normal? > > Yes, this is how ping -f works. ping -f sends a packet whenever it received > a response or when a timer fired (IIRC that one is set to 1ms). So ping -f > will not ramp up if the delay is smaller then the internal timer and hover > around 1/delay pps until packet loss or bigger delays happen. Yes, this is normal. It is how ping -f doesn't work -- it doesn't do anything resembling flooding, except possibly accidentally when 1 Mbps ethernet was fast. The ramping up is also accidental. The ping -f timeout is 10 msec (actually more, due to timer granularity). That was a lot even when 1Mbps ethernet was fast (since the theoretical max packet rate for 1 MBps ethernet is about 1.5Kpps, and the timeout only gives 100 pps), but when 1 MPbps was fast CPUs were slow so even 100 pps may have been fast for them). Now, 10 msec is a long time, and can even be beaten using the non-flood option "-i 0.001". This gives a timeout of 1 msec (actually more, due to timeout granularity, and considerably more if the timeout granularity is 10 msec as it should be). 1 msec is also a long time, but the -i arg is bogusly limited for non-root to that (such limits give don't even defend agains denial of service attacks, since without other limits anyone that can can execute ping can easily excecute ping -c1 in a shell loop much faster than once per millisecond, excepf of course when 1 Mbps ethernet was fast, and the execs for this give a better local denial of service that ping -i. So, even if the timeout granularity is preposterously smaller than 1 msec, you have to be root to get a flood ping using ping -i. For root, you just need to configure HZ to be about twice as large as the reciprical of the desired flood rate and have enough CPU to handle the timeouts from this (not easy to do for 1 GBps ethernet since this requires HZ to be about 3 million to test the limits). The ramping up occurs due to interaction of various layers of buffering and delays. em is especially predictable since its interrupt moderation is normally configured to give interrupts at 8 KHz. This tends to give an initial "flood" ping packet rate of 8 Kpps. There is initially no flooding at all, but just packets coming back at a rate of 8 Kpps, after each is delayed by precisely 125 usec by the interrupt moderation, as needed to give this rate. But occasionally, due to unrelated network activity affecting the timing, or just due to ping sending an extra packet every 100 msec and this packet happening to be delivered with another packet (which would have a low probablilty without the interrupt moderation, but is likely after just a few seconds or minutes with the interrupt moderation), packets will come back in "bursts". It takes a burst length of just 2 to double the packet rate from 8 Kpps to 16 Kpps. The interrupt moderation delivers 2 packets in these small bursts and ping responds by sending out the next 2 packets in a burst of the same length. These tend to come back (after interrupt moderation) in another burst of the same length. The burst length increases with time until something saturates, unless unrelated network or CPU activity prevents processing of the established bursts fast enough to satisfy the established burst timing,. All this has very little to do with the max packet rate. With one of my bge NICs, saturation occurs at about 100Kpps although the network can do 600Kpps. ping -f works better for determining network latency, but could be improved for that too, e.g., by not sending anything the packet every 100 msec if something came back, and doing other things to prevent bursts). Bruce From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 12:32:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745111065694 for ; Thu, 25 Nov 2010 12:32:26 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 26B8B8FC1C for ; Thu, 25 Nov 2010 12:32:25 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PLazw-0006Yh-9v for freebsd-net@freebsd.org; Thu, 25 Nov 2010 13:32:24 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Nov 2010 13:32:24 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Nov 2010 13:32:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 25 Nov 2010 13:32:18 +0100 Lines: 12 Message-ID: References: <4CEBBB8F.70400@sentex.net> <20101123151153.GB27694@diehard.n-r-g.com> <20101125150444.D1713@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20101125150444.D1713@besplex.bde.org> X-Enigmail-Version: 1.1.2 Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 25 Nov 2010 12:32:26 -0000 On 11/25/10 05:54, Bruce Evans wrote: > Yes, this is normal. It is how ping -f doesn't work -- it doesn't do > anything > resembling flooding, except possibly accidentally when 1 Mbps ethernet was > fast. The ramping up is also accidental. > ... Thank you, that was a very informative explanation! So in case I really do want to flood ping or in some other way test PPS throughput, are there any convenient tools for that? From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 13:22:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 329001065670; Thu, 25 Nov 2010 13:22:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id C2B868FC12; Thu, 25 Nov 2010 13:22:52 +0000 (UTC) Received: from c122-106-145-124.carlnfd1.nsw.optusnet.com.au (c122-106-145-124.carlnfd1.nsw.optusnet.com.au [122.106.145.124]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oAPDMnOH022253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Nov 2010 00:22:50 +1100 Date: Fri, 26 Nov 2010 00:22:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ivan Voras In-Reply-To: Message-ID: <20101125234706.O3121@besplex.bde.org> References: <4CEBBB8F.70400@sentex.net> <20101123151153.GB27694@diehard.n-r-g.com> <20101125150444.D1713@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 25 Nov 2010 13:22:53 -0000 On Thu, 25 Nov 2010, Ivan Voras wrote: > On 11/25/10 05:54, Bruce Evans wrote: > >> Yes, this is normal. It is how ping -f doesn't work -- it doesn't do >> anything >> resembling flooding, except possibly accidentally when 1 Mbps ethernet was >> fast. The ramping up is also accidental. >> ... > > Thank you, that was a very informative explanation! > > So in case I really do want to flood ping or in some other way test PPS > throughput, are there any convenient tools for that? netrate (netsend/netblast) is almost adequate. I normally use a 1990ish version of ttcp with iny modifications. It is also almost adequate. A problem with all of these is that that cannot do the right thing when the send queue fills up. send() should then return ENOBUFS. Userland then has the following bad options to handle this: - loop calling send(). Takes 100% of 1 CPU and may consume time needed for productive i/o - try using blocking mode and select(), and usually discover that select() doesn't work for for handling ENOBUFS. Maybe it is the blocking mode that doesn't work. I think the FreeBSD kernel can't easily tell if it should block because the driver would return ENOBUFS. Userland has even less chance of telling if it should not try to send() because the i/o would either block or fail with ENOBUFS - try to predict when send() will not block due to ENOBUFS, and wait until then non-busily using sleep(). Old ttcp does essentially this, and does it very badly -- it uses a very long hard-coded sleep time that may have worked when 1 Mbps ethernet was fast, but is now not so good. Newer ttcps try harder using shorter sleeps, but still tend to fail due to the sleep granularity being large. Send buffer queue lengths for 1 Gbps ethernet are typically 1024 packets, so the whole buffer can be drained in less than 1 msec and the sleep granularity needs to be considerably less than 1 msec to keep up, but this is unreasonably short. I avoid this problem using very large queue length (~10000, so that the sleeps for 10 msec in old ttcp can keep up (also depends on my NIC not draining as fast as theoretically possible, else I would need a queue length of 40000)). netsend also uses sleeps to control its rate, and cannot work very well due to sleep granularity. The limits for input are easier to test, once you can generate floods from somewhere, since the ENOBUFS problem corresponds to saturation/dropping packets/flow control, so when you hit it you know that you are at the limit. sam@ implemented or ported kttcp (kernel ttcp) which reduces at least the network stack overheads for sending packets, so the limits are closer to the driver and/or network. I have't got around to trying it. I don't know how it handlers ENOBUFS. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 17:10:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 965E7106566B for ; Thu, 25 Nov 2010 17:10:07 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 12E7F8FC15 for ; Thu, 25 Nov 2010 17:10:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PLfKe-00038v-HM for freebsd-net@freebsd.org; Thu, 25 Nov 2010 18:10:04 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Nov 2010 18:10:04 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Nov 2010 18:10:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 25 Nov 2010 18:09:59 +0100 Lines: 46 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 X-Enigmail-Version: 1.1.2 Subject: ab: No buffer space available 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, 25 Nov 2010 17:10:07 -0000 "ab" is "apache benchmark", a trivial tool for testing web servers: > ab -n 100000 -c 10 http://localhost/file This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 10000 requests Send request failed! socket: No buffer space available (55) Total of 16479 requests completed Each request "ab" makes is a full TCP connection and HTTP "GET" request, a round-trip over localhost. The "file" is a static local file, fully cached, probably mmaped by Apache and ready to be served in any case. When I force "ab" to reuse connections (keepalive), the test finishes cleanly (with ~~ 19,000 RPS). The fact that it doesn't finish when always establishing new connections looks a bit strange. After digging around it looked like it's not about buffer space but maybe about ephemaral port exhaustion. If I set net.inet.ip.portrange.hifirst to 10,000 the ab tool proceeds to more requests (25,635) before it fails. This is more than before but still not the 65535-10000=55535 requests I'd expect if that theory was true. I have also disabled net.inet.ip.portrange.randomized but without effect. This number (25,000) looked suspiciously like kern.ipc.maxsockets so I've increased that to 60,000 and ab made more requests (~~57,000) before dieing from "apr_socket_connect(): Can't assign requested address". All this kind of makes sense but: 1) Why is this an issue at all? Since concurrency is 10, this means that ab establishes at most 10 concurrent TCP sessions, not tens of thousands of them (as far as I can tell, this is true judging from the number of active web server threads). 2) In the context of #1, why does the performance goes down as more requests are made? 3) What is the next barrier? After the test is run I see a lot of connections in netstat in LAST_ACK state - how do I reduce those? From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 18:00:26 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B883B106564A for ; Thu, 25 Nov 2010 18:00:26 +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 8C0F98FC14 for ; Thu, 25 Nov 2010 18:00:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAPI0QQU071840 for ; Thu, 25 Nov 2010 18:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAPI0QVV071815; Thu, 25 Nov 2010 18:00:26 GMT (envelope-from gnats) Date: Thu, 25 Nov 2010 18:00:26 GMT Message-Id: <201011251800.oAPI0QVV071815@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pawel Tyll Cc: Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel Tyll List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 18:00:26 -0000 The following reply was made to PR kern/152360; it has been noted by GNATS. From: Pawel Tyll To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. Date: Thu, 25 Nov 2010 18:40:16 +0100 Confirmed crash on FreeBSD 8.1-STABLE #0: Mon Nov 8 12:16:53 CET 2010. System also hang without dumping. Help? :( From owner-freebsd-net@FreeBSD.ORG Thu Nov 25 22:45:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 173DF10656BD; Thu, 25 Nov 2010 22:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 898718FC12; Thu, 25 Nov 2010 22:45:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E9F6E41C747; Thu, 25 Nov 2010 23:45:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id aKwr4ZptHlu8; Thu, 25 Nov 2010 23:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 65B5C41C736; Thu, 25 Nov 2010 23:45:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 69ED744490B; Thu, 25 Nov 2010 22:41:36 +0000 (UTC) Date: Thu, 25 Nov 2010 22:41:36 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Steve Polyack In-Reply-To: <4CED50E0.7020205@comcast.net> Message-ID: <20101125224035.K24596@maildrop.int.zabbadoz.net> References: <4CED50E0.7020205@comcast.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Brian A. Seklecki" , User Questions Subject: Re: Jail source address selection in 8.1-RELEASE 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, 25 Nov 2010 22:45:08 -0000 On Wed, 24 Nov 2010, Steve Polyack wrote: Hi, > There appears to be a loosely documented sysctl > 'security.jail.param.ip4.saddrsel' which should limit source IP selection of > jails to their primary jail interface/IP. The sysctl does not appear to do > anything, however: > > # sysctl security.jail.param.ip4.saddrsel=0 > -> > # echo $? > 0 > # sysctl security.jail.param.ip4.saddrsel > # > # sysctl -d security.jail.param.ip4.saddrsel > security.jail.param.ip4.saddrsel: Do (not) use IPv4 source address selection > rather than the primary jail IPv4 address. > > Is this tunable only available when VIMAGE jails are built? The 8.1-RELEASE > Release Notes suggest it is for VIMAGE jail(8) containers, while 7.3-RELEASE > Release Notes suggest that it is available for the entire jail(8) subsystem > as 'security.jail.ip4_saddrsel', a different OID. Don't use the systctl; the param tree only tells you which options are available; ip4.saddrsel is an option to the jail -c|-m command. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 02:51:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB028106564A for ; Fri, 26 Nov 2010 02:51:07 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from nm11-vm0.bullet.mail.ne1.yahoo.com (nm11-vm0.bullet.mail.ne1.yahoo.com [98.138.90.58]) by mx1.freebsd.org (Postfix) with SMTP id 977C68FC16 for ; Fri, 26 Nov 2010 02:51:07 +0000 (UTC) Received: from [98.138.90.49] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 26 Nov 2010 02:37:16 -0000 Received: from [98.138.84.39] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 26 Nov 2010 02:37:16 -0000 Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP; 26 Nov 2010 02:37:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1290739036; bh=ofcc7AxKxakVvca2V7b9wHEI42Cbr1eNfFfoCuoGeho=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=MlEDyQW+Z6WyWz6BcwosRBiAm0Wokljq0W0TEWP6qMGM0LgmzVw8n5bU2y/0RnKQkIacKi8gT/W/nFuUK+Wof5/UpucO8hKy2PssRXmtj0CKDjujkDjSWiL0XCAekl2ij36DqB+Wl4g2PrzlRIF3aIM33SlL2TVXJhuRHmAALB4= X-Yahoo-Newman-Id: 132881.95386.bm@smtp107.mail.ne1.yahoo.com Received: from china (beezarliu@180.168.37.66 with login) by smtp107.mail.ne1.yahoo.com with SMTP; 25 Nov 2010 18:37:15 -0800 PST X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- X-YMail-OSG: 4wZrMQwVM1kJwLElyRy15isUQnKEBmS8PmNGwB1mDU8InUd GBJ0amSy.IoLQrcxx9X7b_tmNEQNFhmTzEibawzk5SsIoNsJn.lg3.Talw_G 9A7OOz0C6nNQsNjS95XbK50T.XrbCRqHY0q.dZN7ET8imdTx6ats8J_ujnNp 8Rn1Nmi3O56xa7NMiIGoMXBnd6afXHqQIzv6IPxlwugKkBh4tnQcgOPjp9AT noguElvHNyK8UlUqWEwcuBnn4eOktuysgr5RnuuQ- X-Yahoo-Newman-Property: ymail-3 Date: Fri, 26 Nov 2010 10:37:12 +0800 From: "beezarliu" To: "freebsd-net" Message-ID: <201011261037105152721@yahoo.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 02:51:07 -0000 Hi, We currently did a testing with a Intel dual-port 10G NICs. The driver version is "2.0.1". A: 82599, the chipset id is 0x10fb. B: 82598. When I config a vlan 77 on both machines, and ping B from A, I captured the packets on A: tcpdump: WARNING: ix0: no IPv4 address assigned tcpdump: listening on ix0, link-type EN10MB (Ethernet), capture size 50000 bytes 15:12:18.508614 00:0c:bd:00:9d:82 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 77, p 0, ethertype ARP, arp who-has 192.168.111.1 tell 192.168.111.2 0x0000: ffff ffff ffff 000c bd00 9d82 8100 004d ...............M 0x0010: 0806 0001 0800 0604 0001 000c bd00 9d82 ................ 0x0020: c0a8 6f02 0000 0000 0000 c0a8 6f01 ..o.........o. 15:12:18.508913 00:1b:21:3b:e6:39 > 00:0c:bd:00:9d:82, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype 802.1Q, vlan 77, p 0, ethertype ARP, arp reply 192.168.111.1 is-at 00:1b:21:3b:e6:39 0x0000: 000c bd00 9d82 001b 213b e639 8100 0000 ........!;.9.... 0x0010: 8100 004d 0806 0001 0800 0604 0002 001b ...M............ 0x0020: 213b e639 c0a8 6f01 000c bd00 9d82 c0a8 !;.9..o......... 0x0030: 6f02 0000 0000 0000 0000 0000 0000 0000 o............... At the same time, I captured the following packets on B: 15:13:03.958850 00:0c:bd:00:9d:82 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 56: arp who-has 192.168.111.1 tell 192.168.111.2 0x0000: ffff ffff ffff 000c bd00 9d82 0806 0001 ................ 0x0010: 0800 0604 0001 000c bd00 9d82 c0a8 6f02 ..............o. 0x0020: 0000 0000 0000 c0a8 6f01 0000 0000 0000 ........o....... 0x0030: 0000 0000 0000 0000 ........ 15:13:03.958864 00:1b:21:3b:e6:39 > 00:0c:bd:00:9d:82, ethertype ARP (0x0806), length 42: arp reply 192.168.111.1 is-at 00:1b:21:3b:e6:39 0x0000: 000c bd00 9d82 001b 213b e639 0806 0001 ........!;.9.... 0x0010: 0800 0604 0002 001b 213b e639 c0a8 6f01 ........!;.9..o. 0x0020: 000c bd00 9d82 c0a8 6f02 ........o. As you can see, the second packet A received had two vlan tags, the outer is 0, the inner is 77. So I digged into the source and added debugging information on our running system, and found the vlan stripping for 82599 work very strange. The VP bit in receiving descriptor is set, but vlan tag is still zero, and the real tag is not stripped! The datasheet says: 7.4.3.2 Stripping 802.1q Tags on Receives Software might instruct the 82599 to strip 802.1q VLAN tags from received packets. The policy whether to strip the VLAN tag is configurable per queue. If the RXDCTL.VME bit for a given queue is set to 1b, and the incoming packet is an 802.1q VLAN packet (that is, its Ethernet Type field matched the VLNCTRL.VET), then the 82599 strips the 4-byte VLAN tag from the packet, and stores the TCI in the VLAN Tag field of the receive descriptor. The 82599 also sets the VP bit in the receive descriptor to indicate that the packet had a VLAN tag that was stripped. If the RXDCTL.VME bit is not set, the 802.1q packets can still be received if they pass the receive filter, but the VLAN tag is not stripped and the VP bit is not set. Any commet? Thanks 2010-11-26 beezarliu From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 12:48:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B82001065670 for ; Fri, 26 Nov 2010 12:48:26 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2198FC14 for ; Fri, 26 Nov 2010 12:48:25 +0000 (UTC) Received: by eyb7 with SMTP id 7so936706eyb.13 for ; Fri, 26 Nov 2010 04:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D9vbNcJyj8xf6QSMIGCPro9qMRvS9oCRDgD6so0GDW4=; b=cPyuTTIsuQH4MDsKenzKLv517SmBVNN7KdIF3kXIL/S2V6XsxmzD5A1bmiVZshIaSV skkWdfPzcy0S/B0DXsPcEj5hmHK3yztMcD6w17ng85v04W2y/MU1RIT+BX2HnWPpdiRG sWbCqpVyj0aGuBZpXlwZYSaBkU35R1u7TYrpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eL64i5Jc3S/5XkiFvBU3HZhxhrQnsLcfSpdXfA1tYiEvWPWWyPKN1Qp6j7/ctysIS3 ubL9W4sY41e5z6IZCqGzxen3oVdiWgwerLU8eRqdpV760/GAyh6y6yCZyGGahxPzCWi/ a/SRjnEcL2KxTXpt3iG898Yagk2rEi86fhFN4= MIME-Version: 1.0 Received: by 10.213.112.145 with SMTP id w17mr358358ebp.0.1290775704870; Fri, 26 Nov 2010 04:48:24 -0800 (PST) Received: by 10.213.14.138 with HTTP; Fri, 26 Nov 2010 04:48:24 -0800 (PST) In-Reply-To: <201011261037105152721@yahoo.com.cn> References: <201011261037105152721@yahoo.com.cn> Date: Fri, 26 Nov 2010 07:48:24 -0500 Message-ID: From: Ryan Stone To: beezarliu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net , Jack Vogel Subject: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 12:48:26 -0000 This one bit me hard several months ago. Your analysis is correct. It's a hardware bug. The solution is to track in the driver whether the VME bit is set for the given queue, and if it isn't, ignore the VP bit. I meant to report this one to Jack but forgot, evidently. Ryan Stone From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 13:24:44 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0125106564A for ; Fri, 26 Nov 2010 13:24:44 +0000 (UTC) (envelope-from tobias@ntelecom.com.br) Received: from mail.ntelecom.com.br (mail.ntelecom.com.br [189.1.176.244]) by mx1.freebsd.org (Postfix) with ESMTP id 63D998FC08 for ; Fri, 26 Nov 2010 13:24:43 +0000 (UTC) Received: from [172.16.16.100] (gw01.ntelecom.com.br [189.1.176.250]) by mail.ntelecom.com.br (Postfix) with ESMTPA id 34BEC25886DC for ; Fri, 26 Nov 2010 11:07:42 -0200 (BRST) Message-ID: <4CEFB11D.8070806@ntelecom.com.br> Date: Fri, 26 Nov 2010 11:07:41 -0200 From: "Tobias P. Santos" User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.4 at mail.ntelecom.com.br X-Virus-Status: Clean Subject: Remove route 0.0.0.0&0x1 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, 26 Nov 2010 13:24:44 -0000 Hello, I was adding a static route and "accidentally" put an extra number 1 after the command, like this: route add -net 192.168.0.100 192.168.0.200 255.255.255.255 1 netstat -rn prints: Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 0.0.0.0&0x1 192.168.0.200 UGS 0 0 bge0 I tried to remove this route without success, either with: route delete -net 192.168.0.100 192.168.0.200 255.255.255.255 1 or route delete -net 192.168.0.100 192.168.0.200 255.255.255.255 I had to run route flush to get rid of it. Anyone has any clues? And also, how come a route like this being interpreted as the default route? This happened on a 7.3-RELEASE and I also tested on an old 6.2-RELEASE without being able to remove the route. The only difference is that it shows as 0.0.0.0&0x1 on 7.3 and as 0&0x1 on 6.2. Thank you in advance, Tobias. From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 20:14:46 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 172F71065675 for ; Fri, 26 Nov 2010 20:14:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id DCE8B8FC13 for ; Fri, 26 Nov 2010 20:14:45 +0000 (UTC) Received: by pxi1 with SMTP id 1so459510pxi.13 for ; Fri, 26 Nov 2010 12:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Ueut+Y0/+7v6P/E3V4kqlDylQPm1uOtpwjtapUxlY9A=; b=Nk92BlltVRkG2Vfr9OQ6gazhHpONvEO7FfSJ3oxE3soR2IH0bYrPMJ1wWhEDrUki9U Es2EerWREpKStpZwJ+rjTVpW20Ar14t6UD29rJDu2y/WMfRX/Sb8b1K+wkDaOn1hzob/ UUvlAu4D6ud6MRd4ZJOMWvvVdZg7maEfklH6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k7G2jZFoYGGRRuDGuI6258Khh6kC3r0WNCqCRH++rIYdlhEiTQRrhYt2YjaRme6ufg c1HYXb6UNVxfSbjV+pFnqzEueH8JaDYapgnHJ3mV0qy1R8G1pa834luMB8K02cWSaFHK Sf9yaKq1sm7PCyIgNfp8IoTs1aBysI0HWGNzE= MIME-Version: 1.0 Received: by 10.142.100.13 with SMTP id x13mr2549497wfb.270.1290802485378; Fri, 26 Nov 2010 12:14:45 -0800 (PST) Received: by 10.142.51.9 with HTTP; Fri, 26 Nov 2010 12:14:45 -0800 (PST) In-Reply-To: References: <201011261037105152721@yahoo.com.cn> Date: Fri, 26 Nov 2010 12:14:45 -0800 Message-ID: From: Jack Vogel To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: beezarliu , freebsd-net Subject: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 20:14:46 -0000 Hmmm, so you're saying the VP get's set when it shouldn't ? I'm not sure I follow the logic of how that would result in what he is seeing? I'm wondering if this might also have to do with a problem reported with IPv6 forwarding and vlans?? At least I can code this simply enough. Jack On Fri, Nov 26, 2010 at 4:48 AM, Ryan Stone wrote: > This one bit me hard several months ago. Your analysis is correct. > It's a hardware bug. The solution is to track in the driver whether > the VME bit is set for the given queue, and if it isn't, ignore the VP > bit. > > I meant to report this one to Jack but forgot, evidently. > > Ryan Stone > From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 20:42:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62BCA106566C for ; Fri, 26 Nov 2010 20:42:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E68338FC15 for ; Fri, 26 Nov 2010 20:42:46 +0000 (UTC) Received: by eyb7 with SMTP id 7so1156655eyb.13 for ; Fri, 26 Nov 2010 12:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=J/5uKnWbeNTgNcAyuruM5qDOblM8IWbaAlt7W3nSKLY=; b=oulhU3wAJCUrC0bhITFeITT8JjpgoU2Ek9UOykR4g32BKP1VpoLFzVGd3kp9EDYIAD 5GAvHo6p9ev26FjxmHGn6yAy0FLxijPW/7DD2QAI9PdyWCjIka8MMeBLW/3vF1h7c9sa nqTkJjM0W/IUfQhtlj3PaDDI3JmSvSqsJ/vP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t/AQVUfRQ0on86Gur+lw8nkkhL8ZY660YdZnqKUMeDfXW20tcQNx5ZBJ5vG/lYl+9v i+Un+Pmy2CzWH3Xz/Kt+6ajk/jWJLlqq+l36HkBg6ygYRqm7Wf5eme/ByPSgWuDMrsCi Y9C3byZRX2N7q6KqPp4cbJ4xiEZ6Y7WdrNJMQ= MIME-Version: 1.0 Received: by 10.213.8.146 with SMTP id h18mr6944464ebh.87.1290804165665; Fri, 26 Nov 2010 12:42:45 -0800 (PST) Received: by 10.213.14.138 with HTTP; Fri, 26 Nov 2010 12:42:45 -0800 (PST) In-Reply-To: References: <201011261037105152721@yahoo.com.cn> Date: Fri, 26 Nov 2010 15:42:45 -0500 Message-ID: From: Ryan Stone To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: beezarliu , freebsd-net Subject: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 20:42:47 -0000 If vlan stripping is disabled on the 82599(i.e. RXDCTL.VME is 0 for that queue is clear) and a vlan-tagged packet is received, then the descriptor for that packet will have the VP bit set even though the vlan was not stripped, and the VLAN Tag field in the descriptor is set to 0. ixgbe_rxeof will see that the VP bit is set and set the M_VLANTAG on the mbuf, and put 0 in m_pkthdr.ether_vtag. This means that the stack will treat the packet as if it was double vlan tagged, with outer tag being 0. Ryan Stone From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 20:46:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7D2910656C8 for ; Fri, 26 Nov 2010 20:46:14 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87ABF8FC23 for ; Fri, 26 Nov 2010 20:46:14 +0000 (UTC) Received: by pzk32 with SMTP id 32so316389pzk.13 for ; Fri, 26 Nov 2010 12:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=yxZaUhSITR1Tjk4CHAVG0MCn18Lbwi1KZ8LuLzIWT2U=; b=SbB64LKGhTnasfqC9XE6ZLnvQ1QliwqNfBhbF0EvxGdM3na9vq7T4eZOib3DocbSi9 hnNlF16fzuJqzOx118IuEb12r/KO2kazV0mTMQwD22/z/8mnHabTInIdcXKBko3fo4/W 6IT2ydPlKnoh5tV4QnCfVZoIX08PPWVmwJ3is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k5baraNPpF8KnsOuOqNxC6QfpUDYTsG+KGsg/+KkX5m7Yhsbq6CQ+NTc2pWkqkivGy 8i83dFq69/FwX80hdRFVEbL7tB32TvUGKrlgn2Gp/IARc5MB8EkdyEee/4ZPabEVXt5L kXWysMvootY/pWDwFJ6udNJX9z0DmAX/56zOQ= MIME-Version: 1.0 Received: by 10.142.211.21 with SMTP id j21mr2859044wfg.213.1290804373065; Fri, 26 Nov 2010 12:46:13 -0800 (PST) Received: by 10.142.51.9 with HTTP; Fri, 26 Nov 2010 12:46:13 -0800 (PST) In-Reply-To: References: <201011261037105152721@yahoo.com.cn> Date: Fri, 26 Nov 2010 12:46:13 -0800 Message-ID: From: Jack Vogel To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: beezarliu , freebsd-net Subject: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 20:46:14 -0000 Ahh, OK, so how would this solution work: In rxeof, in addition to requiring VP to be set, also check that adapter->num_vlans is non-zero, in order to store the tag. Jack On Fri, Nov 26, 2010 at 12:42 PM, Ryan Stone wrote: > If vlan stripping is disabled on the 82599(i.e. RXDCTL.VME is 0 for > that queue is clear) and a vlan-tagged packet is received, then the > descriptor for that packet will have the VP bit set even though the > vlan was not stripped, and the VLAN Tag field in the descriptor is set > to 0. ixgbe_rxeof will see that the VP bit is set and set the > M_VLANTAG on the mbuf, and put 0 in m_pkthdr.ether_vtag. This means > that the stack will treat the packet as if it was double vlan tagged, > with outer tag being 0. > > Ryan Stone > From owner-freebsd-net@FreeBSD.ORG Fri Nov 26 21:00:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CCBE10656B8 for ; Fri, 26 Nov 2010 21:00:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E58B18FC26 for ; Fri, 26 Nov 2010 21:00:20 +0000 (UTC) Received: by eyb7 with SMTP id 7so1161215eyb.13 for ; Fri, 26 Nov 2010 13:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bCyISxR4bomuKZoWJhE9BXLxFE+zBd3AsfVDvDIHip0=; b=T/jsUVtyBBJjs9kd7dfHbcpznAZ3O34UbChLjBTgPZVned1vuqDzPqMgYHDbOSyYSV 4U5gnLiHAE0oIRuy8ms9LObtK5MCk4GwBzDCr3AzYf4nO0b8jiXgQhGMyn3ShZsxpvGS IhvdTSLJst1MUuZcffe0syUFS/joS1KWX2fA8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cprnP5a64KRbSKxEJ0bG5y70EHW1fmdzM3US09jtBin/Jk58fS3Fkjxv3rwQQhwaM4 Oi3JuDV6OXm596fSBxa798ThtUFrr5yxXn0u4qvGBpf7DpaCjCjLxDsMfXntGghuf0ce 7REl+V7DL1uNVJfYjokIur7p41HDq7RBVGRJg= MIME-Version: 1.0 Received: by 10.213.3.68 with SMTP id 4mr2827081ebm.0.1290805219765; Fri, 26 Nov 2010 13:00:19 -0800 (PST) Received: by 10.213.14.138 with HTTP; Fri, 26 Nov 2010 13:00:19 -0800 (PST) In-Reply-To: References: <201011261037105152721@yahoo.com.cn> Date: Fri, 26 Nov 2010 16:00:19 -0500 Message-ID: From: Ryan Stone To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: beezarliu , freebsd-net Subject: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 21:00:24 -0000 On Fri, Nov 26, 2010 at 3:46 PM, Jack Vogel wrote: > Ahh, OK, so how would this solution work: > > In rxeof, in addition to requiring VP to be set, also check that > adapter->num_vlans is non-zero, in order to store the tag. > > Jack Yes, I believe that will work. Ryan Stone From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 03:13:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77B5A1065695; Sat, 27 Nov 2010 03:13:57 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id BAE678FC2D; Sat, 27 Nov 2010 03:13:56 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 66BC37E84A; Sat, 27 Nov 2010 14:13:54 +1100 (EST) Message-ID: <4CF07771.7050409@freebsd.org> Date: Sat, 27 Nov 2010 14:13:53 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.12) Gecko/20101117 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Kostik Belousov References: <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> <4CD090EF.4020402@freebsd.org> <4CD64814.2000906@freebsd.org> <4CDD0C7D.1070102@freebsd.org> <4CDD1529.8070504@freebsd.org> <20101112104109.GY2392@deviant.kiev.zoral.com.ua> <4CDD3EA5.7020101@freebsd.org> In-Reply-To: <4CDD3EA5.7020101@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Igor Sysoev , Andre Oppermann , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 03:13:57 -0000 On 11/13/10 00:18, Lawrence Stewart wrote: > On 11/12/10 21:41, Kostik Belousov wrote: >> On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote: >>> On 11/12/10 20:44, Lawrence Stewart wrote: >>>> On 11/07/10 17:32, Lawrence Stewart wrote: >>>>> On 11/03/10 09:30, Andre Oppermann wrote: >>>>>> On 02.11.2010 01:11, Maxim Dounin wrote: >>>>>>> Hello! >>>>>>> >>>>>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: >>>>>>> >>>>>>>> On 27.09.2010 10:12, Maxim Dounin wrote: >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> Andre, could you please take a look at one more patch as well? >>>>>>>>>> >>>>>>>>>> Igor reported that it still sees 100ms delays with rfc3465 turned >>>>>>>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) >>>>>>>>>> for hosts found in hostcache. >>>>>>>>>> >>>>>>>>>> The problem with setting cwnd from hostcache was already reported >>>>>>>>>> here: >>>>>>>>>> >>>>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 >>>>>>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html >>>>>>>>>> >>>>>>>>>> As using larger cwnd from hostcache may cause problems on >>>>>>>>>> congested links (see second thread) I changed code to only use >>>>>>>>>> cached cwnd as an upper bound for cwnd (instead of fixing current >>>>>>>>>> code). This is also in-line with what we do on connection >>>>>>>>>> restarts. >>>>>>>>>> >>>>>>>>>> We may later consider re-adding usage of larger cwnd from >>>>>>>>>> hostcache. But I believe it should be done carefully and >>>>>>>>>> probably behind sysctl, off by default. >>>>>>>>> >>>>>>>>> Ping. >>>>>>>> >>>>>>>> Thanks for the reminder. I'll disable priming CWND from hostcache. >>>>>>> >>>>>>> Ping again. >>>>>>> >>>>>>> I would like to see the patch in question[1] committed and MFC'ed >>>>>>> somewhere before 8.2. >>>>>>> >>>>>>> Andre, if you are just too busy to do it yourself - please say so, >>>>>>> I'll ask somebody else to commit it. >>>>>> >>>>>> Thanks for the reminder. After EuroBSDCon Developer Summit I was >>>>>> busy with other work and most of my tcp work was stalled due to >>>>>> review bandwidth issues. >>>>> >>>>> Sorry for the review bandwidth issues. I'm only just managing to keep my >>>>> head above water at the moment and have had to reduce much of my FreeBSD >>>>> work to a trickle. >>>>> >>>>>> Lawrence, could you please spare a few seconds and take a quick look >>>>>> at the attached patch? >>>>> >>>>> The patch looks fine, please commit. I hope to give the hostcache some >>>>> TLC at some point, but in the meantime it's fine to ignore cached cwnd. >>>> >>>> FYI Andre, this patch got rolled into r215166 because I had to move all >>>> the code around which the patch was based on. Is that going to cause any >>>> issues here? I should have checked prior to committing but completely >>>> forgot I had pulled the patch into my dev tree before creating the mod >>>> CC patch. >>> >>> Gah, I think I've answered my own question. MFCing the patch standalone >>> in time for 8.2 as Maxim requested is not going to be possible. I think >>> I'll have to back out r215166, commit your patch and then recommit the >>> modular CC patch. >>> >>> Unless someone can think of a way that doesn't involve all the mucking >>> about? >> Well, if the change is indeed already in HEAD, you can do a direct commit >> to stable/8 after proper MFC period, noting that this is a cherry-pick of >> the part of corresponding revision. > > hmm, not ideal but would get the job done. When I eventually MFC the > modular CC patch everything will be back in sync mergeinfo wise as well. > Would anyone object if I follow Kostik's suggestion and direct commit > the TCP_METRICS_CWND patch to stable/8 in, say, a week's time? If I > don't hear anything, I'll aim to do the commit next weekend. FYI, committed to stable/8 as r215925 and stable/7 as r215926. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 04:24:55 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA9EE106566C for ; Sat, 27 Nov 2010 04:24:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 658DD8FC0A for ; Sat, 27 Nov 2010 04:24:55 +0000 (UTC) Received: by wyf19 with SMTP id 19so2565720wyf.13 for ; Fri, 26 Nov 2010 20:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=EqNXLMce0PziEoti8emAvGwsO4H+2Sp6XgoL4FHdlo4=; b=bqchObVvDnxYTncz1DhPCUZK8pKnVRX+3xl3uhWiKWxFtKM4MrbCVUhB4nsEXx/tU3 j3/3mkaFjUEaLf3mpMXb41eW5OYXMF4NBkD88kVa41gLJ63LFdSuHstF+fx7E0gPtUld O7viOGI/hl2mFmL6HFhrBwhr2iiF9ZvfUbTek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vU9bXy+ekDHbGXsYJ0HPnN9herPXOrDDj88571nbZbEA11EriGBtQ1S5UVl5URjjn1 3IVQPkdKv8h8TRy1G5xXKqWgXAiwNvNnEYufNI1ZgaHsvq9/jS1YDf5iu0P4DDeCciAZ j2LBlLkrGRAOPS1dJQRMqMAA/VP7az7xJtmu8= MIME-Version: 1.0 Received: by 10.216.179.210 with SMTP id h60mr2713113wem.42.1290831893919; Fri, 26 Nov 2010 20:24:53 -0800 (PST) Received: by 10.216.2.206 with HTTP; Fri, 26 Nov 2010 20:24:53 -0800 (PST) In-Reply-To: <201011270946271408828@yahoo.com.cn> References: <201011261037105152721@yahoo.com.cn> <201011270946271408828@yahoo.com.cn> Date: Fri, 26 Nov 2010 20:24:53 -0800 Message-ID: From: Jack Vogel To: beezarliu Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , Ryan Stone Subject: Re: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 04:24:55 -0000 Will you please test with the code I just checked in and see if it also eliminates the problem, if not I can change it to your method. Just for the record, I was not aware of a hardware bug, and for right now no one is around :) I will ask around next week to see if something was known that I missed. Thanks, Jack 2010/11/26 beezarliu > On 2010-11-27 05:01:11, Ryan Stone wrote: > >On Fri, Nov 26, 2010 at 3:46 PM, Jack Vogel wrote: > >> Ahh, OK, so how would this solution work: > >> > >> In rxeof, in addition to requiring VP to be set, also check that > >> adapter->num_vlans is non-zero, in order to store the tag. > >> > >> Jack > > > >Yes, I believe that will work. > > > >Ryan Stone > >_______________________________________________ > >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 ixgbe_init -> ixgbe_init_lock -> ixgbe_setup_vlan_hw_support, > I'm sure the VME bit is set for all rx queues. > But in my testing, the vlan tag is not stripped but VP bit is set. > It's very strange, and I'm not sure it's hardware bug. > > I currently fix it by checking vlan tag is not zero before add M_VLANTAG, > because vlan tag id 0 is not used. > > if ((staterr & IXGBE_RXD_STAT_VP) && vtag)= { > sendmp->m_pkthdr.ether_vtag =3D vt= ag; > sendmp->m_flags |=3D M_VLANTAG; > } > > > Thanks > Beezar > > > __________________________________________________ > =B8=CF=BF=EC=D7=A2=B2=E1=D1=C5=BB=A2=B3=AC=B4=F3=C8=DD=C1=BF=C3=E2=B7=D1= =D3=CA=CF=E4? > http://cn.mail.yahoo.com > From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 12:52:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08F26106564A for ; Sat, 27 Nov 2010 12:52:58 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 876A58FC1B for ; Sat, 27 Nov 2010 12:52:57 +0000 (UTC) Received: by eyb7 with SMTP id 7so1334370eyb.13 for ; Sat, 27 Nov 2010 04:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jO7fmCAfLQT7PFSY+jJRtP0haCvdhA78Qq22yYpMESM=; b=rsGTBReAycVRGYxSo4TPm3QgB3IRgIhYxreR0tXf1gVRU00/uQ7/b9n9h3owUlwWvD 2CbQPKNbBRiprXQk3EyFe+NLJxJoB87YLTj/7PsyebJPgm9JZIl19SeE00zhWeIGblTe bSMhUhwGKMI2IpPnC7V1SEQKg0WOiB+NuTvfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Df+kbFfhr2nhYhKOSmZdSzHEvUUgrrwSFc9mrDflTxNDTmRHGcKO+3uk2i3838tONv 3Fz/Bcuc2s1Y/eflOW7PkPvD33OwxIePKSZyUmH8YckQk5GBmrrYkzbftBfcN3o9e83j lr4NY04G55W+PiltOYNdE6VmcqNGMjBIAEO1Q= MIME-Version: 1.0 Received: by 10.213.33.80 with SMTP id g16mr7465772ebd.61.1290862376347; Sat, 27 Nov 2010 04:52:56 -0800 (PST) Received: by 10.213.14.138 with HTTP; Sat, 27 Nov 2010 04:52:56 -0800 (PST) In-Reply-To: References: <201011261037105152721@yahoo.com.cn> <201011270946271408828@yahoo.com.cn> Date: Sat, 27 Nov 2010 07:52:56 -0500 Message-ID: From: Ryan Stone To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: beezarliu , freebsd-net Subject: Re: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 12:52:58 -0000 2010/11/26 Jack Vogel : > Just for the record, I was not aware of a hardware bug, and > for right now no one is around :) I will ask around next week > to see if something was known that I missed. I doubt that anybody at Intel will know about this one. To my knowledge, it's not in the errata for the 82599. This is just something that I discovered independently over the summer, fixed in my local tree and promptly forgot about. From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 17:59:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7E291065673 for ; Sat, 27 Nov 2010 17:59:11 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5424D8FC12 for ; Sat, 27 Nov 2010 17:59:10 +0000 (UTC) Received: by wwb13 with SMTP id 13so302606wwb.31 for ; Sat, 27 Nov 2010 09:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=myI5PBPYevONCS4sbTGs93UrG9T27HijJvHSb62PPLw=; b=jjU32ap101wcKsxaggBqTU05+Udtfx6LcnGFPbcOo9n40I9WaOvppOL6IQll7N3EKZ +VHe8kAAiofdPgscSWTSJsaWWKG5wIve5Q0+9MdiqkAZrW73FgbFSRAwRpyinqsrgEB0 BxAxL8mMhaXGzlDpKeBtrYg5w1oxtXOJOP+go= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tUlIaKeFhVZjG685zz9cKAvgW3P0Ry/wBw3skiiufUOkBjMVt8v68jC1PB42jgbaQL 4Nn7/SWs+O5DgqMc2WHWc3bvGwbi/7hZEg0Io7tof87MV8Z0/DmtLXkL1XVEcwlRnLNp 6Ug1K4CaM4qqi9delzww4quq7U6/J7fsu4baQ= MIME-Version: 1.0 Received: by 10.216.59.193 with SMTP id s43mr1440545wec.42.1290880750162; Sat, 27 Nov 2010 09:59:10 -0800 (PST) Received: by 10.216.2.206 with HTTP; Sat, 27 Nov 2010 09:59:10 -0800 (PST) In-Reply-To: References: <201011261037105152721@yahoo.com.cn> <201011270946271408828@yahoo.com.cn> Date: Sat, 27 Nov 2010 09:59:10 -0800 Message-ID: From: Jack Vogel To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: beezarliu , freebsd-net Subject: Re: Re: 82599 receiving packets with vlan tag=0 (vlan strip problem)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 17:59:12 -0000 Well, that will be cool if so, its not usually FreeBSD that finds bugs, and if it really is hardware then they need to know. Thanks Ryan! Jack On Sat, Nov 27, 2010 at 4:52 AM, Ryan Stone wrote: > 2010/11/26 Jack Vogel : > > Just for the record, I was not aware of a hardware bug, and > > for right now no one is around :) I will ask around next week > > to see if something was known that I missed. > > I doubt that anybody at Intel will know about this one. To my > knowledge, it's not in the errata for the 82599. This is just > something that I discovered independently over the summer, fixed in my > local tree and promptly forgot about. > From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 19:36:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05ABD1065679 for ; Sat, 27 Nov 2010 19:36:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8971C8FC0A for ; Sat, 27 Nov 2010 19:36:57 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id oARJA5Ua078417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 27 Nov 2010 20:10:05 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id oARJ9saG071295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Nov 2010 20:09:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id oARJ9sVq089298; Sat, 27 Nov 2010 20:09:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id oARJ9s61089297; Sat, 27 Nov 2010 20:09:54 +0100 (CET) (envelope-from ticso) Date: Sat, 27 Nov 2010 20:09:54 +0100 From: Bernd Walter To: freebsd-net@freebsd.org Message-ID: <20101127190953.GN77319@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Bernd Walter Subject: cannot forward from X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 19:36:58 -0000 What are those messages about? I know that bbbb:: is in an undefined address range, but is this the reason for this error? cannot forward from bbbb::1 to bbbb::11:22ff:fe33:4455 nxt 58 received on ue1 cannot forward from 2002:559f:e31:1::16 to bbbb::11:22ff:fe33:4455 nxt 58 received on ue1 cannot forward from bbbb::11 to 2002:559f:e31:1::16 nxt 58 received on ue1 cannot forward from bbbb::11 to 2002:559f:e31:1::16 nxt 58 received on ue1 cannot forward from bbbb::11 to 2002:559f:e31:1::16 nxt 58 received on ue1 cannot forward from 2002:559f:e31:1::1 to bbbb::11:22ff:fe33:4455 nxt 58 received on ue1 cannot forward from 2002:559f:e31:1::1 to bbbb::11:22ff:fe33:4455 nxt 58 received on ue1 cannot forward from bbbb::11 to 2002:559f:e31:1::1 nxt 58 received on ue1 cannot forward from bbbb::11 to 2002:559f:e31:1::1 nxt 58 received on ue1 -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Sat Nov 27 20:33:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F1F11065675 for ; Sat, 27 Nov 2010 20:33:22 +0000 (UTC) (envelope-from pascal@vizeli.ch) Received: from mail.dragonbsd.ch (kenshin.dragonbsd.ch [91.121.168.144]) by mx1.freebsd.org (Postfix) with ESMTP id 07E758FC1B for ; Sat, 27 Nov 2010 20:33:21 +0000 (UTC) Received: from mail.dragonbsd.ch (mail.dragonbsd.local [127.0.1.16]) by mail.dragonbsd.ch (Postfix) with ESMTP id D70BA5B29DD for ; Sat, 27 Nov 2010 21:16:39 +0100 (CET) Received: from [192.168.23.121] (192-154.198-178.cust.bluewin.ch [178.198.154.192]) by mail.dragonbsd.ch (Postfix) with ESMTPSA id 968895B29D6 for ; Sat, 27 Nov 2010 21:16:39 +0100 (CET) Message-ID: <4CF16727.1010704@vizeli.ch> Date: Sat, 27 Nov 2010 21:16:39 +0100 From: Pascal Vizeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Sat, 27 Nov 2010 21:23:49 +0000 Subject: [Bug][ND6] proxy dosn't work 8.1-R 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, 27 Nov 2010 20:33:22 -0000 Dear Is it possible that the ndp proxy dosn't work at the moment? I've set it but it dosn't have any effect on my FreeBSD 8.1 RELEASE version. greets pascal