From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 01:07: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 3F95F106566C for ; Sun, 28 Nov 2010 01:07:37 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 8CE138FC0A for ; Sun, 28 Nov 2010 01:07:36 +0000 (UTC) Received: (qmail 23238 invoked by uid 0); 28 Nov 2010 01:07:34 -0000 Received: from 79.107.35.215 by rms-eu011.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Sun, 28 Nov 2010 01:54:57 +0100 From: "Nikos Vassiliadis" Message-ID: <20101128010732.229640@gmx.com> MIME-Version: 1.0 To: "Tobias P. Santos" ,freebsd-net@freebsd.org X-Authenticated: #46156728 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: ZpLCdIFtMmA6V9Mnq2NnzTY5MjQ1Nx0Q Cc: Subject: Re: 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: Sun, 28 Nov 2010 01:07:37 -0000 > ----- Original Message ----- > From: Tobias P. Santos > Sent: 11/26/10 03:07 PM > To: freebsd-net@freebsd.org > Subject: Remove route 0.0.0.0&0x1 > > 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. Try: route delete 0.0.0.0 -netmask 0.0.0.1 > Anyone has any clues? And also, how come a route like this being > interpreted as the default route? A 0.0.0.0/0.0.0.1 route matches every IP with bit 0 clear and is half the size of a 0.0.0.0/0.0.0.0 route - which is pretty big. Something like: 0.0.0.0 0.0.0.2 0.0.0.4 ... 255.255.255.252 255.255.255.254 HTH, Nikos From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 08:16:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55A1B106566C for ; Sun, 28 Nov 2010 08:16:21 +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 58BBE8FC08 for ; Sun, 28 Nov 2010 08:16:19 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 2D05E39824; Sun, 28 Nov 2010 10:16:17 +0200 (SAST) Date: Sun, 28 Nov 2010 10:16:17 +0200 From: John Hay To: Jack Vogel Message-ID: <20101128081617.GA90332@zibbi.meraka.csir.co.za> References: <201011261037105152721@yahoo.com.cn> <201011270946271408828@yahoo.com.cn> 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 , 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: Sun, 28 Nov 2010 08:16:21 -0000 Hi Jack, On Sat, Nov 27, 2010 at 09:59:10AM -0800, Jack Vogel wrote: > 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. I don't think your solution / workaround work in every case. To debug my other vlan + ipv6 problem, I have configured a mirrored port on the switch and connected that to one of the ixgbe interfaces with no vlans configured on it. Packets dumped on it looks like this: ######################################### # tcpdump -i ix3 -n -s 0 -e ether host 00:23:ae:a5:00:ef tcpdump: WARNING: ix3: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ix3, link-type EN10MB (Ethernet), capture size 65535 bytes 10:00:58.215870 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 0, length 16 10:00:59.207090 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 1, length 16 10:01:00.206506 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 2, length 16 10:01:01.206923 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 3, length 16 10:01:02.206378 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 4, length 16 10:01:03.168219 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 86: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor advertisement, tgt is fe80::21b:21ff:fe57:b420, length 24 10:01:03.206846 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 5, length 16 10:01:03.215452 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 94: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor solicitation, who has fe80::223:aeff:fea5:ef, length 32 10:01:04.206331 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 6, length 16 10:01:05.206760 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 7, length 16 10:01:06.206203 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 8, length 16 10:01:07.206794 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 9, length 16 ######################################## On the base interface that actually sent the packets out, it looked like this: ######################################## # tcpdump -i ix2 -n -s 0 -e ether host 00:23:ae:a5:00:ef tcpdump: WARNING: ix2: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ix2, link-type EN10MB (Ethernet), capture size 65535 bytes 10:00:58.215838 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 0, length 16 10:00:58.215861 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 0, length 16 10:00:59.207067 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 1, length 16 10:00:59.207081 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 1, length 16 10:01:00.206484 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 2, length 16 10:01:00.206497 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 2, length 16 10:01:01.206899 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 3, length 16 10:01:01.206913 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 3, length 16 10:01:02.206355 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 4, length 16 10:01:02.206368 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 4, length 16 10:01:03.168187 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 90: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, neighbor solicitation, who has fe80::21b:21ff:fe57:b420, length 32 10:01:03.168210 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 82: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor advertisement, tgt is fe80::21b:21ff:fe57:b420, length 24 10:01:03.206828 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 5, length 16 10:01:03.206838 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 5, length 16 10:01:03.215445 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 90: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor solicitation, who has fe80::223:aeff:fea5:ef, length 32 10:01:03.215604 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 82: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, neighbor advertisement, tgt is fe80::223:aeff:fea5:ef, length 24 10:01:04.206307 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 6, length 16 10:01:04.206321 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 6, length 16 10:01:05.206739 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 7, length 16 10:01:05.206751 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 7, length 16 10:01:06.206181 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 8, length 16 10:01:06.206194 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 8, length 16 10:01:07.206772 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 9, length 16 ######################################## You can see that there is only one vlan tag. You can also see that all of these were sent out on vlan 1, while by the time they arrive on the mirrored port some have been mangled to vlan 8. This is after updating to the new driver that was merged today. It seems that I do not need routing anymore for this condition to happen. Just a ping to the link-local address triggers it. I did this from another machine: ######################################## # ping6 fe80::21b:21ff:fe57:b420%em0 PING6(56=40+8+8 bytes) fe80::223:aeff:fea5:ef%em0 --> fe80::21b:21ff:fe57:b420%em0 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=5 hlim=64 time=0.180 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=6 hlim=64 time=0.134 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=7 hlim=64 time=0.145 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=8 hlim=64 time=0.169 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=33 hlim=64 time=0.135 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=34 hlim=64 time=0.145 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=35 hlim=64 time=0.151 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=36 hlim=64 time=0.166 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=37 hlim=64 time=0.159 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=38 hlim=64 time=0.147 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=39 hlim=64 time=0.146 ms 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=40 hlim=64 time=0.213 ms ^C --- fe80::21b:21ff:fe57:b420%em0 ping6 statistics --- 41 packets transmitted, 12 packets received, 70.7% packet loss round-trip min/avg/max/std-dev = 0.134/0.158/0.213/0.021 ms ######################################## Currently the configs look like this: ######################################## mr3# ifconfig ix2 ix2: flags=8843 metric 0 mtu 1500 options=1b8 ether 00:1b:21:57:ef:7c inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 nd6 options=3 media: Ethernet autoselect (10Gbase-SR ) status: active mr3# ifconfig ix3 ix3: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1b:21:57:ef:7d inet6 fe80::21b:21ff:fe57:ef7d%ix3 prefixlen 64 scopeid 0x4 nd6 options=3 media: Ethernet autoselect (10Gbase-SR ) status: active mr3# ifconfig ix2.1 ix2.1: flags=8843 metric 0 mtu 1500 ether 00:1b:21:57:ef:7c inet 146.64.28.2 netmask 0xffffff00 broadcast 146.64.28.255 inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0xa inet6 2001:4200:7000:3:21b:21ff:fe57:b420 prefixlen 64 inet6 2001:4200:7000:3:: prefixlen 64 anycast nd6 options=3 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 1 parent interface: ix2 mr3# ifconfig ix2.8 ix2.8: flags=8843 metric 0 mtu 1500 ether 00:1b:21:57:ef:7c inet 146.64.8.50 netmask 0xffffff00 broadcast 146.64.8.255 inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xb inet6 2001:4200:7000:1:21b:21ff:fe57:b420 prefixlen 64 inet6 2001:4200:7000:1:: prefixlen 64 anycast nd6 options=3 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 8 parent interface: ix2 ######################################## John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 09:19: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 D7885106564A for ; Sun, 28 Nov 2010 09:19:09 +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 3C4FB8FC0A for ; Sun, 28 Nov 2010 09:19:08 +0000 (UTC) Received: by wwb13 with SMTP id 13so664795wwb.31 for ; Sun, 28 Nov 2010 01:19:08 -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=5I5L6mL+nQPZHLsKFISp1lwI8NwioYLkwGs2eHi+6yA=; b=VJzBPXVQ2kmYXWY4AMKkl9e2Nqjrq5thMKzuHVqa3wjSKnJ5QJogcq/9ZkWvELyssu SZXzgGj6sv3mLVFU/S9Sf7L9gIS9G8u7X5lhVjFqf3SFrc/H1uolbj7jT3UyW2JSKF7b UFloanjghIvjxljmTxJXc/GbUutxzs5l10qFg= 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=OTNpDQEEZPczDPhh1jqdtZNoIRAsvju/KwMCDB8DMdpeOTQB6OvXTk9D0Y+9VeWIFT FS6TZyoFQ7JoW7lq51jY0bNlM4srmJJo/H/purUGgLLlTuYnVxxbrSS8Xcd8rijmd073 OubqVk/ZoEtW9pYmYufBpc38mQ4J18ZpDGD/g= MIME-Version: 1.0 Received: by 10.216.179.210 with SMTP id h60mr3723163wem.42.1290935947707; Sun, 28 Nov 2010 01:19:07 -0800 (PST) Received: by 10.216.2.206 with HTTP; Sun, 28 Nov 2010 01:19:07 -0800 (PST) In-Reply-To: <20101128081617.GA90332@zibbi.meraka.csir.co.za> References: <201011261037105152721@yahoo.com.cn> <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> Date: Sun, 28 Nov 2010 01:19:07 -0800 Message-ID: From: Jack Vogel To: John Hay Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 28 Nov 2010 09:19:09 -0000 Well, its not solving this odd vlan tag change problem, that isn't what the workaround was about, at least I dont see how to connect them. So you arent using HW Filters? or does that just not show up in the ifconfig display? Jack On Sun, Nov 28, 2010 at 12:16 AM, John Hay wrote: > Hi Jack, > > On Sat, Nov 27, 2010 at 09:59:10AM -0800, Jack Vogel wrote: > > 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. > > I don't think your solution / workaround work in every case. To debug my > other vlan + ipv6 problem, I have configured a mirrored port on the switch > and connected that to one of the ixgbe interfaces with no vlans configured > on it. Packets dumped on it looks like this: > > ######################################### > # tcpdump -i ix3 -n -s 0 -e ether host 00:23:ae:a5:00:ef > tcpdump: WARNING: ix3: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ix3, link-type EN10MB (Ethernet), capture size 65535 bytes > 10:00:58.215870 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 0, length 16 > 10:00:59.207090 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 1, length 16 > 10:01:00.206506 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 2, length 16 > 10:01:01.206923 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 3, length 16 > 10:01:02.206378 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 4, length 16 > 10:01:03.168219 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 86: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor > advertisement, tgt is fe80::21b:21ff:fe57:b420, length 24 > 10:01:03.206846 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 5, length 16 > 10:01:03.215452 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 94: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor > solicitation, who has fe80::223:aeff:fea5:ef, length 32 > 10:01:04.206331 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 6, length 16 > 10:01:05.206760 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 7, length 16 > 10:01:06.206203 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 8, length 16 > 10:01:07.206794 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > seq 9, length 16 > ######################################## > > On the base interface that actually sent the packets out, it looked like > this: > > ######################################## > # tcpdump -i ix2 -n -s 0 -e ether host 00:23:ae:a5:00:ef > tcpdump: WARNING: ix2: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ix2, link-type EN10MB (Ethernet), capture size 65535 bytes > 10:00:58.215838 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 0, length 16 > 10:00:58.215861 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 0, length 16 > 10:00:59.207067 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 1, length 16 > 10:00:59.207081 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 1, length 16 > 10:01:00.206484 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 2, length 16 > 10:01:00.206497 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 2, length 16 > 10:01:01.206899 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 3, length 16 > 10:01:01.206913 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 3, length 16 > 10:01:02.206355 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 4, length 16 > 10:01:02.206368 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 4, length 16 > 10:01:03.168187 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor solicitation, who has > fe80::21b:21ff:fe57:b420, length 32 > 10:01:03.168210 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, neighbor advertisement, tgt is > fe80::21b:21ff:fe57:b420, length 24 > 10:01:03.206828 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 5, length 16 > 10:01:03.206838 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 5, length 16 > 10:01:03.215445 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, neighbor solicitation, who has > fe80::223:aeff:fea5:ef, length 32 > 10:01:03.215604 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor advertisement, tgt is > fe80::223:aeff:fea5:ef, length 24 > 10:01:04.206307 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 6, length 16 > 10:01:04.206321 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 6, length 16 > 10:01:05.206739 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 7, length 16 > 10:01:05.206751 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 7, length 16 > 10:01:06.206181 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 8, length 16 > 10:01:06.206194 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 8, length 16 > 10:01:07.206772 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 9, length 16 > ######################################## > > You can see that there is only one vlan tag. > > You can also see that all of these were sent out on vlan 1, while by the > time they arrive on the mirrored port some have been mangled to vlan 8. > > This is after updating to the new driver that was merged today. It seems > that I do not need routing anymore for this condition to happen. Just a > ping to the link-local address triggers it. > > I did this from another machine: > > ######################################## > # ping6 fe80::21b:21ff:fe57:b420%em0 > PING6(56=40+8+8 bytes) fe80::223:aeff:fea5:ef%em0 --> > fe80::21b:21ff:fe57:b420%em0 > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=5 hlim=64 time=0.180 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=6 hlim=64 time=0.134 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=7 hlim=64 time=0.145 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=8 hlim=64 time=0.169 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=33 hlim=64 time=0.135 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=34 hlim=64 time=0.145 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=35 hlim=64 time=0.151 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=36 hlim=64 time=0.166 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=37 hlim=64 time=0.159 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=38 hlim=64 time=0.147 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=39 hlim=64 time=0.146 > ms > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=40 hlim=64 time=0.213 > ms > ^C > --- fe80::21b:21ff:fe57:b420%em0 ping6 statistics --- > 41 packets transmitted, 12 packets received, 70.7% packet loss > round-trip min/avg/max/std-dev = 0.134/0.158/0.213/0.021 ms > ######################################## > > Currently the configs look like this: > > ######################################## > mr3# ifconfig ix2 > ix2: flags=8843 metric 0 mtu 1500 > options=1b8 > ether 00:1b:21:57:ef:7c > inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 > nd6 options=3 > media: Ethernet autoselect (10Gbase-SR ) > status: active > mr3# ifconfig ix3 > ix3: flags=8843 metric 0 mtu 1500 > > options=1bb > ether 00:1b:21:57:ef:7d > inet6 fe80::21b:21ff:fe57:ef7d%ix3 prefixlen 64 scopeid 0x4 > nd6 options=3 > media: Ethernet autoselect (10Gbase-SR ) > status: active > mr3# ifconfig ix2.1 > ix2.1: flags=8843 metric 0 mtu 1500 > ether 00:1b:21:57:ef:7c > inet 146.64.28.2 netmask 0xffffff00 broadcast 146.64.28.255 > inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0xa > inet6 2001:4200:7000:3:21b:21ff:fe57:b420 prefixlen 64 > inet6 2001:4200:7000:3:: prefixlen 64 anycast > nd6 options=3 > media: Ethernet autoselect (10Gbase-SR ) > status: active > vlan: 1 parent interface: ix2 > mr3# ifconfig ix2.8 > ix2.8: flags=8843 metric 0 mtu 1500 > ether 00:1b:21:57:ef:7c > inet 146.64.8.50 netmask 0xffffff00 broadcast 146.64.8.255 > inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xb > inet6 2001:4200:7000:1:21b:21ff:fe57:b420 prefixlen 64 > inet6 2001:4200:7000:1:: prefixlen 64 anycast > nd6 options=3 > media: Ethernet autoselect (10Gbase-SR ) > status: active > vlan: 8 parent interface: ix2 > > ######################################## > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 10:24: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 A8CB11065673; Sun, 28 Nov 2010 10:24:57 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 3871D8FC18; Sun, 28 Nov 2010 10:24:56 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id C4BBF17019; Sun, 28 Nov 2010 13:24:54 +0300 (MSK) Date: Sun, 28 Nov 2010 13:24:54 +0300 From: Maxim Dounin To: Lawrence Stewart Message-ID: <20101128102453.GH72777@mdounin.ru> References: <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> <4CF07771.7050409@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF07771.7050409@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-net@freebsd.org, Igor Sysoev , Andre Oppermann 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: Sun, 28 Nov 2010 10:24:57 -0000 Hello! On Sat, Nov 27, 2010 at 02:13:53PM +1100, Lawrence Stewart wrote: > 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. Thanks a lot. PR kern/92690 probably should be closed. Maxim Dounin From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 10:27: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 E6724106566B for ; Sun, 28 Nov 2010 10:27:35 +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 5B1658FC15 for ; Sun, 28 Nov 2010 10:27:34 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id C1DB239824; Sun, 28 Nov 2010 12:17:02 +0200 (SAST) Date: Sun, 28 Nov 2010 12:17:02 +0200 From: John Hay To: Jack Vogel Message-ID: <20101128101702.GA1574@zibbi.meraka.csir.co.za> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net , 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: Sun, 28 Nov 2010 10:27:36 -0000 On Sun, Nov 28, 2010 at 01:19:07AM -0800, Jack Vogel wrote: > Well, its not solving this odd vlan tag change problem, that isn't what the > workaround was about, at least I dont see how to connect them. Yes, but I still see the double vlan tags on the mirror port that I connected to ix3, which is what Ryan reported? > So you arent using HW Filters? or does that just not show up in the ifconfig > display? Which HW Filters? I have -rxcsum -lro from previous debugging. I can turn it on again. Or are there others that I do not know about? John > > Jack > > > On Sun, Nov 28, 2010 at 12:16 AM, John Hay wrote: > > > Hi Jack, > > > > On Sat, Nov 27, 2010 at 09:59:10AM -0800, Jack Vogel wrote: > > > 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. > > > > I don't think your solution / workaround work in every case. To debug my > > other vlan + ipv6 problem, I have configured a mirrored port on the switch > > and connected that to one of the ixgbe interfaces with no vlans configured > > on it. Packets dumped on it looks like this: > > > > ######################################### > > # tcpdump -i ix3 -n -s 0 -e ether host 00:23:ae:a5:00:ef > > tcpdump: WARNING: ix3: no IPv4 address assigned > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on ix3, link-type EN10MB (Ethernet), capture size 65535 bytes > > 10:00:58.215870 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 0, length 16 > > 10:00:59.207090 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 1, length 16 > > 10:01:00.206506 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 2, length 16 > > 10:01:01.206923 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 3, length 16 > > 10:01:02.206378 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 4, length 16 > > 10:01:03.168219 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 86: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor > > advertisement, tgt is fe80::21b:21ff:fe57:b420, length 24 > > 10:01:03.206846 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 5, length 16 > > 10:01:03.215452 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 94: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, neighbor > > solicitation, who has fe80::223:aeff:fea5:ef, length 32 > > 10:01:04.206331 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 6, length 16 > > 10:01:05.206760 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 7, length 16 > > 10:01:06.206203 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 8, length 16 > > 10:01:07.206794 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, ethertype > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo reply, > > seq 9, length 16 > > ######################################## > > > > On the base interface that actually sent the packets out, it looked like > > this: > > > > ######################################## > > # tcpdump -i ix2 -n -s 0 -e ether host 00:23:ae:a5:00:ef > > tcpdump: WARNING: ix2: no IPv4 address assigned > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on ix2, link-type EN10MB (Ethernet), capture size 65535 bytes > > 10:00:58.215838 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 0, length 16 > > 10:00:58.215861 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 0, length 16 > > 10:00:59.207067 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 1, length 16 > > 10:00:59.207081 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 1, length 16 > > 10:01:00.206484 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 2, length 16 > > 10:01:00.206497 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 2, length 16 > > 10:01:01.206899 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 3, length 16 > > 10:01:01.206913 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 3, length 16 > > 10:01:02.206355 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 4, length 16 > > 10:01:02.206368 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 4, length 16 > > 10:01:03.168187 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor solicitation, who has > > fe80::21b:21ff:fe57:b420, length 32 > > 10:01:03.168210 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, neighbor advertisement, tgt is > > fe80::21b:21ff:fe57:b420, length 24 > > 10:01:03.206828 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 5, length 16 > > 10:01:03.206838 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 5, length 16 > > 10:01:03.215445 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, neighbor solicitation, who has > > fe80::223:aeff:fea5:ef, length 32 > > 10:01:03.215604 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor advertisement, tgt is > > fe80::223:aeff:fea5:ef, length 24 > > 10:01:04.206307 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 6, length 16 > > 10:01:04.206321 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 6, length 16 > > 10:01:05.206739 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 7, length 16 > > 10:01:05.206751 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 7, length 16 > > 10:01:06.206181 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 8, length 16 > > 10:01:06.206194 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::21b:21ff:fe57:b420 > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 8, length 16 > > 10:01:07.206772 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, fe80::223:aeff:fea5:ef > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 9, length 16 > > ######################################## > > > > You can see that there is only one vlan tag. > > > > You can also see that all of these were sent out on vlan 1, while by the > > time they arrive on the mirrored port some have been mangled to vlan 8. > > > > This is after updating to the new driver that was merged today. It seems > > that I do not need routing anymore for this condition to happen. Just a > > ping to the link-local address triggers it. > > > > I did this from another machine: > > > > ######################################## > > # ping6 fe80::21b:21ff:fe57:b420%em0 > > PING6(56=40+8+8 bytes) fe80::223:aeff:fea5:ef%em0 --> > > fe80::21b:21ff:fe57:b420%em0 > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=5 hlim=64 time=0.180 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=6 hlim=64 time=0.134 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=7 hlim=64 time=0.145 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=8 hlim=64 time=0.169 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=33 hlim=64 time=0.135 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=34 hlim=64 time=0.145 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=35 hlim=64 time=0.151 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=36 hlim=64 time=0.166 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=37 hlim=64 time=0.159 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=38 hlim=64 time=0.147 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=39 hlim=64 time=0.146 > > ms > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=40 hlim=64 time=0.213 > > ms > > ^C > > --- fe80::21b:21ff:fe57:b420%em0 ping6 statistics --- > > 41 packets transmitted, 12 packets received, 70.7% packet loss > > round-trip min/avg/max/std-dev = 0.134/0.158/0.213/0.021 ms > > ######################################## > > > > Currently the configs look like this: > > > > ######################################## > > mr3# ifconfig ix2 > > ix2: flags=8843 metric 0 mtu 1500 > > options=1b8 > > ether 00:1b:21:57:ef:7c > > inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 > > nd6 options=3 > > media: Ethernet autoselect (10Gbase-SR ) > > status: active > > mr3# ifconfig ix3 > > ix3: flags=8843 metric 0 mtu 1500 > > > > options=1bb > > ether 00:1b:21:57:ef:7d > > inet6 fe80::21b:21ff:fe57:ef7d%ix3 prefixlen 64 scopeid 0x4 > > nd6 options=3 > > media: Ethernet autoselect (10Gbase-SR ) > > status: active > > mr3# ifconfig ix2.1 > > ix2.1: flags=8843 metric 0 mtu 1500 > > ether 00:1b:21:57:ef:7c > > inet 146.64.28.2 netmask 0xffffff00 broadcast 146.64.28.255 > > inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0xa > > inet6 2001:4200:7000:3:21b:21ff:fe57:b420 prefixlen 64 > > inet6 2001:4200:7000:3:: prefixlen 64 anycast > > nd6 options=3 > > media: Ethernet autoselect (10Gbase-SR ) > > status: active > > vlan: 1 parent interface: ix2 > > mr3# ifconfig ix2.8 > > ix2.8: flags=8843 metric 0 mtu 1500 > > ether 00:1b:21:57:ef:7c > > inet 146.64.8.50 netmask 0xffffff00 broadcast 146.64.8.255 > > inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xb > > inet6 2001:4200:7000:1:21b:21ff:fe57:b420 prefixlen 64 > > inet6 2001:4200:7000:1:: prefixlen 64 anycast > > nd6 options=3 > > media: Ethernet autoselect (10Gbase-SR ) > > status: active > > vlan: 8 parent interface: ix2 > > > > ######################################## > > > > John > > -- > > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > > From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 15:01:47 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91A2A106566C; Sun, 28 Nov 2010 15:01:47 +0000 (UTC) (envelope-from cperciva@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 672078FC15; Sun, 28 Nov 2010 15:01:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oASF1lSo072000; Sun, 28 Nov 2010 15:01:47 GMT (envelope-from cperciva@freefall.freebsd.org) Received: (from cperciva@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oASF1lsC071996; Sun, 28 Nov 2010 15:01:47 GMT (envelope-from cperciva) Date: Sun, 28 Nov 2010 15:01:47 GMT Message-Id: <201011281501.oASF1lsC071996@freefall.freebsd.org> To: cperciva@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-xen@FreeBSD.org From: cperciva@FreeBSD.org Cc: Subject: Re: kern/148780: [panic] mtx_lock() of spin mutex (null) @ /usr/src/sys/net/netisr.c:830 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, 28 Nov 2010 15:01:47 -0000 Synopsis: [panic] mtx_lock() of spin mutex (null) @ /usr/src/sys/net/netisr.c:830 Responsible-Changed-From-To: freebsd-net->freebsd-xen Responsible-Changed-By: cperciva Responsible-Changed-When: Sun Nov 28 14:59:04 UTC 2010 Responsible-Changed-Why: This is actually a FreeBSD/Xen bug. Somehow the pcpu data is being mangled in the presence of VM pressure; the panic shows up in netisr because netisr looks up a per-cpu data structure (and locks it, hence the locking assertion). http://www.freebsd.org/cgi/query-pr.cgi?pr=148780 From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 05:20: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 EE0791065670; Mon, 29 Nov 2010 05:20:26 +0000 (UTC) (envelope-from cperciva@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C36998FC0A; Mon, 29 Nov 2010 05:20: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 oAT5KQvh061318; Mon, 29 Nov 2010 05:20:26 GMT (envelope-from cperciva@freefall.freebsd.org) Received: (from cperciva@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAT5KQfr061308; Mon, 29 Nov 2010 05:20:26 GMT (envelope-from cperciva) Date: Mon, 29 Nov 2010 05:20:26 GMT Message-Id: <201011290520.oAT5KQfr061308@freefall.freebsd.org> To: cperciva@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-xen@FreeBSD.org From: cperciva@FreeBSD.org Cc: Subject: Re: kern/148862: [panic] page fault while in kernel mode at _mtx_lock_sleep 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, 29 Nov 2010 05:20:27 -0000 Synopsis: [panic] page fault while in kernel mode at _mtx_lock_sleep Responsible-Changed-From-To: freebsd-net->freebsd-xen Responsible-Changed-By: cperciva Responsible-Changed-When: Mon Nov 29 05:19:21 UTC 2010 Responsible-Changed-Why: This is a Xen bug, not a network stack bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=148862 From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 11:07:06 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C4E1065695 for ; Mon, 29 Nov 2010 11:07:06 +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 44C448FC13 for ; Mon, 29 Nov 2010 11:07:06 +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 oATB76rS053145 for ; Mon, 29 Nov 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oATB75Fp053143 for freebsd-net@FreeBSD.org; Mon, 29 Nov 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Nov 2010 11:07:05 GMT Message-Id: <201011291107.oATB75Fp053143@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, 29 Nov 2010 11:07:06 -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/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 368 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 17:52:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CD1E1065670 for ; Mon, 29 Nov 2010 17:52:04 +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 951068FC18 for ; Mon, 29 Nov 2010 17:52:03 +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 ED9A0258889C; Mon, 29 Nov 2010 15:51:47 -0200 (BRST) Message-ID: <4CF3E833.5040507@ntelecom.com.br> Date: Mon, 29 Nov 2010 15:51:47 -0200 From: "Tobias P. Santos" User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: Nikos Vassiliadis References: <20101128010732.229640@gmx.com> In-Reply-To: <20101128010732.229640@gmx.com> 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 Cc: freebsd-net@freebsd.org Subject: Re: 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: Mon, 29 Nov 2010 17:52:04 -0000 >> [...] >> >> route add -net 192.168.0.100 192.168.0.200 255.255.255.255 1 >> >> Destination Gateway Flags Refs Use Netif Expire >> 0.0.0.0&0x1 192.168.0.200 UGS 0 0 bge > Try: > route delete 0.0.0.0 -netmask 0.0.0.1 > It worked! > [...] > A 0.0.0.0/0.0.0.1 route matches every IP with bit 0 clear and is > half the size of a 0.0.0.0/0.0.0.0 route - which is pretty big. > Something like: > 0.0.0.0 > 0.0.0.2 > 0.0.0.4 > ... > 255.255.255.252 > 255.255.255.254 > > HTH, Nikos > I agree. What I don't understand is how the command I typed could become 0.0.0.0/0.0.0.1 in the routing table. Thank you, Tobias. From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 17:54: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 7DB19106564A for ; Mon, 29 Nov 2010 17:54:57 +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 050B58FC13 for ; Mon, 29 Nov 2010 17:54:56 +0000 (UTC) Received: by wwf26 with SMTP id 26so514387wwf.31 for ; Mon, 29 Nov 2010 09:54: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=TidEnPMSem3U3uYzsHWFKYLD2S1XGEn9j1A44OkHOMM=; b=Kg1tiolIXet4i5HR6MeXzDW6/tISOc8Mm4ccmfB11eJnNmzK78QIwBj1ClJLiOJCb/ zZMPFcRPry42Ot8yK1GwBgn63VDic4zafLN+BoQZXeQB8EVBY0JeL0ODffl6yTyoOBIv P2+twzSgp5HjMfOcKEmPC9vXM4BeDcjOhJN/c= 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=rJWdVPxru3pr6hikL1PNmF2pKxsYW5oUAxVjpXoBIUKKoxFOzd3FJlUA5jImJSjd+5 RFEtOojEb0nUcj8J2vtGeWaPYjSJaUTkkpoI14hWoGJv6FnAbIn1Uku8TGW2y3umd+qL XfjegO+48XM+rkN2cWZBLQJ4HqwhdLAXPX+XA= MIME-Version: 1.0 Received: by 10.216.179.210 with SMTP id h60mr1189358wem.42.1291053295905; Mon, 29 Nov 2010 09:54:55 -0800 (PST) Received: by 10.216.2.206 with HTTP; Mon, 29 Nov 2010 09:54:55 -0800 (PST) In-Reply-To: <20101129175128.GA32977@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101129175128.GA32977@rdtc.ru> Date: Mon, 29 Nov 2010 09:54:55 -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 Subject: Re: em(4) updated to version 7.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 17:54:57 -0000 Thanks for reporting that, will see it gets fixed! Jack On Mon, Nov 29, 2010 at 9:51 AM, Eugene Grosbein wrote: > Hi! > > I've just noticed new sysctl named flow_control has wrong description > due to obvious cut-n-paste 'cosmetic' error :-) > > em_add_rx_process_limit(adapter, "rx_processing_limit", > > "max number of rx packets to process", > &adapter->rx_process_limit, > em_rx_process_limit); > > + /* Sysctl for setting the interface flow control */ > + em_set_flow_cntrl(adapter, "flow_control", > > + "max number of rx packets to process", > + &adapter->fc_setting, em_fc_setting); > + > > Eugene Grosbein > From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 18:10: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 90BFA106564A for ; Mon, 29 Nov 2010 18:10:37 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA218FC1E for ; Mon, 29 Nov 2010 18:10:36 +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 oATHpSjR033008; Mon, 29 Nov 2010 23:51:28 +0600 (NOVT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.4/8.14.4/Submit) id oATHpS3w033007; Mon, 29 Nov 2010 23:51:28 +0600 (NOVT) (envelope-from eugen) Date: Mon, 29 Nov 2010 23:51:28 +0600 From: Eugene Grosbein To: Jack Vogel Message-ID: <20101129175128.GA32977@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net Subject: em(4) updated to version 7.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 18:10:37 -0000 Hi! I've just noticed new sysctl named flow_control has wrong description due to obvious cut-n-paste 'cosmetic' error :-) em_add_rx_process_limit(adapter, "rx_processing_limit", > "max number of rx packets to process", &adapter->rx_process_limit, em_rx_process_limit); + /* Sysctl for setting the interface flow control */ + em_set_flow_cntrl(adapter, "flow_control", > + "max number of rx packets to process", + &adapter->fc_setting, em_fc_setting); + Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 18:26: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 CB2301065672 for ; Mon, 29 Nov 2010 18:26:54 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 1074F8FC15 for ; Mon, 29 Nov 2010 18:26:53 +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 oATIQq5A033192; Tue, 30 Nov 2010 00:26:52 +0600 (NOVT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.4/8.14.4/Submit) id oATIQqjl033191; Tue, 30 Nov 2010 00:26:52 +0600 (NOVT) (envelope-from eugen) Date: Tue, 30 Nov 2010 00:26:52 +0600 From: Eugene Grosbein To: Jack Vogel Message-ID: <20101129182652.GA33150@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101129175128.GA32977@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 , Eugene Grosbein Subject: Re: em(4) updated to version 7.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 18:26:54 -0000 On Mon, Nov 29, 2010 at 09:54:55AM -0800, Jack Vogel wrote: > Thanks for reporting that, will see it gets fixed! More serious problem. I had experienced kernel panics for two em(4)-based heavy loaded routers. I've checked PR database and found this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=150920 I've found the same lack of NULL pointer check in em(4), applied following patch to if_em.c and panics have gone. It seems for me that new driver code still has this problem, now this code resides inside em_rx_discard() function. Please take a look. --- if_em.c.orig 2010-11-02 15:45:56.000000000 +0600 +++ if_em.c 2010-11-08 14:24:46.000000000 +0600 @@ -4181,9 +4181,11 @@ ifp->if_ierrors++; /* Reuse loaded DMA map and just update mbuf chain */ mp = rxr->rx_buffers[i].m_head; + if(mp) { mp->m_len = mp->m_pkthdr.len = MCLBYTES; mp->m_data = mp->m_ext.ext_buf; mp->m_next = NULL; + } if (adapter->max_frame_size <= (MCLBYTES - ETHER_ALIGN)) m_adj(mp, ETHER_ALIGN); Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 19:10:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49EE4106566B for ; Mon, 29 Nov 2010 19:10:34 +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 C91418FC17 for ; Mon, 29 Nov 2010 19:10:33 +0000 (UTC) Received: by wwf26 with SMTP id 26so583844wwf.31 for ; Mon, 29 Nov 2010 11:10:32 -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=wXIJ43SoM6FenEvnGd1IaYHJF/jgpU9I2/NDB0Ma/fM=; b=CZ7l94zTe6+Y8ElSLExuE35dDv/Hf5PEAm+SlLPF5sne023xr5aNlj7VBbtN/L7oPe uYl5k60bmTzA2tcsQ8U5UQuBeSz2t60qaj2pvpxXZmb7DyHGzUCbjY+2Qsg+SDt8lUlH 82K8Kbk3duRJm3ufwEaE5iqKHwn80aNgHH7FM= 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=Q7sRPpJrOUlNvoA36trP10AVRej6cwLz+Gw+YXwLH418r+fEUm8ukL0V+RRHJxtN2W fSr1zzP8Y7Je9pWp+VDmxTwDzq5Y7Wn7gAv5r7ZTxXtUaqRoMWRbaho32UDduOiO7n1C 8JVW2nSecsqZWQDHV9ZzgWTKFr0ynDixNA3lY= MIME-Version: 1.0 Received: by 10.216.59.193 with SMTP id s43mr815194wec.42.1291057831618; Mon, 29 Nov 2010 11:10:31 -0800 (PST) Received: by 10.216.2.206 with HTTP; Mon, 29 Nov 2010 11:10:22 -0800 (PST) In-Reply-To: <20101129182652.GA33150@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101129175128.GA32977@rdtc.ru> <20101129182652.GA33150@rdtc.ru> Date: Mon, 29 Nov 2010 11:10:22 -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 Subject: Re: em(4) updated to version 7.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 19:10:34 -0000 Not sure what code you created this from, but its not the new driver, things have been reorganized and I do not believe this issue exists. Please test with the latest. Jack On Mon, Nov 29, 2010 at 10:26 AM, Eugene Grosbein wrote: > On Mon, Nov 29, 2010 at 09:54:55AM -0800, Jack Vogel wrote: > > > Thanks for reporting that, will see it gets fixed! > > More serious problem. I had experienced kernel panics for two em(4)-based > heavy loaded routers. I've checked PR database and found this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=150920 > > I've found the same lack of NULL pointer check in em(4), > applied following patch to if_em.c and panics have gone. > It seems for me that new driver code still has this problem, > now this code resides inside em_rx_discard() function. > Please take a look. > > --- if_em.c.orig 2010-11-02 15:45:56.000000000 +0600 > +++ if_em.c 2010-11-08 14:24:46.000000000 +0600 > @@ -4181,9 +4181,11 @@ > ifp->if_ierrors++; > /* Reuse loaded DMA map and just update mbuf chain > */ > mp = rxr->rx_buffers[i].m_head; > + if(mp) { > mp->m_len = mp->m_pkthdr.len = MCLBYTES; > mp->m_data = mp->m_ext.ext_buf; > mp->m_next = NULL; > + } > if (adapter->max_frame_size <= > (MCLBYTES - ETHER_ALIGN)) > m_adj(mp, ETHER_ALIGN); > > > Eugene Grosbein > From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 19:10: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 299EA1065693 for ; Mon, 29 Nov 2010 19:10:53 +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 A887F8FC15 for ; Mon, 29 Nov 2010 19:10:52 +0000 (UTC) Received: by mail-ww0-f50.google.com with SMTP id 26so583844wwf.31 for ; Mon, 29 Nov 2010 11:10:52 -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=+DS99DfDSyivEZ/YEFw5Xh0MNAOIAS4+lBYEoexPQQc=; b=gPQ9pXvvPwG9xUIFCJMDdBoC3kf1JXq+L+UgFIYPN8A3rTuTjfXnuTcqNH7d0OcCzW Iad+9hjFHYYywEoK1/de3ykxGxgIUtaQhd/a7HA0Tr2o00TB7f3kZJy+ocY09zatiifA p+oE4WQV4416ae4mQkwX3COKQJkaUclb1Y+Iw= 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=YFxE/yrLeH8PNsy6IMIrJZLYLZ/3PcBA7qidjcxjUqkgkJj+nqzj2jNe1JIX5J8eHu wF+2rSwIyzasDOq+spbRCFy0w8hm74MeAFwXK/nUvPyn9AUWfGuOgObHMIiJgbFfE2FT OdnSdUZdxmtDeWxxBqAtt//QV5HBsutPdUfCU= MIME-Version: 1.0 Received: by 10.216.3.3 with SMTP id 3mr808169weg.57.1291057830115; Mon, 29 Nov 2010 11:10:30 -0800 (PST) Received: by 10.216.2.206 with HTTP; Mon, 29 Nov 2010 11:10:22 -0800 (PST) In-Reply-To: <20101129182652.GA33150@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101129175128.GA32977@rdtc.ru> <20101129182652.GA33150@rdtc.ru> Date: Mon, 29 Nov 2010 11:10:22 -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 Subject: Re: em(4) updated to version 7.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 19:10:53 -0000 Not sure what code you created this from, but its not the new driver, things have been reorganized and I do not believe this issue exists. Please test with the latest. Jack On Mon, Nov 29, 2010 at 10:26 AM, Eugene Grosbein wrote: > On Mon, Nov 29, 2010 at 09:54:55AM -0800, Jack Vogel wrote: > > > Thanks for reporting that, will see it gets fixed! > > More serious problem. I had experienced kernel panics for two em(4)-based > heavy loaded routers. I've checked PR database and found this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=150920 > > I've found the same lack of NULL pointer check in em(4), > applied following patch to if_em.c and panics have gone. > It seems for me that new driver code still has this problem, > now this code resides inside em_rx_discard() function. > Please take a look. > > --- if_em.c.orig 2010-11-02 15:45:56.000000000 +0600 > +++ if_em.c 2010-11-08 14:24:46.000000000 +0600 > @@ -4181,9 +4181,11 @@ > ifp->if_ierrors++; > /* Reuse loaded DMA map and just update mbuf chain > */ > mp = rxr->rx_buffers[i].m_head; > + if(mp) { > mp->m_len = mp->m_pkthdr.len = MCLBYTES; > mp->m_data = mp->m_ext.ext_buf; > mp->m_next = NULL; > + } > if (adapter->max_frame_size <= > (MCLBYTES - ETHER_ALIGN)) > m_adj(mp, ETHER_ALIGN); > > > Eugene Grosbein > From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 19:23: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 DE356106564A for ; Mon, 29 Nov 2010 19:23:16 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 242608FC1F for ; Mon, 29 Nov 2010 19:23:15 +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 oATJNCdw033638; Tue, 30 Nov 2010 01:23:12 +0600 (NOVT) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.4/8.14.4/Submit) id oATJNCZV033637; Tue, 30 Nov 2010 01:23:12 +0600 (NOVT) (envelope-from eugen) Date: Tue, 30 Nov 2010 01:23:12 +0600 From: Eugene Grosbein To: Jack Vogel Message-ID: <20101129192312.GA33547@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101129175128.GA32977@rdtc.ru> <20101129182652.GA33150@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 , Eugene Grosbein Subject: Re: em(4) updated to version 7.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 19:23:16 -0000 On Mon, Nov 29, 2010 at 11:10:22AM -0800, Jack Vogel wrote: > Not sure what code you created this from, but its not the new driver, Yes, that's for previous version and that's what keeps my production servers from panicing. > things have been reorganized and I do not believe this issue exists. > Please test with the latest. I'd rather not risk. Here is the same check for today's RELENG_8 driver. Please, please take a look. After several days of nearly gigabit load it has already happened m_head was NULL here, in previous version. Can it be possible in current version? There is still no check before dereferencing. --- if_em.c.orig 2010-11-30 01:16:17.000000000 +0600 +++ if_em.c 2010-11-30 01:19:09.000000000 +0600 @@ -4321,10 +4321,12 @@ /* Reset state, keep loaded DMA map and reuse */ m = rbuf->m_head; + if(m) { m->m_len = m->m_pkthdr.len = adapter->rx_mbuf_sz; m->m_flags |= M_PKTHDR; m->m_data = m->m_ext.ext_buf; m->m_next = NULL; + } return; } From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 19:50: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 3D3F9106566C for ; Mon, 29 Nov 2010 19:50:26 +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 BD69D8FC13 for ; Mon, 29 Nov 2010 19:50:21 +0000 (UTC) Received: by wyf19 with SMTP id 19so4746582wyf.13 for ; Mon, 29 Nov 2010 11:50:20 -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=9Y/uh0hAGNxNJEcPitjFGrtdrWp91+WGR+3HpvtCtAU=; b=Z+vVjTuJrs1DccoC8i8jXMY6Swos/azJJyjhAZJ0gV/ZzMXsQ5xiNCDtXFZUDs9NAS BBOYgbw8szcnauWJYsJhqwQ9M4MOulu0RxRyI/E0nuymu16L9dCURbpbVdjuaS0QVFsN PYZXtQRiWbmFWApmaIMBMpxniF8QGJ4/0wKdw= 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=vVax57sEX3FZnHmyd4Jsv5E1mXL0LydtGMqN+JBUYnNHqZccSo/4ySdwHWImVd7BIT lTPNCsdAOV6Y5M6faaguJMJg5qJK+uHF2YeFcI3m1mP2d3EpZYN+zexiXMWE80XaDChA CYAEF/UtK+0aQNbyaznGnu/iLaeIzsgBmZmaw= MIME-Version: 1.0 Received: by 10.216.3.3 with SMTP id 3mr862702weg.57.1291060219796; Mon, 29 Nov 2010 11:50:19 -0800 (PST) Received: by 10.216.2.206 with HTTP; Mon, 29 Nov 2010 11:50:19 -0800 (PST) In-Reply-To: <20101129192312.GA33547@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101129175128.GA32977@rdtc.ru> <20101129182652.GA33150@rdtc.ru> <20101129192312.GA33547@rdtc.ru> Date: Mon, 29 Nov 2010 11:50:19 -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 Subject: Re: em(4) updated to version 7.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 19:50:26 -0000 True, there is no check, I do not see a way in which the mbuf pointer should be NULL, however, perhaps I should change things to follow what the igb driver does, always checking for NULL and freeing the existing mbuf to allow em_refresh_mbufs() to repop. If you say you have had panics then there must be a path to have it NULL. Jack On Mon, Nov 29, 2010 at 11:23 AM, Eugene Grosbein wrote: > On Mon, Nov 29, 2010 at 11:10:22AM -0800, Jack Vogel wrote: > > > Not sure what code you created this from, but its not the new driver, > > Yes, that's for previous version and that's what keeps my production > servers from panicing. > > > things have been reorganized and I do not believe this issue exists. > > Please test with the latest. > > I'd rather not risk. Here is the same check for today's RELENG_8 driver. > Please, please take a look. After several days of nearly gigabit load > it has already happened m_head was NULL here, in previous version. > Can it be possible in current version? > There is still no check before dereferencing. > > --- if_em.c.orig 2010-11-30 01:16:17.000000000 +0600 > +++ if_em.c 2010-11-30 01:19:09.000000000 +0600 > @@ -4321,10 +4321,12 @@ > > /* Reset state, keep loaded DMA map and reuse */ > m = rbuf->m_head; > + if(m) { > m->m_len = m->m_pkthdr.len = adapter->rx_mbuf_sz; > m->m_flags |= M_PKTHDR; > m->m_data = m->m_ext.ext_buf; > m->m_next = NULL; > + } > > return; > } > From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 20:08: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 3AF041065672 for ; Mon, 29 Nov 2010 20:08:00 +0000 (UTC) (envelope-from jfvogel@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 67A938FC08 for ; Mon, 29 Nov 2010 20:07:59 +0000 (UTC) Received: by eyb7 with SMTP id 7so2352112eyb.13 for ; Mon, 29 Nov 2010 12:07:58 -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=SvYhynHlrWIOs7FEukKKrdhptTMDDlsTySsHBNRFIxI=; b=noKs6cB/bpIqMe1KKvwNagDcrGg3k1MFfcefgZ3DEnjd0P3Nbh1GqNsxuAYpoy5Boy /KFFiYi+XuQaGwKRpwnFk9KA3Lt4vbiZEhIWSkuLY84lED4ReIJytGbbg2ByY8cxiPqD WkpvzakvuJ9JpK+ZDxj2SofKNq49DecuZ3lJE= 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=KrrFlokL7wZOY+hmpOZyBgHJq40P0TGUIPhZjQR1rmydTAedtav47p93uOjNa1arUG aXpnF9XH5zHxwkdX7hfhbc3tOv7s36MmJ/OoZW5bKfa1Td45NBJeGgDDhmmgoXi86ND0 VjzrLCoRpTgMcHQneYhbZcCJXvTxEOOQ7bbjI= MIME-Version: 1.0 Received: by 10.216.179.210 with SMTP id h60mr1371396wem.42.1291061278011; Mon, 29 Nov 2010 12:07:58 -0800 (PST) Received: by 10.216.2.206 with HTTP; Mon, 29 Nov 2010 12:07:57 -0800 (PST) In-Reply-To: <20101128101702.GA1574@zibbi.meraka.csir.co.za> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101128101702.GA1574@zibbi.meraka.csir.co.za> Date: Mon, 29 Nov 2010 12:07:57 -0800 Message-ID: From: Jack Vogel To: John Hay Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 29 Nov 2010 20:08:00 -0000 You use `ifconfig ix0 vlanhwfilter`, its off by default, I assume you're using the new driver code from either HEAD or STABLE/8 now, right? Try another experiment please: at line 4232 is a condition: if ((adapter->num_vlans) &&... Change that to: if ((vtag) && .... See if either of those change things. Jack On Sun, Nov 28, 2010 at 2:17 AM, John Hay wrote: > On Sun, Nov 28, 2010 at 01:19:07AM -0800, Jack Vogel wrote: > > Well, its not solving this odd vlan tag change problem, that isn't what > the > > workaround was about, at least I dont see how to connect them. > > Yes, but I still see the double vlan tags on the mirror port that I > connected to ix3, which is what Ryan reported? > > > So you arent using HW Filters? or does that just not show up in the > ifconfig > > display? > > Which HW Filters? I have -rxcsum -lro from previous debugging. I can > turn it on again. Or are there others that I do not know about? > > John > > > > > Jack > > > > > > On Sun, Nov 28, 2010 at 12:16 AM, John Hay wrote: > > > > > Hi Jack, > > > > > > On Sat, Nov 27, 2010 at 09:59:10AM -0800, Jack Vogel wrote: > > > > 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. > > > > > > I don't think your solution / workaround work in every case. To debug > my > > > other vlan + ipv6 problem, I have configured a mirrored port on the > switch > > > and connected that to one of the ixgbe interfaces with no vlans > configured > > > on it. Packets dumped on it looks like this: > > > > > > ######################################### > > > # tcpdump -i ix3 -n -s 0 -e ether host 00:23:ae:a5:00:ef > > > tcpdump: WARNING: ix3: no IPv4 address assigned > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > > > listening on ix3, link-type EN10MB (Ethernet), capture size 65535 bytes > > > 10:00:58.215870 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 0, length 16 > > > 10:00:59.207090 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 1, length 16 > > > 10:01:00.206506 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 2, length 16 > > > 10:01:01.206923 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 3, length 16 > > > 10:01:02.206378 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 4, length 16 > > > 10:01:03.168219 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 86: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, > neighbor > > > advertisement, tgt is fe80::21b:21ff:fe57:b420, length 24 > > > 10:01:03.206846 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 5, length 16 > > > 10:01:03.215452 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 94: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, > neighbor > > > solicitation, who has fe80::223:aeff:fea5:ef, length 32 > > > 10:01:04.206331 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 6, length 16 > > > 10:01:05.206760 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 7, length 16 > > > 10:01:06.206203 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 8, length 16 > > > 10:01:07.206794 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > ethertype > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > reply, > > > seq 9, length 16 > > > ######################################## > > > > > > On the base interface that actually sent the packets out, it looked > like > > > this: > > > > > > ######################################## > > > # tcpdump -i ix2 -n -s 0 -e ether host 00:23:ae:a5:00:ef > > > tcpdump: WARNING: ix2: no IPv4 address assigned > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > > > listening on ix2, link-type EN10MB (Ethernet), capture size 65535 bytes > > > 10:00:58.215838 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 0, length 16 > > > 10:00:58.215861 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 0, length 16 > > > 10:00:59.207067 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 1, length 16 > > > 10:00:59.207081 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 1, length 16 > > > 10:01:00.206484 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 2, length 16 > > > 10:01:00.206497 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 2, length 16 > > > 10:01:01.206899 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 3, length 16 > > > 10:01:01.206913 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 3, length 16 > > > 10:01:02.206355 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 4, length 16 > > > 10:01:02.206368 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 4, length 16 > > > 10:01:03.168187 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor solicitation, who has > > > fe80::21b:21ff:fe57:b420, length 32 > > > 10:01:03.168210 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, neighbor advertisement, tgt is > > > fe80::21b:21ff:fe57:b420, length 24 > > > 10:01:03.206828 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 5, length 16 > > > 10:01:03.206838 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 5, length 16 > > > 10:01:03.215445 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, neighbor solicitation, who has > > > fe80::223:aeff:fea5:ef, length 32 > > > 10:01:03.215604 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor advertisement, tgt is > > > fe80::223:aeff:fea5:ef, length 24 > > > 10:01:04.206307 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 6, length 16 > > > 10:01:04.206321 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 6, length 16 > > > 10:01:05.206739 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 7, length 16 > > > 10:01:05.206751 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 7, length 16 > > > 10:01:06.206181 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 8, length 16 > > > 10:01:06.206194 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::21b:21ff:fe57:b420 > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 8, length 16 > > > 10:01:07.206772 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > fe80::223:aeff:fea5:ef > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 9, length 16 > > > ######################################## > > > > > > You can see that there is only one vlan tag. > > > > > > You can also see that all of these were sent out on vlan 1, while by > the > > > time they arrive on the mirrored port some have been mangled to vlan 8. > > > > > > This is after updating to the new driver that was merged today. It > seems > > > that I do not need routing anymore for this condition to happen. Just a > > > ping to the link-local address triggers it. > > > > > > I did this from another machine: > > > > > > ######################################## > > > # ping6 fe80::21b:21ff:fe57:b420%em0 > > > PING6(56=40+8+8 bytes) fe80::223:aeff:fea5:ef%em0 --> > > > fe80::21b:21ff:fe57:b420%em0 > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=5 hlim=64 > time=0.180 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=6 hlim=64 > time=0.134 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=7 hlim=64 > time=0.145 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=8 hlim=64 > time=0.169 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=33 hlim=64 > time=0.135 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=34 hlim=64 > time=0.145 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=35 hlim=64 > time=0.151 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=36 hlim=64 > time=0.166 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=37 hlim=64 > time=0.159 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=38 hlim=64 > time=0.147 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=39 hlim=64 > time=0.146 > > > ms > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=40 hlim=64 > time=0.213 > > > ms > > > ^C > > > --- fe80::21b:21ff:fe57:b420%em0 ping6 statistics --- > > > 41 packets transmitted, 12 packets received, 70.7% packet loss > > > round-trip min/avg/max/std-dev = 0.134/0.158/0.213/0.021 ms > > > ######################################## > > > > > > Currently the configs look like this: > > > > > > ######################################## > > > mr3# ifconfig ix2 > > > ix2: flags=8843 metric 0 mtu > 1500 > > > options=1b8 > > > ether 00:1b:21:57:ef:7c > > > inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 > > > nd6 options=3 > > > media: Ethernet autoselect (10Gbase-SR ) > > > status: active > > > mr3# ifconfig ix3 > > > ix3: flags=8843 metric 0 mtu > 1500 > > > > > > > options=1bb > > > ether 00:1b:21:57:ef:7d > > > inet6 fe80::21b:21ff:fe57:ef7d%ix3 prefixlen 64 scopeid 0x4 > > > nd6 options=3 > > > media: Ethernet autoselect (10Gbase-SR ) > > > status: active > > > mr3# ifconfig ix2.1 > > > ix2.1: flags=8843 metric 0 mtu > 1500 > > > ether 00:1b:21:57:ef:7c > > > inet 146.64.28.2 netmask 0xffffff00 broadcast 146.64.28.255 > > > inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0xa > > > inet6 2001:4200:7000:3:21b:21ff:fe57:b420 prefixlen 64 > > > inet6 2001:4200:7000:3:: prefixlen 64 anycast > > > nd6 options=3 > > > media: Ethernet autoselect (10Gbase-SR ) > > > status: active > > > vlan: 1 parent interface: ix2 > > > mr3# ifconfig ix2.8 > > > ix2.8: flags=8843 metric 0 mtu > 1500 > > > ether 00:1b:21:57:ef:7c > > > inet 146.64.8.50 netmask 0xffffff00 broadcast 146.64.8.255 > > > inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xb > > > inet6 2001:4200:7000:1:21b:21ff:fe57:b420 prefixlen 64 > > > inet6 2001:4200:7000:1:: prefixlen 64 anycast > > > nd6 options=3 > > > media: Ethernet autoselect (10Gbase-SR ) > > > status: active > > > vlan: 8 parent interface: ix2 > > > > > > ######################################## > > > > > > John > > > -- > > > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > > > > From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 23:25: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 9A63E106566B; Mon, 29 Nov 2010 23:25:09 +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 845128FC14; Mon, 29 Nov 2010 23:25:08 +0000 (UTC) Received: by wwf26 with SMTP id 26so833962wwf.31 for ; Mon, 29 Nov 2010 15:25:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.231.82 with SMTP id k60mr5446258weq.64.1291073106160; Mon, 29 Nov 2010 15:25:06 -0800 (PST) Received: by 10.216.39.198 with HTTP; Mon, 29 Nov 2010 15:25:06 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Nov 2010 13:25:06 -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: Mon, 29 Nov 2010 23:25:09 -0000 I rebuilt from a tree checked out nov 1, 2010 and rebuilt hostapd and it works now, so it looks like the import did break it 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 Tue Nov 30 04: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 9A03A1065670 for ; Tue, 30 Nov 2010 04:04:58 +0000 (UTC) (envelope-from adrian.chadd@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 D2C7D8FC0A for ; Tue, 30 Nov 2010 04:04:57 +0000 (UTC) Received: by wwf26 with SMTP id 26so878442wwf.1 for ; Mon, 29 Nov 2010 20:04:56 -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=djJlrxEZ+9IlVXvEEoPDTu1u63me8AdJZU94Rnhv5pk=; b=Agkmz2WR8zkXlOVppDP+Qlnskb/JNE4xRSzdFFaF9ZRYPFqMtfn2Hx0OMUHdMfuhO4 ujIa6TAEXC5VMlEFch6eBDQKM7UJMIZvDv8BX7hVqpUvMc4rrSPC8USVkQfFAmOksI7o BOrlXI+k8yuyn1jL9a3KYB16S7mNKPmBUOfLo= 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=Fw950HrgcLF7XpZaas8CT5e7ic77jVHhq8X4p3yYCyRzniU7rUmNyY5+9GVe9rJKG+ kXvzfx/o9d1lK1weIWZUg31O7KHaQTgQJIagomxe+zKk3hGJNyzeBMYPz/dFFmuOzr3i 7Pow5YlZOxExMgABFWjElCkIqLAcd9hMtQI6k= MIME-Version: 1.0 Received: by 10.227.142.133 with SMTP id q5mr7008714wbu.3.1291089896815; Mon, 29 Nov 2010 20:04:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Mon, 29 Nov 2010 20:04:56 -0800 (PST) In-Reply-To: References: Date: Tue, 30 Nov 2010 12:04:56 +0800 X-Google-Sender-Auth: MeQP9vM56QdQEqs6-czSb5F2Ty4 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: Tue, 30 Nov 2010 04:04:58 -0000 Would you please create a PR for it? Rui hasgiven me a pointer where to look at fixing it so I'll include that in the PR. Adrian On 30 November 2010 07:25, David Cornejo wrote: > I rebuilt from a tree checked out nov 1, 2010 and rebuilt hostapd and it > works now, so it looks like the import did break it > > 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. =A0From a Windows 7 machine it complains that there i= s a >> > network key mismatch. =A0I've checked it, changed it, and still no dic= e. >> > =A0I >> > took the debug output from hostapd and find two odd things: =A0first t= here >> > is >> > a "frame too short for this IEEE 802.1X packet" message, and then I se= e >> > "ioctl[SIOCS80211]: No such file or directory" messages. =A0The rc.con= f >> > and >> > hostapd.conf are copied direct from a similar device compiled in >> > February >> > which works fine. =A0I also used the same wlan_* options from the earl= ier >> > 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.conf >> > 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= _len=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= _len=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= _len=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= _len=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= _len=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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f5 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 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: ST= A >> > 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f6 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 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: ST= A >> > 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f7 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 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: ST= A >> > 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f8 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 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: ST= A >> > 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 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 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 pai= rwise=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 4= a >> > b6 >> > 61 b5 89 88 29 22 36 da 56 cb 5f b1 7e 94 91 50 be 8b ba ba c1 f9 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 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: ST= A >> > 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 Tue Nov 30 07:38: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 6F74A106566C for ; Tue, 30 Nov 2010 07:38:57 +0000 (UTC) (envelope-from monthadar@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 EC7A08FC0A for ; Tue, 30 Nov 2010 07:38:56 +0000 (UTC) Received: by qwd7 with SMTP id 7so19610qwd.13 for ; Mon, 29 Nov 2010 23:38: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:date:message-id :subject:from:to:content-type; bh=nXPc4gBIUoL1BaHZPkJq6w36Bg1AAHYn2ZwAvg1FLSg=; b=w5ucrZYOPrQB7meTKm4dZHjaV6CXsNeV9HMyTTNMeIysXI03QxjB+N8mG8JJvJEcKC IjpIxRK/4/yV6IzKtjy19BChP8ClTOvd9q43YWKfqNsG2Uw6dRSLBoGOLihifQ8uqxXH mTd2/bk9HQfk1HYtvbhA0nfdiV95nioPlHHVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BVKHBTIrYP0K9wSBqcgkxyTSSN7APlZ5L0UuIwEVhbQv3p5yGMHObj5svkgSWhpYYn RXloiXL0Kn9oqcdMeUwD6PrtJ2WuZ6100FtRGCYq+HCKpWLOEp5itUbP3bXZAMWfflrD Z4tfvKUB91BJf75zQ+xdmAHZACuDioKq4vJ6g= MIME-Version: 1.0 Received: by 10.229.240.4 with SMTP id ky4mr5723698qcb.104.1291102736264; Mon, 29 Nov 2010 23:38:56 -0800 (PST) Received: by 10.229.248.193 with HTTP; Mon, 29 Nov 2010 23:38:56 -0800 (PST) Date: Tue, 30 Nov 2010 08:38:56 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Bridging mesh with wired not working? 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, 30 Nov 2010 07:38:57 -0000 Hi, Can anyone confirm that bridging a mesh with a wired interface is not working? I want to make sure that it is not a problem from my side. When I ping from outside the mesh I get: "!valid or proxy" and "frame not fwd'd, no path" from the debug information. My setup is simple STA --- MPP )) -- (( MP STA: Ubuntu PC MPP: RSPRO mesh portal bridging wired and mesh MP: RSPRO mesh point ifconfig for MPP: arge0: flags=8943 metric 0 mtu 1500 options=80000 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect (100baseTX ) status: active wlan0: flags=8943 metric 0 mtu 1500 ether YY:YY:YY:YY:YY:YY inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:67:21:8d country US ecm authmode OPEN privacy OFF txpower 20 scanvalid 60 protmode CTS wme burst meshttl 31 meshpeering meshforward meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED hwmpmaxhops 31 bridge0: flags=28943 metric 0 mtu 1500 ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: arge0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 200000 member: wlan0 flags=143 ifmaxaddr 0 port 7 priority 128 path cost 370370 br, -- //Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Tue Nov 30 08:12: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 BF165106564A for ; Tue, 30 Nov 2010 08:12:32 +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 5093B8FC0A for ; Tue, 30 Nov 2010 08:12:30 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 0790E39822; Tue, 30 Nov 2010 10:12:28 +0200 (SAST) Date: Tue, 30 Nov 2010 10:12:27 +0200 From: John Hay To: Jack Vogel Message-ID: <20101130081227.GA26691@zibbi.meraka.csir.co.za> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <20101128101702.GA1574@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net , 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: Tue, 30 Nov 2010 08:12:32 -0000 On Mon, Nov 29, 2010 at 12:07:57PM -0800, Jack Vogel wrote: > You use `ifconfig ix0 vlanhwfilter`, its off by default, I assume you're > using the > new driver code from either HEAD or STABLE/8 now, right? I'm using the driver in STABLE/8 that you merged voer the weekend, yes. It reports as: ix0: ... Using "vlanhwfilter vlanhwtag" it is still broken, ie. packets sometimes go out on the wrong vlan. Not sure if "vlanhwfilter -vlanhwtag" is useful, but that works. > > Try another experiment please: at line 4232 is a condition: if > ((adapter->num_vlans) &&... > Change that to: if ((vtag) && .... This does not seem to make a difference. There is no difference between "vlanhwfilter" and "-vlanhwfilter". With both I get a lot of packets going out on the wrong vlan. Again doing "-vlanhwtag" solves the problem. Lately I see I do not need routing for the problem to appear anymore. Just vlans and a ping6 to the link-local or global ipv6 address will show it. I do not know if it makes a difference, but most of my testing is on ix2 and vlans on it. Now that I do not need routing to show the problem, I did some more tcpdumping on the mirror port and realised something. It seems that traffic on the other vlan seems to trigger it. It looks like every time a packet was transmitted on the wrong vlan, there was some activity (by the machine) on that other vlan. (Sometimes just replying to an ipv4 ping.) Testing that theory, I did "ifconfig ix2.8 down", so that only ix2.1 is running and did not see a problem during a ping6 of 180 packets. John > > See if either of those change things. > > Jack > > > On Sun, Nov 28, 2010 at 2:17 AM, John Hay wrote: > > > On Sun, Nov 28, 2010 at 01:19:07AM -0800, Jack Vogel wrote: > > > Well, its not solving this odd vlan tag change problem, that isn't what > > the > > > workaround was about, at least I dont see how to connect them. > > > > Yes, but I still see the double vlan tags on the mirror port that I > > connected to ix3, which is what Ryan reported? > > > > > So you arent using HW Filters? or does that just not show up in the > > ifconfig > > > display? > > > > Which HW Filters? I have -rxcsum -lro from previous debugging. I can > > turn it on again. Or are there others that I do not know about? > > > > John > > > > > > > > Jack > > > > > > > > > On Sun, Nov 28, 2010 at 12:16 AM, John Hay wrote: > > > > > > > Hi Jack, > > > > > > > > On Sat, Nov 27, 2010 at 09:59:10AM -0800, Jack Vogel wrote: > > > > > 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. > > > > > > > > I don't think your solution / workaround work in every case. To debug > > my > > > > other vlan + ipv6 problem, I have configured a mirrored port on the > > switch > > > > and connected that to one of the ixgbe interfaces with no vlans > > configured > > > > on it. Packets dumped on it looks like this: > > > > > > > > ######################################### > > > > # tcpdump -i ix3 -n -s 0 -e ether host 00:23:ae:a5:00:ef > > > > tcpdump: WARNING: ix3: no IPv4 address assigned > > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > > decode > > > > listening on ix3, link-type EN10MB (Ethernet), capture size 65535 bytes > > > > 10:00:58.215870 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 0, length 16 > > > > 10:00:59.207090 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 1, length 16 > > > > 10:01:00.206506 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 2, length 16 > > > > 10:01:01.206923 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 3, length 16 > > > > 10:01:02.206378 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 4, length 16 > > > > 10:01:03.168219 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 86: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, > > neighbor > > > > advertisement, tgt is fe80::21b:21ff:fe57:b420, length 24 > > > > 10:01:03.206846 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 5, length 16 > > > > 10:01:03.215452 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 94: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, > > neighbor > > > > solicitation, who has fe80::223:aeff:fea5:ef, length 32 > > > > 10:01:04.206331 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 6, length 16 > > > > 10:01:05.206760 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 7, length 16 > > > > 10:01:06.206203 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 1, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 8, length 16 > > > > 10:01:07.206794 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 78: vlan 0, p 0, ethertype 802.1Q, vlan 8, p 0, > > ethertype > > > > IPv6, fe80::21b:21ff:fe57:b420 > fe80::223:aeff:fea5:ef: ICMP6, echo > > reply, > > > > seq 9, length 16 > > > > ######################################## > > > > > > > > On the base interface that actually sent the packets out, it looked > > like > > > > this: > > > > > > > > ######################################## > > > > # tcpdump -i ix2 -n -s 0 -e ether host 00:23:ae:a5:00:ef > > > > tcpdump: WARNING: ix2: no IPv4 address assigned > > > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > > decode > > > > listening on ix2, link-type EN10MB (Ethernet), capture size 65535 bytes > > > > 10:00:58.215838 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 0, length 16 > > > > 10:00:58.215861 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 0, length 16 > > > > 10:00:59.207067 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 1, length 16 > > > > 10:00:59.207081 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 1, length 16 > > > > 10:01:00.206484 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 2, length 16 > > > > 10:01:00.206497 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 2, length 16 > > > > 10:01:01.206899 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 3, length 16 > > > > 10:01:01.206913 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 3, length 16 > > > > 10:01:02.206355 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 4, length 16 > > > > 10:01:02.206368 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 4, length 16 > > > > 10:01:03.168187 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor solicitation, who has > > > > fe80::21b:21ff:fe57:b420, length 32 > > > > 10:01:03.168210 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, neighbor advertisement, tgt is > > > > fe80::21b:21ff:fe57:b420, length 24 > > > > 10:01:03.206828 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 5, length 16 > > > > 10:01:03.206838 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 5, length 16 > > > > 10:01:03.215445 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 90: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, neighbor solicitation, who has > > > > fe80::223:aeff:fea5:ef, length 32 > > > > 10:01:03.215604 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 82: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, neighbor advertisement, tgt is > > > > fe80::223:aeff:fea5:ef, length 24 > > > > 10:01:04.206307 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 6, length 16 > > > > 10:01:04.206321 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 6, length 16 > > > > 10:01:05.206739 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 7, length 16 > > > > 10:01:05.206751 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 7, length 16 > > > > 10:01:06.206181 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 8, length 16 > > > > 10:01:06.206194 00:1b:21:57:ef:7c > 00:23:ae:a5:00:ef, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::21b:21ff:fe57:b420 > > > > > fe80::223:aeff:fea5:ef: ICMP6, echo reply, seq 8, length 16 > > > > 10:01:07.206772 00:23:ae:a5:00:ef > 00:1b:21:57:ef:7c, ethertype 802.1Q > > > > (0x8100), length 74: vlan 1, p 0, ethertype IPv6, > > fe80::223:aeff:fea5:ef > > > > > fe80::21b:21ff:fe57:b420: ICMP6, echo request, seq 9, length 16 > > > > ######################################## > > > > > > > > You can see that there is only one vlan tag. > > > > > > > > You can also see that all of these were sent out on vlan 1, while by > > the > > > > time they arrive on the mirrored port some have been mangled to vlan 8. > > > > > > > > This is after updating to the new driver that was merged today. It > > seems > > > > that I do not need routing anymore for this condition to happen. Just a > > > > ping to the link-local address triggers it. > > > > > > > > I did this from another machine: > > > > > > > > ######################################## > > > > # ping6 fe80::21b:21ff:fe57:b420%em0 > > > > PING6(56=40+8+8 bytes) fe80::223:aeff:fea5:ef%em0 --> > > > > fe80::21b:21ff:fe57:b420%em0 > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=5 hlim=64 > > time=0.180 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=6 hlim=64 > > time=0.134 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=7 hlim=64 > > time=0.145 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=8 hlim=64 > > time=0.169 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=33 hlim=64 > > time=0.135 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=34 hlim=64 > > time=0.145 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=35 hlim=64 > > time=0.151 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=36 hlim=64 > > time=0.166 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=37 hlim=64 > > time=0.159 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=38 hlim=64 > > time=0.147 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=39 hlim=64 > > time=0.146 > > > > ms > > > > 16 bytes from fe80::21b:21ff:fe57:b420%em0, icmp_seq=40 hlim=64 > > time=0.213 > > > > ms > > > > ^C > > > > --- fe80::21b:21ff:fe57:b420%em0 ping6 statistics --- > > > > 41 packets transmitted, 12 packets received, 70.7% packet loss > > > > round-trip min/avg/max/std-dev = 0.134/0.158/0.213/0.021 ms > > > > ######################################## > > > > > > > > Currently the configs look like this: > > > > > > > > ######################################## > > > > mr3# ifconfig ix2 > > > > ix2: flags=8843 metric 0 mtu > > 1500 > > > > options=1b8 > > > > ether 00:1b:21:57:ef:7c > > > > inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 > > > > nd6 options=3 > > > > media: Ethernet autoselect (10Gbase-SR ) > > > > status: active > > > > mr3# ifconfig ix3 > > > > ix3: flags=8843 metric 0 mtu > > 1500 > > > > > > > > > > options=1bb > > > > ether 00:1b:21:57:ef:7d > > > > inet6 fe80::21b:21ff:fe57:ef7d%ix3 prefixlen 64 scopeid 0x4 > > > > nd6 options=3 > > > > media: Ethernet autoselect (10Gbase-SR ) > > > > status: active > > > > mr3# ifconfig ix2.1 > > > > ix2.1: flags=8843 metric 0 mtu > > 1500 > > > > ether 00:1b:21:57:ef:7c > > > > inet 146.64.28.2 netmask 0xffffff00 broadcast 146.64.28.255 > > > > inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0xa > > > > inet6 2001:4200:7000:3:21b:21ff:fe57:b420 prefixlen 64 > > > > inet6 2001:4200:7000:3:: prefixlen 64 anycast > > > > nd6 options=3 > > > > media: Ethernet autoselect (10Gbase-SR ) > > > > status: active > > > > vlan: 1 parent interface: ix2 > > > > mr3# ifconfig ix2.8 > > > > ix2.8: flags=8843 metric 0 mtu > > 1500 > > > > ether 00:1b:21:57:ef:7c > > > > inet 146.64.8.50 netmask 0xffffff00 broadcast 146.64.8.255 > > > > inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xb > > > > inet6 2001:4200:7000:1:21b:21ff:fe57:b420 prefixlen 64 > > > > inet6 2001:4200:7000:1:: prefixlen 64 anycast > > > > nd6 options=3 > > > > media: Ethernet autoselect (10Gbase-SR ) > > > > status: active > > > > vlan: 8 parent interface: ix2 > > > > > > > > ######################################## > > > > > > > > John > > > > -- > > > > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 04:02:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63CB21065672 for ; Wed, 1 Dec 2010 04:02:33 +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 E7F628FC16 for ; Wed, 1 Dec 2010 04:02:32 +0000 (UTC) Received: by wyf19 with SMTP id 19so6460736wyf.13 for ; Tue, 30 Nov 2010 20:02:31 -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=B54S8nVLBNOq8+6DzVPYHjW//S/28L98yUjU6ejpJUk=; b=tytzXLhyjMZwKVmedshnfGd/iwA2r5XYCYhYW/yCvRMiehaooRDXwGCKaRE+zZB5Y8 T2z9V1O5PUvw6ssvnPP2Pg+S50Wrnsr19+lELMagQwavWFvW/IgwNXG/6aJ59NlIuNyl hVKGPq4HRE9g7atqR3BLjsU/RqZLPPAq4uOFA= 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=XP4FiT6cmnL/lS4NQVOKGrW8Vq98gsfIVcSypMPrHd1K61gbXKBBrmURH61oXApwvS ikz2Wfghlo6J+pUPfTa0dLffu3vB2ofqohtR51klx8l3s/hBfQ7h35javUSTeCvc6fqf vKCqVoyQI8+1WFZ2sWaW7wHsRWeCsGgMukZD8= MIME-Version: 1.0 Received: by 10.216.179.81 with SMTP id g59mr1427905wem.35.1291176151780; Tue, 30 Nov 2010 20:02:31 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Tue, 30 Nov 2010 20:02:31 -0800 (PST) In-Reply-To: References: Date: Wed, 1 Dec 2010 12:02:31 +0800 X-Google-Sender-Auth: Dn5dw4c4GYFXDyWeZUlxK-wqVWg Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Bridging mesh with wired not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 04:02:33 -0000 I believe that's supposed to work. :-) adrian On 30 November 2010 15:38, Monthadar Al Jaberi wrote: > Hi, > > Can anyone confirm that bridging a mesh with a wired interface is not > working? I want to make sure that it is not a problem from my side. > > When I ping from outside the mesh I get: "!valid or proxy" and "frame > not fwd'd, no path" from the debug information. > > My setup is simple > > STA --- MPP )) -- (( MP > > STA: Ubuntu PC > MPP: RSPRO mesh portal bridging wired and mesh > MP: RSPRO mesh point > > ifconfig for MPP: > arge0: flags=3D8943 > metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D80000 > =A0 =A0 =A0 =A0ether XX:XX:XX:XX:XX:XX > =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) > =A0 =A0 =A0 =A0status: active > wlan0: flags=3D8943 > metric 0 mtu 1500 > =A0 =A0 =A0 =A0ether YY:YY:YY:YY:YY:YY > =A0 =A0 =A0 =A0inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168.1.2= 55 > =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <= mesh> > =A0 =A0 =A0 =A0status: running > =A0 =A0 =A0 =A0meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:67:21= :8d > =A0 =A0 =A0 =A0country US ecm authmode OPEN privacy OFF txpower 20 scanva= lid 60 > =A0 =A0 =A0 =A0protmode CTS wme burst meshttl 31 meshpeering meshforward > =A0 =A0 =A0 =A0meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED hwm= pmaxhops 31 > bridge0: flags=3D28943 > metric 0 mtu 1500 > =A0 =A0 =A0 =A0ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ > =A0 =A0 =A0 =A0id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 1= 5 > =A0 =A0 =A0 =A0maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > =A0 =A0 =A0 =A0root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > =A0 =A0 =A0 =A0member: arge0 flags=3D143 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 4 priority 128 path cost = 200000 > =A0 =A0 =A0 =A0member: wlan0 flags=3D143 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 7 priority 128 path cost = 370370 > > br, > -- > //Monthadar Al Jaberi > _______________________________________________ > 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 Dec 1 07:48: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 488231065674 for ; Wed, 1 Dec 2010 07:48:59 +0000 (UTC) (envelope-from monthadar@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 DBC008FC14 for ; Wed, 1 Dec 2010 07:48:58 +0000 (UTC) Received: by qwj9 with SMTP id 9so1251873qwj.13 for ; Tue, 30 Nov 2010 23:48:58 -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=IJb3crtr12Uf13sfOCmtBB3lXym28t1WdOODQCt+b0M=; b=rrownothre8Qk+2KA/yO9Cw54IlFogKuNY78gLP6S2hJc0h8ZDaLzttM2GZd/Q6cZ7 lyjpM0Njj77I5YirGdGId4dGh/Mh2XBRUsLGdhjXbcf6GoF/T7qhOGpAfdlpZUPQ0xor fpDROkrYNepG+IwWZk4awlTO53dcrp57dO9cc= 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=D9M8flBRnS3uLBWoAbltuj4IMnHvlnbBe/GTT4rTbsRQ0ruUGsZe5eYEvirnX2lcdr XeBbeAxUs3O+iJlxbl0qjeyQy7ujlQF7F5Gxf18hE5w7rFUo9ZIExuDT0bfjX0/xzEwi e+UPJTHFHeNfLeQ6oQnEgDtfbgm8urx7mBNOo= MIME-Version: 1.0 Received: by 10.229.232.211 with SMTP id jv19mr7048242qcb.28.1291189737290; Tue, 30 Nov 2010 23:48:57 -0800 (PST) Received: by 10.229.248.193 with HTTP; Tue, 30 Nov 2010 23:48:56 -0800 (PST) In-Reply-To: References: Date: Wed, 1 Dec 2010 08:48:56 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Bridging mesh with wired not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 07:48:59 -0000 On Wed, Dec 1, 2010 at 5:02 AM, Adrian Chadd wrote: > I believe that's supposed to work. :-) Did you try it? on current? I am running 201010 Current. From the code I see some comments like "/* XXX add support for proxied addresses */". For me it looks like the code for proxy is half done, if I may say so myself :P see this method in net80211/ieee80211_mesh.c /* * Iterate the routing table and locate the next hop. */ static struct ieee80211_node * mesh_find_txnode(struct ieee80211vap *vap, const uint8_t dest[IEEE80211_ADDR_LEN]) { ... if ((rt->rt_flags & IEEE80211_MESHRT_FLAGS_VALID) =3D=3D 0 || (rt->rt_flags & IEEE80211_MESHRT_FLAGS_PROXY)) { IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_MESH, dest, "%s: !valid or proxy, flags 0x%x", __func__, rt->rt_flags); /* XXX stat */ return NULL; } ... } it stops if the dest node is a proxy. Then after failing in forwarding it goes out (=3D=3D discard frame?), I put a print message there to verify that it goes out: static int mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) { ... /* * Potentially forward packet. See table s36 (p140) * for the rules. XXX tap fwd'd packets not for us? */ if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS || !mesh_isucastforme(vap, wh, mc)) { mesh_forward(vap, m, mc); if (dir =3D=3D IEEE80211_FC1_DIR_DSTODS) goto out; /* NB: fall thru to deliver mcast frames locally */ } ... } I am puzzeled... everyone says it works, did I miss something?! :P br, > > > adrian > > On 30 November 2010 15:38, Monthadar Al Jaberi wrot= e: >> Hi, >> >> Can anyone confirm that bridging a mesh with a wired interface is not >> working? I want to make sure that it is not a problem from my side. >> >> When I ping from outside the mesh I get: "!valid or proxy" and "frame >> not fwd'd, no path" from the debug information. >> >> My setup is simple >> >> STA --- MPP )) -- (( MP >> >> STA: Ubuntu PC >> MPP: RSPRO mesh portal bridging wired and mesh >> MP: RSPRO mesh point >> >> ifconfig for MPP: >> arge0: flags=3D8943 >> metric 0 mtu 1500 >> =A0 =A0 =A0 =A0options=3D80000 >> =A0 =A0 =A0 =A0ether XX:XX:XX:XX:XX:XX >> =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) >> =A0 =A0 =A0 =A0status: active >> wlan0: flags=3D8943 >> metric 0 mtu 1500 >> =A0 =A0 =A0 =A0ether YY:YY:YY:YY:YY:YY >> =A0 =A0 =A0 =A0inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168.1.= 255 >> =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 11g = >> =A0 =A0 =A0 =A0status: running >> =A0 =A0 =A0 =A0meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:67:2= 1:8d >> =A0 =A0 =A0 =A0country US ecm authmode OPEN privacy OFF txpower 20 scanv= alid 60 >> =A0 =A0 =A0 =A0protmode CTS wme burst meshttl 31 meshpeering meshforward >> =A0 =A0 =A0 =A0meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED hw= mpmaxhops 31 >> bridge0: flags=3D28943 >> metric 0 mtu 1500 >> =A0 =A0 =A0 =A0ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ >> =A0 =A0 =A0 =A0id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay = 15 >> =A0 =A0 =A0 =A0maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >> =A0 =A0 =A0 =A0root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >> =A0 =A0 =A0 =A0member: arge0 flags=3D143 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 4 priority 128 path cost= 200000 >> =A0 =A0 =A0 =A0member: wlan0 flags=3D143 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 7 priority 128 path cost= 370370 >> >> br, >> -- >> //Monthadar Al Jaberi >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > --=20 //Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 08:22: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 3FA09106566C for ; Wed, 1 Dec 2010 08:22:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E8E258FC13 for ; Wed, 1 Dec 2010 08:22:22 +0000 (UTC) Received: by gwj21 with SMTP id 21so3438202gwj.13 for ; Wed, 01 Dec 2010 00:22:22 -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=ugqOMDZBmSbUJA9ITDixSzFYn+0q6wZvVbHkmT2Rdkw=; b=unRO+Px3Ryb3KqWeW0sx0t+h5Rkohfg6FBdiGrhFFcAE0bEnhPCyMoYkxkyAI5uJoT c/HsTB5Z+QGZN8K/jh9QGccpHsGK7iR/15nXeqhfbIR2lT9Z7qO6Wggstzr/wYThUUE9 EQ33aqxI/4xcDOD6LwGe1zLMakuuZ+3bntXow= 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=ee0HbzBH04q5Jc2pIk0JfeTV7DHiwjkoFliP/ytBUT7xIv6k9zvwM6sGfCUmSJNdP3 CXlYSTKzGlSPyc80F/tw+pmQZVWKIh93kkWyTaZ/C5zqszqzTC6R3Wbe3Cyaoql6CK33 3GMT/igIPHgqd7Pnyozrj5wC09kxBo3VvcxbY= MIME-Version: 1.0 Received: by 10.90.61.2 with SMTP id j2mr1169991aga.205.1291191741616; Wed, 01 Dec 2010 00:22:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.90.88.17 with HTTP; Wed, 1 Dec 2010 00:22:21 -0800 (PST) In-Reply-To: References: Date: Wed, 1 Dec 2010 16:22:21 +0800 X-Google-Sender-Auth: ErguLPqlFXVujHLhczwE_nMvNmI Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Bridging mesh with wired not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 08:22:23 -0000 The mesh code is really a proof of concept. It definitely needs someone to actually sit down and use it, then document all of the things that aren't working. I tried it for about 5 minutes and discovered that although it seems to basically work, MAC addresses migrating from wired<->wireless didn't migrate destinations in the mesh table, so the mesh network would treat it incorrectly. I ran out of time (my spare time is focused on understanding and implementing Atheros 11n at the moment) so I had to stop. If you'd like to be the person who sits down and tries to use the meshing stuff then please, by all means. :-) Adrian On 1 December 2010 15:48, Monthadar Al Jaberi wrote: > On Wed, Dec 1, 2010 at 5:02 AM, Adrian Chadd wrote: >> I believe that's supposed to work. :-) > > Did you try it? on current? I am running 201010 Current. From the code > I see some comments like "/* XXX add support for proxied addresses > */". For me it looks like the code for proxy is half done, if I may > say so myself :P > > see this method in net80211/ieee80211_mesh.c > /* > =A0* Iterate the routing table and locate the next hop. > =A0*/ > static struct ieee80211_node * > mesh_find_txnode(struct ieee80211vap *vap, > =A0 =A0const uint8_t dest[IEEE80211_ADDR_LEN]) > { > ... > if ((rt->rt_flags & IEEE80211_MESHRT_FLAGS_VALID) =3D=3D 0 || > =A0 =A0 =A0 =A0 =A0 =A0(rt->rt_flags & IEEE80211_MESHRT_FLAGS_PROXY)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_MESH= , dest, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"%s: !valid or proxy, flags 0x%x",= __func__, rt->rt_flags); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* XXX stat */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL; > } > ... > } > > it stops if the dest node is a proxy. Then after failing in forwarding > it goes out (=3D=3D discard frame?), I put a print message there to verif= y > that it goes out: > static int > mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) > { > ... > /* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Potentially forward packet. =A0See tabl= e s36 (p140) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * for the rules. =A0XXX tap fwd'd packets= not for us? > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS || > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0!mesh_isucastforme(vap, wh, mc)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mesh_forward(vap, m, mc); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211_F= C1_DIR_DSTODS) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* NB: fall thru to delive= r mcast frames locally */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > ... > } > > I am puzzeled... everyone says it works, did I miss something?! :P > > > br, > >> >> >> adrian >> >> On 30 November 2010 15:38, Monthadar Al Jaberi wro= te: >>> Hi, >>> >>> Can anyone confirm that bridging a mesh with a wired interface is not >>> working? I want to make sure that it is not a problem from my side. >>> >>> When I ping from outside the mesh I get: "!valid or proxy" and "frame >>> not fwd'd, no path" from the debug information. >>> >>> My setup is simple >>> >>> STA --- MPP )) -- (( MP >>> >>> STA: Ubuntu PC >>> MPP: RSPRO mesh portal bridging wired and mesh >>> MP: RSPRO mesh point >>> >>> ifconfig for MPP: >>> arge0: flags=3D8943 >>> metric 0 mtu 1500 >>> =A0 =A0 =A0 =A0options=3D80000 >>> =A0 =A0 =A0 =A0ether XX:XX:XX:XX:XX:XX >>> =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) >>> =A0 =A0 =A0 =A0status: active >>> wlan0: flags=3D8943 >>> metric 0 mtu 1500 >>> =A0 =A0 =A0 =A0ether YY:YY:YY:YY:YY:YY >>> =A0 =A0 =A0 =A0inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168.1= .255 >>> =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 11g= >>> =A0 =A0 =A0 =A0status: running >>> =A0 =A0 =A0 =A0meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:67:= 21:8d >>> =A0 =A0 =A0 =A0country US ecm authmode OPEN privacy OFF txpower 20 scan= valid 60 >>> =A0 =A0 =A0 =A0protmode CTS wme burst meshttl 31 meshpeering meshforwar= d >>> =A0 =A0 =A0 =A0meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED h= wmpmaxhops 31 >>> bridge0: flags=3D28943 >>> metric 0 mtu 1500 >>> =A0 =A0 =A0 =A0ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ >>> =A0 =A0 =A0 =A0id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay= 15 >>> =A0 =A0 =A0 =A0maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >>> =A0 =A0 =A0 =A0root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>> =A0 =A0 =A0 =A0member: arge0 flags=3D143 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 4 priority 128 path cos= t 200000 >>> =A0 =A0 =A0 =A0member: wlan0 flags=3D143 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 7 priority 128 path cos= t 370370 >>> >>> br, >>> -- >>> //Monthadar Al Jaberi >>> _______________________________________________ >>> 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" >>> >> > > > > -- > //Monthadar Al Jaberi > _______________________________________________ > 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 Dec 1 09:03: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 AABF7106566B; Wed, 1 Dec 2010 09:03:01 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 445198FC0C; Wed, 1 Dec 2010 09:03:00 +0000 (UTC) Received: by qyk8 with SMTP id 8so2200376qyk.13 for ; Wed, 01 Dec 2010 01:03:00 -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=T0TP8gr2iJlKmg+Idb1LOosAgXbbtPm+/gJ+iKe5Yic=; b=jgagheVSPKLJiCjKGQZ0jOK1cqHet9UO4RAXQAO/A6z68Vg0OLUoG14PkpqmGQM3/Z VD6zoNRWyXmFFWbSUXhieXP+bBYARN73Gwf2i5XsHEi0Ibnkt4LxvehPYwcKWUQR8obU g0GEXSCbOj6uyXs/Vt5E7GrN7JHmLmU+/UWWQ= 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=UJ4600wlXSt401ymj80ZyhV6/sYerZWGa4IrRg1IMDzoAXkkktJV5lH8Sy8ZSgOOKc LxH39LLypOyEWeijvN3SH7i9KB64HECJnd5Ay2GLgJwCq+tYyURUP69nSlv1iGfp/7WD q/76be0Mua4OSp+iU9iLw2kSPdu6M+jOeZQH4= MIME-Version: 1.0 Received: by 10.229.191.130 with SMTP id dm2mr6934466qcb.256.1291194180253; Wed, 01 Dec 2010 01:03:00 -0800 (PST) Received: by 10.229.248.193 with HTTP; Wed, 1 Dec 2010 01:03:00 -0800 (PST) In-Reply-To: References: Date: Wed, 1 Dec 2010 10:03:00 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Bridging mesh with wired not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 09:03:01 -0000 On Wed, Dec 1, 2010 at 9:22 AM, Adrian Chadd wrote: > The mesh code is really a proof of concept. It definitely needs > someone to actually sit down and use it, then document all of the > things that aren't working. > > I tried it for about 5 minutes and discovered that although it seems > to basically work, MAC addresses migrating from wired<->wireless > didn't migrate destinations in the mesh table, so the mesh network > would treat it incorrectly. I ran out of time (my spare time is how was your setup? Was it like mine? did you ping? I can ping the MESH PORTAL itself but not the MESH POINT behind it. > focused on understanding and implementing Atheros 11n at the moment) > so I had to stop. Thank you for your time :) > > If you'd like to be the person who sits down and tries to use the > meshing stuff then please, by all means. :-) I have been trying to understand the code for some time now, its hard especially that the standard changed a lot? I found that if you set it up like I did, it wont ping at all, cause it would stop at the place I noted. I tried to make it run the rest of the code instead of going out when it is a proxy dest, and it did ping!!! but! if I change anything in how the mesh is set up it wont invalidate old values and thus stop working for proxy addresses :( > > > > Adrian br, > > On 1 December 2010 15:48, Monthadar Al Jaberi wrote= : >> On Wed, Dec 1, 2010 at 5:02 AM, Adrian Chadd wrote: >>> I believe that's supposed to work. :-) >> >> Did you try it? on current? I am running 201010 Current. From the code >> I see some comments like "/* XXX add support for proxied addresses >> */". For me it looks like the code for proxy is half done, if I may >> say so myself :P >> >> see this method in net80211/ieee80211_mesh.c >> /* >> =A0* Iterate the routing table and locate the next hop. >> =A0*/ >> static struct ieee80211_node * >> mesh_find_txnode(struct ieee80211vap *vap, >> =A0 =A0const uint8_t dest[IEEE80211_ADDR_LEN]) >> { >> ... >> if ((rt->rt_flags & IEEE80211_MESHRT_FLAGS_VALID) =3D=3D 0 || >> =A0 =A0 =A0 =A0 =A0 =A0(rt->rt_flags & IEEE80211_MESHRT_FLAGS_PROXY)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_MES= H, dest, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"%s: !valid or proxy, flags 0x%x"= , __func__, rt->rt_flags); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* XXX stat */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL; >> } >> ... >> } >> >> it stops if the dest node is a proxy. Then after failing in forwarding >> it goes out (=3D=3D discard frame?), I put a print message there to veri= fy >> that it goes out: >> static int >> mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) >> { >> ... >> /* >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Potentially forward packet. =A0See tab= le s36 (p140) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * for the rules. =A0XXX tap fwd'd packet= s not for us? >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS |= | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0!mesh_isucastforme(vap, wh, mc)) = { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mesh_forward(vap, m, mc); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211_= FC1_DIR_DSTODS) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* NB: fall thru to deliv= er mcast frames locally */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> ... >> } >> >> I am puzzeled... everyone says it works, did I miss something?! :P >> >> >> br, >> >>> >>> >>> adrian >>> >>> On 30 November 2010 15:38, Monthadar Al Jaberi wr= ote: >>>> Hi, >>>> >>>> Can anyone confirm that bridging a mesh with a wired interface is not >>>> working? I want to make sure that it is not a problem from my side. >>>> >>>> When I ping from outside the mesh I get: "!valid or proxy" and "frame >>>> not fwd'd, no path" from the debug information. >>>> >>>> My setup is simple >>>> >>>> STA --- MPP )) -- (( MP >>>> >>>> STA: Ubuntu PC >>>> MPP: RSPRO mesh portal bridging wired and mesh >>>> MP: RSPRO mesh point >>>> >>>> ifconfig for MPP: >>>> arge0: flags=3D8943 >>>> metric 0 mtu 1500 >>>> =A0 =A0 =A0 =A0options=3D80000 >>>> =A0 =A0 =A0 =A0ether XX:XX:XX:XX:XX:XX >>>> =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) >>>> =A0 =A0 =A0 =A0status: active >>>> wlan0: flags=3D8943 >>>> metric 0 mtu 1500 >>>> =A0 =A0 =A0 =A0ether YY:YY:YY:YY:YY:YY >>>> =A0 =A0 =A0 =A0inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168.= 1.255 >>>> =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 11= g >>>> =A0 =A0 =A0 =A0status: running >>>> =A0 =A0 =A0 =A0meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:67= :21:8d >>>> =A0 =A0 =A0 =A0country US ecm authmode OPEN privacy OFF txpower 20 sca= nvalid 60 >>>> =A0 =A0 =A0 =A0protmode CTS wme burst meshttl 31 meshpeering meshforwa= rd >>>> =A0 =A0 =A0 =A0meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED = hwmpmaxhops 31 >>>> bridge0: flags=3D28943 >>>> metric 0 mtu 1500 >>>> =A0 =A0 =A0 =A0ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ >>>> =A0 =A0 =A0 =A0id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddela= y 15 >>>> =A0 =A0 =A0 =A0maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >>>> =A0 =A0 =A0 =A0root id 00:00:00:00:00:00 priority 32768 ifcost 0 port = 0 >>>> =A0 =A0 =A0 =A0member: arge0 flags=3D143 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 4 priority 128 path co= st 200000 >>>> =A0 =A0 =A0 =A0member: wlan0 flags=3D143 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 7 priority 128 path co= st 370370 >>>> >>>> br, >>>> -- >>>> //Monthadar Al Jaberi >>>> _______________________________________________ >>>> 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" >>>> >>> >> >> >> >> -- >> //Monthadar Al Jaberi >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > --=20 //Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 14:39: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 C302B1065674 for ; Wed, 1 Dec 2010 14:39:24 +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 505B88FC17 for ; Wed, 1 Dec 2010 14:39:23 +0000 (UTC) Received: by wwf26 with SMTP id 26so2802254wwf.31 for ; Wed, 01 Dec 2010 06:39:23 -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=oh3SIOs3nEWh9KFkB2HhKZ35sxxKzuP6/XI4+DmH6CY=; b=cEkKkM6VVc1tW/FAtdenRI7nbgYTIDp7785Xg5SJ76pGCDTtPV2pKiJN64Q+97QhdI ANErA19C9kQFCNpJ19rrqVHhAOGH+jXj+p29KzlnbxaoDBhG7fcsZD5cm/IQBsV8TTPV h0DLcptPBYpf+Mnn7Qiv00sqvyoqDHdP9seXQ= 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=KQxPWExmbwVd8oDKVJ6sHQlmwb2enw7t3lyICm3eJJsI8HwTZ3m0UuBkg6qsCFeECw GrOOujdCMXLoh2QsSJ0INgSR0PV6is9oc08rKzamLFNKX9jyiQhwrC989VDTM011aI6Z x1ZIWvKy96e1NQ6vrxYSsgXza3CIpwbebtEcA= MIME-Version: 1.0 Received: by 10.216.142.131 with SMTP id i3mr2079216wej.5.1291214360606; Wed, 01 Dec 2010 06:39:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Wed, 1 Dec 2010 06:39:20 -0800 (PST) In-Reply-To: References: Date: Wed, 1 Dec 2010 22:39:20 +0800 X-Google-Sender-Auth: goUPpUJ2rXqDzAeMbd4Fdn5Q8aY Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Bridging mesh with wired not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 14:39:24 -0000 I don't recall the exact particulars of the setup, I'm sorry. Adrian On 1 December 2010 17:03, Monthadar Al Jaberi wrote: > On Wed, Dec 1, 2010 at 9:22 AM, Adrian Chadd wrote: >> The mesh code is really a proof of concept. It definitely needs >> someone to actually sit down and use it, then document all of the >> things that aren't working. >> >> I tried it for about 5 minutes and discovered that although it seems >> to basically work, MAC addresses migrating from wired<->wireless >> didn't migrate destinations in the mesh table, so the mesh network >> would treat it incorrectly. I ran out of time (my spare time is > > how was your setup? Was it like mine? did you ping? I can ping the > MESH PORTAL itself but not the MESH POINT behind it. > >> focused on understanding and implementing Atheros 11n at the moment) >> so I had to stop. > > Thank you for your time :) > >> >> If you'd like to be the person who sits down and tries to use the >> meshing stuff then please, by all means. :-) > > I have been trying to understand the code for some time now, its hard > especially that the standard changed a lot? > I found that if you set it up like I did, it wont ping at all, cause > it would stop at the place I noted. > > I tried to make it run the rest of the code instead of going out when > it is a proxy dest, and it did ping!!! > but! if I change anything in how the mesh is set up it wont invalidate > old values and thus stop working for proxy addresses :( > >> >> >> >> Adrian > > br, > >> >> On 1 December 2010 15:48, Monthadar Al Jaberi wrot= e: >>> On Wed, Dec 1, 2010 at 5:02 AM, Adrian Chadd wrote= : >>>> I believe that's supposed to work. :-) >>> >>> Did you try it? on current? I am running 201010 Current. From the code >>> I see some comments like "/* XXX add support for proxied addresses >>> */". For me it looks like the code for proxy is half done, if I may >>> say so myself :P >>> >>> see this method in net80211/ieee80211_mesh.c >>> /* >>> =A0* Iterate the routing table and locate the next hop. >>> =A0*/ >>> static struct ieee80211_node * >>> mesh_find_txnode(struct ieee80211vap *vap, >>> =A0 =A0const uint8_t dest[IEEE80211_ADDR_LEN]) >>> { >>> ... >>> if ((rt->rt_flags & IEEE80211_MESHRT_FLAGS_VALID) =3D=3D 0 || >>> =A0 =A0 =A0 =A0 =A0 =A0(rt->rt_flags & IEEE80211_MESHRT_FLAGS_PROXY)) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_ME= SH, dest, >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"%s: !valid or proxy, flags 0x%x= ", __func__, rt->rt_flags); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* XXX stat */ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL; >>> } >>> ... >>> } >>> >>> it stops if the dest node is a proxy. Then after failing in forwarding >>> it goes out (=3D=3D discard frame?), I put a print message there to ver= ify >>> that it goes out: >>> static int >>> mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) >>> { >>> ... >>> /* >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Potentially forward packet. =A0See ta= ble s36 (p140) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * for the rules. =A0XXX tap fwd'd packe= ts not for us? >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS = || >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0!mesh_isucastforme(vap, wh, mc))= { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mesh_forward(vap, m, mc)= ; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211= _FC1_DIR_DSTODS) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out= ; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* NB: fall thru to deli= ver mcast frames locally */ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> ... >>> } >>> >>> I am puzzeled... everyone says it works, did I miss something?! :P >>> >>> >>> br, >>> >>>> >>>> >>>> adrian >>>> >>>> On 30 November 2010 15:38, Monthadar Al Jaberi w= rote: >>>>> Hi, >>>>> >>>>> Can anyone confirm that bridging a mesh with a wired interface is not >>>>> working? I want to make sure that it is not a problem from my side. >>>>> >>>>> When I ping from outside the mesh I get: "!valid or proxy" and "frame >>>>> not fwd'd, no path" from the debug information. >>>>> >>>>> My setup is simple >>>>> >>>>> STA --- MPP )) -- (( MP >>>>> >>>>> STA: Ubuntu PC >>>>> MPP: RSPRO mesh portal bridging wired and mesh >>>>> MP: RSPRO mesh point >>>>> >>>>> ifconfig for MPP: >>>>> arge0: flags=3D8943 >>>>> metric 0 mtu 1500 >>>>> =A0 =A0 =A0 =A0options=3D80000 >>>>> =A0 =A0 =A0 =A0ether XX:XX:XX:XX:XX:XX >>>>> =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) >>>>> =A0 =A0 =A0 =A0status: active >>>>> wlan0: flags=3D8943 >>>>> metric 0 mtu 1500 >>>>> =A0 =A0 =A0 =A0ether YY:YY:YY:YY:YY:YY >>>>> =A0 =A0 =A0 =A0inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168= .1.255 >>>>> =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 1= 1g >>>>> =A0 =A0 =A0 =A0status: running >>>>> =A0 =A0 =A0 =A0meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:6= 7:21:8d >>>>> =A0 =A0 =A0 =A0country US ecm authmode OPEN privacy OFF txpower 20 sc= anvalid 60 >>>>> =A0 =A0 =A0 =A0protmode CTS wme burst meshttl 31 meshpeering meshforw= ard >>>>> =A0 =A0 =A0 =A0meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED= hwmpmaxhops 31 >>>>> bridge0: flags=3D28943 >>>>> metric 0 mtu 1500 >>>>> =A0 =A0 =A0 =A0ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ >>>>> =A0 =A0 =A0 =A0id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddel= ay 15 >>>>> =A0 =A0 =A0 =A0maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 120= 0 >>>>> =A0 =A0 =A0 =A0root id 00:00:00:00:00:00 priority 32768 ifcost 0 port= 0 >>>>> =A0 =A0 =A0 =A0member: arge0 flags=3D143 >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 4 priority 128 path c= ost 200000 >>>>> =A0 =A0 =A0 =A0member: wlan0 flags=3D143 >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 7 priority 128 path c= ost 370370 >>>>> >>>>> br, >>>>> -- >>>>> //Monthadar Al Jaberi >>>>> _______________________________________________ >>>>> 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= " >>>>> >>>> >>> >>> >>> >>> -- >>> //Monthadar Al Jaberi >>> _______________________________________________ >>> 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" >>> >> > > > > -- > //Monthadar Al Jaberi > From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 17:54: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 9276B10657AE for ; Wed, 1 Dec 2010 17:54:10 +0000 (UTC) (envelope-from john@traktor.dnepro.net) Received: from smtp-out.dnepro.net (smtp-out.dnepro.net [195.24.131.41]) by mx1.freebsd.org (Postfix) with ESMTP id 281448FC12 for ; Wed, 1 Dec 2010 17:54:09 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id oB1Hs1Vf076372 for ; Wed, 1 Dec 2010 19:54:02 +0200 (EET) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id oB1Hs11T076368 for freebsd-net@freebsd.org; Wed, 1 Dec 2010 19:54:01 +0200 (EET) (envelope-from john) Date: Wed, 1 Dec 2010 19:54:01 +0200 From: Eugene Perevyazko To: freebsd-net@freebsd.org Message-ID: <20101201175401.GA69269@traktor.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20101110110428.GA3505@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20101110110428.GA3505@traktor.dnepro.net> User-Agent: Mutt/1.4.2.3i Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 17:54:10 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 10, 2010 at 01:04:28PM +0200, Eugene Perevyazko wrote: > > I have a router running RELENG_7 with two dual-port igbs - igb0 and igb1 are on > 82575 on intel s5520ur mb and igb2 and igb3 are on 82576 on ET dual-port card. > 82576 is in 8x slot. > Main traffic flows from igb0+igb1 to igb2+igb3, less traffic goes back. > There's no traffic flow in directions igb0 - igb1 and igb2 - igb3. > > There are vlans on all interfaces. > > igb0 and igb1 are outbound links. > igb2 and igb3 are connected to switch. > CPU is E5620@2.4GHz, 8 cores, irqs bound to different cores skipping HT ones. > Tried 2 queues and 1 queue per iface, neither hitting cpu limit. > > The problem is that traffic through igb2+igb3 is limited at around 1200Mbps Tx > while I was hoping for 1600-1800Mbps Tx. > I'd like to say that now this host is forwarding 1710 Mb/s @ 189 kpps in one direction + 411 Mb/s @ 140 kpps in reverse direction (30 minutes average). The following changes were made: - no lagg in use - only one vlan left instead of 5 vlans - added motherboard module 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' with 2 em interfaces (only one used) - 3 interfaces are connected to hosts with patchcords, not through switch - hyperthreading turned off in bios - igb driver patched to reduce irq rate and make it tunable (patch follows) - hw.igb.num_queues=4, dev.igb.*.enable_aim=0, dev.igb.*.default_intrrate=4000 the last sysctl is added in patch) - igb queues manually repinned to different cores - ipfw rules minimized igb driver used is 1.9.6/RELENG_7, igb.c version 1.3.2.12 Can't say for sure whether there is a key change or is it all changes summed up, sorry. -- Eugene Perevyazko --k+w/mQv8wyuph6w0 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="igb.intrrate.patch" --- if_igb.c.old 2010-09-27 21:34:04.000000000 +0300 +++ if_igb.c 2010-11-16 14:31:11.000000000 +0200 @@ -293,6 +293,17 @@ static int igb_enable_aim = TRUE; TUNABLE_INT("hw.igb.enable_aim", &igb_enable_aim); /* +** default interrupt rate in ints/sec +** applied to each queue separately +** used if enable_aim=0 +*/ +static int igb_default_intrrate = IGB_INTS_PER_SEC; +TUNABLE_INT("hw.igb.default_intrrate", &igb_default_intrrate); +#undef IGB_DEFAULT_ITR +/*#define IGB_DEFAULT_ITR 1000000000/(igb_default_intrrate * 256)*/ +#define IGB_DEFAULT_ITR ((1000000/igb_default_intrrate)<<2) + +/* * MSIX should be the default for best performance, * but this allows it to be forced off for testing. */ @@ -422,6 +433,11 @@ igb_attach(device_t dev) OID_AUTO, "enable_aim", CTLTYPE_INT|CTLFLAG_RW, &igb_enable_aim, 1, "Interrupt Moderation"); + SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), + SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), + OID_AUTO, "default_intrrate", CTLTYPE_INT|CTLFLAG_RW, + &igb_default_intrrate, 1, "Default ints/sec (for each queue)"); + callout_init_mtx(&adapter->timer, &adapter->core_mtx, 0); /* Determine hardware and mac info */ @@ -2342,6 +2358,7 @@ igb_configure_queues(struct adapter *ada } /* Set the starting interrupt rate */ + newitr &= 0x7FFC; /* Mask invalid bits */ if (hw->mac.type == e1000_82575) newitr |= newitr << 16; else --k+w/mQv8wyuph6w0-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 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 42B70106566B for ; Wed, 1 Dec 2010 18:07:38 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DB0FF8FC1A for ; Wed, 1 Dec 2010 18:07:35 +0000 (UTC) Received: by wwf26 with SMTP id 26so3006969wwf.31 for ; Wed, 01 Dec 2010 10:07:34 -0800 (PST) Received: by 10.216.166.67 with SMTP id f45mr2180360wel.112.1291226854313; Wed, 01 Dec 2010 10:07:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.177.195 with HTTP; Wed, 1 Dec 2010 10:06:53 -0800 (PST) In-Reply-To: <20101201175401.GA69269@traktor.dnepro.net> References: <20101110110428.GA3505@traktor.dnepro.net> <20101201175401.GA69269@traktor.dnepro.net> From: Vlad Galu Date: Wed, 1 Dec 2010 19:06:53 +0100 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 18:07:38 -0000 On Wed, Dec 1, 2010 at 6:54 PM, Eugene Perevyazko wrote: > On Wed, Nov 10, 2010 at 01:04:28PM +0200, Eugene Perevyazko wrote: >> >> I have a router running RELENG_7 with two dual-port igbs - igb0 and igb1= are on >> 82575 on intel s5520ur mb and igb2 and igb3 are on 82576 on ET dual-port= card. >> 82576 is in 8x slot. >> Main traffic flows from igb0+igb1 to igb2+igb3, less traffic goes back. >> There's no traffic flow in directions igb0 - igb1 and igb2 - igb3. >> >> There are vlans on all interfaces. >> >> igb0 and igb1 are outbound links. >> igb2 and igb3 are connected to switch. >> CPU is E5620@2.4GHz, 8 cores, irqs bound to different cores skipping HT = ones. >> Tried 2 queues and 1 queue per iface, neither hitting cpu limit. >> >> The problem is that traffic through igb2+igb3 is limited at around 1200M= bps Tx >> while I was hoping for 1600-1800Mbps Tx. >> > > I'd like to say that now this host is forwarding 1710 Mb/s @ 189 kpps in = one direction + 411 Mb/s @ 140 kpps in reverse direction (30 minutes averag= e). > The following changes were made: > =A0- no lagg in use > =A0- only one vlan left instead of 5 vlans > =A0- added motherboard module 'HP NC360T PCIe DP Gigabit Server Adapter (= n1e5132)' with 2 em interfaces (only one used) > =A0- 3 interfaces are connected to hosts with patchcords, not through swi= tch > =A0- hyperthreading turned off in bios > =A0- igb driver patched to reduce irq rate and make it tunable (patch fol= lows) > =A0- hw.igb.num_queues=3D4, dev.igb.*.enable_aim=3D0, dev.igb.*.default_i= ntrrate=3D4000 the last sysctl is added in patch) > =A0- igb queues manually repinned to different cores > =A0- ipfw rules minimized Can you please run a test with IPFW disabled? It's best to avoid using a firewall where throughput is the primary goal. > > igb driver used is 1.9.6/RELENG_7, igb.c version 1.3.2.12 > > Can't say for sure whether there is a key change or is it all changes sum= med up, > sorry. > > -- > Eugene Perevyazko > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 Good, fast & cheap. Pick any two. From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 18:09: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 99ABE10656A3 for ; Wed, 1 Dec 2010 18:09:32 +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 25D278FC08 for ; Wed, 1 Dec 2010 18:09:31 +0000 (UTC) Received: by wwf26 with SMTP id 26so3008859wwf.31 for ; Wed, 01 Dec 2010 10:09:31 -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=j062RVf/NmFyfuAoLuPSy1FHTiNnQBzoAkNyo7aZx+s=; b=IBHKDlQayFYJ8ZcflTo4JJ2K8qvg8kDYCt1ELZwTVZgT92kuqfnuJU2BF1zvAE7TKN vzIPWaEgQQPBTXpRDIngoK7No/2HO8sX/HOszRIfEcxEXrvMBx3LVf5TWjvh3Rh4WOmn kEpX7wO4+cMk7Yk9NKWTDSLb4Y50ZaqoTdpII= 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=VQeEMaqCG7JzVSHy2A7ia2lqQGbLRiPyfA+WY7keHn7+ep5idmlO4e3nPnhZWnQ8+T K1l3bulquNh07+3Zi3OCaObr5yPJwZ0r4zW2/uiPvgDzRzafy9BJLhvZUdcic0ZpKQwv xq3U3S3uIONPheyYpAFHJhvwUk+/jFBKbk9a0= MIME-Version: 1.0 Received: by 10.216.59.193 with SMTP id s43mr2366181wec.42.1291226971149; Wed, 01 Dec 2010 10:09:31 -0800 (PST) Received: by 10.216.2.206 with HTTP; Wed, 1 Dec 2010 10:09:31 -0800 (PST) In-Reply-To: References: <20101110110428.GA3505@traktor.dnepro.net> <20101201175401.GA69269@traktor.dnepro.net> Date: Wed, 1 Dec 2010 10:09:31 -0800 Message-ID: From: Jack Vogel To: Vlad Galu Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 18:09:32 -0000 And why don't you use the driver in 7.4 PRERELEASE (2.0.7) and eliminate any inevitable questions about fixes you don't have. Jack On Wed, Dec 1, 2010 at 10:06 AM, Vlad Galu wrote: > On Wed, Dec 1, 2010 at 6:54 PM, Eugene Perevyazko wrote: > > On Wed, Nov 10, 2010 at 01:04:28PM +0200, Eugene Perevyazko wrote: > >> > >> I have a router running RELENG_7 with two dual-port igbs - igb0 and igb1 > are on > >> 82575 on intel s5520ur mb and igb2 and igb3 are on 82576 on ET dual-port > card. > >> 82576 is in 8x slot. > >> Main traffic flows from igb0+igb1 to igb2+igb3, less traffic goes back. > >> There's no traffic flow in directions igb0 - igb1 and igb2 - igb3. > >> > >> There are vlans on all interfaces. > >> > >> igb0 and igb1 are outbound links. > >> igb2 and igb3 are connected to switch. > >> CPU is E5620@2.4GHz, 8 cores, irqs bound to different cores skipping HT > ones. > >> Tried 2 queues and 1 queue per iface, neither hitting cpu limit. > >> > >> The problem is that traffic through igb2+igb3 is limited at around > 1200Mbps Tx > >> while I was hoping for 1600-1800Mbps Tx. > >> > > > > I'd like to say that now this host is forwarding 1710 Mb/s @ 189 kpps in > one direction + 411 Mb/s @ 140 kpps in reverse direction (30 minutes > average). > > The following changes were made: > > - no lagg in use > > - only one vlan left instead of 5 vlans > > - added motherboard module 'HP NC360T PCIe DP Gigabit Server Adapter > (n1e5132)' with 2 em interfaces (only one used) > > - 3 interfaces are connected to hosts with patchcords, not through > switch > > - hyperthreading turned off in bios > > - igb driver patched to reduce irq rate and make it tunable (patch > follows) > > - hw.igb.num_queues=4, dev.igb.*.enable_aim=0, > dev.igb.*.default_intrrate=4000 the last sysctl is added in patch) > > - igb queues manually repinned to different cores > > - ipfw rules minimized > > Can you please run a test with IPFW disabled? It's best to avoid using > a firewall where throughput is the primary goal. > > > > > igb driver used is 1.9.6/RELENG_7, igb.c version 1.3.2.12 > > > > Can't say for sure whether there is a key change or is it all changes > summed up, > > sorry. > > > > -- > > Eugene Perevyazko > > > > _______________________________________________ > > 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" > > > > > > -- > Good, fast & cheap. Pick any two. > _______________________________________________ > 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 Dec 1 19: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 DB1EF10656A6 for ; Wed, 1 Dec 2010 19:06:39 +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 6B7A38FC1F for ; Wed, 1 Dec 2010 19:06:39 +0000 (UTC) Received: (qmail 13573 invoked by uid 399); 1 Dec 2010 19:06:38 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Dec 2010 19:06:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CF69CBC.5010109@FreeBSD.org> Date: Wed, 01 Dec 2010 11:06:36 -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, freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: IPv6 + CARP + VLANs + pf == panic on 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: Wed, 01 Dec 2010 19:06:39 -0000 [ Pardon the cross-post, feel free to follow up to just one list, I'm on both. ] Running a system on the latest 8-stable as a router we are seeing the following panic: http://pastebin.com/AJzXmEWe Kernel is as follows: include GENERIC ident ROUTER options SW_WATCHDOG options DEVICE_POLLING options TCP_SIGNATURE options IPSEC device crypto device cryptodev device carp device pf device pflog device pfsync options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options WITNESS options INVARIANTS options INVARIANT_SUPPORT options DDB options BREAK_TO_DEBUGGER Advice and suggestions welcome. A quick look at the diff between HEAD and RELENG_8 didn't show anything obvious to me in the areas affected, but that doesn't mean it isn't there. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 21:32: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 B88BA1065670 for ; Wed, 1 Dec 2010 21:32:32 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 5703C8FC08 for ; Wed, 1 Dec 2010 21:32:32 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 98DEBE7158 for ; Wed, 1 Dec 2010 21:32:31 +0000 (GMT) Received: from core.draftnet (client-86-31-8-12.midd.adsl.virginmedia.com [86.31.8.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Wed, 1 Dec 2010 21:32:30 +0000 (GMT) Date: Wed, 1 Dec 2010 21:32:17 +0000 From: Bruce Cran To: freebsd-net@freebsd.org Message-ID: <20101201213217.19712470@core.draftnet> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: EHOSTUNREACH returned for refused IPv6 connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 21:32:32 -0000 It appears that the network stack on -CURRENT is returning EHOSTUNREACH instead of ECONNREFUSED when trying to connect to a closed port over IPv6. e.g.: > telnet www.kame.net 10000 Trying 203.178.141.194... telnet: connect to address 203.178.141.194: Connection refused Trying 2001:200:dff:fff1:216:3eff:feb1:44d7... telnet: connect to address 2001:200:dff:fff1:216:3eff:feb1:44d7: No route to host telnet: Unable to connect to remote host Though it works locally: > telnet localhost 10000 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused Trying ::1... telnet: connect to address ::1: Connection refused telnet: Unable to connect to remote host -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 21:40:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E0B1065694 for ; Wed, 1 Dec 2010 21:40:25 +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 08A828FC16 for ; Wed, 1 Dec 2010 21:40:25 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0E17141C707; Wed, 1 Dec 2010 22:40:24 +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 TQR2p32Armkz; Wed, 1 Dec 2010 22:40:23 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 4443941C711; Wed, 1 Dec 2010 22:40:23 +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 4DD5644490B; Wed, 1 Dec 2010 21:40:16 +0000 (UTC) Date: Wed, 1 Dec 2010 21:40:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Bruce Cran In-Reply-To: <20101201213217.19712470@core.draftnet> Message-ID: <20101201213841.U6126@maildrop.int.zabbadoz.net> References: <20101201213217.19712470@core.draftnet> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: EHOSTUNREACH returned for refused IPv6 connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 21:40:25 -0000 On Wed, 1 Dec 2010, Bruce Cran wrote: > It appears that the network stack on -CURRENT is returning EHOSTUNREACH > instead of ECONNREFUSED when trying to connect to a closed port over > IPv6. e.g.: > >> telnet www.kame.net 10000 > Trying 203.178.141.194... > telnet: connect to address 203.178.141.194: Connection refused > Trying 2001:200:dff:fff1:216:3eff:feb1:44d7... > telnet: connect to address 2001:200:dff:fff1:216:3eff:feb1:44d7: No > route to host No route to host ... can you ping6/traceroute6 to www.kame.net? Can you reach it with: telnet -6 www.kame.net 80 ? Your connectivity to there seems to be foobared if you'd ask me as: bz:~> telnet -6 www.kame.net 10000 Trying 2001:200:dff:fff1:216:3eff:feb1:44d7... telnet: connect to address 2001:200:dff:fff1:216:3eff:feb1:44d7: Connection refused telnet: Unable to connect to remote host I get the connection refused. > telnet: Unable to connect to remote host > > Though it works locally: > >> telnet localhost 10000 > Trying 127.0.0.1... > telnet: connect to address 127.0.0.1: Connection refused > Trying ::1... > telnet: connect to address ::1: Connection refused > telnet: Unable to connect to remote host > > -- 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 Wed Dec 1 21:58: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 481C31065697 for ; Wed, 1 Dec 2010 21:58:44 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7888FC26 for ; Wed, 1 Dec 2010 21:58:44 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 69EDEE7159; Wed, 1 Dec 2010 21:58:43 +0000 (GMT) Received: from core.draftnet (client-86-31-8-12.midd.adsl.virginmedia.com [86.31.8.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 1 Dec 2010 21:58:42 +0000 (GMT) Date: Wed, 1 Dec 2010 21:58:29 +0000 From: Bruce Cran To: "Bjoern A. Zeeb" Message-ID: <20101201215829.2c4387e8@core.draftnet> In-Reply-To: <20101201213841.U6126@maildrop.int.zabbadoz.net> References: <20101201213217.19712470@core.draftnet> <20101201213841.U6126@maildrop.int.zabbadoz.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: EHOSTUNREACH returned for refused IPv6 connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 21:58:44 -0000 On Wed, 1 Dec 2010 21:40:16 +0000 (UTC) "Bjoern A. Zeeb" wrote: > Your connectivity to there seems to be foobared if you'd ask me as: Sorry, you're right: I forgot I don't have my tunnel setup so there's no external IPv6 connectivity (I don't have an IPv6 network configured at the moment at all). What confused me initially was the fact that ssh displays the "No route to host" error instead of "Connection refused" when both IPv4 and IPv6 addresses are available but only IPv4 works. -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 06:18:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E23F7106564A for ; Thu, 2 Dec 2010 06:18:24 +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 3EF288FC13 for ; Thu, 2 Dec 2010 06:18:23 +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 oB26IKAi008527; Thu, 2 Dec 2010 12:18:20 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CF73A2C.7000802@rdtc.ru> Date: Thu, 02 Dec 2010 12:18:20 +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: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 06:18:25 -0000 Hi! I'm building new router using 8.2-PRERELEASE containing new igb(4) driver. I use SuperMicro SuperServer 5016T-MTFB based on X8STi-F motherboard with add-on Intel Gigabit ET Dual Port Server Adapter in PCIe slot. pciconf -lv shows: igb0@pci0:3:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 class = network subclass = ethernet igb1@pci0:3:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 class = network subclass = ethernet I connect both ports to Cisco 7606 core router and they link after "ifconfig ibg1 up" command. But "ifconfig igb1 down" does NOT bring link down: - ifconfig igb still shows "status: active" (but not UP nor RUNNING); - LEDs are on (both SuperServer's and Cisco's) - Cisco also shows interfaces in "up" state. That's bad as I plan to use EtherChannel/lagg configuration and need working up/down management. Driver igb(4) is not compiled into kernel, it's loaded using if_igb.ko. I've rebuilt kernel module changing if_igb.h to get debugging output: #define DEBUG_INIT 1 #define DEBUG_IOCTL 1 #define DEBUG_HW 1 Now I have in kernel log after single "ifconfig igb1 down" command: Dec 2 11:46:11 k-45-pc-2 kernel: ioctl rcv'd: SIOCSIFFLAGS (Set Interface Flags) Dec 2 11:46:11 k-45-pc-2 kernel: igb_stop: begin Dec 2 11:46:13 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:46:13 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:46:13 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:46:13 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:46:13 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:46:13 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:47:52 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:47:52 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:47:52 k-45-pc-2 kernel: Dec 2 11:47:52 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:47:52 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:47:52 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:47:52 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:51:15 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:51:15 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:51:15 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:51:15 k-45-pc-2 kernel: igb_media_status: begin Dec 2 11:51:15 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 11:51:15 k-45-pc-2 kernel: igb_media_status: begin Dec 2 12:05:16 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 12:05:16 k-45-pc-2 kernel: igb_media_status: begin Dec 2 12:05:16 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 12:05:16 k-45-pc-2 kernel: igb_media_status: begin Dec 2 12:05:16 k-45-pc-2 kernel: ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media) Dec 2 12:05:16 k-45-pc-2 kernel: igb_media_status: begin Dec 2 12:05:16 k-45-pc-2 kernel: If I do "ifconfig igb1 up" now, link is brought down for short time then up. This SuperServer box has two built-in em(4) ports that have not this problem. How should I fix this? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 10:18:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03F0F1065698 for ; Thu, 2 Dec 2010 10:18:48 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 345108FC15 for ; Thu, 2 Dec 2010 10:18:46 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.hq.norma.perm.ru [192.168.7.246]) by elf.hq.norma.perm.ru (8.14.3/8.14.3) with ESMTP id oB29juGC064388 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 2 Dec 2010 14:45:56 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4CF76AD4.1010704@norma.perm.ru> Date: Thu, 02 Dec 2010 14:45:56 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100917 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [192.168.3.10]); Thu, 02 Dec 2010 14:45:56 +0500 (YEKT) X-Callback: Sender verified by milter-callback 1.5.10 at elf.hq.norma.perm.ru. X-Callback-Status: relay [192.168.7.246] found in white list. X-Callback-Envelope-From: emz@norma.perm.ru X-Spam-Status: No hits=-102.9 bayes=0.0000 testhits ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Subject: ah_input: packet replay failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 10:18:48 -0000 Hi. What does this message means ? I'm getting a lots of those. ===Cut=== Dec 2 14:35:15 ural85-gw0-omega kernel: ah_input: packet replay failure: SA(SPI=3662816 src=10.50.116.6 dst=10.50.110.210) ===Cut=== I'm using FreeBSD as a security gateway: FreeBSD A >======ipsec over gre===> FreeBSD B A is 10.50.110.210 B is 10.50.116.6 А is a 8.1-RELEASE amd64 box, B is 8.0-RELEASE-p2 i386. A is not the only ipsec peer of B, B has a dozen of another cisco/freebsd peers. Keys are exchanged via the ipsec-tools racoon fork. However, I'm getting much lesser of messages on B (and all of them are about A), for example: ===Cut=== Dec 2 14:35:09 wizard kernel: ah_input: packet replay failure: SA(SPI=136093282 src=10.50.110.210 dst=10.50.116.6) ===Cut=== And I'm getting no messages aboyut other FreeBSD/Cisco hosts (and all of them are using IKE). All of other FreeBSD boxes are i386. I'm using ah+esp policy (can post it here if it's related). All seems to be working fine, except those messages. I'm worrying because the cause of those messages can be the cause of rarely encountered VoIP distortions, but to be honest, the messages occurs much more frequently than the distortions and can be releted with overloaded channel, but still. Thanks. Eugene. From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 15:30:14 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 E4F8A1065670 for ; Thu, 2 Dec 2010 15:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B78868FC14 for ; Thu, 2 Dec 2010 15:30:14 +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 oB2FUE2O034906 for ; Thu, 2 Dec 2010 15:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB2FUEh1034901; Thu, 2 Dec 2010 15:30:14 GMT (envelope-from gnats) Date: Thu, 2 Dec 2010 15:30:14 GMT Message-Id: <201012021530.oB2FUEh1034901@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?windows-1251?B?1e7w8+bo6SDR5fDj5ekg3vD85eLo9w==?= Cc: Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?1e7w8+bo6SDR5fDj5ekg3vD85eLo9w==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:30:15 -0000 The following reply was made to PR kern/124753; it has been noted by GNATS. From: =?windows-1251?B?1e7w8+bo6SDR5fDj5ekg3vD85eLo9w==?= To: bug-followup@FreeBSD.org, nugundam@nugundam.best.vwh.net Cc: Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early Date: Thu, 2 Dec 2010 18:07:32 +0300 I had the exact same problem with Atheros 9285 and 8.1-STABLE, such as 9-CU= RRENT. Changing kernel source as a=20 http://thread.gmane.org/gmane.os.freebsd.current/110707 didn't help. What else can I do to it work properly? From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 18:09:31 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 7539110656A9; Thu, 2 Dec 2010 18:09:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8EE8FC1B; Thu, 2 Dec 2010 18:09:31 +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 oB2I9VL6000971; Thu, 2 Dec 2010 18:09:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB2I9VvS000967; Thu, 2 Dec 2010 18:09:31 GMT (envelope-from linimon) Date: Thu, 2 Dec 2010 18:09:31 GMT Message-Id: <201012021809.oB2I9VvS000967@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/152768: [mfi] Weird check in mfi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 18:09:31 -0000 Old Synopsis: Weird check in mfi(4) New Synopsis: [mfi] Weird check in mfi(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 2 18:09:11 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=152768 From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 18:09:53 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 071D6106564A; Thu, 2 Dec 2010 18:09:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D16458FC1A; Thu, 2 Dec 2010 18:09:52 +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 oB2I9qYO001021; Thu, 2 Dec 2010 18:09:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB2I9qUt001017; Thu, 2 Dec 2010 18:09:52 GMT (envelope-from linimon) Date: Thu, 2 Dec 2010 18:09:52 GMT Message-Id: <201012021809.oB2I9qUt001017@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/152768: [mfi] Weird check in mfi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 18:09:53 -0000 Synopsis: [mfi] Weird check in mfi(4) Responsible-Changed-From-To: freebsd-net->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 2 18:09:40 UTC 2010 Responsible-Changed-Why: bah. too early in the morning, I guess. http://www.freebsd.org/cgi/query-pr.cgi?pr=152768 From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 20:33: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 17D84106566B for ; Thu, 2 Dec 2010 20:33:15 +0000 (UTC) (envelope-from Rozhuk_I@mail.ru) Received: from smtp1.mail.ru (smtp1.mail.ru [94.100.176.129]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB978FC1A for ; Thu, 2 Dec 2010 20:33:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Reply-To; bh=9MuNMQEEykW/rQQIGOb3d+YsPnWLU5EcwXtGXrXDxyE=; b=So3fEeexQj8jnJosPNlDNf5vcCWZl/+R5HMq6PvBf+X8KehzUuw0mvZKiXisSxkLATrA7TaRzeaw/LC/3GWvF6MyInMXjcDz/DC6skDYbRcj9AGECqnKZlLLqdMW/PgO; Received: from [92.124.46.175] (port=1 helo=smtp1.mail.ru) by smtp1.mail.ru with asmtp id 1POFq4-00049H-00 for freebsd-net@freebsd.org; Thu, 02 Dec 2010 23:33:12 +0300 From: "Rozhuk Ivan" To: Date: Fri, 3 Dec 2010 04:33:10 +0800 Message-ID: <000001cb9260$23aeb900$6b0c2b00$@ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01CB92A3.31D1F900" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuSYCKL7alibDEUS/Cf/u0nsLKDlA== Content-Language: ru X-Mras: Ok Subject: kern/152141: [vlan] encapsulate vlan in ng_ether before output to if 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: Thu, 02 Dec 2010 20:33:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CB92A3.31D1F900 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi! This is a patch for ng_ether_rcv_lower function in ng_ether.c to = encapsulate vlan before send to net. =A0 -- Rozhuk Ivan =A0=20 ------=_NextPart_000_0001_01CB92A3.31D1F900 Content-Type: application/octet-stream; name="ng_ether.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ng_ether.patch" --- /usr/src/sys/netgraph/ng_ether.c 2010-01-19 04:34:00.000000000 +0800=0A= +++ /usr/src/sys/netgraph/ng_ether.new 2010-11-20 18:26:55.000000000 = +0800=0A= @@ -652,6 +652,20 @@=0A= ETHER_ADDR_LEN);=0A= }=0A= =0A= + /*=0A= + * If underlying interface can not do VLAN tag insertion itself=0A= + * then attach a packet tag that holds it.=0A= + */=0A= + if ((m->m_flags & M_VLANTAG) &&=0A= + (ifp->if_capenable & IFCAP_VLAN_HWTAGGING) =3D=3D 0) {=0A= + m =3D ether_vlanencap(m, m->m_pkthdr.ether_vtag);=0A= + if (m =3D=3D NULL) {=0A= + ifp->if_oerrors++;=0A= + return (ENOBUFS);=0A= + }=0A= + m->m_flags &=3D ~M_VLANTAG;=0A= + }=0A= +=0A= /* Send it on its way */=0A= return ether_output_frame(ifp, m);=0A= }=0A= ------=_NextPart_000_0001_01CB92A3.31D1F900-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 20:56: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 5B6521065698 for ; Thu, 2 Dec 2010 20:56:59 +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 E37878FC13 for ; Thu, 2 Dec 2010 20:56:58 +0000 (UTC) Received: by fxm16 with SMTP id 16so6628349fxm.13 for ; Thu, 02 Dec 2010 12:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=cviKZdeTQtBFUuCvlS/rWzMLkkLT/azb6cDKVLI+/xc=; b=ST6wafkFBQj3vxhjb4m8LmvudQs33iHzu+TFteCU08cRxqPDa2C1RzcV/SuqWS4g5E 5/zVfxgj4fGs3LwL8cNznVH0QagplRVmb/oqcv3t2qpiNBNqhUc1rEtUEXHsSwpSCiNV siPmWTs9OpRcwEBld9uH9hZ7PKX2066sAMjFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=x2gN/bMKbIhAqzefRCmH4gStBxnGMGfUMeswK7t/vxPi7h8l+wHvE4JuqS5I+QVa/Q huQimJIhpMp2G28UCaMQGjyUmw8bLoPKk9XXGewpwuNfYbA0+EgvsRSMnfnmFERF5MoO C2wjwZHlPvA+ydCUbtebkgu24aJoB6EsJvHc0= Received: by 10.223.123.209 with SMTP id q17mr1139141far.126.1291323417640; Thu, 02 Dec 2010 12:56:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.85.207 with HTTP; Thu, 2 Dec 2010 12:56:42 -0800 (PST) From: Gabor Radnai Date: Thu, 2 Dec 2010 21:56:42 +0100 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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: Thu, 02 Dec 2010 20:56:59 -0000 Hi, Could someone pls advise how to inject HEAD driver to stable release without full kernel rebuild (if possible)? I tried this way but found no assurance/evidence actually kernel using the new driver: 1. download full HEAD source with help of csup 2. in /usr/src/sys/modules/re did make install which in turn compiled re driver and installed into default /boot/kernel 3. reboot So far so good but still re0 driver cannot properly handle rtl8111 chip seeing the very same symptoms as in case of the driver shipped with RELEASE. Thanks. From owner-freebsd-net@FreeBSD.ORG Thu Dec 2 21:00: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 0C1E0106564A for ; Thu, 2 Dec 2010 21:00: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 82AD08FC15 for ; Thu, 2 Dec 2010 21:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7CA9D41C749; Thu, 2 Dec 2010 22:00:06 +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 EU67MQGp7F0E; Thu, 2 Dec 2010 22:00:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id DD6F141C75B; Thu, 2 Dec 2010 22:00: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 B852C4448F3; Thu, 2 Dec 2010 20:58:59 +0000 (UTC) Date: Thu, 2 Dec 2010 20:58:59 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "Eugene M. Zheganin" In-Reply-To: <4CF76AD4.1010704@norma.perm.ru> Message-ID: <20101202205442.C6126@maildrop.int.zabbadoz.net> References: <4CF76AD4.1010704@norma.perm.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: ah_input: packet replay failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:00:08 -0000 On Thu, 2 Dec 2010, Eugene M. Zheganin wrote: Hi, > What does this message means ? > I'm getting a lots of those. > > ===Cut=== > Dec 2 14:35:15 ural85-gw0-omega kernel: ah_input: packet replay failure: > SA(SPI=3662816 src=10.50.116.6 dst=10.50.110.210) > ===Cut=== you are running with debugging turn on; otherwise you'd just see the statistics being updated. > I'm using FreeBSD as a security gateway: > > FreeBSD A >======ipsec over gre===> FreeBSD B What it means is that a packet with either an invalid sequence, a sequence lower than the last seen and outside the window, or a sequence seen already (lately) has arrived. Could it be that something is duplicating packets or that you have packet loss between A and B? Given that you say that you are running IPsec on top of GRE (which sounds strange anyway) I'd monitor the outer tunnel endpoints independently to see what's going on. /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 Thu Dec 2 21:30: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 6FB4F1065675 for ; Thu, 2 Dec 2010 21:30:32 +0000 (UTC) (envelope-from pyunyh@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 2434A8FC13 for ; Thu, 2 Dec 2010 21:30:31 +0000 (UTC) Received: by gxk8 with SMTP id 8so4661119gxk.13 for ; Thu, 02 Dec 2010 13:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=iIpWCRNu+n0PPCDpFY7JiB8nO+rhcULKme60wdmrw1U=; b=T8sjpZ8VstSEh1l37q2eAxIKFw+iykRhp2Yi6tRYRh4EUTjGgqzUuXMOsK3zvUg5dU u01f/Nz2KpyMszgYoCRtft9aERmIysmarGPm8LLBoz2PdIuEYZNY5l0c2/JcszKbQe3z 56rflOVDogPesVLycsC7MFRLpU1qgQPnAiefw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=P9G84klO+f44Rkd6R1g7Nx+kHw/0/WVXes66XRU5dJqM6Vkk+AJw4A/OMxHiwX4pC5 tsVquLumqg8xxisOvcwWPBYC5nx2FaQKOs5pIJ9Lltt195HicoWoajqXSxTjUh+QxJfi AEK6QFjSJsj9Kgqohr+tLBDw/iTtYGajJPMTc= Received: by 10.147.137.13 with SMTP id p13mr28022yan.37.1291325431367; Thu, 02 Dec 2010 13:30:31 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id u68sm573735yhc.47.2010.12.02.13.30.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 13:30:30 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 2 Dec 2010 13:30:28 -0800 From: Pyun YongHyeon Date: Thu, 2 Dec 2010 13:30:28 -0800 To: Gabor Radnai Message-ID: <20101202213028.GE13006@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:30:32 -0000 On Thu, Dec 02, 2010 at 09:56:42PM +0100, Gabor Radnai wrote: > Hi, > > Could someone pls advise how to inject HEAD driver to stable release without > full kernel rebuild (if possible)? > If you have updated to stable/8, the driver code would be the same. So need to replace driver with HEAD version. > I tried this way but found no assurance/evidence actually kernel using the > new driver: > 1. download full HEAD source with help of csup > 2. in /usr/src/sys/modules/re did make install which in turn compiled re > driver and installed into default /boot/kernel > 3. reboot > > So far so good but still re0 driver cannot properly handle rtl8111 chip > seeing the very same symptoms as in case of > the driver shipped with RELEASE. > If my memory is correct, your controller is somewhat old 8168 PCIe controller. I also have the same TP-Link TG-3468 PCIe network card which seems to be the only stand-alone PCIe 8168 controller in market. I don't see any problems using the controller so would you summarize your issue again?(Sorry, if you already post it) > Thanks. From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 07:40:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B32211065693 for ; Fri, 3 Dec 2010 07:40:27 +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 109FF8FC18 for ; Fri, 3 Dec 2010 07:40:26 +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 oB37eNaQ015680; Fri, 3 Dec 2010 13:40:23 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CF89EE7.8020807@rdtc.ru> Date: Fri, 03 Dec 2010 13:40:23 +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: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> In-Reply-To: <4CF73A2C.7000802@rdtc.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 07:40:27 -0000 On 02.12.2010 12:18, Eugene Grosbein wrote: > Hi! > > I'm building new router using 8.2-PRERELEASE containing new igb(4) driver. > I use SuperMicro SuperServer 5016T-MTFB based on X8STi-F motherboard > with add-on Intel Gigabit ET Dual Port Server Adapter in PCIe slot. > > pciconf -lv shows: > > igb0@pci0:3:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 > class = network > subclass = ethernet > igb1@pci0:3:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 > class = network > subclass = ethernet > > I connect both ports to Cisco 7606 core router and they link > after "ifconfig ibg1 up" command. > > But "ifconfig igb1 down" does NOT bring link down: > - ifconfig igb still shows "status: active" (but not UP nor RUNNING); > - LEDs are on (both SuperServer's and Cisco's) > - Cisco also shows interfaces in "up" state. > > That's bad as I plan to use EtherChannel/lagg configuration > and need working up/down management. > This SuperServer box has two built-in em(4) ports that have not this problem. Really em(4) does have this probem too. How do I lock link down using em/igb NICs? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 09:53: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 4CFCD1065696 for ; Fri, 3 Dec 2010 09:53:14 +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 D4DA28FC24 for ; Fri, 3 Dec 2010 09:53:13 +0000 (UTC) Received: by fxm16 with SMTP id 16so7147736fxm.13 for ; Fri, 03 Dec 2010 01:53:12 -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=Gu8eb4fIYT99N0jR/vZqFHIIk/yphyMETD1Gn7kFZbA=; b=O14CQ30p1lwqWFMnGGxH4idl/IFa4h41z3zK74I9HYAb73LtWyHtFGhWPt03daqABR 7av83pNVnDOqI2LjzL13/+YmJJkwIMkj3l9Za0QIUT/R0imAq7G/sFu66RyG8ik54cVH p7twCEyUdCeWD+Nyc/3CbasXXMv8iTGmFmK+s= 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=mtDRx5MaFNX1EWjWDbqS7lKEoG4VphraKWlRt1SVQdr1iHouUPm4ZDdA1RnLcEZCkV LjFXMh8m5bAKW1W3jkHgjl7QxgnXhVj0bC2ZSFNevoMYIUz9xvn0zaGyAxnb/y9AqaJL LDmJy7wn/WQfuXtmEKLGj2QvblxqM+PgfE+RE= Received: by 10.223.78.139 with SMTP id l11mr1879747fak.31.1291369992660; Fri, 03 Dec 2010 01:53:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.85.207 with HTTP; Fri, 3 Dec 2010 01:52:57 -0800 (PST) In-Reply-To: <20101202213028.GE13006@michelle.cdnetworks.com> References: <20101202213028.GE13006@michelle.cdnetworks.com> From: Gabor Radnai Date: Fri, 3 Dec 2010 10:52:57 +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: Fri, 03 Dec 2010 09:53:14 -0000 Hi, On Thu, Dec 2, 2010 at 10:30 PM, Pyun YongHyeon wrote: > > On Thu, Dec 02, 2010 at 09:56:42PM +0100, Gabor Radnai wrote: > > Hi, > > > > Could someone pls advise how to inject HEAD driver to stable release without > > full kernel rebuild (if possible)? > > > > If you have updated to stable/8, the driver code would be the same. > So need to replace driver with HEAD version. How exactly? What do you mean on 'replace': compile from source, just copy the binary from a snapshot image to /boot/kernel or ... ? > > > I tried this way but found no assurance/evidence actually kernel using the > > new driver: > > 1. download full HEAD source with help of csup > > 2. in /usr/src/sys/modules/re did make install which in turn compiled re > > driver and installed into default /boot/kernel > > 3. reboot > > > > So far so good but still re0 driver cannot properly handle rtl8111 chip > > seeing the very same symptoms as in case of > > the driver shipped with RELEASE. > > > > If my memory is correct, your controller is somewhat old 8168 PCIe > controller. I also have the same TP-Link TG-3468 PCIe network card > which seems to be the only stand-alone PCIe 8168 controller in > market. I don't see any problems using the controller so would you > summarize your issue again?(Sorry, if you already post it) If you check the original post I did all details there but a quick summary: I have two TP-Link TG-3468 PCIe network cards which is using Realtek 8168/8111 chip. re0: port 0xac00-0xacff mem 0xfdbff000-0xfdbfffff irq 16 at device 0.0 on pci1 re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: d8:5d:4c:80:b4:88 re0: [FILTER] When I try to use it cannot process DHCP answer properly (sets IP address to 0.0.0.0/255.255.255.255), neither works if using fix IP. Link is up, cable is working but card simply cannot communicate. I switched back and forth all components I could: new cable, connect to different switch port, replace card, use the cable/switch port which is working for integrated motherboard NIC, disable integrated NIC ... no luck so far. Thanks. From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 13:00:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6C110656A4 for ; Fri, 3 Dec 2010 13:00:21 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB6B8FC0A for ; Fri, 3 Dec 2010 13:00:11 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.hq.norma.perm.ru [192.168.7.246]) by elf.hq.norma.perm.ru (8.14.3/8.14.3) with ESMTP id oB3D05CQ039592 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 3 Dec 2010 18:00:05 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4CF8E9D5.3060105@norma.perm.ru> Date: Fri, 03 Dec 2010 18:00:05 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100917 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CF76AD4.1010704@norma.perm.ru> <20101202205442.C6126@maildrop.int.zabbadoz.net> In-Reply-To: <20101202205442.C6126@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [192.168.3.10]); Fri, 03 Dec 2010 18:00:05 +0500 (YEKT) X-Callback: Sender verified by milter-callback 1.5.10 at elf.hq.norma.perm.ru. X-Callback-Status: relay [192.168.7.246] found in white list. X-Callback-Envelope-From: emz@norma.perm.ru X-Spam-Status: No hits=-102.9 bayes=0.0000 testhits ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Subject: Re: ah_input: packet replay failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 13:00:22 -0000 Hi. On 03.12.2010 01:58, Bjoern A. Zeeb wrote: >> >> FreeBSD A >======ipsec over gre===> FreeBSD B > I'm using FreeBSD as a security gateway: > > What it means is that a packet with either an invalid sequence, a > sequence lower than the last seen and outside the window, or a > sequence seen already (lately) has arrived. > > Could it be that something is duplicating packets or that you have > packet loss between A and B? Given that you say that you are running > IPsec on top of GRE (which sounds strange anyway) I'd monitor the > outer tunnel endpoints independently to see what's going on. Well, could you be more exact, please, about what did you mean by saying 'strange' ? Probably, my english isn't that good, I just tried to say that I use ipsec to encrypt my gre tunnels. Could this out-of-the-sequence thing be caused by traffic shaping, such as pf ALTQing ? I just realised that this is the only link I have which has the queueing enabled. Thanks. Eugene. From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 17:49: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 DDDA9106566B for ; Fri, 3 Dec 2010 17:49:50 +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 68FBF8FC13 for ; Fri, 3 Dec 2010 17:49:50 +0000 (UTC) Received: by wyf19 with SMTP id 19so9707996wyf.13 for ; Fri, 03 Dec 2010 09:49:49 -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=80RswTmSdGySrxyQ1zVjS74+Ua5f/YOK/Eg1IQM0zOc=; b=uHBlmiP2VPK1D/Ag3k5sZJd1YlefrLh8ZlF8uyVZyWCxos7o52f+vqlNMVueFfalXm NcA+ZoCdYChQQPj+tQU7T7J3DZFTf4UuSebT5xD+B6/JUl+ofUI3HLXPLlZAMLEM4wZg UmXe7U6iScbPCXga+K7ioees8LtP1DgB25YLM= 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=tWHX8j2Jus4Jja2rW2JiG6v5I8wo1rW66SufW/sex14JfWMgUstxlX4F08OYYK7bQE cyjuo7YrZDuz9Ysa4l0FaYS4cnrYSIhmbbja1py0XZ1TaUE0ZTTBVkDFRQpp5FB5y1U7 L2fvDQ5d6e89DGrcEum/0xngoz/UwNAC6ddis= MIME-Version: 1.0 Received: by 10.216.179.210 with SMTP id h60mr1972237wem.42.1291398588882; Fri, 03 Dec 2010 09:49:48 -0800 (PST) Received: by 10.216.2.206 with HTTP; Fri, 3 Dec 2010 09:49:48 -0800 (PST) In-Reply-To: <4CF89EE7.8020807@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> Date: Fri, 3 Dec 2010 09:49:48 -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 Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 17:49:50 -0000 It has never been the case that 'down'ing an interface brings link down, not on em or igb. So this isn't problem with the release. Jack On Thu, Dec 2, 2010 at 11:40 PM, Eugene Grosbein wrote: > On 02.12.2010 12:18, Eugene Grosbein wrote: > > Hi! > > > > I'm building new router using 8.2-PRERELEASE containing new igb(4) > driver. > > I use SuperMicro SuperServer 5016T-MTFB based on X8STi-F motherboard > > with add-on Intel Gigabit ET Dual Port Server Adapter in PCIe slot. > > > > pciconf -lv shows: > > > > igb0@pci0:3:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 > rev=0x01 hdr=0x00 > > class = network > > subclass = ethernet > > igb1@pci0:3:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 > rev=0x01 hdr=0x00 > > class = network > > subclass = ethernet > > > > I connect both ports to Cisco 7606 core router and they link > > after "ifconfig ibg1 up" command. > > > > But "ifconfig igb1 down" does NOT bring link down: > > - ifconfig igb still shows "status: active" (but not UP nor RUNNING); > > - LEDs are on (both SuperServer's and Cisco's) > > - Cisco also shows interfaces in "up" state. > > > > That's bad as I plan to use EtherChannel/lagg configuration > > and need working up/down management. > > > This SuperServer box has two built-in em(4) ports that have not this > problem. > > Really em(4) does have this probem too. > > How do I lock link down using em/igb NICs? > > Eugene Grosbein > From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 18:44: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 407691065672 for ; Fri, 3 Dec 2010 18:44:11 +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 9288C8FC0A for ; Fri, 3 Dec 2010 18:44:10 +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 oB3Ii7lH018772; Sat, 4 Dec 2010 00:44:07 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CF93A77.30804@rdtc.ru> Date: Sat, 04 Dec 2010 00:44:07 +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: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 18:44:11 -0000 On 03.12.2010 23:49, Jack Vogel wrote: > It has never been the case that 'down'ing an interface brings link down, > not on em > or igb. So this isn't problem with the release. > > Jack Now I see, thanks. Is it technically possible to bring link down for distinct port of dual-port em/igb-supported NICs using software? If yes, I'd like to patch my source tree. For EtherChannel this kind of management should be possible. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 19:02:06 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FC371065670 for ; Fri, 3 Dec 2010 19:02:06 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aob105.obsmtp.com (eu1sys200aob105.obsmtp.com [207.126.144.118]) by mx1.freebsd.org (Postfix) with SMTP id AB1618FC13 for ; Fri, 3 Dec 2010 19:02:05 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKTPk+qkM3Pmg/aEQv/AyBYDkVXBhfQOXG@postini.com; Fri, 03 Dec 2010 19:02:04 UTC Received: from [172.17.10.53] (unknown [172.17.10.53]) by bbbx3.usdmm.com (Postfix) with ESMTP id 2F596FD01C; Fri, 3 Dec 2010 19:02:02 +0000 (UTC) Message-ID: <4CF93E43.8010801@tomjudge.com> Date: Fri, 03 Dec 2010 13:00:19 -0600 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; 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, jfvogel@gmail.com X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: igb and jumbo frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:02:06 -0000 Hi, So I have been playing around with some new hosts I have been deploying (Dell R710's). The systems have a single dual port card in them: igb0@pci0:5:0:0: class=0x020000 card=0xa04c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) igb1@pci0:5:0:1: class=0x020000 card=0xa04c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) Running 8.1 these cards panic the system at boot when initializing the jumbo mtu, so to solve this I back ported the stable/8 driver to 8.1 and booted with this kernel. So far so good. However when configuring the interfaces with and mtu of 8192 the system is unable to allocate the required mbufs for the receive queue. I believe the message was from here: http://fxr.watson.org/fxr/source/dev/e1000/if_igb.c#L1209 After a little digging and playing with just one interface i discovered that the default tuning for kern.ipc.nmbjumbo9 was insufficient to run a single interface with jumbo frames as it seemed just the TX queue consumed 90% of the available 9k jumbo clusters. So my question is (well 2 questions really): 1) Should igb be auto tuning kern.ipc.nmbjumbo9 and kern.ipc.nmbclusters up to suite its needs? 2) Should this be documented in igb(4)? Tom -- TJU13-ARIN From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 19:38: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 1B99C1065672 for ; Fri, 3 Dec 2010 19:38:03 +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 C19948FC26 for ; Fri, 3 Dec 2010 19:38:02 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:2c91:fa66:2350:ddab] ([IPv6:2607:f3e0:0:4:2c91:fa66:2350:ddab]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oB3Jc0cC017332 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 3 Dec 2010 14:38:00 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CF9470F.4020709@sentex.net> Date: Fri, 03 Dec 2010 14:37: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: Eugene Grosbein References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> In-Reply-To: <4CF93A77.30804@rdtc.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:38:03 -0000 On 12/3/2010 1:44 PM, Eugene Grosbein wrote: > On 03.12.2010 23:49, Jack Vogel wrote: >> It has never been the case that 'down'ing an interface brings link down, >> not on em >> or igb. So this isn't problem with the release. >> >> Jack > > Now I see, thanks. > > Is it technically possible to bring link down > for distinct port of dual-port em/igb-supported NICs using software? > > If yes, I'd like to patch my source tree. > For EtherChannel this kind of management should be possible. If your switch port's speed and duplex are manual, change the media options on the NIC to something like 10 half. The switch should see the port "down" then. ---Mike > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 19:41: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 AA675106564A for ; Fri, 3 Dec 2010 19:41:10 +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 098028FC0A for ; Fri, 3 Dec 2010 19:41:09 +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 oB3Jf8JW018936; Sat, 4 Dec 2010 01:41:08 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CF947D4.10504@rdtc.ru> Date: Sat, 04 Dec 2010 01:41:08 +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: Mike Tancsa References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> In-Reply-To: <4CF9470F.4020709@sentex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:41:10 -0000 On 04.12.2010 01:37, Mike Tancsa wrote: >> Now I see, thanks. >> >> Is it technically possible to bring link down >> for distinct port of dual-port em/igb-supported NICs using software? >> >> If yes, I'd like to patch my source tree. >> For EtherChannel this kind of management should be possible. > > > If your switch port's speed and duplex are manual, change the media > options on the NIC to something like 10 half. The switch should see the > port "down" then. Yes, but switches are not always at my control and one may be in auto mode. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 22:00: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 62D27106564A for ; Fri, 3 Dec 2010 22:00:11 +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 AB6188FC15 for ; Fri, 3 Dec 2010 22:00:10 +0000 (UTC) Received: by wyf19 with SMTP id 19so9975285wyf.13 for ; Fri, 03 Dec 2010 14:00:09 -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=TW7tuOD4GU7AD9v7OabpmyaCPyZXZTYbaTyDbL3L0vw=; b=nX0l195aaCt7IwRc9ncHFOMxHu8H5R6ruCOPg2EAP9yc3lr6/3urZpHjj30tuCdmxU mJNAS6SrlKL7S6pLPrmWnZXovWho7HAw5Vq2VZp73NANVOSYshCzehVGO17DmYcliElG VPWhAOpMshCL35q/PQ4Pt+d6YhNvCyXQWBXNM= 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=vwJskVNwpk43XufrcEg6oJVEsfXML7SRNBRy5tHMNm6MMIJlUMMhSwuMiQlpDep37B +Tap/qPXGOLSb4GOtH6yeehRyq2Yu1GC7lZSFEfQd+sCGqIYrcr39cXqOHE6JqHFDj2V Hn/wvCaFXF7QOoU6Z63eWlmHaXB4LpBtWyhGA= MIME-Version: 1.0 Received: by 10.216.169.72 with SMTP id m50mr2249869wel.27.1291413609310; Fri, 03 Dec 2010 14:00:09 -0800 (PST) Received: by 10.216.2.206 with HTTP; Fri, 3 Dec 2010 14:00:08 -0800 (PST) In-Reply-To: <4CF947D4.10504@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> Date: Fri, 3 Dec 2010 14:00:08 -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 , Mike Tancsa Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 22:00:11 -0000 There are pros and cons either way you do things. I was talking to some of our Linux crew, they recently changed things so it would shut down the phy, but that doesn't always make everyone happy either. Just saying that my FreeBSD drivers have not done so forever :) Jack On Fri, Dec 3, 2010 at 11:41 AM, Eugene Grosbein wrote: > On 04.12.2010 01:37, Mike Tancsa wrote: > > >> Now I see, thanks. > >> > >> Is it technically possible to bring link down > >> for distinct port of dual-port em/igb-supported NICs using software? > >> > >> If yes, I'd like to patch my source tree. > >> For EtherChannel this kind of management should be possible. > > > > > > If your switch port's speed and duplex are manual, change the media > > options on the NIC to something like 10 half. The switch should see the > > port "down" then. > > Yes, but switches are not always at my control and one may be in auto mode. > > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 22:05: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 0195D106566C for ; Fri, 3 Dec 2010 22:05:35 +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 7DE988FC14 for ; Fri, 3 Dec 2010 22:05:34 +0000 (UTC) Received: by wyf19 with SMTP id 19so9982751wyf.13 for ; Fri, 03 Dec 2010 14:05: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=yDmoVKMtTEk+VgWckpSslMVbaIjyFApUT5Hxg3+SujU=; b=QwWYQDWOQ1XUqgnrHP062c/yDI9xKcDSxYD8AsH+2UdyXATDteMCBkNCjsMJA+Bv5r qAKF9gcg57GLBim6JZTX7mZG5oRAPMH4D5jiROxxj+UH4+gi+HB2XkXSbiMD+VtLaLMU Llt1vYCUCmwT5w88MQHrUX/+dhkJ6ORK8AzH4= 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=U4ZX9s9FMEyKFj1Bln8OJSQhUfeB3hPqWUZZLWcdO5xbzLE2+N3Jih7P8Rb0XUzS9x xA96bxhZrmF57TRv20MnesiIu7pOrWUtSU5HeQfz6BUIeNi0l3sgHhNZ8ViSeeYKfNyd jHDrWpkr9qj8XiInTTuTJRR3s+gr9GlPTuC/s= MIME-Version: 1.0 Received: by 10.216.154.8 with SMTP id g8mr1198187wek.12.1291413932973; Fri, 03 Dec 2010 14:05:32 -0800 (PST) Received: by 10.216.2.206 with HTTP; Fri, 3 Dec 2010 14:05:32 -0800 (PST) In-Reply-To: <4CF93E43.8010801@tomjudge.com> References: <4CF93E43.8010801@tomjudge.com> Date: Fri, 3 Dec 2010 14:05:32 -0800 Message-ID: From: Jack Vogel To: Tom Judge Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: igb and jumbo frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 22:05:35 -0000 Since you're already configuring the system into a special non-standard way you are playing the admin, so I'd expect you to also configure memory pool resources, not to have the driver do so. Its also going to depend on the number of queues you have, you can reduce those manually as well. I'm glad you're trying this out however, the 9K cluster use is new, and not uncontroversial either, I decided to put it in, but if problems occur, or someone has a strong valid-sounding argument for not using them, I could be persuaded to take it our and just use 2K and 4K sizes. So... any feedback is good right now. Jack On Fri, Dec 3, 2010 at 11:00 AM, Tom Judge wrote: > Hi, > > So I have been playing around with some new hosts I have been deploying > (Dell R710's). > > The systems have a single dual port card in them: > > igb0@pci0:5:0:0: class=0x020000 card=0xa04c8086 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > igb1@pci0:5:0:1: class=0x020000 card=0xa04c8086 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > > > Running 8.1 these cards panic the system at boot when initializing the > jumbo mtu, so to solve this I back ported the stable/8 driver to 8.1 and > booted with this kernel. So far so good. > > However when configuring the interfaces with and mtu of 8192 the system > is unable to allocate the required mbufs for the receive queue. > > I believe the message was from here: > http://fxr.watson.org/fxr/source/dev/e1000/if_igb.c#L1209 > > After a little digging and playing with just one interface i discovered > that the default tuning for kern.ipc.nmbjumbo9 was insufficient to run a > single interface with jumbo frames as it seemed just the TX queue > consumed 90% of the available 9k jumbo clusters. > > So my question is (well 2 questions really): > > 1) Should igb be auto tuning kern.ipc.nmbjumbo9 and kern.ipc.nmbclusters > up to suite its needs? > > 2) Should this be documented in igb(4)? > > Tom > > -- > TJU13-ARIN > From owner-freebsd-net@FreeBSD.ORG Fri Dec 3 22:19: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 036DE106566C for ; Fri, 3 Dec 2010 22:19:37 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by mx1.freebsd.org (Postfix) with SMTP id D9DF88FC12 for ; Fri, 3 Dec 2010 22:19:35 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKTPls9sQIiAI+c/6zntYC0li5ADufeTqz@postini.com; Fri, 03 Dec 2010 22:19:36 UTC Received: from [172.17.10.53] (unknown [172.17.10.53]) by bbbx3.usdmm.com (Postfix) with ESMTP id 0075EFD019; Fri, 3 Dec 2010 22:19:33 +0000 (UTC) Message-ID: <4CF96C8F.6020203@tomjudge.com> Date: Fri, 03 Dec 2010 16:17:51 -0600 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jack Vogel References: <4CF93E43.8010801@tomjudge.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: igb and jumbo frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 22:19:37 -0000 Hi Jack, Thanks for the response. On 12/03/2010 04:05 PM, Jack Vogel wrote: > Since you're already configuring the system into a special non-standard > way you are playing the admin, so I'd expect you to also configure memory > pool resources, not to have the driver do so. Its also going to depend on > the number of queues you have, you can reduce those manually as well. > In light of this is it worth documenting in igb(4) that it can use a lot of resources? Maybe adding a little more information about the allocation in the error messages would be a good idea also. The reason I say this that for some reason the drivers requests for jumbos that where failing did not show up in the denied counters in netstat -m. I'm currently using the following settings in loader.conf: kern.ipc.nmbclusters="131072" kern.ipc.nmbjumbo9="38400" Not sure where the first one should be but i had to raise it from the default to get things to work. The second leaves me at about 50% utilisation for 9k clusters operating 2 NICs at 8192 mtu: 16385/2214/18599/32768 9k jumbo clusters in use (current/cache/total/max) > I'm glad you're trying this out however, the 9K cluster use is new, and not > uncontroversial either, I decided to put it in, but if problems occur, > or someone > has a strong valid-sounding argument for not using them, I could be > persuaded > to take it our and just use 2K and 4K sizes. I'm not sure it is or will be an issue, but I was hitting my head on the desk for a few hours before I worked out why this was happening. I had to read the code to deduce where the error was coming from and work out the issue. Hopefully we don't have the same issue here as with bce(4) where the memory area get fragmented and the system can't allocate any new 9k clusters. > > So... any feedback is good right now. > I will provide more feedback in the coming weeks as we load these (4) systems up. Currently they are idling waiting for the application jails to be deployed on them. Tom > Jack > > > On Fri, Dec 3, 2010 at 11:00 AM, Tom Judge > wrote: > > Hi, > > So I have been playing around with some new hosts I have been deploying > (Dell R710's). > > The systems have a single dual port card in them: > > igb0@pci0:5:0:0: class=0x020000 card=0xa04c8086 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > igb1@pci0:5:0:1: class=0x020000 card=0xa04c8086 chip=0x10c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > > > Running 8.1 these cards panic the system at boot when initializing the > jumbo mtu, so to solve this I back ported the stable/8 driver to 8.1 and > booted with this kernel. So far so good. > > However when configuring the interfaces with and mtu of 8192 the system > is unable to allocate the required mbufs for the receive queue. > > I believe the message was from here: > http://fxr.watson.org/fxr/source/dev/e1000/if_igb.c#L1209 > > After a little digging and playing with just one interface i discovered > that the default tuning for kern.ipc.nmbjumbo9 was insufficient to run a > single interface with jumbo frames as it seemed just the TX queue > consumed 90% of the available 9k jumbo clusters. > > So my question is (well 2 questions really): > > 1) Should igb be auto tuning kern.ipc.nmbjumbo9 and kern.ipc.nmbclusters > up to suite its needs? > > 2) Should this be documented in igb(4)? > > Tom > > -- > TJU13-ARIN > > -- TJU13-ARIN From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 00:32:15 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 E17F6106566C; Sat, 4 Dec 2010 00:32:15 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B7B128FC13; Sat, 4 Dec 2010 00:32:15 +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 oB40WF6s012605; Sat, 4 Dec 2010 00:32:15 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB40WF7N012601; Sat, 4 Dec 2010 00:32:15 GMT (envelope-from adrian) Date: Sat, 4 Dec 2010 00:32:15 GMT Message-Id: <201012040032.oB40WF7N012601@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, adrian@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 00:32:16 -0000 Synopsis: [ieee80211] net80211 discards power-save queue packets early Responsible-Changed-From-To: freebsd-net->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Sat Dec 4 00:31:29 UTC 2010 Responsible-Changed-Why: I'll take care of this; I've been knee-deep in this code for sometime. :/ http://www.freebsd.org/cgi/query-pr.cgi?pr=124753 From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 00:34: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 C1D451065674 for ; Sat, 4 Dec 2010 00:34:38 +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 53DA98FC14 for ; Sat, 4 Dec 2010 00:34:37 +0000 (UTC) Received: by wyf19 with SMTP id 19so10111735wyf.13 for ; Fri, 03 Dec 2010 16:34:37 -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=1ikJWxLgeRAXtkYiz5Piam8vT/GhZUsNyEITnbDXo8I=; b=EFU1KKhqxQtKLC4uCInaBlC3v+KjZYgquzEaigOwRSZc/uHlsQ26Hxpla8pvJZ00aT ef4jNT0UHsVdpSBu0/8xw/onNnQvgy6aiWJqX4rdY0H3zX8dLSkD+64YGGtWIywMVE5n ACd3uwkGvraZ6ZuDP9e1sxF/ojQUPbs6HEvN0= 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=iAIXl7aoRrv5AMSDBMbNkNNi/Qv4VxmtcHTIiMCeb9o5dQaiQe/h/WDCp+rC6X01qm hPpKNvrpjGrrYbZi8p5ItX9BnSK3H2kgvF2Ii0nKrWK2Jr7GH8jeaYii3LHOoaLg4H5g 79DlCjYJnD4+fM0AgFrkBtDioAVFLVLwhszWk= MIME-Version: 1.0 Received: by 10.216.46.193 with SMTP id r43mr1311109web.20.1291422875613; Fri, 03 Dec 2010 16:34:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Fri, 3 Dec 2010 16:34:35 -0800 (PST) In-Reply-To: <201012021530.oB2FUEh1034901@freefall.freebsd.org> References: <201012021530.oB2FUEh1034901@freefall.freebsd.org> Date: Sat, 4 Dec 2010 08:34:35 +0800 X-Google-Sender-Auth: LbvARtzyGCV7aOpZ6egSf_zTzKc Message-ID: From: Adrian Chadd To: =?KOI8-R?B?6M/S1dbJyiDzxdLHxcog4NLYxdfJ3g==?= Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 00:34:38 -0000 Hi, Ok. This looks somewhat straight-forward to diagnose and debug. I don't however have any devices to reproduce this with. Would someone please describe -exactly- what device(s) I need to try and acquire to reproduce this behaviour? Or if you have it happening for you, would you please do a tcpdump on the wifi interface and capture all of the radio frames in question? I'd like to see how often it's sending power save mgmt frames. tcpdump -ni wlan0 -y IEEE802_11_RADIO captures the frames. Please take a snapshot: # tcpdump -s 0 -v -w pcap.out -ni wlan0 -y IEEE802_11_RADIO Thanks! Adrian 2010/12/2 =E8=CF=D2=D5=D6=C9=CA =F3=C5=D2=C7=C5=CA =E0=D2=D8=C5=D7=C9=DE : > The following reply was made to PR kern/124753; it has been noted by GNAT= S. > > From: =3D?windows-1251?B?1e7w8+bo6SDR5fDj5ekg3vD85eLo9w=3D=3D?=3D > To: bug-followup@FreeBSD.org, nugundam@nugundam.best.vwh.net > Cc: > Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue = packets early > Date: Thu, 2 Dec 2010 18:07:32 +0300 > > =9AI had the exact same problem with Atheros 9285 and 8.1-STABLE, such as= 9-CU=3D > =9ARRENT. > =9AChanging kernel source as a=3D20 > =9Ahttp://thread.gmane.org/gmane.os.freebsd.current/110707 didn't help. > =9AWhat else can I do to it work properly? > > _______________________________________________ > 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 Sat Dec 4 07:49: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 60157106566B for ; Sat, 4 Dec 2010 07:49:00 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 18AA18FC16 for ; Sat, 4 Dec 2010 07:49:00 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id oB47mwvZ019559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Dec 2010 23:48:58 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id oB47mw7M019558; Fri, 3 Dec 2010 23:48:58 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA26208; Fri, 3 Dec 10 23:36:45 PST Date: Fri, 03 Dec 2010 23:36:17 -0800 From: perryh@pluto.rain.com To: egrosbein@rdtc.ru, jfvogel@gmail.com Message-Id: <4cf9ef71./9OtjLOA2+IV0UUh%perryh@pluto.rain.com> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mike@sentex.net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 07:49:00 -0000 Jack Vogel wrote: > There are pros and cons either way you do things. I was talking > to some of our Linux crew, they recently changed things so it > would shut down the phy, but that doesn't always make everyone > happy either. In particular, depending on the type of switch and how it is configured, it may take 30 seconds or so after link is restored for the switch to do spanning-tree validation before it will start to pass traffic. There may be something to be said for making the driver's behavior configurable. From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 08:28: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 322BF106564A for ; Sat, 4 Dec 2010 08:28:54 +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 AB4978FC1F for ; Sat, 4 Dec 2010 08:28:53 +0000 (UTC) Received: by wwf26 with SMTP id 26so6029952wwf.31 for ; Sat, 04 Dec 2010 00:28:52 -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=VHxhRCnO6LNQbBgwwUMjZRVSr55sWviRodCpygc3YQo=; b=vbYdhGx4VIXL3dOS9+SzmxQjRliCeuDiHbFUWV7zTcOMJwcmeJT08lSOUjOkff+iNm RwWgfc+kdZZ5TN2SHoYWPMfL4YdCoMfccSGOivcGr3qmy+CmOdFkmwTYVj3E82UTtz2x dIclJvkQcWW9oiNQ+0D5F6ZU9y/q1GmYFPDfw= 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=kNCuKswCcJHDeGZcB4UtLiiDzZS2xbVqix3n7Ahs7N05m6Iu5bfx9jhWlg0owPa7xU VI9gnH+7juJK+sK3ps37AP0BAc+TTD0qhIy47Kw4pqqeiV8+qo1idunxBIED1dL6iBsA a55klDETNcObU+S1g/lmmcmcy61K6BPN1ZgkU= MIME-Version: 1.0 Received: by 10.216.199.81 with SMTP id w59mr240558wen.100.1291451332538; Sat, 04 Dec 2010 00:28:52 -0800 (PST) Received: by 10.216.71.14 with HTTP; Sat, 4 Dec 2010 00:28:52 -0800 (PST) In-Reply-To: <4cf9ef71./9OtjLOA2+IV0UUh%perryh@pluto.rain.com> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> <4cf9ef71./9OtjLOA2+IV0UUh%perryh@pluto.rain.com> Date: Sat, 4 Dec 2010 00:28:52 -0800 Message-ID: From: Jack Vogel To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, egrosbein@rdtc.ru, mike@sentex.net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 08:28:54 -0000 LOL, ya, I have one of those switches that takes that long, a Dell 5224, takes some getting used to when you're used to back to back speeds :) There hasn't been any crying for this feature so I'm disinclined, however if more than 1 or two want it I would reconsider. Jack On Fri, Dec 3, 2010 at 11:36 PM, wrote: > Jack Vogel wrote: > > > There are pros and cons either way you do things. I was talking > > to some of our Linux crew, they recently changed things so it > > would shut down the phy, but that doesn't always make everyone > > happy either. > > In particular, depending on the type of switch and how it is > configured, it may take 30 seconds or so after link is restored for > the switch to do spanning-tree validation before it will start to > pass traffic. > > There may be something to be said for making the driver's behavior > configurable. > From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 08:58:25 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 35916106566C; Sat, 4 Dec 2010 08:58:25 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACCA8FC17; Sat, 4 Dec 2010 08:58:25 +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 oB48wOeT068757; Sat, 4 Dec 2010 08:58:24 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB48wOSZ068753; Sat, 4 Dec 2010 08:58:24 GMT (envelope-from remko) Date: Sat, 4 Dec 2010 08:58:24 GMT Message-Id: <201012040858.oB48wOSZ068753@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/152569: [net]: Multiple ppp connections and routing table problem with poptop X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 08:58:25 -0000 Old Synopsis: Multiple ppp connections and routing table problem with poptop New Synopsis: [net]: Multiple ppp connections and routing table problem with poptop Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Dec 4 08:58:02 UTC 2010 Responsible-Changed-Why: This seems more like something for the networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=152569 From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 09:08: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 97A67106564A for ; Sat, 4 Dec 2010 09:08:53 +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 1D09F8FC1D for ; Sat, 4 Dec 2010 09:08:52 +0000 (UTC) Received: by wwf26 with SMTP id 26so6049746wwf.31 for ; Sat, 04 Dec 2010 01:08:52 -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=/+cCcHKT3oBIPl+bXbnclmzJnGurhQ6AQe5tML42sPY=; b=NhHgGxB+mdDdsbznUEttQu156T6r2JFYPrmaMlUcLqK1Cd9GXLCpvDu67eBNaXQy9+ m5cxLxFRu2IEXreEHuOQmZEJmzvXUKEcY5Z7ZXn9L6+xgx43XKpk2xEVTPu97+HqDVmu 5N+1Y+RJBocmfOvQxUr4+uGjZLROXlDlnso88= 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=drzALM+zfudxkI1KiktnYYv+i9ZOVilwDGVQ2rf0xOn+WxyYhCKx1oJgDLYFneQUv3 EGnKK7cLDYzDGfzEdf0MQiXl/criTY5GXEgzRtOrGC0XPXfLBH4BjmeLtZTFbHhiU+lK gPqr1zXYM0nQd4dlH5NVgkyBoWMrImHYpufdA= MIME-Version: 1.0 Received: by 10.216.169.209 with SMTP id n59mr341457wel.85.1291453731824; Sat, 04 Dec 2010 01:08:51 -0800 (PST) Received: by 10.216.71.14 with HTTP; Sat, 4 Dec 2010 01:08:51 -0800 (PST) In-Reply-To: <4CFA0435.7020100@rdtc.ru> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> <4CFA0435.7020100@rdtc.ru> Date: Sat, 4 Dec 2010 01:08:51 -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 , Mike Tancsa Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 09:08:53 -0000 This isn't some simple 'go change this line or parameter', there were some problematic issues that my Linux coworkers faced, I have to go look into it before I even decide... so...patience friend. Jack 2010/12/4 Eugene Grosbein > On 04.12.2010 04:00, Jack Vogel wrote: > > There are pros and cons either way you do things. I was talking to some > > of our > > Linux crew, they recently changed things so it would shut down the phy, > > but that > > doesn't always make everyone happy either. > > Of course, that should be made optional with default 'keep link on' > due to POLA. > > > Just saying that my FreeBSD drivers have not done so forever :) > > Glad to know it's technically possible. I'd like to patch my tree > manually to get this behavour right now. What direction should I take - > use ACPI D3 or something else? I need to brink link down per-port > for dual-port cards. > > Eugene Grosbein > From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 09:15:42 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E88A91065675 for ; Sat, 4 Dec 2010 09:15:42 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5CA8FC15 for ; Sat, 4 Dec 2010 09:15:41 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oB49FduT002164; Sat, 4 Dec 2010 15:15:39 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CFA06BB.6050504@rdtc.ru> Date: Sat, 04 Dec 2010 15:15:39 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jack Vogel References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> <4CFA0435.7020100@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net , Mike Tancsa Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 09:15:43 -0000 On 04.12.2010 15:08, Jack Vogel wrote: > This isn't some simple 'go change this line or parameter', > there were some problematic issues that my Linux coworkers > faced, I have to go look into it before I even decide... > > so...patience friend. I should said it more precise: I will patch the driver myself and test it. That's sad but I have not much time to wait. Just asking, what direction should I take in my attempts :-) From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 09:31:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C380F106566B for ; Sat, 4 Dec 2010 09:31:21 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 83DF28FC0A for ; Sat, 4 Dec 2010 09:31:19 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oB494rPe002140; Sat, 4 Dec 2010 15:04:54 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CFA0435.7020100@rdtc.ru> Date: Sat, 04 Dec 2010 15:04:53 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jack Vogel References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net , Mike Tancsa Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 09:31:21 -0000 On 04.12.2010 04:00, Jack Vogel wrote: > There are pros and cons either way you do things. I was talking to some > of our > Linux crew, they recently changed things so it would shut down the phy, > but that > doesn't always make everyone happy either. Of course, that should be made optional with default 'keep link on' due to POLA. > Just saying that my FreeBSD drivers have not done so forever :) Glad to know it's technically possible. I'd like to patch my tree manually to get this behavour right now. What direction should I take - use ACPI D3 or something else? I need to brink link down per-port for dual-port cards. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 09:31: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 759CC1065672 for ; Sat, 4 Dec 2010 09:31:24 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9D44D8FC27 for ; Sat, 4 Dec 2010 09:31:23 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oB497nTW002145; Sat, 4 Dec 2010 15:07:49 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CFA04E5.1060209@rdtc.ru> Date: Sat, 04 Dec 2010 15:07:49 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jack Vogel References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> <4cf9ef71./9OtjLOA2+IV0UUh%perryh@pluto.rain.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, perryh@pluto.rain.com, mike@sentex.net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 09:31:24 -0000 On 04.12.2010 14:28, Jack Vogel wrote: > LOL, ya, I have one of those switches that takes that long, a > Dell 5224, takes some getting used to when you're used to > back to back speeds :) > > There hasn't been any crying for this feature so I'm disinclined, > however if more than 1 or two want it I would reconsider. Most of time switch may be (and should be) reconfigured to skip this STP timeout for ports connected to routers (portfast for Cisco, edge port for D-Link etc.) Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 10: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 0D1111065672 for ; Sat, 4 Dec 2010 10: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 8B9598FC1C for ; Sat, 4 Dec 2010 10:45:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 973CC41C710; Sat, 4 Dec 2010 11:45:06 +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 e6hcFtyCmmVy; Sat, 4 Dec 2010 11:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id BE99241C70C; Sat, 4 Dec 2010 11: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 1BB8A4448F3; Sat, 4 Dec 2010 10:41:58 +0000 (UTC) Date: Sat, 4 Dec 2010 10:41:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "Eugene M. Zheganin" In-Reply-To: <4CF8E9D5.3060105@norma.perm.ru> Message-ID: <20101204103845.P6126@maildrop.int.zabbadoz.net> References: <4CF76AD4.1010704@norma.perm.ru> <20101202205442.C6126@maildrop.int.zabbadoz.net> <4CF8E9D5.3060105@norma.perm.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: ah_input: packet replay failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 10:45:08 -0000 On Fri, 3 Dec 2010, Eugene M. Zheganin wrote: > Hi. > > On 03.12.2010 01:58, Bjoern A. Zeeb wrote: >>> >>> FreeBSD A >======ipsec over gre===> FreeBSD B >> I'm using FreeBSD as a security gateway: >> >> What it means is that a packet with either an invalid sequence, a >> sequence lower than the last seen and outside the window, or a >> sequence seen already (lately) has arrived. >> >> Could it be that something is duplicating packets or that you have >> packet loss between A and B? Given that you say that you are running >> IPsec on top of GRE (which sounds strange anyway) I'd monitor the >> outer tunnel endpoints independently to see what's going on. > Well, could you be more exact, please, about what did you mean by saying > 'strange' ? > Probably, my english isn't that good, I just tried to say that I use ipsec to > encrypt my gre tunnels. If it is ipsec outer and gre inner encapsulation, that's fine. I was worried that you'd do it the other way round for some reason. So it's gre inside ipsec. > Could this out-of-the-sequence thing be caused by traffic shaping, such as pf > ALTQing ? Yes. Very likely, especially if you have bursts of packets. /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 Sat Dec 4 10:55:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBADD106564A for ; Sat, 4 Dec 2010 10:55:06 +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 88FD68FC2F for ; Sat, 4 Dec 2010 10:55:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E29E541C710; Sat, 4 Dec 2010 11:55: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 aaqpNMfouJAP; Sat, 4 Dec 2010 11:55:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 7EB0441C70C; Sat, 4 Dec 2010 11:55: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 021424448F3; Sat, 4 Dec 2010 10:50:23 +0000 (UTC) Date: Sat, 4 Dec 2010 10:50:23 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jack Vogel In-Reply-To: Message-ID: <20101204104546.S6126@maildrop.int.zabbadoz.net> References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , Eugene Grosbein , Mike Tancsa Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 10:55:07 -0000 On Fri, 3 Dec 2010, Jack Vogel wrote: > There are pros and cons either way you do things. I was talking to some of > our > Linux crew, they recently changed things so it would shut down the phy, but > that > doesn't always make everyone happy either. It's kind of the classic admin shutdown but I can guess people .. well anyway. Another argument is that you actually save power and if you have 30k machines out of which 20k don't need the 2nd port and you can save .2W it's saving around 4kW just by turning PHYs off. > Just saying that my FreeBSD drivers have not done so forever :) And I am not saying they have to do it by yesterday;) The very worst I'd suggest is to add a sysctl so people can control it that the PHY should be off if the interface goes down if you cannot find a consensus with your coworkers. /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 Sat Dec 4 13:03: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 98277106566C for ; Sat, 4 Dec 2010 13:03:10 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by mx1.freebsd.org (Postfix) with ESMTP id 218EC8FC08 for ; Sat, 4 Dec 2010 13:03:09 +0000 (UTC) Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id oB4CVeF0037853 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 4 Dec 2010 07:31:41 -0500 (EST) (envelope-from feenberg@nber.org) Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.8+Sun/8.12.10) with ESMTP id oB4CTMh7007440; Sat, 4 Dec 2010 07:29:22 -0500 (EST) Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id oB4CTIPY007437; Sat, 4 Dec 2010 07:29:19 -0500 (EST) X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs Date: Sat, 4 Dec 2010 07:29:18 -0500 (EST) From: Daniel Feenberg To: Jack Vogel In-Reply-To: Message-ID: References: <201011270946271408828@yahoo.com.cn> <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@rdtc.ru> <4cf9ef71./9OtjLOA2+IV0UUh%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20101203 #4397277, check: 20101204 clean Cc: freebsd-net@freebsd.org, perryh@pluto.rain.com, egrosbein@rdtc.ru, mike@sentex.net Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 13:03:10 -0000 On Sat, 4 Dec 2010, Jack Vogel wrote: > LOL, ya, I have one of those switches that takes that long, a > Dell 5224, takes some getting used to when you're used to > back to back speeds :) On the Dell you can speed things up with the "portfast" option. "Rapid STP" will also help. These should be available on expensive switches. Cheap switches don't cause any delay (the don't do STP which is the source of the delay). FreeBSD shouldn't count on that being available, though. Daniel Feenberg From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 13:19:08 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 00EDF106564A; Sat, 4 Dec 2010 13:19:08 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA1B78FC13; Sat, 4 Dec 2010 13:19:07 +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 oB4DJ7K0089462; Sat, 4 Dec 2010 13:19:07 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB4DJ7dM089458; Sat, 4 Dec 2010 13:19:07 GMT (envelope-from adrian) Date: Sat, 4 Dec 2010 13:19:07 GMT Message-Id: <201012041319.oB4DJ7dM089458@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, adrian@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/150148: [ath] Atheros 5424/2424 - AR2425 stopped working with WPA2-PSK(AES) in 8.1-RELEASE [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 13:19:08 -0000 Synopsis: [ath] Atheros 5424/2424 - AR2425 stopped working with WPA2-PSK(AES) in 8.1-RELEASE [regression] Responsible-Changed-From-To: freebsd-net->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Sat Dec 4 13:18:56 UTC 2010 Responsible-Changed-Why: This is biting me in 11n support. I'll take it over. http://www.freebsd.org/cgi/query-pr.cgi?pr=150148 From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 21:54: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 7E69F1065670 for ; Sat, 4 Dec 2010 21:54:08 +0000 (UTC) (envelope-from rozhuk.im@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 0D8658FC15 for ; Sat, 4 Dec 2010 21:54:07 +0000 (UTC) Received: by wyf19 with SMTP id 19so10855717wyf.13 for ; Sat, 04 Dec 2010 13:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=y4beOEWEiypz11/wbIey2GJEqwLVH82h8SIwcHWFxXE=; b=XxpcTpKzYbIsOpOb9t7/1pPKAdpO/ZoRzI1hqT4E3/cTe+sSvqQqOvrOO9Z5Iwa0UI +N736TCyuKh4smxD16zboQm7mU3Uz0y4veA4EUIn0rmSpKnG4JbkryU5QbwHi1/O3Uro VzK0oRCBzT0RTZ6IqJG+Kln8NqBrL6EY9TOYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; b=Xve+o+9KQpagHvo65+5GK3+pB14T0k4h+YYdWLKV+/fIEgUvOSdR+QPaXzxeLph1Fi 1KjJ5NU9KgDLA/NMqbh5r7B3N1K1FHmhILAXf0hCyMoQc7sbKVNv/dKB4YibTL5kAQkM z9VbehaFqLHWhJuKD1x1TzGaF4BrDDX4cd2XA= Received: by 10.227.146.13 with SMTP id f13mr3720427wbv.90.1291499647039; Sat, 04 Dec 2010 13:54:07 -0800 (PST) Received: from rimwks1x64 ([92.124.32.21]) by mx.google.com with ESMTPS id m10sm2286310wbc.4.2010.12.04.13.54.04 (version=SSLv3 cipher=RC4-MD5); Sat, 04 Dec 2010 13:54:05 -0800 (PST) From: rozhuk.im@gmail.com To: Date: Sun, 5 Dec 2010 05:54:02 +0800 Message-ID: <4cfab87d.8a1ce30a.0d50.ffffa507@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0031_01CB9440.D3694360" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuT/cNMdFhtnH/WSxOQ7cnWd0TdMg== Content-Language: ru Subject: ip_fastfwd - statistic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 21:54:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0031_01CB9440.D3694360 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi! More correct statistic update in ip_fastfwd ip_input not affected Please, add patch to source. =A0 -- Rozhuk Ivan =A0=20 ------=_NextPart_000_0031_01CB9440.D3694360 Content-Type: application/octet-stream; name="ip_fastfwd.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ip_fastfwd.patch" --- /usr/src/sys/netinet/ip_fastfwd.c 2010-12-02 16:52:06.000000000 +0800=0A= +++ /usr/src/sys/netinet/ip_fastfwd.new 2010-12-05 05:47:37.000000000 = +0800=0A= @@ -218,7 +218,7 @@=0A= */=0A= hlen =3D ip->ip_hl << 2;=0A= if (hlen < sizeof(struct ip)) { /* minimum header length */=0A= - IPSTAT_INC(ips_badlen);=0A= + IPSTAT_INC(ips_badhlen);=0A= goto drop;=0A= }=0A= if (hlen > m->m_len) {=0A= ------=_NextPart_000_0031_01CB9440.D3694360-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 23:56: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 6318C1065670 for ; Sat, 4 Dec 2010 23:56:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1C99D8FC17 for ; Sat, 4 Dec 2010 23:56:50 +0000 (UTC) Received: by iwn39 with SMTP id 39so12898345iwn.13 for ; Sat, 04 Dec 2010 15:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=KsYrRFsiwiHUB2a//tSLc/7yC/2tk+fuDSWAF5WbLEk=; b=IZXDRofnMWZ4BZG8OZSl7A8UA+SiF5LWUefQZpqUX/uALOARiZSqnPXbRm3ayaEYyG zv2/+ElXyGQYoRdTOIi0Lt7HajUMak+EKVC3CluCeDR2YHwmhJY+YEso+tAoeqFN8R+k fMEJSOGqDH9Pb8/hIX3KQmH46Wn8BQb37rNQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Rynb8pXyQDq/yOEzovzrLc1CJcQslcVq+NPa/or+Bz3pTYqpFRMgFTt9QJOKGsU4UQ TMWMOGyXD0qHFTULykE7CloAiYf9U0JUYtdJ99DI0PMOzgjfGPdQQIZrFpMKVt7+la7U CLLW2Nv3oLP0SEEu50Jj58QG4Oso+vDPM45Ok= Received: by 10.231.59.197 with SMTP id m5mr3802341ibh.94.1291507010132; Sat, 04 Dec 2010 15:56:50 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d21sm3187076ibg.21.2010.12.04.15.56.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 04 Dec 2010 15:56:48 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 4 Dec 2010 15:56:50 -0800 From: Pyun YongHyeon Date: Sat, 4 Dec 2010 15:56:50 -0800 To: Jack Vogel Message-ID: <20101204235650.GA1489@michelle.cdnetworks.com> References: <20101128081617.GA90332@zibbi.meraka.csir.co.za> <4CF73A2C.7000802@rdtc.ru> <4CF89EE7.8020807@rdtc.ru> <4CF93A77.30804@rdtc.ru> <4CF9470F.4020709@sentex.net> <4CF947D4.10504@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 , Eugene Grosbein , Mike Tancsa Subject: Re: Problem with igb(4) updated to version 2.0.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 23:56:51 -0000 On Fri, Dec 03, 2010 at 02:00:08PM -0800, Jack Vogel wrote: > There are pros and cons either way you do things. I was talking to some of > our > Linux crew, they recently changed things so it would shut down the phy, but > that > doesn't always make everyone happy either. > > Just saying that my FreeBSD drivers have not done so forever :) > I also think powering down the PHY when interface is down is not good idea in most cases but administrators is able to do that by choosing 'none' media for drivers which use mii(4). For example, #ifconfig foo0 media none will power down the PHY. Of course igb(4) is not aware of mii(4) so the command above does not work at this moment. > Jack > > > On Fri, Dec 3, 2010 at 11:41 AM, Eugene Grosbein wrote: > > > On 04.12.2010 01:37, Mike Tancsa wrote: > > > > >> Now I see, thanks. > > >> > > >> Is it technically possible to bring link down > > >> for distinct port of dual-port em/igb-supported NICs using software? > > >> > > >> If yes, I'd like to patch my source tree. > > >> For EtherChannel this kind of management should be possible. > > > > > > > > > If your switch port's speed and duplex are manual, change the media > > > options on the NIC to something like 10 half. The switch should see the > > > port "down" then. > > > > Yes, but switches are not always at my control and one may be in auto mode. > > > > Eugene Grosbein > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"