From owner-freebsd-net@FreeBSD.ORG Sun Mar 22 21:00:14 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC40BDD2 for ; Sun, 22 Mar 2015 21:00:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A236F6A3 for ; Sun, 22 Mar 2015 21:00:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2ML0Eab024423 for ; Sun, 22 Mar 2015 21:00:14 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201503222100.t2ML0Eab024423@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 22 Mar 2015 21:00:14 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Mar 2015 21:00:14 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Mar 23 13:19:20 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E54AFCCD for ; Mon, 23 Mar 2015 13:19:20 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 908F29AD for ; Mon, 23 Mar 2015 13:19:19 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2NDJImb010672 for ; Mon, 23 Mar 2015 06:19:18 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2NDJIdR010671 for net@freebsd.org; Mon, 23 Mar 2015 06:19:18 -0700 (PDT) (envelope-from david) Date: Mon, 23 Mar 2015 06:19:18 -0700 From: David Wolfskill To: net@freebsd.org Subject: iwn(4) works (mostly) in stable/10; fails to associate in head Message-ID: <20150323131918.GN7594@albert.catwhisker.org> Reply-To: net@freebsd.org, David Wolfskill MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/TUrtqMIkCP4YtJm" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Mar 2015 13:19:21 -0000 --/TUrtqMIkCP4YtJm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After about 7 years of service (including rebuilding FreeBSD stable & head daily), I replaced my dell Precision M4400 laptop with a Dell Precision 4800. The transition is mostly complete, though it's had a bit of turbulence at times. One of the issues was that I found the provided WLAN device: none1@pci0:3:0:0: class=3D0x028000 card=3D0x00171028 chip=3D0x43b114e= 4 rev=3D0x03=20 hdr=3D0x00 vendor =3D 'Broadcom Corporation' class =3D network completely unusable -- I was unable to get a driver to recognize it. So I swapped WLAN devices with the old M4400; the M4800 now has: iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x13218086 chip=3D0x4232808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'WiFi Link 5100' class =3D network I find that this (iwn(4) device): * Works a bit better in the M4800 than in the M4400. I suspect that after 7 years of fairly heavy use, including transport on my bike when I was commuting to & from my former employer, may have helped some connections to get a bit flaky: I had noticed that in the last year or so, the WiFi connection was flaky enough that I could no longer reasonably expect to arise in the morning and expect that the laptop would have updated its local private mirror of the SVN repo, for example (so I reverted to using the wired NIC). I still see that to some extent for the M4800, but rather less frequently. * Completely fails to associate when running head (@ r280342 or r280361). And yes, /etc/{rc,wpa_supplicant}.conf are identical in the 2 environments. stable/10 was @ r280343 & r280356, respectively (though I suppose "is" would be a better tense in the latter case). Caveat: the laptop arrived with BIOS A11 installed. One of the first things I did was swap out the disk drive, both to leave it pristine in case I needed to send the machine in for repair, and to replace it with a larger, faster drive. (I thought this was worth the ~$85 or so.) I have since found that BIOS A13 is available, and purportedly addresses some keyboard issues when running non-MS OSes (which I believe I've experienced). It is certainly plausible that updating the BIOS will have other effects; some of those might actually be good (or at least useful). I'm working on figuring out how to perform the update while trying to minimize the probability of bricking the machine. Here's an excerpt from a verbose boot of head, showing info about the iwn(4) device: =2E.. pcib3: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xf7000000-0xf70fffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: memory decode 0xf7000000-0xf70fffff pci3: on pcib3 pcib3: allocated bus range (3-3) for rid 0 of pci3 pci3: domain=3D0, physical bus=3D3 found-> vendor=3D0x8086, dev=3D0x4232, revid=3D0x00 domain=3D0, bus=3D3, slot=3D0, func=3D0 class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf7000000, size 13, enabled pcib3: allocated memory range (0xf7000000-0xf7001fff) for rid 10 of pci0:3:= 0:0 pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 iwn0: mem 0xf7000000-0xf7001fff irq 18 at device 0.0= on pci3 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 269 to local APIC 0 vector 65 iwn0: using IRQ 269 for MSI iwn0: MIMO 1T2R, MoW, address 00:24:d6:7a:03:ce iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps iwn0: 1T2R iwn0: 11na MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: 11na MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: 11na MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: 11na MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps iwn0: 11ng MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: 11ng MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: 11ng MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: 11ng MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps And "ifconfig -v wlan0" output under stable/10: g1-254(10.1-S)[6] ifconfig -v wlan0 wlan0: flags=3D8843 metric 0 mtu 15= 00 ether 34:e6:d7:3c:4a:93 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 04:18:d6:22:22:= 1f regdomain 0 country US anywhere -ecm authmode WPA2/802.11i -wps -tsn privacy ON deftxkey UNDEF AES-CCM 2:128-bit powersavemode OFF powersavesleep 100 txpower 15 txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 10 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6 half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6 quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:11a rssi 7dBm rate 12 Mb/s roam:11b rssi 7dBm rate 1 Mb/s roam:11g rssi 7dBm rate 5 Mb/s roam:turboA rssi 7dBm rate 12 Mb/s roam:turboG rssi 7dBm rate 12 Mb/s roam:sturbo rssi 7dBm rate 12 Mb/s roam:11na rssi 7dBm MCS 1 =20 roam:11ng rssi 7dBm MCS 1 =20 roam:half rssi 7dBm rate 6 Mb/s roam:quarter rssi 7dBm rate 3 Mb/s -pureg protmode CTS ht htcompat ampdu ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi htprotmode RTSCTS -puren -smps -rifs wme -burst -dwds roaming MANUAL bintval 100 AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm groups: wlan=20 g1-254(10.1-S)[7]=20 (FWIW, my access point has both 2.4GHz & 5GHz radios, and I have wpa_supplicant.conf set up to prefer each equally.) I also had picked up an Atheros-based NIC, but I've been unable to get it to associate for for than a couple seconds at a time (and it doesn't light the WiFi status light, so I'm pretty much "flying blind" when I try to use it). What may I do toward getting any of the WLAN NICs to work in both stable/10 and head? Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --/TUrtqMIkCP4YtJm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVEBLVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7BKMP/RJ2BTJclML5WO+WaSr0Fvg2 HePv2UAmP7bDDFSNg7mLDeGMtmAw8mevZJQmPBcpNOGtg3ewDoo80cb71kcnMCB6 Jvn5iHQhRNv03KDBAjiHDQJ92s3DEY50ddkv6JGsBUktPyaHPjiGLa7LkuDbovk+ EsUKAM2K6b9X3dHGbEJzqY7poyE2p9Z9jVu08uAv6Y0TkMcMeStRk67iS9RB6AF4 9AFwJSedrAHbWskh1JYe3oyhts/12VX3maOB6C+S8SsZ6ZV45NxjXcWQJvm1Cng2 WSqcFdI4B8ootAmlQK9xnvB8GctHrYJvlQJri6ljyDSMs7rhsRWS1/fitTC+2vkb Cruy3vNYbSWN0jy1/qThAEN7okHtamtuOCzDxaKxyK13mY0CKrjGuMqOXRwgYwTw XqFI69arnzNUNtVDzF8cXS5tnIMqJT3/3/ipY3Wi5BMqeBpOBttev1woY/nAVOG3 gIV9o4wYiLdqIhhfvZ6jHzh8BQIsqRGo/zSoC5yIChCUkreg3OKXspqr3+5vGyXE iYD5yYXVsWrIgBpn0cGjMOm9yliEqgTygJZnvJ9HhXelXKkTk90+o6CY088JNIJh XfOQQoWekG/Rmr35aMDr7UKH6MVWwBWNn6Suk+byqMsdL3wr2s4aLVCvhyUrU/4K 8WiH0FMjDpQFtDnc1c1T =K5n/ -----END PGP SIGNATURE----- --/TUrtqMIkCP4YtJm-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 23 13:40:35 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5AFA2A8 for ; Mon, 23 Mar 2015 13:40:35 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8694DCE8 for ; Mon, 23 Mar 2015 13:40:35 +0000 (UTC) Received: by igbud6 with SMTP id ud6so42196311igb.1 for ; Mon, 23 Mar 2015 06:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FukouFyuqlfFHkT64sZcUQRAoNi7xsPFx/Rqfgm8LoQ=; b=CEtWh54ooP0YrSIM5dkOE4HmJoqefzFqU0ACLm/tMn8mJlC5/2y8yyW8c+X13VXUZT BVz2lLmLMrqH8/CtfEz0l5jbLvloQK9serrkvAHihj1plu/Ld7s/SvLFQ0uKEK/S5qFa wM2vZ9DhQu2FAG5f0yhAD2ShvKXmZ+pU0mmq3vIcDZejh1uPR7NdAODqznG+RoWK5p44 GEPUzRBTvQOosR5R1jyKsnlpQStx9a21E16KilMqnvVz9Shdyam0HYCNm1SqDqnT15If BSFfxrDhJTC5VNxrwxtQWmtNOZHyjrbuAIayU9OwjO5dJPi4iiX5pKlQ5by5p8yYtqWj Dtgw== X-Received: by 10.50.39.65 with SMTP id n1mr14413102igk.37.1427118034886; Mon, 23 Mar 2015 06:40:34 -0700 (PDT) Received: from [10.10.1.5] ([192.252.130.194]) by mx.google.com with ESMTPSA id k4sm2986831igf.0.2015.03.23.06.40.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 06:40:34 -0700 (PDT) Message-ID: <551017D1.60008@gmail.com> Date: Mon, 23 Mar 2015 09:40:33 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Another fragment question / patch References: <550C3A62.3080403@gmail.com> <550C5F6C.3080302@selasky.org> <550C7D0C.3090603@gmail.com> <550D3675.5030900@selasky.org> In-Reply-To: <550D3675.5030900@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Mar 2015 13:40:35 -0000 On 2015-03-21 5:14 AM, Hans Petter Selasky wrote: > On 03/20/15 21:03, Karim Fodil-Lemelin wrote: >> On 2015-03-20 1:57 PM, Hans Petter Selasky wrote: >>> On 03/20/15 16:18, Karim Fodil-Lemelin wrote: >>>> Hi, >>>> >>>> While reading through a previous comment on this list about fragments >>>> I've noticed that mbuf tags aren't being copied from the leading >>>> fragment (header) to the subsequent fragment packets. In other words, >>>> one would expect that all fragments of a packet are carrying the same >>>> tags that were set on the original packet. I have built a simple test >>>> were I use ipfw with ALTQ and sent large packet (bigger then MTU) off >>>> that BSD machine. I have observed that the leading fragment (m0) >>>> packet >>>> is going through the right class although the next fragments are >>>> hitting >>>> the default class for unclassified packets. >>>> >>>> Here is a patch that makes things works as expected (all fragments >>>> carry >>>> the ALTQ tag): >>>> >>>> diff --git a/freebsd/sys/netinet/ip_output.c >>>> b/freebsd/sys/netinet/ip_output.c >>>> index d650949..7d8f041 100644 >>>> --- a/freebsd/sys/netinet/ip_output.c >>>> +++ b/freebsd/sys/netinet/ip_output.c >>>> @@ -1184,7 +1184,10 @@ smart_frag_failure: >>>> ipstat.ips_odropped++; >>>> goto done; >>>> } >>>> - m->m_flags |= (m0->m_flags & M_MCAST) | M_FRAG; >>>> + >>>> + m->m_flags |= (m0->m_flags & M_COPYFLAGS) | M_FRAG; >>>> + m_tag_copy_chain(m, m0, M_NOWAIT); >>>> + >>>> /* >>>> * In the first mbuf, leave room for the link >>>> header, then >>>> * copy the original IP header including options. The >>>> payload >>>> diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h >>>> index 2efff38..6ad8439 100644 >>>> --- a/freebsd/sys/sys/mbuf.h >>>> >>> >>> Hi, >>> >>> I see your point about copying the tags. I'm not sure however that >>> M_COPYFLAGS is correct, because it also copies M_RDONLY, which is not >>> relevant for this case. Can you explain what flags need copying in >>> addition to M_MCAST ? Maybe we need to define these flags separately. >>> >>> Thank you! >>> >>> --HPS >> Hi, >> >> Arguably the M_RDONLY is added when m_copy() is called a bit later in >> that function. m_copym() does a shallow copy (through a call to >> mb_dupcl) and will set the RDONLY flag when doing so. So the fact it was >> copied over from M_COPYFLAGS shouldn't be a problem in terms of >> functionality. A similar logic applies to the M_VLANTAG since it should >> never be set in ip_output() (severe layer violation). I guess >> M_COPYFLAGS is kinda safe but not necessarily correct. >> >> In terms of appropriate behavior (whats the real purpose of >> M_COPYFLAGS?) my initial patch is debatable and to answer your question >> I would consider to copy the remaining flags: >> >> M_PKTHDR => already in there through the m_gethdr() call >> M_BCAST => no need to copy >> M_MCAST => already in there in ip_fragment() >> M_PROTOFLAGS >> M_SKIP_FIREWALL => for layer 2 fire-walling? >> >> So something like? >> >> - m->m_flags |= (m0->m_flags & M_MCAST); >> + m->m_flags |= (m0->m_flags & (M_MCAST | M_PROTOFLAGS)); >> + m_tag_copy_chain(m, m0, M_NOWAIT); >> > > Hi, > > Could you have a look at the attached patch, test and give some > comments? I believe the right thing to do in this case is to use the > copy packet header function. > > --HPS > Hi, Your patch seems to work as well as mine, albeit completely swinging the other way now since your copying a lot more from the packet header with the call to m_dup_pkthdr() (including the M_COPYFLAGS, vlan tags, etc..). I think this is fine, one would expect IP fragments to be somewhat very close to the original packet. Thanks, Karim. From owner-freebsd-net@FreeBSD.ORG Mon Mar 23 16:03:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 082D1EA6 for ; Mon, 23 Mar 2015 16:03:08 +0000 (UTC) Received: from nef2.ens.fr (nef2.ens.fr [129.199.96.40]) by mx1.freebsd.org (Postfix) with ESMTP id AE468242 for ; Mon, 23 Mar 2015 16:03:07 +0000 (UTC) Received: from biologie.ens.fr (milda.ens.fr [129.199.18.219]) by nef2.ens.fr (8.13.6/1.01.28121999) with ESMTP id t2NFWuZD056462 ; Mon, 23 Mar 2015 16:32:56 +0100 (CET) X-Envelope-To: freebsd-net@freebsd.org Received: from localhost (av3.biologie.ens.fr [129.199.21.124]) by biologie.ens.fr (Postfix) with ESMTP id 8BA285E3; Mon, 23 Mar 2015 16:32:56 +0100 (CET) X-Virus-Scanned: spam & virus filtering at av3.ens.fr X-Spam-Flag: NO X-Spam-Score: -10.91 X-Spam-Level: X-Spam-Status: No, score=-10.91 tagged_above=-9999 required=5 tests=[ALL_TRUSTED=-1, AUTHD_RELAY=-8, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from biologie.ens.fr ([IPv6:::ffff:129.199.18.219]) by localhost (av3.biologie.ens.fr [::ffff:129.199.21.124]) (amavisd-new, port 10024) with ESMTP id 1glhmty91dcj; Mon, 23 Mar 2015 16:32:56 +0100 (CET) Received: from [129.199.16.44] (hades.ens.fr [129.199.16.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: phnguyen) by biologie.ens.fr (Postfix) with ESMTPSA id 314404B; Mon, 23 Mar 2015 16:32:56 +0100 (CET) Message-ID: <55103227.1090005@biologie.ens.fr> Date: Mon, 23 Mar 2015 16:32:55 +0100 From: Phi-Phong NGUYEN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Carp unpingable on vlan interfaces with lagg on emulex cards Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef2.ens.fr [129.199.96.32]); Mon, 23 Mar 2015 16:32:56 +0100 (CET) Cc: =?UTF-8?B?ImNvY2ggPj4gT2xpdmllciBDb2NoYXJkLUxhYmLDqSI=?= , sysinfo , pierre vincens X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Mar 2015 16:03:08 -0000 I have two routers running freeBSD 10.1-RELEASE with 10gigaethernet Emulex cards (OCm14104-UX-D + OCe14102‑UX-D) On each router : ifconfig_lagg2="laggproto lacp laggport oce0 laggport oce1 laggport oce4 laggport oce6" Several vlans are build within the lagg : On router1 : [...] cloned_interfaces=".... vlan3101 ..." ifconfig_vlan3101="vlan 3101 vlandev lagg2 X.X.X.252/24" ifconfig_vlan3101_alias0="vhid 121 advskew 100 pass mypass X.X.X.254/32" [...] vlan3101: flags=8943 metric 0 mtu 1500 options=303 ether 00:90:fa:xx:xx:xx inet X.X.X.252 netmask 0xffffff00 broadcast X.X.X.255 inet X.X.X.254 netmask 0xffffffff broadcast X.X.X.254 vhid 121 nd6 options=29 media: Ethernet autoselect status: active vlan: 3101 parent interface: lagg2 carp: BACKUP vhid 121 advbase 1 advskew 100 On router2 : [...] cloned_interfaces=".... vlan3101 ..." ifconfig_vlan3101="vlan 3101 vlandev lagg2 X.X.X.252/24" ifconfig_vlan3101_alias0="vhid 121 pass mypass X.X.X.254/32" [...] vlan3101: flags=8943 metric 0 mtu 1500 options=303 ether 00:90:fa:xx:xx:xx inet X.X.X.253 netmask 0xffffff00 broadcast X.X.X.255 inet X.X.X.254 netmask 0xffffffff broadcast X.X.X.254 vhid 121 nd6 options=29 media: Ethernet autoselect status: active vlan: 3101 parent interface: lagg2 carp: MASTER vhid 121 advbase 1 advskew 0 So, router2 is the master VRRP for vlan3101, ang changing advskew to 150 on router2 leaves router1 become the master. BUT : Router1 can ping X.X.X.253 and router2 is able to ping X.X.X.252, alas, router1 can't ping X.X.X.254 (the virtual ip address) as a host belonging to the 3101 vlan. The arp request does work : router1 # ping X.X.X.254 <- no "Host is down", no unreachable router1 # arp -n X.X.X.254 ? (X.X.X.254) at 00:00:5e:00:01:79 on vlan3101 expires in 1129 seconds [vlan] Already try : 1) Reduce the lagg to one single interface -> Doesn't work 2) Create the vlans on a physical emulex interface -> Doesn't work 3) Downgrade to 9.3-RELEASE with old syntax carp -> Doesn't work 4) Upgrade all the firmwares including Emulex cards. 5) Create the lagg on a physical copper interface (Intel X540) -> Does work !! So, my questions are : 1) Is it related to the Emulex cards ? 2) Is there a workaround for this sort of problem ? 2) If I replace some Emulex cards with Intel ones (Say X520 items), is the result guaranteed ? At $ 700-$ 800 each, this is a crucial question. More information : router1 # sysctl -a |grep carp net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.demotion: 0 net.inet.carp.senderr_demotion_factor: 0 net.inet.carp.ifdown_demotion_factor: 240 Thanks in advance. -- Phi-Phong NGUYEN Service informatique Institut de Biologie ENS 46 rue d'Ulm 75230 PARIS CEDEX 05 Tel: 01 44 32 36 34 Fax: 01 44 32 36 30 From owner-freebsd-net@FreeBSD.ORG Mon Mar 23 23:39:16 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61676A18; Mon, 23 Mar 2015 23:39:16 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C30DF98; Mon, 23 Mar 2015 23:39:15 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 9D385106E5B; Mon, 23 Mar 2015 16:39:08 -0700 (PDT) Date: Mon, 23 Mar 2015 16:39:08 -0700 From: hiren panchasara To: freebsd-net@freebsd.org, jfv@freebsd.org, erj@frebsd.org Message-ID: <20150323233908.GT53237@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CMEQapY8OuP5ao1l" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adrian Chadd , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Mar 2015 23:39:16 -0000 --CMEQapY8OuP5ao1l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable scottl@freebsd.org Bcc:=20 Subject: Full 32bit flowid from igb(4) [was: Re: Unbalanced LACP link] Reply-To:=20 In-Reply-To: <20150319175145.GH53237@strugglingcoder.info> On 03/19/15 at 10:51P, hiren panchasara wrote: > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > On 17 March 2015 at 11:33, Jason Wolfe wrote: > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky wrote: > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > >>> > > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > > >>> significant? In a description it says "Shift flowid bits to prevent > > >>> multiqueue collisions". > > >> > > >> > > >> Hi, > > >> > > >> Maybe your ethernet hardware is not properly setting the m_flowid ... > > >> > > >> --HPS > > >> > > > > > > Flip use_flowid back to 1 and try setting > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift to 0 > > > as Hiren suggested. r260179 added this shift, which has caused us > > > balancing issues with the i350/igb. > > > > > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D260179 > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > flowid' under normal conditions, does that mean this shift should be 0 > > > by default to ensure we don't break balancing for devices that only > > > set the CPU/MSIX queue? > >=20 > > Or we can just see if there's anything wrong with putting the full 32 > > bit RSS flowid in received packets that have them. >=20 > It'd be nice to have but for now I am proposing following to fix a known > broken case because of an optimization: > https://reviews.freebsd.org/D2098 Turns out, setting flowid_shift to 0 is not the correct solution. Please look at the review above for more details.=20 Looking at the code, we have a way to get full flowid but it's hidden under "ifdef RSS": rxr->fmp->m_pkthdr.flowid =3D le32toh(cur->wb.lower.hi_dword.rss); Using just this line gives me good hash on I350 igb(4) chipset that we have. Is it possible to expose this outside RSS? Would this break other things/chips? Cheers, Hiren --CMEQapY8OuP5ao1l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVEKQcXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lt1wH/0doNoSRjK/xpQxyrgheUAp1 RWIkDJ9blhTSPz4JjBd8pHNZAr3QUrPRezXUTGjSdoW6A7XOeCrIs8AqX3lXsA8R xQzauz+LmdUgOYxnAOCNMmgZYQkxjxZDLktbWmzIawXYTuEbfuqsG9SVroDgyBpD P6JRC6IBQAf1RkHQ3GaoVVCYhULcKUIMQYJLsUPgZyoWXUKpG3dqH92l04qKYt9H aof1CxPeB9O+4rZU/98VbHiVt0O3XoyS1JNWFZXPNPuzNZym2v1dY5hfbZq2kdWs WosIOaiATGTxIATZ0IqRhIDw6L09Z2/SYZ+Rlj9SsMNiEsU7JH6j0rNVDDV50yQ= =i9IX -----END PGP SIGNATURE----- --CMEQapY8OuP5ao1l-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 23 23:42:15 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EF8DCA5; Mon, 23 Mar 2015 23:42:15 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F71ED8; Mon, 23 Mar 2015 23:42:14 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 5CF11106EF7; Mon, 23 Mar 2015 16:42:14 -0700 (PDT) Date: Mon, 23 Mar 2015 16:42:14 -0700 From: hiren panchasara To: freebsd-net@freebsd.org, jfv@freebsd.org, erj@freebsd.org Subject: Full 32bit flowid from igb(4) Message-ID: <20150323234214.GU53237@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R7Dyui215VKdTDYA" Content-Disposition: inline In-Reply-To: <20150323233908.GT53237@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adrian Chadd , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Mar 2015 23:42:15 -0000 --R7Dyui215VKdTDYA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Correcting Eric's email and subject line. On 03/23/15 at 04:39P, hiren panchasara wrote: > scottl@freebsd.org > Bcc:=20 > Subject: Full 32bit flowid from igb(4) [was: Re: Unbalanced LACP link] > Reply-To:=20 > In-Reply-To: <20150319175145.GH53237@strugglingcoder.info> >=20 > On 03/19/15 at 10:51P, hiren panchasara wrote: > > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > > On 17 March 2015 at 11:33, Jason Wolfe wrote: > > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky wrote: > > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > > >>> > > > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > > > >>> significant? In a description it says "Shift flowid bits to preve= nt > > > >>> multiqueue collisions". > > > >> > > > >> > > > >> Hi, > > > >> > > > >> Maybe your ethernet hardware is not properly setting the m_flowid = =2E.. > > > >> > > > >> --HPS > > > >> > > > > > > > > Flip use_flowid back to 1 and try setting > > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift t= o 0 > > > > as Hiren suggested. r260179 added this shift, which has caused us > > > > balancing issues with the i350/igb. > > > > > > > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D260179 > > > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > > flowid' under normal conditions, does that mean this shift should b= e 0 > > > > by default to ensure we don't break balancing for devices that only > > > > set the CPU/MSIX queue? > > >=20 > > > Or we can just see if there's anything wrong with putting the full 32 > > > bit RSS flowid in received packets that have them. > >=20 > > It'd be nice to have but for now I am proposing following to fix a known > > broken case because of an optimization: > > https://reviews.freebsd.org/D2098 >=20 > Turns out, setting flowid_shift to 0 is not the correct solution. Please > look at the review above for more details.=20 >=20 > Looking at the code, we have a way to get full flowid but it's hidden > under "ifdef RSS": > rxr->fmp->m_pkthdr.flowid =3D le32toh(cur->wb.lower.hi_dword.rss); >=20 > Using just this line gives me good hash on I350 igb(4) chipset that we > have. >=20 > Is it possible to expose this outside RSS? Would this break other > things/chips? >=20 > Cheers, > Hiren --R7Dyui215VKdTDYA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVEKTVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lomgIAKIvM6TwFTT+PaFvN8TPRdNc LJ1iY+8iAeGkwz1YJZ1oOVYONScc/zl4rYQdxzKvYwMges0eHTdJFEltwbSGGyzG BkYZR/BzvMzpLzGe/aDqATbotxOCBzbMdoWNuY3mwhmNfNLphoOq/YLb9y/202SY d9642VJInhtURcrD2t1isOzXg9bNzQISpN4Ti1I/+x+p2Cptzx4UwjOPoiJVd59s HxolAbawUckOW+3Ze4SOyP+nM470rlmWuRx+ifmh6uJgl0lsjD/3AtqY/dHaE88a rh+tYU9cHwo4PRuNUE7wiQekCXaVwEYwf4A5jb7cTE+8CbB/O5tJna9lgZz4HkA= =F6OG -----END PGP SIGNATURE----- --R7Dyui215VKdTDYA-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 23 23:58:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D3B523E; Mon, 23 Mar 2015 23:58:45 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB262243; Mon, 23 Mar 2015 23:58:44 +0000 (UTC) Received: by wibg7 with SMTP id g7so61084465wib.1; Mon, 23 Mar 2015 16:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vaRcF9K4bngPk0xeYn5ncvP6IB1axgdfVBezM5p41wI=; b=zUOAItMbZExsyLCLnI5AtqY9ACwJswVbU+GWDF38fsewpGrsMmQhahLdMooLYMsfmb hOiSR39nNSrEAiHl5mla4Cgp2yxH0f/mg+2arT1w/t3N7k0kFWin1u7bmLYjK+eB3Vpp FEI8L08I6e5q2iw76w9gAIbWt/hO6XaCaYUJdT5YWDxxa+A/WnRKXSm6/H6FVQINTKEh BdhohbgIyxr2NOFjPlHuZqhGaLCnI6m560FYTMsaVYD9gboCu7Jj0qNZGl+E/C+JbDEG 84eRiVwlaFt//wyxpoJEtU7pwBUy7hl15q7G7T/TSCrzzZ0YEqsO7BMHnZ0l7aHra3+k CuWw== MIME-Version: 1.0 X-Received: by 10.180.14.66 with SMTP id n2mr20299167wic.64.1427155123235; Mon, 23 Mar 2015 16:58:43 -0700 (PDT) Received: by 10.194.162.103 with HTTP; Mon, 23 Mar 2015 16:58:43 -0700 (PDT) In-Reply-To: <20150323234214.GU53237@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> Date: Mon, 23 Mar 2015 16:58:43 -0700 Message-ID: Subject: Re: Full 32bit flowid from igb(4) From: Jack Vogel To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Jack F Vogel , FreeBSD Net , Adrian Chadd , erj@freebsd.org, Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Mar 2015 23:58:45 -0000 I think that line was there at one time outside the RSS define, I'd have to take a look at the code a bit more, or maybe Eric will.... Jack On Mon, Mar 23, 2015 at 4:42 PM, hiren panchasara < hiren@strugglingcoder.info> wrote: > Correcting Eric's email and subject line. > > On 03/23/15 at 04:39P, hiren panchasara wrote: > > scottl@freebsd.org > > Bcc: > > Subject: Full 32bit flowid from igb(4) [was: Re: Unbalanced LACP link] > > Reply-To: > > In-Reply-To: <20150319175145.GH53237@strugglingcoder.info> > > > > On 03/19/15 at 10:51P, hiren panchasara wrote: > > > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > > > On 17 March 2015 at 11:33, Jason Wolfe wrote: > > > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky < > hps@selasky.org> wrote: > > > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > > > >>> > > > > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > > > > >>> significant? In a description it says "Shift flowid bits to > prevent > > > > >>> multiqueue collisions". > > > > >> > > > > >> > > > > >> Hi, > > > > >> > > > > >> Maybe your ethernet hardware is not properly setting the m_flowid > ... > > > > >> > > > > >> --HPS > > > > >> > > > > > > > > > > Flip use_flowid back to 1 and try setting > > > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift > to 0 > > > > > as Hiren suggested. r260179 added this shift, which has caused us > > > > > balancing issues with the i350/igb. > > > > > > > > > > https://svnweb.freebsd.org/base?view=revision&revision=260179 > > > > > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > > > flowid' under normal conditions, does that mean this shift should > be 0 > > > > > by default to ensure we don't break balancing for devices that only > > > > > set the CPU/MSIX queue? > > > > > > > > Or we can just see if there's anything wrong with putting the full 32 > > > > bit RSS flowid in received packets that have them. > > > > > > It'd be nice to have but for now I am proposing following to fix a > known > > > broken case because of an optimization: > > > https://reviews.freebsd.org/D2098 > > > > Turns out, setting flowid_shift to 0 is not the correct solution. Please > > look at the review above for more details. > > > > Looking at the code, we have a way to get full flowid but it's hidden > > under "ifdef RSS": > > rxr->fmp->m_pkthdr.flowid = le32toh(cur->wb.lower.hi_dword.rss); > > > > Using just this line gives me good hash on I350 igb(4) chipset that we > > have. > > > > Is it possible to expose this outside RSS? Would this break other > > things/chips? > > > > Cheers, > > Hiren > > From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 09:00:56 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A912A1E1 for ; Tue, 24 Mar 2015 09:00:56 +0000 (UTC) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0074.outbound.protection.outlook.com [157.56.112.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2709A372 for ; Tue, 24 Mar 2015 09:00:55 +0000 (UTC) Received: from AMXPR05MB0631.eurprd05.prod.outlook.com (10.242.10.153) by VI1PR05MB1118.eurprd05.prod.outlook.com (25.162.15.140) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 24 Mar 2015 09:00:46 +0000 Received: from AMXPR05MB0631.eurprd05.prod.outlook.com ([10.242.10.153]) by AMXPR05MB0631.eurprd05.prod.outlook.com ([10.242.10.153]) with mapi id 15.01.0118.021; Tue, 24 Mar 2015 09:00:46 +0000 From: Shani Michaeli To: "freebsd-net@freebsd.org" Subject: Does lox interfaces support looping ethernet traffic? Thread-Topic: Does lox interfaces support looping ethernet traffic? Thread-Index: AdBmD28tprLZ13Y4SuaEJU98Lu/PtA== Date: Tue, 24 Mar 2015 09:00:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.47.165.251] authentication-results: freebsd.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB1118; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(164054003)(50986999)(15975445007)(2656002)(66066001)(74316001)(33656002)(86362001)(16236675004)(76576001)(46102003)(19580395003)(54356999)(19625215002)(77096005)(92566002)(40100003)(19300405004)(77156002)(110136001)(2501003)(122556002)(2900100001)(62966003)(102836002)(87936001)(2351001)(229853001)(450100001)(19609705001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB1118; H:AMXPR05MB0631.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:VI1PR05MB1118; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB1118; x-forefront-prvs: 0525BB0ADF MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2015 09:00:45.7930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB1118 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 09:00:56 -0000 Hi, I'm trying to send traffic to myself (server and client on the same machine= ) using rdma connection management. I'm failing. What I saw is that in netstat -rn all traffic with my IP destination go thr= ough lo0, and therefore the rtalloc1 function (in file route.c) returns lo0= . My problem is when using arpresolve (in file if_ether.c) afterwards, in ord= er to retrieve the MAC, the arpresolve fails for lo0 (I can see also that i= t doesn't have MAC addr). So my question is what should I do in order to be able to send traffic to m= yself using the functions rtalloc1 and arpresolve? Thanks, Shany Michaely | SW Engineer From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 09:27:00 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7461072F; Tue, 24 Mar 2015 09:27:00 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0C33B7EB; Tue, 24 Mar 2015 09:26:59 +0000 (UTC) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 45EA6270474B; Tue, 24 Mar 2015 10:26:52 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 0E26F2704752; Tue, 24 Mar 2015 10:26:52 +0100 (CET) Received: from work.netasq.com ([127.0.0.1]) by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TbpOVUWV005O; Tue, 24 Mar 2015 10:26:51 +0100 (CET) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id B641B270474D; Tue, 24 Mar 2015 10:26:51 +0100 (CET) Date: Tue, 24 Mar 2015 10:26:48 +0100 (CET) From: Emeric POUPON To: Adrian Chadd Message-ID: <1776547746.25937476.1427189208729.JavaMail.zimbra@stormshield.eu> In-Reply-To: References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> <550C6D65.6070409@selasky.org> Subject: Re: Fragment questions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_25937470_1392766137.1427189208673" Thread-Topic: Fragment questions Thread-Index: s2THZGbL/tddgKH3O963gPdstiWmpA== Cc: Hans Petter Selasky , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 09:27:00 -0000 ------=_Part_25937470_1392766137.1427189208673 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Please find attached a proposal using atomic_fetchadd. Best Regards, Emeric ----- Mail original ----- De: "Adrian Chadd" =C3=80: "Hans Petter Selasky" Cc: "Emeric POUPON" , "freebsd-net" Envoy=C3=A9: Vendredi 20 Mars 2015 20:04:44 Objet: Re: Fragment questions On 20 March 2015 at 11:56, Hans Petter Selasky wrote: > On 03/20/15 19:02, Adrian Chadd wrote: >> >> On 20 March 2015 at 10:58, Hans Petter Selasky wrote: >>> >>> On 03/20/15 14:31, Emeric POUPON wrote: >>>> >>>> >>>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use >>>> randomized id. >>> >>> >>>> In multi core systems, we may emit successive packets with the same id= . >>> >>> >>> Will using a mutex or an atomic macro fix this issue when incrementing >>> the >>> V_ip_id ? >> >> >> It will, but it'll ping-pong between multiple cores and slow things >> down at high pps. >> > > Hi, > > Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random = CPU > core number? Hm, someone with more cycles to spend on analysing the repercussions from this should investigate it. I think in the short term using an atomic is fine, as it's no worse than what is currently there. But as we get more PPS unlocked and happening we may need to fix it. -adrian ------=_Part_25937470_1392766137.1427189208673 Content-Type: text/x-patch; name=patch-ip_id-atomic-fetchadd Content-Disposition: attachment; filename=patch-ip_id-atomic-fetchadd Content-Transfer-Encoding: base64 LS0tIHN5cy9uZXRpbmV0L2lwX3Zhci5oLm9yaWcJMjAxNS0wMy0yMyAxNzo1Nzo0MC42MDEwNzIy MDAgKzAxMDAKKysrIHN5cy9uZXRpbmV0L2lwX3Zhci5oCTIwMTUtMDMtMjMgMTc6NTg6MzEuMDkz NzE1MTc3ICswMTAwCkBAIC0xNzQsNyArMTc0LDcgQEAgc3RydWN0IGlucGNiOwogc3RydWN0IHJv dXRlOwogc3RydWN0IHNvY2tvcHQ7CiAKLVZORVRfREVDTEFSRSh1X3Nob3J0LCBpcF9pZCk7CQkJ LyogaXAgcGFja2V0IGN0ciwgZm9yIGlkcyAqLworVk5FVF9ERUNMQVJFKHVfaW50MzJfdCwgaXBf aWQpOwkJCS8qIGlwIHBhY2tldCBjdHIsIGZvciBpZHMgKi8KIFZORVRfREVDTEFSRShpbnQsIGlw X2RlZnR0bCk7CQkJLyogZGVmYXVsdCBJUCB0dGwgKi8KIFZORVRfREVDTEFSRShpbnQsIGlwZm9y d2FyZGluZyk7CQkvKiBpcCBmb3J3YXJkaW5nICovCiAjaWZkZWYgSVBTVEVBTFRICkBAIC0zMDYs NyArMzA2LDcgQEAgZXh0ZXJuIGludAkoKmlwX2RuX2lvX3B0cikoc3RydWN0IG1idWYgKgogVk5F VF9ERUNMQVJFKGludCwgaXBfZG9fcmFuZG9taWQpOwogI2RlZmluZQlWX2lwX2RvX3JhbmRvbWlk CVZORVQoaXBfZG9fcmFuZG9taWQpCiAjZGVmaW5lCWlwX25ld2lkKCkJKChWX2lwX2RvX3JhbmRv bWlkICE9IDApID8gaXBfcmFuZG9taWQoKSA6IFwKLQkJCSAgICBodG9ucyhWX2lwX2lkKyspKQor CQkJICAgIGh0b25zKGF0b21pY19mZXRjaGFkZF8zMigmVl9pcF9pZCwgMSkgJiAweEZGRkYpKQog CiAjZW5kaWYgLyogX0tFUk5FTCAqLwogCi0tLSBzeXMvbmV0aW5ldC9pcF9vdXRwdXQuYy5vcmln CTIwMTUtMDMtMjMgMTc6NTc6NDYuNTE0NDk4ODQ2ICswMTAwCisrKyBzeXMvbmV0aW5ldC9pcF9v dXRwdXQuYwkyMDE1LTAzLTIzIDE3OjU4OjUyLjEyNDQyNjc2MCArMDEwMApAQCAtOTEsNyArOTEs NyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IGhlYWQvc3lzL25ldGluZXQvaXBfCiAKICNpbmNsdWRl IDxzZWN1cml0eS9tYWMvbWFjX2ZyYW1ld29yay5oPgogCi1WTkVUX0RFRklORSh1X3Nob3J0LCBp cF9pZCk7CitWTkVUX0RFRklORSh1X2ludDMyX3QsIGlwX2lkKTsKIAogI2lmZGVmIE1CVUZfU1RS RVNTX1RFU1QKIHN0YXRpYyBpbnQgbWJ1Zl9mcmFnX3NpemUgPSAwOwo= ------=_Part_25937470_1392766137.1427189208673-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 12:54:39 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6CF070C for ; Tue, 24 Mar 2015 12:54:39 +0000 (UTC) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx141.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A817E22D for ; Tue, 24 Mar 2015 12:54:39 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,458,1422950400"; d="asc'?scan'208";a="32255363" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 24 Mar 2015 05:49:22 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 24 Mar 2015 05:49:22 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f07f:691d:89d:53b7%21]) with mapi id 15.00.0995.031; Tue, 24 Mar 2015 05:49:22 -0700 From: "Eggert, Lars" To: "freebsd-net@freebsd.org" Subject: siftr buildkernel failure? Thread-Topic: siftr buildkernel failure? Thread-Index: AQHQZjDz4b7PfobHfU+Aw1LHaOZLTg== Date: Tue, 24 Mar 2015 12:49:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2093) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_E779D304-B73E-453E-8539-E6850379CD90"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Lawrence Stewart X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 12:54:39 -0000 --Apple-Mail=_E779D304-B73E-453E-8539-E6850379CD90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Anyone else seeing this on -current right now? /usr/home/elars/src/sys/modules/siftr/../../netinet/siftr.c:493:7: = error: data argument not used by format string = [-Werror,-Wformat-extra-args] pkt_node->flowid, ^ Lars --Apple-Mail=_E779D304-B73E-453E-8539-E6850379CD90 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlURXVEACgkQIWcjmsUTWRrWMwCdHO+7q/Q3IhLfIUcLQHqzG1Hu Yd8AoNMNw74pc5cmrXTzXkf2nDgqAr1/ =X8na -----END PGP SIGNATURE----- --Apple-Mail=_E779D304-B73E-453E-8539-E6850379CD90-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 14:22:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 719CD3DA for ; Tue, 24 Mar 2015 14:22:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4208DEBA for ; Tue, 24 Mar 2015 14:22:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2OEMJ4C000220 for ; Tue, 24 Mar 2015 14:22:19 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2OEMJ7j000219; Tue, 24 Mar 2015 14:22:19 GMT (envelope-from root) Date: Tue, 24 Mar 2015 14:22:19 +0000 To: freebsd-net@freebsd.org From: "sbruno (Sean Bruno)" Subject: [Differential] [Updated] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <4f7ce65e4594ca646b1bf4cac8a1fc66@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFURcxs= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 14:22:20 -0000 sbruno added a comment. Randall: Do you want to close this review as committed? The commit hook doesn't seem to have fired to close this when comitted at svn r278472 REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz, sbruno Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 14:22:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66A34489 for ; Tue, 24 Mar 2015 14:22:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DD54ED0 for ; Tue, 24 Mar 2015 14:22:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2OEMXd0000414 for ; Tue, 24 Mar 2015 14:22:33 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2OEMXN3000413; Tue, 24 Mar 2015 14:22:33 GMT (envelope-from root) Date: Tue, 24 Mar 2015 14:22:33 +0000 To: freebsd-net@freebsd.org From: "sbruno (Sean Bruno)" Subject: [Differential] [Accepted] D1777: Associated fix for arp/nd6 timer usage. Message-ID: <2bf8a9f2a28ecbf03a1bc1e24e009a85@localhost.localdomain> X-Priority: 3 Thread-Topic: D1777: Associated fix for arp/nd6 timer usage. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2Y2Y2VmY2ZjNTc1MTM4NTA3YmIzZDk3NmE4IFURcyk= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 14:22:34 -0000 sbruno accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz, sbruno Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 14:24:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E41793 for ; Tue, 24 Mar 2015 14:24:53 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B12C8F12 for ; Tue, 24 Mar 2015 14:24:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2OEOqeJ002100 for ; Tue, 24 Mar 2015 14:24:52 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2OEOqKd002099; Tue, 24 Mar 2015 14:24:52 GMT (envelope-from root) Date: Tue, 24 Mar 2015 14:24:52 +0000 To: freebsd-net@freebsd.org From: "sbruno (Sean Bruno)" Subject: [Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <9ee1d70e31fdf738c35f56e02d908944@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFURc7Q= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 14:24:53 -0000 sbruno accepted this revision. sbruno added a comment. This revision is now accepted and ready to land. Randall: I think this needs to be manually closed as the svn commit hook didn't fire when r278469 hit the tree. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, imp, adrian, hselasky, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 15:18:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CFD7E7C for ; Tue, 24 Mar 2015 15:18:40 +0000 (UTC) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5C820792 for ; Tue, 24 Mar 2015 15:18:39 +0000 (UTC) Received: from lgwl-lstewart2.corp.netflix.com (dhcp-ac72.meeting.ietf.org [31.133.172.114]) by lauren.room52.net (Postfix) with ESMTPSA id C96127E81E; Wed, 25 Mar 2015 02:09:45 +1100 (EST) Message-ID: <55117E37.80301@swin.edu.au> Date: Tue, 24 Mar 2015 10:09:43 -0500 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: siftr buildkernel failure? References: <46a9d8ac6681429b81502c09b8ff4e18@GSP-EX02.ds.swin.edu.au> In-Reply-To: <46a9d8ac6681429b81502c09b8ff4e18@GSP-EX02.ds.swin.edu.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: "freebsd-net@freebsd.org" , hiren panchasara X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 15:18:40 -0000 On 03/24/15 07:49, Eggert, Lars wrote: > Anyone else seeing this on -current right now? > > /usr/home/elars/src/sys/modules/siftr/../../netinet/siftr.c:493:7: error: data argument not used by format string [-Werror,-Wformat-extra-args] > pkt_node->flowid, > ^ I didn't look at enough context when reviewing r280233 and missed the bug. Should be fixed in r280441. Thanks for the report and apologies for the hassle. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 15:47:39 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22CD389D for ; Tue, 24 Mar 2015 15:47:39 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AD0AAD9 for ; Tue, 24 Mar 2015 15:47:38 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 823F9D2A67; Tue, 24 Mar 2015 08:47:36 -0700 (PDT) Date: Tue, 24 Mar 2015 08:47:36 -0700 From: hiren panchasara To: Lawrence Stewart Subject: Re: siftr buildkernel failure? Message-ID: <20150324154736.GB53237@strugglingcoder.info> References: <46a9d8ac6681429b81502c09b8ff4e18@GSP-EX02.ds.swin.edu.au> <55117E37.80301@swin.edu.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MR0szId23pLNtImL" Content-Disposition: inline In-Reply-To: <55117E37.80301@swin.edu.au> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , "Eggert, Lars" , hiren panchasara X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 15:47:39 -0000 --MR0szId23pLNtImL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/24/15 at 10:09P, Lawrence Stewart wrote: > On 03/24/15 07:49, Eggert, Lars wrote: > > Anyone else seeing this on -current right now? > >=20 > > /usr/home/elars/src/sys/modules/siftr/../../netinet/siftr.c:493:7: erro= r: data argument not used by format string [-Werror,-Wformat-extra-args] > > pkt_node->flowid, > > ^ >=20 > I didn't look at enough context when reviewing r280233 and missed the > bug. Should be fixed in r280441. Thanks for the report and apologies for > the hassle. Apologies for missing the v6 part.=20 Thanks Lawrence for the quick fix. Hiren --MR0szId23pLNtImL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVEYcYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l+cMIAI3zWkL1gs5o1wi6O0drgrXG 8DiNFKuK4JonGo9PUWHZyzRnVAGnm6YpU0IguUdv8NQwWISe7cZC6In1ZIoH7i2Q /xtBMjTkJhBNSdvudhjrltzHYDuQ3YDNBHqwGIqM2zdIfvTzbZ88ZyWAVxbIKwM+ /9vjG/1sM1/FYr1f2VBr0AbeUWktPoJxlW6UPzdSSStJyDUccp6B5Dcw09ElPDHt MTvZREWjipdPOaGmqR/8yjjmK+3fC7Ewkh6ZrXEsj5S1DyP6++xKhjoqP7zz1znc bPIQ3NTsPK8gSc1MumwSpxltqV4S9Cq2nGaDZ6zBztXlR+Q+2yE0AOFEEyOxpbA= =lXV1 -----END PGP SIGNATURE----- --MR0szId23pLNtImL-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 15:49:31 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1120965; Tue, 24 Mar 2015 15:49:31 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 805F8B3B; Tue, 24 Mar 2015 15:49:31 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 3DBD8D2AD1; Tue, 24 Mar 2015 08:49:31 -0700 (PDT) Date: Tue, 24 Mar 2015 08:49:31 -0700 From: hiren panchasara To: Jack Vogel Subject: Re: Full 32bit flowid from igb(4) Message-ID: <20150324154931.GC53237@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tauoZ0QFNrdllat7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Jack F Vogel , FreeBSD Net , Adrian Chadd , erj@freebsd.org, Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 15:49:31 -0000 --tauoZ0QFNrdllat7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/23/15 at 04:58P, Jack Vogel wrote: > I think that line was there at one time outside the RSS define, I believe this was added by Adrian as part of RSS work and was not there before. I may be wrong. > I'd have to > take a look at > the code a bit more, or maybe Eric will.... I'll wait for the comments. Cheers, Hiren >=20 > Jack >=20 >=20 > On Mon, Mar 23, 2015 at 4:42 PM, hiren panchasara < > hiren@strugglingcoder.info> wrote: >=20 > > Correcting Eric's email and subject line. > > > > On 03/23/15 at 04:39P, hiren panchasara wrote: > > > scottl@freebsd.org > > > Bcc: > > > Subject: Full 32bit flowid from igb(4) [was: Re: Unbalanced LACP link] > > > Reply-To: > > > In-Reply-To: <20150319175145.GH53237@strugglingcoder.info> > > > > > > On 03/19/15 at 10:51P, hiren panchasara wrote: > > > > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > > > > On 17 March 2015 at 11:33, Jason Wolfe wro= te: > > > > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky < > > hps@selasky.org> wrote: > > > > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > > > > >>> > > > > > >>> I've changed use_flowid to 0 and it helped! But isn't it sett= ing > > > > > >>> significant? In a description it says "Shift flowid bits to > > prevent > > > > > >>> multiqueue collisions". > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Maybe your ethernet hardware is not properly setting the m_flo= wid > > ... > > > > > >> > > > > > >> --HPS > > > > > >> > > > > > > > > > > > > Flip use_flowid back to 1 and try setting > > > > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shi= ft > > to 0 > > > > > > as Hiren suggested. r260179 added this shift, which has caused= us > > > > > > balancing issues with the i350/igb. > > > > > > > > > > > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D2601= 79 > > > > > > > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > > > > flowid' under normal conditions, does that mean this shift shou= ld > > be 0 > > > > > > by default to ensure we don't break balancing for devices that = only > > > > > > set the CPU/MSIX queue? > > > > > > > > > > Or we can just see if there's anything wrong with putting the ful= l 32 > > > > > bit RSS flowid in received packets that have them. > > > > > > > > It'd be nice to have but for now I am proposing following to fix a > > known > > > > broken case because of an optimization: > > > > https://reviews.freebsd.org/D2098 > > > > > > Turns out, setting flowid_shift to 0 is not the correct solution. Ple= ase > > > look at the review above for more details. > > > > > > Looking at the code, we have a way to get full flowid but it's hidden > > > under "ifdef RSS": > > > rxr->fmp->m_pkthdr.flowid =3D le32toh(cur->wb.lower.hi_dword.rss); > > > > > > Using just this line gives me good hash on I350 igb(4) chipset that we > > > have. > > > > > > Is it possible to expose this outside RSS? Would this break other > > > things/chips? > > > > > > Cheers, > > > Hiren > > > > > _______________________________________________ > 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" --tauoZ0QFNrdllat7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVEYeKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lWlYH/1XzN27EjGdd7eDHkXFGRMXU nNOTyqWyZbril/emcyznvb887HbMz1dZnpqyMWtgPjJHmRK67bAXgTAdaBLr/HAz NLppdzeL0HmaZ9sx++zbP7+9MGPf6UaCswMoeAb51d3ElJjTtGij9IT08URWhc9P YDVwiQaPADmcMUSm247jEePKJ3cxdpfvA1BIMsEr4CcGucsBuXW+FoHqltpotGN3 aJTjSEoBSOUsiJ+BQoMpykT/yytjjB08CHjZ9g2Fed4g07fuAeAPJBvGRUYK/Bpv S8FnFFk3YaqwbuOv2Ox04GabIRqRZ8CIIznaSLDbjGJ7yL9WRpzn86qdMJGmsZQ= =odC7 -----END PGP SIGNATURE----- --tauoZ0QFNrdllat7-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 24 20:51:38 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FC633D3; Tue, 24 Mar 2015 20:51:38 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54CE867B; Tue, 24 Mar 2015 20:51:38 +0000 (UTC) Received: by iedm5 with SMTP id m5so7657835ied.3; Tue, 24 Mar 2015 13:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xKuprD5Z2ukDFs9CdlXm6TBOkRy3XYygOukxpyInV7o=; b=Id7Bo0R2ARLqnzxXxrUx7B+WSXK5mPwvi7rZ/XYwZRj8/AsrZGbStXICSD8flyd1Xw LR6Pnq1C/rjHAWz4/rRozajFn49L4nVydC55IWEx8weU2B3ruu540+p6F3xFK7FKJplN s9BquVKOgABnsEgNvCA8U2mNQ0U/GrWI7Hth+bAHvre2fbhSVgm6dqcoyvOPPs2RIUyW 2j/PV1TXAlZoaESnK5P0iN6+GUX5pcox5h5mFFFOYQWo5cObegz0dXbMkz/Loie0RvKy 3Y1DTiF9kYKFaeiAaSaysXRHj7Z1MIsOxQVn5+cNqXmc/wBZWu55RuocvJSsDuayqcpV QDuQ== MIME-Version: 1.0 X-Received: by 10.42.93.83 with SMTP id w19mr28220359icm.37.1427230297697; Tue, 24 Mar 2015 13:51:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Tue, 24 Mar 2015 13:51:37 -0700 (PDT) In-Reply-To: <20150324154931.GC53237@strugglingcoder.info> References: <20150323233908.GT53237@strugglingcoder.info> <20150323234214.GU53237@strugglingcoder.info> <20150324154931.GC53237@strugglingcoder.info> Date: Tue, 24 Mar 2015 13:51:37 -0700 X-Google-Sender-Auth: -gFz-Z_5t4s_k8_4iBJn5v7eA-Y Message-ID: Subject: Re: Full 32bit flowid from igb(4) From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , FreeBSD Net , erj@freebsd.org, Jack Vogel , Jason Wolfe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Mar 2015 20:51:38 -0000 Hi, The main reason I didn't add it outside of RSS is that I didn't want to impact the behaviour that was there before. Before, it wasn't using the flowid - only the msix/queue id. I read the intel datasheets about that particular field - I'm pretty sure that by default we'll only see RSS hashed packets for IPv4/IPv6, however non v4/v6 packets won't have a flowid. There are also cases of the flow director or some hardware checksum config using the same field as the flowid. The /full/ solution would very carefully check the return status and ensure what's in the flowid field is a flowid. The "sometimes it may have a flowid, sometimes it won't" problem isn't so bad with kernel RSS enabled - it'll just software hash it. -adrian From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 13:41:03 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3660EDE9; Wed, 25 Mar 2015 13:41:03 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E315B342; Wed, 25 Mar 2015 13:41:02 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AB1441FE022; Wed, 25 Mar 2015 14:40:59 +0100 (CET) Message-ID: <5512BB1A.9070900@selasky.org> Date: Wed, 25 Mar 2015 14:41:46 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Emeric POUPON , Adrian Chadd Subject: Re: Fragment questions References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> <550C6D65.6070409@selasky.org> <1776547746.25937476.1427189208729.JavaMail.zimbra@stormshield.eu> In-Reply-To: <1776547746.25937476.1427189208729.JavaMail.zimbra@stormshield.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 13:41:03 -0000 On 03/24/15 10:26, Emeric POUPON wrote: > Hello, > > Please find attached a proposal using atomic_fetchadd. > > Best Regards, > > Emeric Hi, Your proposal using atomic_fetchadd() looks fine to me. I think however we should define the code like a function, because the htons() might be a macro, referring the input argument multiple times ... What do you think? --HPS From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 13:57:49 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04472259 for ; Wed, 25 Mar 2015 13:57:49 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FDD07EC for ; Wed, 25 Mar 2015 13:57:48 +0000 (UTC) Received: by wixw10 with SMTP id w10so39977337wix.0 for ; Wed, 25 Mar 2015 06:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=HzaxGD2jNlx6bvXkD/fE6vk2aHujZdvfK4WIp4AnbAo=; b=cRsUD+iWkZWCWb4DusEzNjEFrATw32viddlz+NCm2CCkBO3044cu/L8uLMwTru9C0M w3tX16M+oeV2WMAPOLPJqUlRDKNrr/oUDmSsniRptVnJ1HkHKA6cAS1UqbxkM7edQZrx aE52E+Lf6Tfwbs2EOlD20GF64aWaqNUjOSqFpkjKf3m8GXXHos9TXdnKg4ePF5DnmyEm KBCWYW0XCg/fXBvmV+wMSVosbYlNk783A4ygjTc9NVts/DQwqQWk8VnJwOAtVuaIg7RB dNyY66mEMNYBgQW8GULV71dVjPlZABD5FcQqte5TGv+MzOmq799Uu0gp25fJW7QSWmhw SUmw== X-Received: by 10.194.8.99 with SMTP id q3mr18898095wja.88.1427291866705; Wed, 25 Mar 2015 06:57:46 -0700 (PDT) Received: from inverness.bcn.sia.es (114.Red-80-35-188.staticIP.rima-tde.net. [80.35.188.114]) by mx.google.com with ESMTPSA id v8sm20745374wib.0.2015.03.25.06.57.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 06:57:46 -0700 (PDT) Message-ID: <5512BED2.2060509@gmail.com> Date: Wed, 25 Mar 2015 13:57:38 +0000 From: "C.L. Martinez" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Equivalnet options between pf_ring and netmap Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 13:57:49 -0000 Hi all, I am trying to configure some values in netmap under a FreeBSD 10.1 host like it can be done with pf_ring in linux. According to netmap(4) manual page exists some options using sysctl. But I am searching about these options: enable_tx_capture and min_num_slots like in pf_ring. Exists some equivalence in netmap? Is it posible to disable TX? dmesg output: root@bsdhst03:~ # dmesg | grep netmap netmap: loaded module 001.000007 [ 427] vtnet_netmap_attach max rings 1 001.000008 [2705] netmap_attach success for vtnet0 tx 1/1024 rx 1/1024 queues/slots 001.000009 [ 432] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 001.000010 [ 427] vtnet_netmap_attach max rings 1 001.000011 [2705] netmap_attach success for vtnet1 tx 1/1024 rx 1/1024 queues/slots 001.000012 [ 432] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 001.000013 [ 427] vtnet_netmap_attach max rings 1 001.000014 [2705] netmap_attach success for vtnet2 tx 1/1024 rx 1/1024 queues/slots 001.000015 [ 432] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 001.000016 [ 427] vtnet_netmap_attach max rings 1 001.000017 [2705] netmap_attach success for vtnet3 tx 1/1024 rx 1/1024 queues/slots 001.000018 [ 432] vtnet_netmap_attach virtio attached txq=1, txd=1024 rxq=1, rxd=1024 From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 14:03:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4ACE4E2 for ; Wed, 25 Mar 2015 14:03:59 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 252878D0 for ; Wed, 25 Mar 2015 14:03:59 +0000 (UTC) Received: by lbbsy1 with SMTP id sy1so18271704lbb.1 for ; Wed, 25 Mar 2015 07:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WfShH0V1W1Lu+NG3c4wjNmq/KceQgsGP6T2pYwcVNUk=; b=RsZLFenhLxJwEos8vBYCk+9zCqqf1KA6gy5dOtHRtehw9uUkHT5qEDTvKUylZlSD+7 xSNBdXopCFUrQsBzS3rYqzNPcbAgf7g/sd0VF/pRtLFbX/9QcF3kbgL/mfviWOVSCMHq g4uxb32pXPcovM/odr2KlWGBFEQQVNi9VFGzbLX3ycbshGOjR9NQOzG/p1YLUakdW85+ o9hHAHax3R+RjWd/Z0AYjgPxmekC4YYCnQwy3JG+yXswtSCLFXUTaDtKS10dNpIGzRM4 oRf6PxyNcjZ0o2ZAeaXqJLUx3NzKt15SQXkDP+iUZShujnC72epxBGX4Q/a6nYNWFCLr 5Tiw== MIME-Version: 1.0 X-Received: by 10.152.1.70 with SMTP id 6mr8581124lak.83.1427292237058; Wed, 25 Mar 2015 07:03:57 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.180.4 with HTTP; Wed, 25 Mar 2015 07:03:56 -0700 (PDT) In-Reply-To: <5512BED2.2060509@gmail.com> References: <5512BED2.2060509@gmail.com> Date: Wed, 25 Mar 2015 15:03:56 +0100 X-Google-Sender-Auth: BmcOgbka8fJsOCIfPL-kPfmxue0 Message-ID: Subject: Re: Equivalnet options between pf_ring and netmap From: Luigi Rizzo To: "C.L. Martinez" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 14:03:59 -0000 On Wed, Mar 25, 2015 at 2:57 PM, C.L. Martinez wrote: > Hi all, > > I am trying to configure some values in netmap under a FreeBSD 10.1 host > like it can be done with pf_ring in linux. > > According to netmap(4) manual page exists some options using sysctl. But I > am searching about these options: enable_tx_capture and min_num_slots like > in pf_ring. Exists some equivalence in netmap? Is it posible to disable TX? > perhaps it is easier to tell if you explain what those pf_ring options do. i am puzzled by the question on disabling tx, because if you do not want to transmit, you just... don't! :) cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 14:14:15 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DA78C35 for ; Wed, 25 Mar 2015 14:14:15 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B692A42 for ; Wed, 25 Mar 2015 14:14:15 +0000 (UTC) Received: by wibbg6 with SMTP id bg6so25736918wib.0 for ; Wed, 25 Mar 2015 07:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+ccHZ2ImBBvEaYPFdhalbx/DdYXkhxaFV324N9RAblI=; b=bYh2yi7s5SiQncu8EtibiJ6CWiP/J9umQemq4xScDK/dSv0BEG0ZH6b98NtlY/Fh9P 1BK8q98Khoua8AkpXgXiQIyL9QWk31BLcek7JIW6bztk1NzjbYw3RKcb34OvBcWwAzuL RHAKona+b5rwxwUPy5brhY12AfihFcvLTo8fqfg939tBtCI8eDxR7Vo/qpat9F2C3eJM ZojVXKT+hUiFSXvOOICJq2cyxvLff4bKhs2OBT6ZIZU0MmL4+4EBt5e6oOx8pT3g/nE2 3RGxEmDvxESAOaA6/vVvmNhfCfIdLNG4pIIPcNBnN6wDg3XwOUg2ukwBjCUI8uswyI9W unVA== X-Received: by 10.194.91.129 with SMTP id ce1mr18672022wjb.53.1427292848604; Wed, 25 Mar 2015 07:14:08 -0700 (PDT) Received: from inverness.bcn.sia.es (114.Red-80-35-188.staticIP.rima-tde.net. [80.35.188.114]) by mx.google.com with ESMTPSA id n6sm3925112wjy.8.2015.03.25.07.14.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 07:14:08 -0700 (PDT) Message-ID: <5512C2AF.6050300@gmail.com> Date: Wed, 25 Mar 2015 14:14:07 +0000 From: "C.L. Martinez" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Equivalnet options between pf_ring and netmap References: <5512BED2.2060509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 14:14:15 -0000 On 03/25/2015 02:03 PM, Luigi Rizzo wrote: > perhaps it is easier to tell if you explain what those pf_ring options do. > i am puzzled by the question on disabling tx, because if you do not > want to transmit, you just... don't! Ok, I will try to explain it ... I am doing some tests with this FreeBSD kvm guest to act as a IDS. After changing some kernel network related options like net.inet.tcp.recvspace, net.inet.tcp.sendspace, net.inet.tcp.sendbuf_max, etc ... I am loosing too much packets ... Yes I know it: due to I am using this freebsd host as a virtualized guest I can't expect really good results ... but I have another linux virtualized host using pf_ring, and I don't lose too much packets. The main difference is that in the linux server I configured "enable_tx_capture=0" and "min_num_slots=65535" in pf_ring's module. For this reason, I am thinking if it is possible to accomplish same or similar type of configuration in netmap ... From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 14:54:43 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB15BE00 for ; Wed, 25 Mar 2015 14:54:43 +0000 (UTC) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx141.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B9FEAF69 for ; Wed, 25 Mar 2015 14:54:43 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,465,1422950400"; d="diff'?scan'208";a="32508761" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx141-out.netapp.com with ESMTP; 25 Mar 2015 07:49:21 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 25 Mar 2015 07:49:21 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Wed, 25 Mar 2015 07:49:21 -0700 From: "Scheffenegger, Richard" To: "freebsd-net@freebsd.org" Subject: TCP SACK improvements (RFC6675 rescue retransmission and lost retransmission detection) Thread-Topic: TCP SACK improvements (RFC6675 rescue retransmission and lost retransmission detection) Thread-Index: AdBnCsqvL19uko8LSm+1SaVA1edBAg== Date: Wed, 25 Mar 2015 14:49:20 +0000 Message-ID: <046c2d4c51964cb698d0d27f1b8d0451@hioexcmbx05-prd.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] Content-Type: multipart/mixed; boundary="_002_046c2d4c51964cb698d0d27f1b8d0451hioexcmbx05prdhqnetappc_" MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 14:54:44 -0000 --_002_046c2d4c51964cb698d0d27f1b8d0451hioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I hope this is the correct forum to ask for help improving a rather crude p= atch to introduce RFC6675 Rescue Retransmissions and efficient Lost Retrans= mission Detection. Note that this is not a full implementation of the RFC66= 75. The patch that I have is against 8.0, but I believe the SACK scoreboard has= not really changed and thus should be applicable still. One outstanding issue of that patch is the missing interaction with the con= gestion control part, when retransmitting a lost retransmission (that shoul= d reduce cwnd once per cycle). Also, the implementation is not very efficient, as more traversals of the s= coreboard are done checking the elegibility of prior holes to be in need of= being retransmitted once more... Best regards, Richard Scheffenegger --_002_046c2d4c51964cb698d0d27f1b8d0451hioexcmbx05prdhqnetappc_ Content-Type: application/octet-stream; name="sack5-freebsd8.0-release.diff" Content-Description: sack5-freebsd8.0-release.diff Content-Disposition: attachment; filename="sack5-freebsd8.0-release.diff"; size=6825; creation-date="Tue, 05 Oct 2010 14:20:26 GMT"; modification-date="Wed, 25 Mar 2015 13:00:00 GMT" Content-Transfer-Encoding: base64 LS0tIC4uL25ldGluZXQub3JpZy90Y3Bfc2Fjay5jICAyMDEwLTA5LTEwIDIzOjM5OjI1LjAwMDAw MDAwMCArMDIwMA0KKysrIC4uL25ldGluZXQvdGNwX3NhY2suYyAyMDEwLTA5LTIzIDIwOjM3OjA0 LjAwMDAwMDAwMCArMDIwMA0KQEAgLTM0MCwxMCArMzQwLDUyIEBADQogIC8qIEZyZWUgdGhpcyBT QUNLIGhvbGUuICovDQogIHRjcF9zYWNraG9sZV9mcmVlKHRwLCBob2xlKTsNCiB9DQogDQogLyoN CisgKiBDYWxjdWxhdGUgdGhlIHNlcXVlbmNlIG51bWJlciwgd2hpY2ggd2hlbiBTQUNLZWQgd2ls bCBpbmRpY2F0ZSBhIA0KKyAqIGxvc3QgcmV0cmFuc21pc3Npb24uDQorICovDQordGNwX3NlcQ0K K3RjcF9zYWNrX2RvbmVieShpbnQgYnl0ZXMsIHN0cnVjdCB0Y3BjYiAqdHAsIHN0cnVjdCBzYWNr aG9sZSAqcCkNCit7DQorICAgIHdoaWxlICgocCAhPSBOVUxMKSAmJiAoYnl0ZXMgPj0gMCkpIHsN CisgICAgICAgIHAgPSBUQUlMUV9ORVhUKHAsIHNjYmxpbmspOw0KKyAgICAgICAgaWYgKHAgIT0g TlVMTCkgew0KKyAgICAgICAgICAgIGJ5dGVzIC09IChwLT5lbmQgLSBwLT5zdGFydCk7DQorICAg ICAgICAgICAgaWYgKChieXRlcyA+PSAwKSAmJiAvLyBSRkM2Njc1ICJyZXNjdWUgcmV0cmFuc21p c3Npb24iDQorICAgICAgICAgICAgICAgIChUQUlMUV9ORVhUKHAsIHNjYmxpbmspID09IE5VTEwp KQ0KKyAgICAgICAgICAgICAgICAgYnl0ZXMgPSAtbWluKHAtPmVuZCAtIHAtPnN0YXJ0LCB0cC0+ dF9tYXhzZWcpOyAgDQorICAgICAgICB9DQorICAgIH0NCisgICAgaWYgKHAgPT0gTlVMTCkgew0K KyAgICAgICAgcmV0dXJuIHRwLT5zbmRfbnh0Ow0KKyAgICB9IGVsc2Ugew0KKyAgICAgICAgcmV0 dXJuIChwLT5lbmQgKyBieXRlcyk7DQorICAgIH0NCit9DQorDQorLyoNCisgKiBDaGVjayB3ZXRo ZXIgYSBnaXZlbiBzZXF1ZW5jZSBudW1iZXIgaGFzIGJlZW4gU0FDS2VkIG9yIG5vdC4NCisgKi8N CitpbnQNCit0Y3Bfc2Fja19pc2hvbGUodGNwX3NlcSBzZXEsIHN0cnVjdCB0Y3BjYiAqdHAsIHN0 cnVjdCBzYWNraG9sZSAqcCkNCit7DQorICAgIGludCBiID0gMDsNCisgICAgaWYgKFNFUV9HRVEo c2VxLCB0cC0+c25kX2ZhY2spKSB7DQorIHJldHVybiAxOw0KKyAgICB9DQorICAgIHdoaWxlIChw ICE9IE5VTEwpIHsNCisgaWYgKFNFUV9MVChzZXEsIHAtPnN0YXJ0KSkNCisgICAgIGJyZWFrOw0K KyBpZiAoU0VRX0dFUShzZXEsIHAtPnN0YXJ0KSAmJg0KKyAgIFNFUV9MVChzZXEsIHAtPmVuZCkp IHsNCisgICAgIGIgPSAxOw0KKyAgICAgYnJlYWs7DQorIH0NCisgcCA9IFRBSUxRX05FWFQocCwg c2NibGluayk7DQorICAgIH0NCisgICAgcmV0dXJuIGI7DQorfQ0KKw0KKy8qDQogICogUHJvY2Vz cyBjdW11bGF0aXZlIEFDSyBhbmQgdGhlIFRDUCBTQUNLIG9wdGlvbiB0byB1cGRhdGUgdGhlIHNj b3JlYm9hcmQuDQogICogdHAtPnNuZF9ob2xlcyBpcyBhbiBvcmRlcmVkIGxpc3Qgb2YgaG9sZXMg KG9sZGVzdCB0byBuZXdlc3QsIGluIHRlcm1zIG9mDQogICogdGhlIHNlcXVlbmNlIHNwYWNlKS4N CiAgKi8NCiB2b2lkDQpAQCAtNDgwLDExICs1MjIsMTUgQEANCiAgICAgICAqIHByZXZpb3VzIGhv bGUuDQogICAgICAgKi8NCiAgICAgIGN1ciA9IFRBSUxRX1BSRVYoY3VyLCBzYWNraG9sZV9oZWFk LCBzY2JsaW5rKTsNCiAgICAgIGNvbnRpbnVlOw0KICAgIH0NCi0gICB0cC0+c2Fja2hpbnQuc2Fj a19ieXRlc19yZXhtaXQgLT0gKGN1ci0+cnhtaXQgLSBjdXItPnN0YXJ0KTsNCisgICAvKioqKioN CisgICAgKiBsb3N0IGFnYWluDQorICAgICoqKioqLw0KKyAgIHRwLT5zYWNraGludC5zYWNrX2J5 dGVzX3JleG1pdCAtPSAoDQorICAgICBTRVFfTUlOKGN1ci0+cnhtaXQsIGN1ci0+ZW5kKSAtIGN1 ci0+c3RhcnQpOw0KICAgIEtBU1NFUlQodHAtPnNhY2toaW50LnNhY2tfYnl0ZXNfcmV4bWl0ID49 IDAsDQogICAgICAgICgic2Fja2hpbnQgYnl0ZXMgcnR4ID49IDAiKSk7DQogICAgaWYgKFNFUV9M RVEoc2Jsa3AtPnN0YXJ0LCBjdXItPnN0YXJ0KSkgew0KICAgICAgLyogRGF0YSBhY2tzIGF0IGxl YXN0IHRoZSBiZWdpbm5pbmcgb2YgaG9sZS4gKi8NCiAgICAgIGlmIChTRVFfR0VRKHNibGtwLT5l bmQsIGN1ci0+ZW5kKSkgew0KQEAgLTUwNiwxMSArNTUyLDE3IEBADQogICAgfSBlbHNlIHsNCiAg ICAgIC8qIERhdGEgYWNrcyBhdCBsZWFzdCB0aGUgZW5kIG9mIGhvbGUuICovDQogICAgICBpZiAo U0VRX0dFUShzYmxrcC0+ZW5kLCBjdXItPmVuZCkpIHsNCiAgICAgICAgLyogTW92ZSBlbmQgb2Yg aG9sZSBiYWNrd2FyZC4gKi8NCiAgICAgICAgY3VyLT5lbmQgPSBzYmxrcC0+c3RhcnQ7DQotICAg ICAgIGN1ci0+cnhtaXQgPSBTRVFfTUlOKGN1ci0+cnhtaXQsIGN1ci0+ZW5kKTsNCisgICAgICAg LyoqKioqDQorICAgICAgICAqIGxvc3QgYWdhaW4NCisgICAgICAgICoqKioqLw0KKyAgICAgICBp ZiAoU0VRX0dFUShjdXItPnJ4bWl0LCBjdXItPmVuZCkpIHsNCisgICAgICAgICAgIGN1ci0+cnht aXQgPSB0Y3Bfc2Fja19kb25lYnkoDQorICAgICAgICAgdGNwcmV4bXR0aHJlc2ggKiB0cC0+dF9t YXhzZWcsIHRwLCBjdXIpOw0KKyAgICAgICB9DQogICAgICB9IGVsc2Ugew0KICAgICAgICAvKg0K ICAgICAgICAgKiBBQ0tzIHNvbWUgZGF0YSBpbiBtaWRkbGUgb2YgYSBob2xlOyBuZWVkDQogICAg ICAgICAqIHRvIHNwbGl0IGN1cnJlbnQgaG9sZQ0KICAgICAgICAgKi8NCkBAIC01MjIsMjYgKzU3 NCw0NyBAQA0KICAgICAgICAgICAgdHAtPnNhY2toaW50LnNhY2tfYnl0ZXNfcmV4bWl0DQogICAg ICAgICAgICAgICAgKz0gKHRlbXAtPnJ4bWl0DQogICAgICAgICAgICAgICAgLSB0ZW1wLT5zdGFy dCk7DQogICAgICAgICAgfQ0KICAgICAgICAgIGN1ci0+ZW5kID0gc2Jsa3AtPnN0YXJ0Ow0KLSAg ICAgICAgIGN1ci0+cnhtaXQgPSBTRVFfTUlOKGN1ci0+cnhtaXQsDQotICAgICAgICAgICAgIGN1 ci0+ZW5kKTsNCisgICAgICAgICAvKioqKioNCisgICAgICAgICAgKiBsb3N0IGFnYWluDQorICAg ICAgICAgICoqKioqLw0KKyAgICAgICAgIGlmIChTRVFfR0VRKGN1ci0+cnhtaXQsIGN1ci0+ZW5k KSkgew0KKyAgICAgICAgICAgICBjdXItPnJ4bWl0ID0gdGNwX3NhY2tfZG9uZWJ5KA0KKyAgICAg ICAgICAgdGNwcmV4bXR0aHJlc2ggKiB0cC0+dF9tYXhzZWcsIHRwLCBjdXIpOw0KIw0KIw0KIw0K KyAgICAgICAgIH0NCiAgICAgICAgfQ0KICAgICAgfQ0KICAgIH0NCi0gICB0cC0+c2Fja2hpbnQu c2Fja19ieXRlc19yZXhtaXQgKz0gKGN1ci0+cnhtaXQgLSBjdXItPnN0YXJ0KTsNCisgICAvKioq KioNCisgICAgKiBsb3N0IGFnYWluDQorICAgICoqKioqLw0KKyAgIHRwLT5zYWNraGludC5zYWNr X2J5dGVzX3JleG1pdCArPSANCisgICAgIChTRVFfTUlOKGN1ci0+cnhtaXQsIGN1ci0+ZW5kKSAt IGN1ci0+c3RhcnQpOw0KICAgIC8qDQogICAgICogVGVzdGluZyBzYmxrcC0+c3RhcnQgYWdhaW5z dCBjdXItPnN0YXJ0IHRlbGxzIHVzIHdoZXRoZXINCiAgICAgKiB3ZSdyZSBkb25lIHdpdGggdGhl IHNhY2sgYmxvY2sgb3IgdGhlIHNhY2sgaG9sZS4NCiAgICAgKiBBY2NvcmRpbmdseSwgd2UgYWR2 YW5jZSBvbmUgb3IgdGhlIG90aGVyLg0KICAgICAqLw0KICAgIGlmIChTRVFfTEVRKHNibGtwLT5z dGFydCwgY3VyLT5zdGFydCkpDQogICAgICBjdXIgPSBUQUlMUV9QUkVWKGN1ciwgc2Fja2hvbGVf aGVhZCwgc2NibGluayk7DQogICAgZWxzZQ0KICAgICAgc2Jsa3AtLTsNCiAgfQ0KKyAvKioqKioN CisgICogbG9zdCBhZ2Fpbg0KKyAgKioqKiovDQorIGlmICgodGVtcCA9IHRwLT5zYWNraGludC5u ZXh0aG9sZSkgIT0gTlVMTCkgew0KKyAgICAgZG8gew0KKyAgIGlmICghKHRjcF9zYWNrX2lzaG9s ZSh0ZW1wLT5yeG1pdCwgdHAsIHRlbXApKSkgew0KKyAgICAgICB0ZW1wLT5yeG1pdCA9IHRlbXAt PnN0YXJ0Ow0KKyAgICAgICB0cC0+c2Fja2hpbnQubmV4dGhvbGUgPSB0ZW1wOw0KKyAgICAgICAv L1RDUFNUQVRfSU5DKHRjcHNfc2Fja19yZXhtaXRfbG9zdCk7DQorICAgfQ0KKyAgICAgfSB3aGls ZSAoKHRlbXAgPSBUQUlMUV9QUkVWKHRlbXAsIHNhY2tob2xlX2hlYWQsIHNjYmxpbmspKSAhPSBO VUxMKTsNCisgfQ0KIH0NCiANCiAvKg0KICAqIEZyZWUgYWxsIFNBQ0sgaG9sZXMgdG8gY2xlYXIg dGhlIHNjb3JlYm9hcmQuDQogICovDQotLS0gLi4vbmV0aW5ldC5vcmlnL3RjcF92YXIuaCAyMDEw LTA5LTEwIDIzOjM5OjI1LjAwMDAwMDAwMCArMDIwMA0KKysrIC4uL25ldGluZXQvdGNwX3Zhci5o ICAyMDEwLTA5LTE5IDIwOjU5OjQyLjAwMDAwMDAwMCArMDIwMA0KQEAgLTM2LDEwICszNiwxMiBA QA0KICNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPg0KIA0KICNpZmRlZiBfS0VSTkVMDQogI2luY2x1 ZGUgPG5ldC92bmV0Lmg+DQogDQorc3RhdGljIGNvbnN0IGludCB0Y3ByZXhtdHRocmVzaCA9IDM7 DQorDQogLyoNCiAgKiBLZXJuZWwgdmFyaWFibGVzIGZvciB0Y3AuDQogICovDQogVk5FVF9ERUNM QVJFKGludCwgdGNwX2RvX3JmYzEzMjMpOw0KIFZORVRfREVDTEFSRShpbnQsIHRjcF9yZWFzc19x c2l6ZSk7DQpAQCAtNDU3LDEwICs0NTksMTEgQEANCiANCiAgLyogU0FDSyByZWxhdGVkIHN0YXRz ICovDQogIHVfbG9uZyAgdGNwc19zYWNrX3JlY292ZXJ5X2VwaXNvZGU7IC8qIFNBQ0sgcmVjb3Zl cnkgZXBpc29kZXMgKi8NCiAgdV9sb25nICB0Y3BzX3NhY2tfcmV4bWl0czsgICAgICAvKiBTQUNL IHJleG1pdCBzZWdtZW50cyAgICovDQogIHVfbG9uZyAgdGNwc19zYWNrX3JleG1pdF9ieXRlczsg ICAgIC8qIFNBQ0sgcmV4bWl0IGJ5dGVzICAgICAgKi8NCisvLyB1X2xvbmcgIHRjcHNfc2Fja19y ZXhtaXRfbG9zdDsgICAgICAvKiBTQUNLIGxvc3QgcmV4bWl0IHNlZ21lbnRzICovDQogIHVfbG9u ZyAgdGNwc19zYWNrX3Jjdl9ibG9ja3M7ICAgICAvKiBTQUNLIGJsb2NrcyAob3B0aW9ucykgcmVj ZWl2ZWQgKi8NCiAgdV9sb25nICB0Y3BzX3NhY2tfc2VuZF9ibG9ja3M7ICAgICAgLyogU0FDSyBi bG9ja3MgKG9wdGlvbnMpIHNlbnQgICAgICovDQogIHVfbG9uZyAgdGNwc19zYWNrX3Nib3ZlcmZs b3c7ICAgICAgIC8qIHRpbWVzIHNjb3JlYm9hcmQgb3ZlcmZsb3dlZCAqLw0KICANCiAgLyogRUNO IHJlbGF0ZWQgc3RhdHMgKi8NCkBAIC02OTksMTAgKzcwMiwxMiBAQA0KIGV4dGVybiBzdHJ1Y3Qg cHJfdXNycmVxcyB0Y3BfdXNycmVxczsNCiBleHRlcm4gdV9sb25nIHRjcF9zZW5kc3BhY2U7DQog ZXh0ZXJuIHVfbG9uZyB0Y3BfcmVjdnNwYWNlOw0KIHRjcF9zZXEgdGNwX25ld19pc24oc3RydWN0 IHRjcGNiICopOw0KIA0KK3RjcF9zZXEgICB0Y3Bfc2Fja19kb25lYnkoaW50LCBzdHJ1Y3QgdGNw Y2IgKiwgc3RydWN0IHNhY2tob2xlICopOw0KK2ludCAgIHRjcF9zYWNrX2lzaG9sZSh0Y3Bfc2Vx LCBzdHJ1Y3QgdGNwY2IgKiwgc3RydWN0IHNhY2tob2xlICopOw0KIHZvaWQgIHRjcF9zYWNrX2Rv YWNrKHN0cnVjdCB0Y3BjYiAqLCBzdHJ1Y3QgdGNwb3B0ICosIHRjcF9zZXEpOw0KIHZvaWQgIHRj cF91cGRhdGVfc2Fja19saXN0KHN0cnVjdCB0Y3BjYiAqdHAsIHRjcF9zZXEgcmN2X2xhc3RzdGFy dCwgdGNwX3NlcSByY3ZfbGFzdGVuZCk7DQogdm9pZCAgdGNwX2NsZWFuX3NhY2tyZXBvcnQoc3Ry dWN0IHRjcGNiICp0cCk7DQogdm9pZCAgdGNwX3NhY2tfYWRqdXN0KHN0cnVjdCB0Y3BjYiAqdHAp Ow0KIHN0cnVjdCBzYWNraG9sZSAqdGNwX3NhY2tfb3V0cHV0KHN0cnVjdCB0Y3BjYiAqdHAsIGlu dCAqc2Fja19ieXRlc19yZXhtdCk7DQotLS0gLi4vbmV0aW5ldC5vcmlnL3RjcF9pbnB1dC5jIDIw MTAtMDktMTEgMjI6Mzg6NTMuMDAwMDAwMDAwICswMjAwDQorKysgLi4vbmV0aW5ldC90Y3BfaW5w dXQuYyAgMjAxMC0wOS0xNSAxOTowODo0MS4wMDAwMDAwMDAgKzAyMDANCkBAIC05NCwxMiArOTQs MTAgQEANCiANCiAjaW5jbHVkZSA8bWFjaGluZS9pbl9ja3N1bS5oPg0KIA0KICNpbmNsdWRlIDxz ZWN1cml0eS9tYWMvbWFjX2ZyYW1ld29yay5oPg0KIA0KLXN0YXRpYyBjb25zdCBpbnQgdGNwcmV4 bXR0aHJlc2ggPSAzOw0KLQ0KIFZORVRfREVGSU5FKHN0cnVjdCB0Y3BzdGF0LCB0Y3BzdGF0KTsN CiBWTkVUX0RFRklORShpbnQsIGJsYWNraG9sZSk7DQogVk5FVF9ERUZJTkUoaW50LCB0Y3BfZGVs YWNrX2VuYWJsZWQpOw0KIFZORVRfREVGSU5FKGludCwgZHJvcF9zeW5maW4pOw0KIFZORVRfREVG SU5FKGludCwgdGNwX2RvX3JmYzMwNDIpOw0KLS0tIC4uL25ldGluZXQub3JpZy90Y3Bfb3V0cHV0 LmMgIDIwMTAtMDktMTAgMjM6Mzk6MjUuMDAwMDAwMDAwICswMjAwDQorKysgLi4vbmV0aW5ldC90 Y3Bfb3V0cHV0LmMgMjAxMC0wOS0xNSAxOTowMzo1OS4wMDAwMDAwMDAgKzAyMDANCkBAIC05NTEs MTAgKzk1MSwxNyBAQA0KICAgIGVsc2UNCiAgICAgIHRoLT50aF9zZXEgPSBodG9ubCh0cC0+c25k X21heCk7DQogIH0gZWxzZSB7DQogICAgdGgtPnRoX3NlcSA9IGh0b25sKHAtPnJ4bWl0KTsNCiAg ICBwLT5yeG1pdCArPSBsZW47DQorICAgLyoqKioqDQorICAgICogbG9zdCBhZ2Fpbg0KKyAgICAq KioqKi8NCisgICBpZiAoU0VRX0dFUShwLT5yeG1pdCwgcC0+ZW5kKSkgew0KKyAgICAgICBwLT5y eG1pdCA9IHRjcF9zYWNrX2RvbmVieSgNCisgICAgIHRjcHJleG10dGhyZXNoICogdHAtPnRfbWF4 c2VnLCB0cCwgcCk7DQorICAgfQ0KICAgIHRwLT5zYWNraGludC5zYWNrX2J5dGVzX3JleG1pdCAr PSBsZW47DQogIH0NCiAgdGgtPnRoX2FjayA9IGh0b25sKHRwLT5yY3Zfbnh0KTsNCiAgaWYgKG9w dGxlbikgew0KICAgIGJjb3B5KG9wdCwgdGggKyAxLCBvcHRsZW4pOw0K --_002_046c2d4c51964cb698d0d27f1b8d0451hioexcmbx05prdhqnetappc_-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 15:24:53 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08E952D2; Wed, 25 Mar 2015 15:24:53 +0000 (UTC) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id BAD085F2; Wed, 25 Mar 2015 15:24:52 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id ACFAE3C1AE2; Thu, 26 Mar 2015 02:24:48 +1100 (AEDT) Date: Thu, 26 Mar 2015 02:24:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Hans Petter Selasky Subject: Re: Fragment questions In-Reply-To: <5512BB1A.9070900@selasky.org> Message-ID: <20150326005055.C3948@besplex.bde.org> References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> <550C6D65.6070409@selasky.org> <1776547746.25937476.1427189208729.JavaMail.zimbra@stormshield.eu> <5512BB1A.9070900@selasky.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Za4kaKlA c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=kf9_5GuwqjB01lKIac0A:9 a=CjuIK1q_8ugA:10 Cc: Emeric POUPON , freebsd-net , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 15:24:53 -0000 On Wed, 25 Mar 2015, Hans Petter Selasky wrote: > On 03/24/15 10:26, Emeric POUPON wrote: >> >> Please find attached a proposal using atomic_fetchadd. > ... > I think however we should define the code like a function, because the > htons() might be a macro, referring the input argument multiple times ... htons() might be a macro, but then it must act like a function. See POSIX 2.1.1 "Use and Implementation of Functions" clauses 2-3. In particular, it must not evaluate its args more than once (clause 3). These clauses copy the not so good wording of the C standard. E.g., clause 3 also requires parenthesization of the args, but much more than 2.1.1 specifies is required to replace a function by a macro. Args must also be converted the same as a prototype would. Casts to do the conversions are not good enough, since casts should suppress warnings for dubious conversions (e.g., htons(x) where x is a pointer) while the more automatic conversions done by prototypes should warn. 2.1.1 cannot say that the macro implementation behaves identically, since it the behaviour is slightly different. It doesn't mention types at all. The closest it comes to requiring similar behaviour is just "Any function declared in a header may also be implemented as a macro defined in the header". But this is impossible to implement a function as a macro precisely, and 2.1.1 isn't very clear about which parts must be precise (it mentions some parts that are imprecise). POSIX's section about htons() (and most functions) is unclear about this. It says that "On some implementations, these functions [htons family] are _defined_ as macros. That is almost useless, since any function may _also_ be _implemented_ as a macro. It is unclear if the possibility of being defined as a macro means that the function version might not exist. Actually, this is clear in the functions' header. For most functions, e.g., exit(), the wording is that "The following functions shall be _declared_ as functions and may also be defined as macros". [Here it is unclear if _declared_ means more than the declaration of a prototype.] For the htons() family, the wording for netinet/in.h is "The following shall either be declared as functions, defined as macros, or both". FreeBSD's htons() is careful about this. The x86 version uses inline functions to avoid multiple evaluation at the type level. This also accidentally gives the right level of warnings. FreeBSD's man page gives no hints about this except the lower case name of the APIs conventionally means that they are not unsafe macros. It describes the htons() family as "These routines". Routines are unusual in C and in man pages. (In /usr/share/man/man3, there are about 80000 lines matching "function" and only 10000 matching "routine", with mist of the latter in contribish places (lots in spam N-tuplicates from libc/rpc.) Bruce From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 16:34:38 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE87CAC4 for ; Wed, 25 Mar 2015 16:34:38 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E6F2F65 for ; Wed, 25 Mar 2015 16:34:38 +0000 (UTC) Received: by lagg8 with SMTP id g8so24480047lag.1 for ; Wed, 25 Mar 2015 09:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rZi6Z2n9m1tXP3Jo8ADcpSzsANAwLvmJpWWvQQpPd9E=; b=X+I2JVrKGQGykQCpJvG1xZ/4hLLN0shVQqdmhV5prKUwHy9is0VcFo8HIH2TIDGGVR Ee8T14Xzbiwk6XwClJ6ZSH0mZqgaiGCsFXSg4HtYbbvU1ujXlNJS0H7VJH/YFyJjRpdA fiKmnLmn7QB6wtT/2Br+b6Gs7VswQep9m52pf2BOi118smi+Oq4Y5SBt2s+D191vIRcK CL7fm2/2YHFTuyI+3vNtSoN3iy+EvZ4Uwk4eSkwVhpp89WAt/ozEl3DxWD8IWONkpRtS YKH5RTUZ8H4h1G+H0J57mjIDXn7QUhBTZ5q8u8I7bJNQ/V4MuJsZuZNoFPyUSuNE4qEm 3lYw== MIME-Version: 1.0 X-Received: by 10.152.7.172 with SMTP id k12mr9408392laa.100.1427301276398; Wed, 25 Mar 2015 09:34:36 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.180.4 with HTTP; Wed, 25 Mar 2015 09:34:36 -0700 (PDT) In-Reply-To: <5512C2AF.6050300@gmail.com> References: <5512BED2.2060509@gmail.com> <5512C2AF.6050300@gmail.com> Date: Wed, 25 Mar 2015 17:34:36 +0100 X-Google-Sender-Auth: dIIRwBRQunp-Zk1VtK3YQuTu11w Message-ID: Subject: Re: Equivalnet options between pf_ring and netmap From: Luigi Rizzo To: "C.L. Martinez" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 16:34:38 -0000 On Wed, Mar 25, 2015 at 3:14 PM, C.L. Martinez wrote: > On 03/25/2015 02:03 PM, Luigi Rizzo wrote: >> >> perhaps it is easier to tell if you explain what those pf_ring options do. >> i am puzzled by the question on disabling tx, because if you do not >> want to transmit, you just... don't! > > > Ok, I will try to explain it ... I am doing some tests with this FreeBSD kvm > guest to act as a IDS. > > After changing some kernel network related options like > net.inet.tcp.recvspace, net.inet.tcp.sendspace, net.inet.tcp.sendbuf_max, these have nothing to do with netmap. But i just don't understand how the VM fits in the path -- does it act as a "bump in the wire" ie read from one interface and write to another one, or this is an IDS that protects services local to the guest ? Also which IDS you are running and how does it access traffic now ? > etc ... I am loosing too much packets ... Yes I know it: due to I am using > this freebsd host as a virtualized guest I can't expect really good results > ... but I have another linux virtualized host using pf_ring, and I don't > lose too much packets. The main difference is that in the linux server I > configured "enable_tx_capture=0" and "min_num_slots=65535" in pf_ring's > module. > > For this reason, I am thinking if it is possible to accomplish same or > similar type of configuration in netmap ... ok understood. you don't need those parameters, with netmap you basically cut the wire between the OS and the NIC and can read directly what comes from the wire on one ring, and what comes from the OS on another ring (and nothing goes through unless you explicitly write packets to the other side). cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 17:59:07 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 006E0606 for ; Wed, 25 Mar 2015 17:59:06 +0000 (UTC) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1BD1B76 for ; Wed, 25 Mar 2015 17:59:06 +0000 (UTC) Received: by wgra20 with SMTP id a20so36598963wgr.3 for ; Wed, 25 Mar 2015 10:58:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=KGXllimYQdnxoAN6y4r18/IpUAl973PRMTUvFM67Rgw=; b=PvRSKqaMx4fD6cwhTPT83d4NbKND5D9TUXeHabAI0KgOgoLCDUQSq2PjRfWib4ZW7L KqBie7453vLWA2KG8FI8HaCZo7KIF+pR5NWK78x+3Hq5kcgM/YtO3alPG6uWSLGggqWb Fut8YN0Mg71G8aB2a7F4Lwkb4r8sz9tsvdPk8ZrMWCI1nEXjdJBbolFfUItV2SDtCBbn Aeh/UN4I/7rvHdRxJcDhyrOAGrpCGqd/py24CbYspHmc/g12FFdBV/RL++/7CQDMzCGw dVYVyh2a5tTMX9SS2dcuFUvC1XdePVi59aYpT4iOZNM4OdyNaerdY/Q//kx+ckWaMAvC jTfA== X-Gm-Message-State: ALoCoQnYhmPtnphf4p05taf2XBaGKZQzwakveOs4hefHEn2Lo1QEM9dyM4E4TtSSDRfZN9RumYNJ X-Received: by 10.194.157.39 with SMTP id wj7mr20381152wjb.57.1427306339573; Wed, 25 Mar 2015 10:58:59 -0700 (PDT) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by mx.google.com with ESMTPSA id ax10sm4735508wjc.26.2015.03.25.10.58.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 10:58:58 -0700 (PDT) Message-ID: <5512F75A.1020607@freebsd.org> Date: Wed, 25 Mar 2015 18:58:50 +0100 From: Julien Charbon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Robert N. M. Watson" , Adrian Chadd , FreeBSD Net Subject: Re: VIMAGE UDP memory leak fix References: <20141121002937.4f82daea@x23> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> <20141121120201.6c77ea5b@x23> <20141121162042.449b22dc@x23> <072B7B0F-4DE3-4D37-BC94-1DEA38CF3B12@FreeBSD.org> <85C7A32E-121D-495F-93C7-9D2B2F134FF6@FreeBSD.org> In-Reply-To: <85C7A32E-121D-495F-93C7-9D2B2F134FF6@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DTQGpVj3gP2fbOT70eogpa2tDFbHKKuaI" Cc: Craig Rodrigues , "Bjoern A. Zeeb" , Marko Zec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 17:59:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DTQGpVj3gP2fbOT70eogpa2tDFbHKKuaI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On 22/11/14 18:09, Robert N. M. Watson wrote: > On 21 Nov 2014, at 17:40, Adrian Chadd wrote: >>>> Skimming through a bunch of hosts with moderately loaded hosts >>>> with reasonably high uptime I couldn't find one where >>>> net.inet.tcp.timer_race was not zero. A ny suggestions how to >>>> best reproduce the race(s) in tcp_timer.c? >>>=20 >>> They would likely occur only on very highly loaded hosts, as they >>> require race conditions to arise between TCP timers and TCP >>> close. I think I did manage to reproduce it at one stage, and >>> left the counter in to see if we could spot it in production, and >>> I have had (multiple) reports of it in deployed systems. I'm not >>> sure it's worth trying to reproduce them, given that knowledge -- >>> we should simply fix them. >>=20 >> Wasn't this just fixed by Julien @ Verisign? >=20 > I don't believe so, although it's the kind of thing Julien is very > good at fixing! >=20 > The issue here is that we can't call callout_drain() from contexts > where we finalise TCP connection close and attempt to free the inpcb. > The 'easy' fix is to create a taskqueue thread to do the > callout_drain() in the event that we discover that callout_stop() > isn't able to guarantee that pending callouts are neither in > execution nor scheduled. We'd then defer the very tail of TCP > teardown to that asynchronous context rather than trying to do it to > completion in the current (and rather more sensitive) one. This would > happen only very in frequently so have little overhead in practice, > although one would want to carefully look at the sync behaviour to > make sure it wasn't frequently enough that a backlog might build up. Ironically, I was not aware of this discussion before we: - (re)discovered this TCP timers callout race condition - followed Robert's XXXRW comments and advices in source code - proposed a patch for fixing it: Fix TCP timers use-after-free old race conditions https://reviews.freebsd.org/D2079 If the proposed patch follows most of Robert's advices, instead of using a taskqueue thread calling callout_drain(), we re-use directly the callout API to schedule tcpcb's uma_zfree() at appropriate time. Register to the review if your are interested in this fix proposition. But still, nice irony to find this thread _after_ proposing a fix... :) -- Julien --DTQGpVj3gP2fbOT70eogpa2tDFbHKKuaI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVEvdgAAoJEKVlQ5Je6dhx/kIH/1/FN8F8Ixq5LbxwJN9WbvGK BxQketKppg18yTN1DOXpj4IGnRiAURaNGUicRriRRYxyOB4q4U0mSJlAB+dPNlxf RJEFXExekNyi5+jh0ktSUxbwfcKlsuFGcJkgHmyfxFJDXvWFx3Euu5Quc4DgNTQO FgOdNNxwCJut1lauPvfNEoHmNhUgiG+LD13gkubkOU77k/3BK5La8NrembUqvtGD gpCKOD5yMsEj4asl90VYqGh6TKgRaByO/MdWe+NAmq+9eNTqVfF415uCfHJuz64H Y0B5SMKcfvDP2pqw8H/rtSkbJSyRAFPWN+n2j5L7w7gQKxen8ECcPhGncsyogYE= =FZn6 -----END PGP SIGNATURE----- --DTQGpVj3gP2fbOT70eogpa2tDFbHKKuaI-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 20:12:11 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51B70638; Wed, 25 Mar 2015 20:12:11 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 266E3C4C; Wed, 25 Mar 2015 20:12:10 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t2PK3dcn085616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2015 13:03:39 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t2PK3bKe085615; Wed, 25 Mar 2015 13:03:37 -0700 (PDT) (envelope-from jmg) Date: Wed, 25 Mar 2015 13:03:37 -0700 From: John-Mark Gurney To: Hans Petter Selasky Subject: Re: Fragment questions Message-ID: <20150325200337.GE51048@funkthat.com> References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <550AC709.1050404@selasky.org> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> <550C6D65.6070409@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550C6D65.6070409@selasky.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 25 Mar 2015 13:03:39 -0700 (PDT) Cc: Emeric POUPON , freebsd-net , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 20:12:11 -0000 Hans Petter Selasky wrote this message on Fri, Mar 20, 2015 at 19:56 +0100: > On 03/20/15 19:02, Adrian Chadd wrote: > > On 20 March 2015 at 10:58, Hans Petter Selasky wrote: > >> On 03/20/15 14:31, Emeric POUPON wrote: > >>> > >>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use > >>> randomized id. > >> > >>> In multi core systems, we may emit successive packets with the same id. > >> > >> Will using a mutex or an atomic macro fix this issue when incrementing the > >> V_ip_id ? > > > > It will, but it'll ping-pong between multiple cores and slow things > > down at high pps. > > Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random > CPU core number? ip id's only need to be unique for fragments to a specific source address/destination address/protocol tuple... so, using different id buckets per above hash would be best... Take a look at: https://tools.ietf.org/html/rfc6864 Which is a good read for addressing this issue... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Mar 25 21:48:39 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F526F50; Wed, 25 Mar 2015 21:48:39 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E61287C; Wed, 25 Mar 2015 21:48:38 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 92915106953; Wed, 25 Mar 2015 14:48:32 -0700 (PDT) Date: Wed, 25 Mar 2015 14:48:32 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Subject: pagefault in IPv6 codepath in defrouter_select() Message-ID: <20150325214832.GI53237@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZH76yXETYuyhTGDD" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ae@freebsd.org, hrs@freebsd.org, nitroboost@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 25 Mar 2015 21:48:39 -0000 --ZH76yXETYuyhTGDD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable We are seeing following panic with "Panic String: page fault" on a month old stable/10 tree: kgdb) #0 doadump (textdump=3D1) at pcpu.h:219 #1 0xffffffff80746307 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff807466e4 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80a9ab5f in trap_fatal (frame=3D,=20 eva=3D) at /usr/src/sys/amd64/amd64/trap.c:859 #4 0xffffffff80a9ae5d in trap_pfault (frame=3D0xfffffe000038eef0,=20 usermode=3D) at /usr/src/sys/amd64/amd64/trap.c:676 #5 0xffffffff80a9a4da in trap (frame=3D0xfffffe000038eef0) at /usr/src/sys/amd64/amd64/trap.c:440 #6 0xffffffff80a804e2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #7 0xffffffff80744ab3 in __rw_rlock (c=3D0x100b421, file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_rwlock.c:378 #8 0xffffffff80887193 in defrouter_select () at /usr/src/sys/netinet6/nd6_rtr.c:640 #9 0xffffffff80885b58 in nd6_ra_input (m=3D,=20 off=3D, icmp6len=3D) at /usr/src/sys/netinet6/nd6_rtr.c:796 #10 0xffffffff8085fa9f in icmp6_input (mp=3D,=20 offp=3D0xfffffe000038f66c, proto=3D) at /usr/src/sys/netinet6/icmp6.c:814 #11 0xffffffff80874e6c in ip6_input (m=3D0xfffff800269e8a00) at /usr/src/sys/netinet6/ip6_input.c:1019 #12 0xffffffff808144a2 in netisr_dispatch_src (proto=3D,=20 source=3D, m=3D0x0) at /usr/src/sys/net/netisr.c:9= 72 #13 0xffffffff8080ce66 in ether_demux (ifp=3D,=20 m=3D0xfffff800269e8a00) at /usr/src/sys/net/if_ethersubr.c:851 #14 0xffffffff8080daf9 in ether_nh_input (m=3D) at /usr/src/sys/net/if_ethersubr.c:646 #15 0xffffffff808144a2 in netisr_dispatch_src (proto=3D,=20 source=3D, m=3D0x0) at /usr/src/sys/net/netisr.c:9= 72 #16 0xffffffff80437a98 in igb_rxeof (count=3D99) at /usr/src/sys/dev/e1000/if_igb.c:4808 #17 0xffffffff80438131 in igb_msix_que (arg=3D0xfffff8000e6efa08) at /usr/src/sys/dev/e1000/if_igb.c:1621 #18 0xffffffff80716e4b in intr_event_execute_handlers ( p=3D, ie=3D0xfffff8000e6ea500) at /usr/src/sys/kern/kern_intr.c:1264 #19 0xffffffff807177e6 in ithread_loop (arg=3D0xfffff8000e6f5e00) at /usr/src/sys/kern/kern_intr.c:1277 #20 0xffffffff80714a6a in fork_exit ( callout=3D0xffffffff80717750 , arg=3D0xfffff8000e6f5e00,= =20 frame=3D0xfffffe000038fac0) at /usr/src/sys/kern/kern_fork.c:1017 #21 0xffffffff80a80a1e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #22 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) f 7 #7 0xffffffff80744ab3 in __rw_rlock (c=3D0x100b421, file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_rwlock.c:378 378 spin_cnt++; (kgdb) p spin_cnt=20 $6 =3D 1 (kgdb)=20 This is 3rd occurence of this panic. What could be the cause? I have vmcore and can provide more info if needed. Cheers, Hiren --ZH76yXETYuyhTGDD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVEy0vXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lXU4H/AvKGi6wosUrkcyLomyiRB/P 3PZtLJq+KTfUS4ZpIHeMc6znbic3Or+gs9VfPwwqtE56XvTspeTZ+zBeDffULlAf fCU0HfgNZQ6WCxKj+HblRGDYqpw9uiSspwbd7pvkQwoa9Xr8SMlYWFPpPSmoxLPK rstz0MevRul2/1m5uenIQE4B+HxKC7ZPMWzaBJeTeZiAx3iOwWCbvkwwD4MeNrev ZPQ7OYaDAcsXSznpB7oA08cZJDb51CemvwN6aU1zt7oyP66eGy4b4joP95CmUWEx spghQVfT8e6OlBP2OgglkrcbNKZAE8y4UxHU4Jf6dx0TUUx3hmyR6K5clxya2DE= =dTnN -----END PGP SIGNATURE----- --ZH76yXETYuyhTGDD-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 01:17:49 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5730A3A6 for ; Thu, 26 Mar 2015 01:17:49 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BB5FFB1 for ; Thu, 26 Mar 2015 01:17:49 +0000 (UTC) Received: by igcxg11 with SMTP id xg11so41683784igc.0 for ; Wed, 25 Mar 2015 18:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=TE/L60Dqrmw+9rR8CshdAyLLPG9nGj8QO6koB7RXylI=; b=SJ+hfiFujwGNOkhOC56lq08TzeLGWIeMaU8UCiQm7wTvBuvqoKZm+XICL8uPyFhSHh gVPj+gajLivG8fupqw6EIjeFn5qi0R43ZQfaf93+xiibw4HlZEwTWZBm2hOjk2MNDyl2 4FfyMd3hHwOXSzSffNPkq2X1KzXyyI6qROqIQFRKgBIki+ewDiKND2ld+EWG/3r9V1pp Jl0FybebPtfOSXXz7EGy+axuiFSxF+oVboWcANovjKlnV3J/6swLO2IUiqQgEwg/cNoZ uLxZC4emURyde49moft16Vz3C6/diI/JbesWrXCLcTP9ECLF6iWdfUCez3EwUjSbcmdf vDmg== MIME-Version: 1.0 X-Received: by 10.42.93.83 with SMTP id w19mr35094917icm.37.1427332668474; Wed, 25 Mar 2015 18:17:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 25 Mar 2015 18:17:48 -0700 (PDT) In-Reply-To: <20150323131918.GN7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> Date: Wed, 25 Mar 2015 18:17:48 -0700 X-Google-Sender-Auth: xjmYM_Ed7d-aif5QmRJWhPpQuWU Message-ID: Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head From: Adrian Chadd To: "net@freebsd.org" , David Wolfskill Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 01:17:49 -0000 Hi, I'm unfortunately too busy to really help you dig into it. I'd start by using tcpdump on wlan0 to see what's going on - see if it's sending/receiving DHCP responses. Then I'd look at if_iwn_debug.h and enable TX/RX debugging - see if it's actually transmitting the DHCP requests and the TX status code is OK rather than one of the errors. -adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 02:21:34 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 681F66C1; Thu, 26 Mar 2015 02:21:34 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14DBF8C6; Thu, 26 Mar 2015 02:21:33 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2Q2LW84029138; Wed, 25 Mar 2015 19:21:32 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2Q2LWfh029137; Wed, 25 Mar 2015 19:21:32 -0700 (PDT) (envelope-from david) Date: Wed, 25 Mar 2015 19:21:32 -0700 From: David Wolfskill To: Adrian Chadd Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head Message-ID: <20150326022132.GI7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1IYcr18XUmgwOrO2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 02:21:34 -0000 --1IYcr18XUmgwOrO2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2015 at 06:17:48PM -0700, Adrian Chadd wrote: > Hi, >=20 > I'm unfortunately too busy to really help you dig into it. >=20 > I'd start by using tcpdump on wlan0 to see what's going on - see if > it's sending/receiving DHCP responses. Well, in head, it won't even associate, so I suspect that DHCP is a moot point. > Then I'd look at if_iwn_debug.h and enable TX/RX debugging - see if > it's actually transmitting the DHCP requests and the TX status code is > OK rather than one of the errors. > .... Thanks for the hints/tips.... Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1IYcr18XUmgwOrO2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVE20rXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7J0oP/2Sx25gzFmlnv230qlLzWcmw JNAiXz/l+dklsqS6RW3h72kcJ92bszY7/L8QH1mWoxGk6HSO0h7mpvv8Wg0QyAhB wK9MDOStqXw4SwAAYAq+1RouJZFN5Lm/ZYruEgcfAZurhgIN3jGDxuSTifOjbnLe SD6Bj1atKRMql4sM0gypvi81qnnK7IpVCoARZbgbjE5IPoYg45CgZURCRBjvxGtc 0sRlcWVk2AP0HB+TJuBizAufeZBMZIjDefAgh2TaDgI+E0iU0Ucl8Hccp3WeQ2NP VuqYaRbUd81miQwiNde1wDHoNCx41lO6KH3PaC8WI3KhsKbhxsSkWE5sCl9vox1S saDMgGIDdl9/lDzeFuuhNzotB9XuFi8/Tx0wUpOAvClS7uNEIeyJe8Q2TsRherYT uNQdhW9O6w5zp+fRlfQWcUyYrf+sc0nJ1dUgxSpJ+h5Dv3I8DN2U4hEsljE9pEYu 9iqElVAztkqxd80HTeCBezk7oP1V6wO4u1zbLdoQv0Ev7JQ7WxRUhagECPX2UyWd dKxTSnIJhLLDEZu2iQ2NoG8FujG+HGVRx871fAgU1tWNy3AetyGjeSqfg/a8q94a upz8cpdN9y5wVa8edjZEnLDMEcCImYgsGw0TNNPPjFmAThZ0DcYynKjzGd4HZ6Lz A11ArYix0BLuaci0jAbX =xSg+ -----END PGP SIGNATURE----- --1IYcr18XUmgwOrO2-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 04:19:41 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7DEEF8 for ; Thu, 26 Mar 2015 04:19:41 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BAA576E for ; Thu, 26 Mar 2015 04:19:41 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so43818784igb.1 for ; Wed, 25 Mar 2015 21:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HobzDcEv27PwNA610gtYcMcZn2+tEfCNNG36UnCZjdE=; b=lN9MfZ4puLAK1G1ysWXrfP3fqzmgexejQ+IU1dATjzCWhUvHrmeHEx0jtPjOsa8OSV tzjarioXx5l+udAdXw2pwUtxUQHhrikOuzngYXGLoeTZmH6PcnNEKhd26HiBRScqBz9Z F6tLBik5MAr0EPrXEcojaGxFKbVvsRdHpjEURCoIfWY0im9IWouVhUia8864Hde94ieG qbluAnCYW2f4oMOhZFuMlRmqyWZrYmkbz8zSSTY/z2PzR/xGMKovCc4zB1NFFuOtkH57 czZ2wa6nKXXIKSkNqfaNmAq4QhYOgCFqK+7UWWjUlFvdwdv53ylWYDr/QM9NaSEn78Dp 0dbA== MIME-Version: 1.0 X-Received: by 10.42.41.200 with SMTP id q8mr31799419ice.61.1427343580784; Wed, 25 Mar 2015 21:19:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 25 Mar 2015 21:19:40 -0700 (PDT) In-Reply-To: <20150326022132.GI7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> Date: Wed, 25 Mar 2015 21:19:40 -0700 X-Google-Sender-Auth: -SvGr2ClmOL_ywMoUXHO046PKbo Message-ID: Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head From: Adrian Chadd To: David Wolfskill Content-Type: text/plain; charset=UTF-8 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 04:19:41 -0000 On 25 March 2015 at 19:21, David Wolfskill wrote: > On Wed, Mar 25, 2015 at 06:17:48PM -0700, Adrian Chadd wrote: >> Hi, >> >> I'm unfortunately too busy to really help you dig into it. >> >> I'd start by using tcpdump on wlan0 to see what's going on - see if >> it's sending/receiving DHCP responses. > > Well, in head, it won't even associate, so I suspect that DHCP is a moot > point. Ok, sysctl dev.iwn.0.debug=0x1, wlandebug +scan, and then start wpa_supplicant. It should be reasonably obvious what's going on - if it can't see APs or it can't transmit anything successfully, then at least I know where to begin looking when I have spare time. I have a 5100 in my T400: iwn0@pci0:3:0:0: class=0x028000 card=0x12118086 chip=0x42378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 5100 AGN [Shiloh] Network Connection' class = network -adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 06:52:33 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66CD936B; Thu, 26 Mar 2015 06:52:33 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79A0C7C3; Thu, 26 Mar 2015 06:52:30 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id C06BC2E0A5; Thu, 26 Mar 2015 14:52:09 +0800 (CST) Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id 7F6662E018; Thu, 26 Mar 2015 14:44:37 +0800 (CST) Message-ID: <5513AAD8.9060505@gddsn.org.cn> Date: Thu, 26 Mar 2015 14:44:40 +0800 From: Wu ShuKun User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: net@freebsd.org, current@freebsd.org, stable@freebsd.org, questions@freebsd.org Subject: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 06:52:33 -0000 greeting! ssh connection failed by using a new version SSH to and old one. Below is the symptoms which on a same network. Connection is Okay with old version SSH %ssh -V OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 %ssh -v 10.41.172.19 OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. debug1: Connection established. debug1: identity file /home/wsk/.ssh/id_rsa type -1 debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_dsa type -1 debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.4p1 FreeBSD-20100308 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host '10.41.172.19 (10.41.172.19)' can't be established. RSA key fingerprint is ab:81:83:79:6a:d8:29:23:a0:51:1d:e6:f0:aa:ce:d6. Are you sure you want to continue connecting (yes/no)? --- failed with Latest SSH: % ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 % ssh -v 10.41.172.19 OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.41.172.19 [10.41.172.19] port 22. debug1: Connection established. debug1: identity file /home/wsk/.ssh/id_rsa type -1 debug1: identity file /home/wsk/.ssh/id_rsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_dsa type -1 debug1: identity file /home/wsk/.ssh/id_dsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa type -1 debug1: identity file /home/wsk/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/wsk/.ssh/id_ed25519 type -1 debug1: identity file /home/wsk/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH_5* compat 0x0c000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY Connection closed by 10.41.172.19 any ideas? From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 08:30:41 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 183254DE; Thu, 26 Mar 2015 08:30:41 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id C90ECE4; Thu, 26 Mar 2015 08:30:39 +0000 (UTC) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 7B8432700AAA; Thu, 26 Mar 2015 09:30:31 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 54FCF2705193; Thu, 26 Mar 2015 09:30:31 +0100 (CET) Received: from work.netasq.com ([127.0.0.1]) by localhost (work.netasq.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gsAZhVaEHpoq; Thu, 26 Mar 2015 09:30:31 +0100 (CET) Received: from work.netasq.com (localhost.localdomain [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 1C2D62700AAA; Thu, 26 Mar 2015 09:30:31 +0100 (CET) Date: Thu, 26 Mar 2015 09:30:30 +0100 (CET) From: Emeric POUPON To: Hans Petter Selasky Message-ID: <84441657.26248421.1427358630097.JavaMail.zimbra@stormshield.eu> In-Reply-To: <5512BB1A.9070900@selasky.org> References: <522774578.25519037.1426765109046.JavaMail.zimbra@stormshield.eu> <2047974073.25663527.1426858267777.JavaMail.zimbra@stormshield.eu> <550C5FC6.6020401@selasky.org> <550C6D65.6070409@selasky.org> <1776547746.25937476.1427189208729.JavaMail.zimbra@stormshield.eu> <5512BB1A.9070900@selasky.org> Subject: Re: Fragment questions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thread-Topic: Fragment questions Thread-Index: 1t/wdfcGuh+8K0O/kv+7KqSnuyr/bA== Cc: freebsd-net , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 08:30:41 -0000 Ok for the function. Please find the review here: https://reviews.freebsd.org/D2141 Regards, Emeric ----- Mail original ----- De: "Hans Petter Selasky" =C3=80: "Emeric POUPON" , "Adrian Chadd" Cc: "freebsd-net" Envoy=C3=A9: Mercredi 25 Mars 2015 14:41:46 Objet: Re: Fragment questions On 03/24/15 10:26, Emeric POUPON wrote: > Hello, > > Please find attached a proposal using atomic_fetchadd. > > Best Regards, > > Emeric Hi, Your proposal using atomic_fetchadd() looks fine to me. I think however we should define the code like a function, because the=20 htons() might be a macro, referring the input argument multiple times ... What do you think? --HPS From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 10:12:36 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDF769A2; Thu, 26 Mar 2015 10:12:36 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E5FE44; Thu, 26 Mar 2015 10:12:36 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t2QACPwt080238; Thu, 26 Mar 2015 06:12:26 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5513DB89.2050801@sentex.net> Date: Thu, 26 Mar 2015 06:12:25 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Wu ShuKun , net@freebsd.org, current@freebsd.org, stable@freebsd.org, questions@freebsd.org Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 References: <5513AAD8.9060505@gddsn.org.cn> In-Reply-To: <5513AAD8.9060505@gddsn.org.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 10:12:37 -0000 On 3/26/2015 2:44 AM, Wu ShuKun wrote: > OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 > failed with Latest SSH: > % ssh -V > OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 Hi, The latest is 1.0.1m, no? }# ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 What version of FreeBSD are you using ? Ssh and Openssl from the ports ? or in the base ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 11:16:16 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF448A9D; Thu, 26 Mar 2015 11:16:15 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD4E5759; Thu, 26 Mar 2015 11:16:14 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2QBGDHU031847; Thu, 26 Mar 2015 04:16:13 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2QBGDaF031846; Thu, 26 Mar 2015 04:16:13 -0700 (PDT) (envelope-from david) Date: Thu, 26 Mar 2015 04:16:13 -0700 From: David Wolfskill To: Adrian Chadd Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head Message-ID: <20150326111613.GJ7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mjUDp/cLGeqUhYyE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 11:16:16 -0000 --mjUDp/cLGeqUhYyE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2015 at 09:19:40PM -0700, Adrian Chadd wrote: > On 25 March 2015 at 19:21, David Wolfskill wrote: > > On Wed, Mar 25, 2015 at 06:17:48PM -0700, Adrian Chadd wrote: > >> Hi, > >> > >> I'm unfortunately too busy to really help you dig into it. > >> > >> I'd start by using tcpdump on wlan0 to see what's going on - see if > >> it's sending/receiving DHCP responses. > > > > Well, in head, it won't even associate, so I suspect that DHCP is a moot > > point. >=20 > Ok, sysctl dev.iwn.0.debug=3D0x1, wlandebug +scan, and then start wpa_sup= plicant. >=20 > It should be reasonably obvious what's going on - if it can't see APs > or it can't transmit anything successfully, then at least I know where > to begin looking when I have spare time. >=20 > I have a 5100 in my T400: >=20 > iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x12118086 chip=3D0x42378086 > rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'PRO/Wireless 5100 AGN [Shiloh] Network Connection' > class =3D network > ... Excellent! I should have a chance to try that while I'm building today's head, then -- probably about 30 minutes from now or so, depending on how long it takes to build & boot stable/10 & update the installed ports. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --mjUDp/cLGeqUhYyE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVE+p9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7IYMP/2qRG6qX9nZvEQqKGq0SFNFJ utP2tCW5LO3vC73dQUc+P8cu6IT1Rz7+p/TDszdT1voFcFbmQI1YpUfu+OWJcQar YKTxmftvTJXsG+kRI5A4Irj+CXjqBUAxbVGZ3UQouodThdnph+vQK03aJfx+AhNN clz9DMYUN4hUF6AwZSDEMz9ZOnRKHYUpJQqP5Vrl4mq35S5/onRo6NU5HY0MBSTy wn/8H+84oSbpSSClCqQGIy8rnprM1SQ/0LrRG5mKLZ6Gif/scQe4R2NcApwM3iZk 2n+u/E3oLpq1IuZmFdK/HqMZYY8gM6zmQZj7riYOMvSecmkqDADbJ3diXSeivfQt Gt3HHLGX00KFtZI2FYhCYiWnA8B25iTP9FHd6wPToFH3xMtPbi78Q+XxXnY7fUJK rlRMdGfMG3aGB0UE8h3CNAWlq9uOIdwZLP8mUUZufDH+lHaX2ifNBq0fCVjKKYvH KexnxeIgmeBxN7S4/sXz+ynIDJwMNqUgOt6MOQneoBOUIxYTNIpe5J/MmO7buvtH /g2cb6uEkBhzpsDDsIF7dWbnc73xxXILj/GFM2sKEgJK/6d/a6Wkz0QVLmdL60ET pEuvtfiQqBZxcL/hkLxScy170f95j+CqHfdd6R121NYH+gezpAeogYomjrW2yoeD DZLRmD1dFiIkAJW54uqx =VIlz -----END PGP SIGNATURE----- --mjUDp/cLGeqUhYyE-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 11:44:00 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07A5C25E; Thu, 26 Mar 2015 11:44:00 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AADFBA74; Thu, 26 Mar 2015 11:43:59 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2QBhwQO032782; Thu, 26 Mar 2015 04:43:58 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2QBhvjB032781; Thu, 26 Mar 2015 04:43:57 -0700 (PDT) (envelope-from david) Date: Thu, 26 Mar 2015 04:43:57 -0700 From: David Wolfskill To: Adrian Chadd Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head Message-ID: <20150326114357.GL7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t3tFFy74pA5/PEcJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 11:44:00 -0000 --t3tFFy74pA5/PEcJ Content-Type: multipart/mixed; boundary="smEuXhZLKnMjT4Ht" Content-Disposition: inline --smEuXhZLKnMjT4Ht Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2015 at 09:19:40PM -0700, Adrian Chadd wrote: > On 25 March 2015 at 19:21, David Wolfskill wrote: > > On Wed, Mar 25, 2015 at 06:17:48PM -0700, Adrian Chadd wrote: > >> Hi, > >> > >> I'm unfortunately too busy to really help you dig into it. > >> > >> I'd start by using tcpdump on wlan0 to see what's going on - see if > >> it's sending/receiving DHCP responses. > > > > Well, in head, it won't even associate, so I suspect that DHCP is a moot > > point. >=20 > Ok, sysctl dev.iwn.0.debug=3D0x1, wlandebug +scan, and then start wpa_sup= plicant. >=20 > It should be reasonably obvious what's going on - if it can't see APs > or it can't transmit anything successfully, then at least I know where > to begin looking when I have spare time. > .... Well, things didn't go quite to plan... and in the process of trying to debug the iwn0, the perverse bit of hardware managed to associate. I've attached a typescript for your (collective) amusement. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --smEuXhZLKnMjT4Ht Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="typescript.iwn" Content-Transfer-Encoding: quoted-printable Script started on Thu Mar 26 04:32:50 2015 root@g1-254:/tmp # pkill wpa_si=08=1B[Kupplicant=0D=0D root@g1-254:/tmp # service netif stop wlan0 iwn0=0D=0D wpa_supplicant not running? (check /var/run/wpa_supplicant/wlan0.pid).=0D Stopping Network: wlan0 iwn0.=0D ifconfig: interface wlan0 does not exist=0D iwn0: flags=3D8802 metric 0 mtu 2290=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D21=0D media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)=0D status: no carrier=0D root@g1-254:/tmp # sysctl dev.iwn.0=0D=0D dev.iwn.0.wake: 0=0D dev.iwn.0.%parent: pci3=0D dev.iwn.0.%pnpinfo: vendor=3D0x8086 device=3D0x4232 subvendor=3D0x8086 subd= evice=3D0x1321 class=3D0x028000=0D dev.iwn.0.%location: pci0:3:0:0 handle=3D\_SB_.PCI0.RP03.PXSX=0D dev.iwn.0.%driver: iwn=0D dev.iwn.0.%desc: Intel WiFi Link 5100=0D root@g1-254:/tmp # sysctl dev.iwn.0.debug=3D0x1=0D=0D sysctl: unknown oid 'dev.iwn.0.debug': No such file or directory=0D root@g1-254:/tmp # uname -a=0D=0D FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1549 r280= 520M/280523:1100066: Wed Mar 25 05:07:03 PDT 2015 root@g1-254.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386=0D root@g1-254:/tmp # wlandebug +scan=0D=0D wlandebug: sysctl-get(net.wlan.0.debug): No such file or directory=0D root@g1-254:/tmp # sysctl net.wlan.0=08=1B[K=08=1B[K=0D=0D net.wlan.mesh.maxholding: 2=0D net.wlan.mesh.maxretries: 2=0D net.wlan.mesh.backofftimeout: 5000=0D net.wlan.mesh.confirmtimeout: 40=0D net.wlan.mesh.holdingtimeout: 40=0D net.wlan.mesh.retrytimeout: 40=0D net.wlan.mesh.gateint: 10000=0D net.wlan.hwmp.inact: 5000=0D net.wlan.hwmp.rootconfint: 2000=0D net.wlan.hwmp.rannint: 1000=0D net.wlan.hwmp.rootint: 2000=0D net.wlan.hwmp.roottimeout: 5000=0D net.wlan.hwmp.net_diameter_traversal_time: 512=0D net.wlan.hwmp.maxpreq_retries: 3=0D net.wlan.hwmp.pathlifetime: 5000=0D net.wlan.hwmp.targetonly: 0=0D net.wlan.addba_maxtries: 3=0D net.wlan.addba_backoff: 10000=0D net.wlan.addba_timeout: 250=0D net.wlan.recv_bar: 1=0D net.wlan.ampdu_age: 500=0D net.wlan.debug: 0=0D net.wlan.cac_timeout: 60=0D net.wlan.nol_timeout: 1800=0D root@g1-254:/tmp # sysctl net.wlan=1B[15Dwlandebug +scan=1B[15Duname -a=1B[= K=1B[8Dsysctl dev.iwn.0.debug=3D0x1=1B[10D=1B[K=08=1B[K=08=1B[K | sort=0D=0D dev.iwn.%parent: =0D dev.iwn.0.%desc: Intel WiFi Link 5100=0D dev.iwn.0.%driver: iwn=0D dev.iwn.0.%location: pci0:3:0:0 handle=3D\_SB_.PCI0.RP03.PXSX=0D dev.iwn.0.%parent: pci3=0D dev.iwn.0.%pnpinfo: vendor=3D0x8086 device=3D0x4232 subvendor=3D0x8086 subd= evice=3D0x1321 class=3D0x028000=0D dev.iwn.0.wake: 0=0D root@g1-254:/tmp # sysctl dev.iwn | sort=1B[14Dnet.wlan=1B[K | sort=0D=0D net.wlan.addba_backoff: 10000=0D net.wlan.addba_maxtries: 3=0D net.wlan.addba_timeout: 250=0D net.wlan.ampdu_age: 500=0D net.wlan.cac_timeout: 60=0D net.wlan.debug: 0=0D net.wlan.hwmp.inact: 5000=0D net.wlan.hwmp.maxpreq_retries: 3=0D net.wlan.hwmp.net_diameter_traversal_time: 512=0D net.wlan.hwmp.pathlifetime: 5000=0D net.wlan.hwmp.rannint: 1000=0D net.wlan.hwmp.rootconfint: 2000=0D net.wlan.hwmp.rootint: 2000=0D net.wlan.hwmp.roottimeout: 5000=0D net.wlan.hwmp.targetonly: 0=0D net.wlan.mesh.backofftimeout: 5000=0D net.wlan.mesh.confirmtimeout: 40=0D net.wlan.mesh.gateint: 10000=0D net.wlan.mesh.holdingtimeout: 40=0D net.wlan.mesh.maxholding: 2=0D net.wlan.mesh.maxretries: 2=0D net.wlan.mesh.retrytimeout: 40=0D net.wlan.nol_timeout: 1800=0D net.wlan.recv_bar: 1=0D root@g1-254:/tmp # sysctl net.wlan.debug=3D1=0D=0D net.wlan.debug: 0 -> 1=0D root@g1-254:/tmp # wlandebug +scan=0D=0D wlandebug: sysctl-get(net.wlan.0.debug): No such file or directory=0D root@g1-254:/tmp # wlandebug +scan=1B[15Dsysctl net.wlan.debug=3D1=08=08=08= =08=08=08=08=1B[1@0=1B[1@.=0D=0D sysctl: unknown oid 'net.wlan.0.debug': No such file or directory=0D root@g1-254:/tmp # service netif start iwn0=0D=0D Starting wpa_supplicant.=0D Starting Network: iwn0.=0D iwn0: flags=3D8843 metric 0 mtu 229= 0=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D21=0D media: IEEE 802.11 Wireless Ethernet autoselect mode 11g=0D status: associated=0D root@g1-254:/tmp # ifconfig wlan0=0D=0D wlan0: flags=3D8843 metric 0 mtu 15= 00=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D29=0D media: IEEE 802.11 Wireless Ethernet MCS mode 11ng=0D status: associated=0D ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 04:18:d6:22:22:1f=0D country US authmode WPA2/802.11i privacy ON deftxkey UNDEF=0D AES-CCM 2:128-bit txpower 15 bmiss 10 scanvalid 60 bgscan=0D bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 64 protmode CTS=0D ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme=0D roaming MANUAL=0D groups: wlan =0D root@g1-254:/tmp # ^D=08=08exit=0D Script done on Thu Mar 26 04:41:05 2015 --smEuXhZLKnMjT4Ht-- --t3tFFy74pA5/PEcJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVE/D9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7IYkQAJU/CInuUSOM5LNfosav/R6v 8fGSAQsWxib6A4xpjCQecGIEcZBKhRvxLtWVmpmBita8/8fOw4R7CENIpWMhh4eY 8QGh3RHSIHXdozjGywArQpjIupYIVgioDYa9375WeX2SNQmB4BsYHLpfCqr1eOYo cQUqC/5QzEdpBP+YEvk0g80tijEIyuMdHIeGlHLdDHfJsvBqzR8QNKxdBaOQsV1b baShqX4Cg0RyUFi/zw5h1ADQZZmlV0Jqq2fAgyCYl08wO+PglFbY2tzE1aa5Xm0S 1EeWlrixQ0c2BoTcRW+WhHaFcbHT49lghYDYS0qj7xvrEkSsettWTtpC0gPV80gr PKMH5Q+F24nitE3X5+qWxqG56fhkD5Ap7WRVU/1Bw5dWjPHvQSi/PwWIxG4+yjEJ 7LDS8IDKrORpBrjQU/XkaQyYlAtlFsnXKPUgLUVjxEEnxIGu60jO6jI1CD6RuW+G Je2Vl/rvwRG18QIyEON0/Gz8EqRkV2tR8p45ue185RiSRtLemluNCW5m7aObxj4H O2tBRSGqWkLuRHIUm76w78bWNC5rj8htWG+tSdZj4CY65EK/R2yMayMwF9D71Zzb +RQ7qp/YLnv0y9B0nmBNbEHJVzX3cv0svqbHAr2wVNNkld5uQXFg265a+7SThV+4 Jv2+q8x+GD2xXHUmXR6i =LEOE -----END PGP SIGNATURE----- --t3tFFy74pA5/PEcJ-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 15:29:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEE95706 for ; Thu, 26 Mar 2015 15:29:37 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F39B9D8 for ; Thu, 26 Mar 2015 15:29:37 +0000 (UTC) Received: by igcxg11 with SMTP id xg11so57068752igc.0 for ; Thu, 26 Mar 2015 08:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3Nld+J/WHp4f9Um1cK7eUPBpNGbTqs59Q7htLRPF330=; b=OoW/0CdR5X10n7qUTsLu5bjZaQKAZabQH/u3BX25Ns3Abvu6XOUVj5Vrhf7kDERIy8 V205r0xusE3Hff+6JKq7k4OaELu+j59zMQslR+Zp80lnN0hYuoOzhHtFCDqIY981Ixln fXSi4RMdW2sl2hTh0YbbkVc481g+XiLrWzfhzAgEzI0HoiKG/vpy6H9JcAXztzXr0VGE LWx7PSO4nKsRvUtNE6SKMQsx9jUkQDognsDqQ1ZDXZyxyy456460HG1QwPiDZv4zGFwd TDRkgtm0qIIBohjk5ZdH9RUfFMAJ6Qfd1hV/2TCfyoCk5sMo8oqLNzarj6sbqudK9uU0 vcjQ== X-Received: by 10.107.8.67 with SMTP id 64mr21308070ioi.61.1427383776861; Thu, 26 Mar 2015 08:29:36 -0700 (PDT) Received: from [10.10.1.5] ([192.252.130.194]) by mx.google.com with ESMTPSA id w3sm11995851igz.4.2015.03.26.08.29.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 08:29:36 -0700 (PDT) Message-ID: <551425DA.3000205@gmail.com> Date: Thu, 26 Mar 2015 11:29:30 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Another fragment question / patch References: <550C3A62.3080403@gmail.com> <550C5F6C.3080302@selasky.org> <550C7D0C.3090603@gmail.com> <550D3675.5030900@selasky.org> <551017D1.60008@gmail.com> In-Reply-To: <551017D1.60008@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 15:29:37 -0000 FYI: I've created a bug report for this. Thanks. On 2015-03-23 9:40 AM, Karim Fodil-Lemelin wrote: > On 2015-03-21 5:14 AM, Hans Petter Selasky wrote: >> On 03/20/15 21:03, Karim Fodil-Lemelin wrote: >>> On 2015-03-20 1:57 PM, Hans Petter Selasky wrote: >>>> On 03/20/15 16:18, Karim Fodil-Lemelin wrote: >>>>> Hi, >>>>> >>>>> While reading through a previous comment on this list about fragments >>>>> I've noticed that mbuf tags aren't being copied from the leading >>>>> fragment (header) to the subsequent fragment packets. In other words, >>>>> one would expect that all fragments of a packet are carrying the same >>>>> tags that were set on the original packet. I have built a simple test >>>>> were I use ipfw with ALTQ and sent large packet (bigger then MTU) off >>>>> that BSD machine. I have observed that the leading fragment (m0) >>>>> packet >>>>> is going through the right class although the next fragments are >>>>> hitting >>>>> the default class for unclassified packets. >>>>> >>>>> Here is a patch that makes things works as expected (all fragments >>>>> carry >>>>> the ALTQ tag): >>>>> >>>>> diff --git a/freebsd/sys/netinet/ip_output.c >>>>> b/freebsd/sys/netinet/ip_output.c >>>>> index d650949..7d8f041 100644 >>>>> --- a/freebsd/sys/netinet/ip_output.c >>>>> +++ b/freebsd/sys/netinet/ip_output.c >>>>> @@ -1184,7 +1184,10 @@ smart_frag_failure: >>>>> ipstat.ips_odropped++; >>>>> goto done; >>>>> } >>>>> - m->m_flags |= (m0->m_flags & M_MCAST) | M_FRAG; >>>>> + >>>>> + m->m_flags |= (m0->m_flags & M_COPYFLAGS) | M_FRAG; >>>>> + m_tag_copy_chain(m, m0, M_NOWAIT); >>>>> + >>>>> /* >>>>> * In the first mbuf, leave room for the link >>>>> header, then >>>>> * copy the original IP header including options. >>>>> The >>>>> payload >>>>> diff --git a/freebsd/sys/sys/mbuf.h b/freebsd/sys/sys/mbuf.h >>>>> index 2efff38..6ad8439 100644 >>>>> --- a/freebsd/sys/sys/mbuf.h >>>>> >>>> >>>> Hi, >>>> >>>> I see your point about copying the tags. I'm not sure however that >>>> M_COPYFLAGS is correct, because it also copies M_RDONLY, which is not >>>> relevant for this case. Can you explain what flags need copying in >>>> addition to M_MCAST ? Maybe we need to define these flags separately. >>>> >>>> Thank you! >>>> >>>> --HPS >>> Hi, >>> >>> Arguably the M_RDONLY is added when m_copy() is called a bit later in >>> that function. m_copym() does a shallow copy (through a call to >>> mb_dupcl) and will set the RDONLY flag when doing so. So the fact it >>> was >>> copied over from M_COPYFLAGS shouldn't be a problem in terms of >>> functionality. A similar logic applies to the M_VLANTAG since it should >>> never be set in ip_output() (severe layer violation). I guess >>> M_COPYFLAGS is kinda safe but not necessarily correct. >>> >>> In terms of appropriate behavior (whats the real purpose of >>> M_COPYFLAGS?) my initial patch is debatable and to answer your question >>> I would consider to copy the remaining flags: >>> >>> M_PKTHDR => already in there through the m_gethdr() call >>> M_BCAST => no need to copy >>> M_MCAST => already in there in ip_fragment() >>> M_PROTOFLAGS >>> M_SKIP_FIREWALL => for layer 2 fire-walling? >>> >>> So something like? >>> >>> - m->m_flags |= (m0->m_flags & M_MCAST); >>> + m->m_flags |= (m0->m_flags & (M_MCAST | M_PROTOFLAGS)); >>> + m_tag_copy_chain(m, m0, M_NOWAIT); >>> >> >> Hi, >> >> Could you have a look at the attached patch, test and give some >> comments? I believe the right thing to do in this case is to use the >> copy packet header function. >> >> --HPS >> > Hi, > > Your patch seems to work as well as mine, albeit completely swinging > the other way now since your copying a lot more from the packet header > with the call to m_dup_pkthdr() (including the M_COPYFLAGS, vlan tags, > etc..). > > I think this is fine, one would expect IP fragments to be somewhat > very close to the original packet. > > Thanks, > > Karim. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 15:33:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44BFD859 for ; Thu, 26 Mar 2015 15:33:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21E26AC4 for ; Thu, 26 Mar 2015 15:33:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2QFXQRU058574 for ; Thu, 26 Mar 2015 15:33:26 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2QFXQh6058573; Thu, 26 Mar 2015 15:33:26 GMT (envelope-from root) Date: Thu, 26 Mar 2015 15:33:26 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1944: PF and VIMAGE fixes Message-ID: <3857b78419f229e1a9d3b2ad8981fc1a@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFUUJsY= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 15:33:27 -0000 rodrigc added a reviewer: kristof. REVISION DETAIL https://reviews.freebsd.org/D1944 To: nvass-gmx.com, gnn, bz, zec, trociny, glebius, rodrigc, kristof Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 16:41:55 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B66F717F for ; Thu, 26 Mar 2015 16:41:55 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BB7B5EF for ; Thu, 26 Mar 2015 16:41:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2QGftcj068986 for ; Thu, 26 Mar 2015 16:41:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 188897] [dc] dc ethernet driver seems to prevent the detection of other NIC chipsets Date: Thu, 26 Mar 2015 16:41:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: clif@eugeneweb.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 16:41:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188897 clif@eugeneweb.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People --- Comment #10 from clif@eugeneweb.com --- I just upgraded the BIOS in my two atom boards and I noticed that the upgrade program would list one bit of info which was differnent between them. Not sure it's useful but the D945GSEJT works fine with quadport cards and the D510MO is broken under FreeBSD. The Port Mapper table on the D945GSEJT (BIOS JT94510H.86A) is at F000:B350 and on the D510MO (BIOS MOPNV10N.86A) its at F000:BDD0 hope that helps, Clif -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 16:44:11 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A801237 for ; Thu, 26 Mar 2015 16:44:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3D1960B for ; Thu, 26 Mar 2015 16:44:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2QGiAcd070581 for ; Thu, 26 Mar 2015 16:44:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 188899] [cas] cas ethernet driver seems to have issues with some multiport card and mother board combinations Date: Thu, 26 Mar 2015 16:44:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: clif@eugeneweb.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 16:44:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188899 clif@eugeneweb.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People --- Comment #4 from clif@eugeneweb.com --- Hey Gavin, Did you find a card yet? I could ship you one if needed. I just upgraded the BIOS in my two atom boards and I noticed that the upgrade program would list one bit of info which was differnent between them. Not sure it's useful but the D945GSEJT works fine with quadport cards and the D510MO is broken under FreeBSD. The Port Mapper table on the D945GSEJT (BIOS JT94510H.86A) is at F000:B350 and on the D510MO (BIOS MOPNV10N.86A) its at F000:BDD0 hope that helps, Clif -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 17:46:47 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 156CB9BC for ; Thu, 26 Mar 2015 17:46:47 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC82AE53 for ; Thu, 26 Mar 2015 17:46:46 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so58924446ied.1 for ; Thu, 26 Mar 2015 10:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0QJp9Adkps5pPpUUHvkCut1RDazdlZ3bFmrZCGVy1I4=; b=noHoeOz9B5QC92zr2qBKS0tveTFgRRpKW9ukH0tk7bsv9jGoxKV4PbwzLycw4Bv3X6 ebxXN8v0cVoOR2lhv+AJFiAiolWI0xUT7duSkM6h/GoHj/Mn8avGRTZfoSnH+UHcFEVK w2YS6tHpxcf3wLAwLMiHi8EPpz6j5I6wAEtm3AAucqjVkZe5YN6cUbpEUQco+kk1ZIwN 2c5/DqRaoH5skyoSzWAOYhX57BiYquFPEKWZZ/nolnFcP3gdP7MB/1nHztNj62KvyH3d UoGO15lTr7CBsoRSGbqeEbx+kEjWDDtVozrcXe2lbgVOwMwdWzCLavcO3sjGgiAoA6vr JAMg== MIME-Version: 1.0 X-Received: by 10.50.143.42 with SMTP id sb10mr38478092igb.49.1427392006258; Thu, 26 Mar 2015 10:46:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Thu, 26 Mar 2015 10:46:46 -0700 (PDT) In-Reply-To: <20150326114357.GL7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> <20150326114357.GL7594@albert.catwhisker.org> Date: Thu, 26 Mar 2015 10:46:46 -0700 X-Google-Sender-Auth: CMF2pQjVrzcSSGucxicZP_dvPPc Message-ID: Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head From: Adrian Chadd To: David Wolfskill Content-Type: text/plain; charset=UTF-8 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 17:46:47 -0000 Yup, recompile with IWN_DEBUG and IEEE80211_DEBUG :) Then those debug bits will work. -adrian On 26 March 2015 at 04:43, David Wolfskill wrote: > On Wed, Mar 25, 2015 at 09:19:40PM -0700, Adrian Chadd wrote: >> On 25 March 2015 at 19:21, David Wolfskill wrote: >> > On Wed, Mar 25, 2015 at 06:17:48PM -0700, Adrian Chadd wrote: >> >> Hi, >> >> >> >> I'm unfortunately too busy to really help you dig into it. >> >> >> >> I'd start by using tcpdump on wlan0 to see what's going on - see if >> >> it's sending/receiving DHCP responses. >> > >> > Well, in head, it won't even associate, so I suspect that DHCP is a moot >> > point. >> >> Ok, sysctl dev.iwn.0.debug=0x1, wlandebug +scan, and then start wpa_supplicant. >> >> It should be reasonably obvious what's going on - if it can't see APs >> or it can't transmit anything successfully, then at least I know where >> to begin looking when I have spare time. >> .... > > Well, things didn't go quite to plan... and in the process of trying to > debug the iwn0, the perverse bit of hardware managed to associate. > > I've attached a typescript for your (collective) amusement. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Those who murder in the name of God or prophet are blasphemous cowards. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 18:56:57 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D84D7D7; Thu, 26 Mar 2015 18:56:57 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 17DEC3676; Thu, 26 Mar 2015 18:56:55 +0000 (UTC) Message-ID: <5514560C.5070406@FreeBSD.org> Date: Thu, 26 Mar 2015 21:55:08 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: hiren panchasara , freebsd-net@freebsd.org Subject: Re: pagefault in IPv6 codepath in defrouter_select() References: <20150325214832.GI53237@strugglingcoder.info> In-Reply-To: <20150325214832.GI53237@strugglingcoder.info> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Xij7XOAS6forwNWoSA7fJ6JoFJMLtsI9h" Cc: hrs@freebsd.org, nitroboost@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 18:56:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xij7XOAS6forwNWoSA7fJ6JoFJMLtsI9h Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 26.03.2015 00:48, hiren panchasara wrote: > This is 3rd occurence of this panic. What could be the cause? > I have vmcore and can provide more info if needed. Hi, the problem is that ND6 code maintains at least two lists of prefixes without any locking: V_nd_defrouter and V_nd_prefix. --=20 WBR, Andrey V. Elsukov --Xij7XOAS6forwNWoSA7fJ6JoFJMLtsI9h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVFFYNAAoJEAHF6gQQyKF6BO0IALUTi9gC9oHUwKFUvPq9EQqV tN22BhLVMf733wihsmcjmA2OdRBkaOdXNP3xnJtymUfjOiqlgVn0MFItsWcowFIQ oecK1axsmFrWq1niN7P2Xc2AyigyFC5fUZS0+Dy05oXI14D+Mtp+p8Nis2U25pCQ wOwo4zWvZEE9rWHZVY77LdQ7N4Zh1PMY0BpwP4WYZHPV9SKhdX433Whwoj7+xcMH fbA2WMW4a6FuB9Z7kJwfJ6YLh7HDG0w0T0tAQjSC4/06DPnn1WbEypwKBBEwBRk0 XnZImYHETtK7u0MtVpweBYBQmrnwWfyOof5IQg2VNEqIT0P4ZFl71Nk4cdx/fjU= =aXGu -----END PGP SIGNATURE----- --Xij7XOAS6forwNWoSA7fJ6JoFJMLtsI9h-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 19:03:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CF0E9E5; Thu, 26 Mar 2015 19:03:06 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1817C9E8; Thu, 26 Mar 2015 19:03:05 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 54743109BAC; Thu, 26 Mar 2015 12:03:04 -0700 (PDT) Date: Thu, 26 Mar 2015 12:03:04 -0700 From: hiren panchasara To: "Andrey V. Elsukov" Message-ID: <20150326190304.GK53237@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PoUpPrJlcBv0qM6G" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, hrs@freebsd.org, nitroboost@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 19:03:06 -0000 --PoUpPrJlcBv0qM6G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable markj@freebsd.org Bcc:=20 Subject: Re: pagefault in IPv6 codepath in defrouter_select() Reply-To:=20 In-Reply-To: <5514560C.5070406@FreeBSD.org> On 03/26/15 at 09:55P, Andrey V. Elsukov wrote: > On 26.03.2015 00:48, hiren panchasara wrote: > > This is 3rd occurence of this panic. What could be the cause? > > I have vmcore and can provide more info if needed. >=20 > Hi, >=20 > the problem is that ND6 code maintains at least two lists of prefixes > without any locking: V_nd_defrouter and V_nd_prefix. I am not too familiar with the code here but is following relevant here? https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034695.html Also ccing markj@ Cheers, Hiren --PoUpPrJlcBv0qM6G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVFFfnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lErkH/RG309Y3ZOxD6uUxKe1IT6CS SsmPmk/bBRPNKnuLQRkir6/KuHQzCsfI7QxVMNxvF+9tyTF31CaRTllusBMcb22Q VnGtuLRNmxxwpRP6nEiUvspA6yebynp7LtXHFduS0nEyfGTepvib67QcU88I5hxd ZRomSTg7tDcRrlT//tvRwIUVkuXBDBuNb3heyX7o0+O02A8TII57POGKeaKsdRD+ 4s7TniYOL5lZmUmFUtA7Z4eXeFrTumTfl/emich6kaXS/WWzNIMSp2DuWATxKawK 1mrx1AYrDqw1tmb7g60SMybqOaEN4WKXBiafQoMvzCWWE1ec4P4Lbamwv4ZmCJo= =V6QU -----END PGP SIGNATURE----- --PoUpPrJlcBv0qM6G-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 19:08:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2E52AF6; Thu, 26 Mar 2015 19:08:59 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B11EA1C; Thu, 26 Mar 2015 19:08:59 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id E71AA109C38; Thu, 26 Mar 2015 12:08:58 -0700 (PDT) Date: Thu, 26 Mar 2015 12:08:58 -0700 From: hiren panchasara To: "Andrey V. Elsukov" Subject: Re: pagefault in IPv6 codepath in defrouter_select() Message-ID: <20150326190858.GL53237@strugglingcoder.info> References: <20150325214832.GI53237@strugglingcoder.info> <5514560C.5070406@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CeC2K4acttR/mmFn" Content-Disposition: inline In-Reply-To: <5514560C.5070406@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, hrs@freebsd.org, nitroboost@gmail.com, markj@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 19:08:59 -0000 --CeC2K4acttR/mmFn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My mailclient is doing something funny. Sorry for that. Trying again to reply to this tread actually. On 03/26/15 at 09:55P, Andrey V. Elsukov wrote: > On 26.03.2015 00:48, hiren panchasara wrote: > > This is 3rd occurence of this panic. What could be the cause? > > I have vmcore and can provide more info if needed. >=20 > Hi, >=20 > the problem is that ND6 code maintains at least two lists of prefixes > without any locking: V_nd_defrouter and V_nd_prefix. I am not too familiar with the code here but is following relevant here? https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034695.html Also ccing markj@ Cheers, Hiren --CeC2K4acttR/mmFn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVFFlKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lo/4H/3xht6rX+NA4XHnw3P9eQnmT S8AYEg2nRk4d6IJOcis+6+z3FI1s5XyQwVtWRQjN8pVN7VaO9EUZ48+iEYGXuPW7 0QpywGskMdM1+jLGcAH/GaahqP7a8NUQi64tdhakrn0hv782Z2+mG7JBiZqbaWV7 FO2+8U4FzlT7KBxlVaoJ3xCKnU0mLkAQKonJzIkNfjQO5dOMnythnfgPEMj+GgJ/ UVQMRU+v+Rw8WBmdirietRVbHem6l9ec/qoR5zYgoNtPwLVCUEYWcnRqtl7ihLgD yvu0Qzoj46W5tVVt9Bf71zGGvTjKMgUkQaudA1CaJk/db9IoIdsswEX/pWAGiaE= =n/BY -----END PGP SIGNATURE----- --CeC2K4acttR/mmFn-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 20:08:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95F0EEAD; Thu, 26 Mar 2015 20:08:54 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EED4129; Thu, 26 Mar 2015 20:08:54 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id B87EECF218; Thu, 26 Mar 2015 13:08:53 -0700 (PDT) Date: Thu, 26 Mar 2015 13:08:53 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Subject: em(4): difference between missed_packets and rx_overrun Message-ID: <20150326200853.GA19536@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: nitroboost@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 20:08:54 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is what we are seeing on em(4) 82574L chipset running stable/10: dev.em.0.mac_stats.missed_packets: 1441927 dev.em.0.interrupts.rx_overrun: 153 =46rom the datasheet: http://www.intel.com/content/www/us/en/ethernet-controllers/82574l-gbe-cont= roller-datasheet.html 10.2.7.4 Missed Packets Count - MPC (0x04010; R) Counts the number of missed packets. Packets are missed when the receive FIFO has insufficient space to store the incoming packet. This could be caused because of too few buffers allocated, or because there is insufficient bandwidth on the IO bus. Events setting this counter cause RXO, the receiver overrun interrupt, to be set. This register does not increment if receives are not enabled. 10.2.4.1 Interrupt Cause Read Register - ICR (0x000C0; RC/WC) RXO Receiver Overrun Set on receive data FIFO overrun. Could be caused either because there are no available buffers or because PCIe receive bandwidth is inadequate. So, first one is a count and another one is an interrupt. Are these 2 related? Both seem to be happen when on card FIFO gets full. We see no evidence of RX queue on the host being full based on dev.em.0.mac_stats.recv_no_buff. Many a times we see missed_packets increasing without rx_overrun changing. The spec says there is a 40KB buffer on card which seems to be used by both RX and TX? Is is split between them for 20KB each? OR is it possible that when we are doing high rate TX, we use up that buffer and RX suffers from that? Any insights would be helpful to understand the problem. Cheers, Hiren --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVFGdUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l8QoH/3xKvDx9inKcwiPW1authYpw P/o7TCALanXNp2RyRjSdLnKr1EU4Kv6Twh1qlSun3N9JuxQbVdRCJiF6bAKsdeMm uvWXFOIOCy1rBbctiVvXUXgPMIEOhywNr7nbdEILV/dFpBMkhGxr9bZPtE7j88cK 0sX6sO8HLE1b94s/SufMMr/cvJr4m3GbNlSxcq2NjUUKafXJohmVaXfJcp9nXRPz 148FUCvLL5/DbatzOyg1UQOXItOk2QghIouNcRhd0ls7yTU4BjGDL2z/c/dFOvfM OV+7jl398uy1k6XnsGDX+TmGunajtIHCPQz4gwV5CJQ0Qq/UqrPs0neBPebUGXo= =09Jg -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 26 21:24:35 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A593CF0 for ; Thu, 26 Mar 2015 21:24:35 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3F8EC62 for ; Thu, 26 Mar 2015 21:24:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2QLOYpT054592 for ; Thu, 26 Mar 2015 21:24:34 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2QLOYib054591; Thu, 26 Mar 2015 21:24:34 GMT (envelope-from root) Date: Thu, 26 Mar 2015 21:24:34 +0000 To: freebsd-net@freebsd.org From: "kristof (Kristof Provost)" Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFUUeRI= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Mar 2015 21:24:35 -0000 kristof added inline comments. INLINE COMMENTS sys/netpfil/pf/pf_ioctl.c:325 It's not clear to me why this is done here, rather than in pf_unload(). The initialisation is done in pf_load() after all. sys/netpfil/pf/pf_ioctl.c:3725 Don't we still need to do all of this somewhere? REVISION DETAIL https://reviews.freebsd.org/D1944 To: nvass-gmx.com, gnn, bz, zec, trociny, glebius, rodrigc, kristof Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 00:05:30 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF6ECAE3; Fri, 27 Mar 2015 00:05:30 +0000 (UTC) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CED7FB9; Fri, 27 Mar 2015 00:05:30 +0000 (UTC) Received: by gddsn.org.cn (Postfix, from userid 65534) id E4CD02E087; Fri, 27 Mar 2015 08:05:27 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gddsn.org.cn X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lp.gddsn.org.cn (unknown [10.44.8.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPSA id B1EC92E035; Fri, 27 Mar 2015 08:05:07 +0800 (CST) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: SSH hung with an OpenSSH_6.6.1p1 --> OpenSSH_5.8p2_hpn13v11 From: =?gb2312?B?zuLK5cCk?= In-Reply-To: <5513DB89.2050801@sentex.net> Date: Fri, 27 Mar 2015 08:05:06 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <108DC3D1-8B34-4221-B6ED-8700BAF08D2C@gddsn.org.cn> References: <5513AAD8.9060505@gddsn.org.cn> <5513DB89.2050801@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Fri, 27 Mar 2015 00:08:14 +0000 Cc: stable@freebsd.org, questions@freebsd.org, current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 00:05:31 -0000 all set are in base. and I=A1=AFm using 10.1-RELEASE-p8 BTW > =D4=DA 2015=C4=EA3=D4=C226=C8=D5=A3=AC=CF=C2=CE=E76:12=A3=ACMike = Tancsa =D0=B4=B5=C0=A3=BA >=20 > On 3/26/2015 2:44 AM, Wu ShuKun wrote: >=20 >> OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 >> failed with Latest SSH: >> % ssh -V >> OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 >=20 > Hi, > The latest is 1.0.1m, no? >=20 > }# ssh -V > OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 >=20 > What version of FreeBSD are you using ? Ssh and Openssl from the = ports ? or in the base ? >=20 > ---Mike >=20 > --=20 > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 02:31:13 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3FEA71D; Fri, 27 Mar 2015 02:31:13 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62B83FD0; Fri, 27 Mar 2015 02:31:12 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2R2VBdx037671; Thu, 26 Mar 2015 19:31:11 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2R2VBYQ037670; Thu, 26 Mar 2015 19:31:11 -0700 (PDT) (envelope-from david) Date: Thu, 26 Mar 2015 19:31:11 -0700 From: David Wolfskill To: Adrian Chadd Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head Message-ID: <20150327023111.GB7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j4ivd53YxxNwCQqF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 02:31:14 -0000 --j4ivd53YxxNwCQqF Content-Type: multipart/mixed; boundary="3m6ZAtymzEdXvUYk" Content-Disposition: inline --3m6ZAtymzEdXvUYk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2015 at 09:19:40PM -0700, Adrian Chadd wrote: > On 25 March 2015 at 19:21, David Wolfskill wrote: > > On Wed, Mar 25, 2015 at 06:17:48PM -0700, Adrian Chadd wrote: > >> Hi, > >> > >> I'm unfortunately too busy to really help you dig into it. > >> > >> I'd start by using tcpdump on wlan0 to see what's going on - see if > >> it's sending/receiving DHCP responses. > > > > Well, in head, it won't even associate, so I suspect that DHCP is a moot > > point. >=20 > Ok, sysctl dev.iwn.0.debug=3D0x1, wlandebug +scan, and then start wpa_sup= plicant. >=20 > It should be reasonably obvious what's going on - if it can't see APs > or it can't transmit anything successfully, then at least I know where > to begin looking when I have spare time. >=20 > I have a 5100 in my T400: >=20 > iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x12118086 chip=3D0x42378086 > rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'PRO/Wireless 5100 AGN [Shiloh] Network Connection' > class =3D network >=20 > .... Mine looks like: iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x13218086 chip=3D0x4232808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'WiFi Link 5100' class =3D network I augmented /etc/src.conf: g1-254(11.0-C)[8] cat /etc/src.conf=20 KERNCONF=3DCANARY PORTS_MODULES=3Dx11/nvidia-driver WITHOUT_DEBUG_FILES=3D1 IWN_DEBUG=3D1 IEEE80211_DEBUG=3D1 g1-254(11.0-C)[9]=20 then re-built head: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1551 r280= 680M/280683:1100067: Thu Mar 26 19:11:52 PDT 2015 root@g1-254.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 I've attached the typescript (as before, but with a bit more success), as well as a chunk of /var/log/messages that covers the period that the typescript does. Once again, though, it associated when I manually ran "service netif start iwn0". Weird. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --3m6ZAtymzEdXvUYk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="typescript.iwn" Content-Transfer-Encoding: quoted-printable Script started on Thu Mar 26 19:18:38 2015 root@g1-254:/tmp # ifc=08=1B[K=08=1B[K=08=1B[K=07uname -a=0D=0D FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1551 r280= 680M/280683:1100067: Thu Mar 26 19:11:52 PDT 2015 root@g1-254.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386=0D root@g1-254:/tmp # ifconfig wlan0=0D=0D wlan0: flags=3D8843 metric 0 mtu 15= 00=0D ether 34:e6:d7:3c:4a:93=0D nd6 options=3D29=0D media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)=0D status: no carrier=0D ssid "" channel 11 (2462 MHz 11g)=0D country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF=0D txpower 15 bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle = 250=0D roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL=0D groups: wlan =0D root@g1-254:/tmp # ic=08=1B[Kfconfig iwn0=0D=0D iwn0: flags=3D8843 metric 0 mtu 229= 0=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D21=0D media: IEEE 802.11 Wireless Ethernet autoselect mode 11g=0D status: associated=0D root@g1-254:/tmp # echo "WiFi LED is blinking"=0D=0D WiFi LED is blinking=0D root@g1-254:/tmp # pkill wpa_supplicant=0D=0D root@g1-254:/tmp # ifconfig wlan0=0D=0D wlan0: flags=3D8802 metric 0 mtu 1500=0D ether 34:e6:d7:3c:4a:93=0D nd6 options=3D29=0D media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)=0D status: no carrier=0D ssid "" channel 149 (5745 MHz 11a ht/40+)=0D country US authmode WPA2/802.11i privacy OFF txpower 15 bmiss 10=0D mcastrate 6 mgmtrate 6 scanvalid 60 bgscan bgscanintvl 300=0D bgscanidle 250 roam:rssi 7 roam:rate 64 ampdulimit 8k -amsdutx amsd= urx=0D shortgi wme=0D groups: wlan =0D root@g1-254:/tmp # ifconfig iwn0=0D=0D iwn0: flags=3D8802 metric 0 mtu 2290=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D21=0D media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)=0D status: no carrier=0D root@g1-254:/tmp # echo "WiFiLED is dark"=0D=0D WiFiLED is dark=0D root@g1-254:/tmp # sysctl dev.ien =08=08=1B[K=08=1B[Ke=08=1B[Kwn net.wlan |= sort=0D=0D dev.iwn.%parent: =0D dev.iwn.0.%desc: Intel WiFi Link 5100=0D dev.iwn.0.%driver: iwn=0D dev.iwn.0.%location: pci0:3:0:0 handle=3D\_SB_.PCI0.RP03.PXSX=0D dev.iwn.0.%parent: pci3=0D dev.iwn.0.%pnpinfo: vendor=3D0x8086 device=3D0x4232 subvendor=3D0x8086 subd= evice=3D0x1321 class=3D0x028000=0D dev.iwn.0.wake: 0=0D net.wlan.0.%parent: iwn0=0D net.wlan.0.ampdu_mintraffic_be: 64=0D net.wlan.0.ampdu_mintraffic_bk: 128=0D net.wlan.0.ampdu_mintraffic_vi: 32=0D net.wlan.0.ampdu_mintraffic_vo: 32=0D net.wlan.0.amrr_max_sucess_threshold: 15=0D net.wlan.0.amrr_min_sucess_threshold: 1=0D net.wlan.0.amrr_rate_interval: 500=0D net.wlan.0.bmiss_max: 2=0D net.wlan.0.debug: 0=0D net.wlan.0.driver_caps: 629203457=0D net.wlan.0.inact_auth: 180=0D net.wlan.0.inact_init: 30=0D net.wlan.0.inact_probe: 30=0D net.wlan.0.inact_run: 300=0D net.wlan.addba_backoff: 10000=0D net.wlan.addba_maxtries: 3=0D net.wlan.addba_timeout: 250=0D net.wlan.ampdu_age: 500=0D net.wlan.cac_timeout: 60=0D net.wlan.debug: 0=0D net.wlan.hwmp.inact: 5000=0D net.wlan.hwmp.maxpreq_retries: 3=0D net.wlan.hwmp.net_diameter_traversal_time: 512=0D net.wlan.hwmp.pathlifetime: 5000=0D net.wlan.hwmp.rannint: 1000=0D net.wlan.hwmp.rootconfint: 2000=0D net.wlan.hwmp.rootint: 2000=0D net.wlan.hwmp.roottimeout: 5000=0D net.wlan.hwmp.targetonly: 0=0D net.wlan.mesh.backofftimeout: 5000=0D net.wlan.mesh.confirmtimeout: 40=0D net.wlan.mesh.gateint: 10000=0D net.wlan.mesh.holdingtimeout: 40=0D net.wlan.mesh.maxholding: 2=0D net.wlan.mesh.maxretries: 2=0D net.wlan.mesh.retrytimeout: 40=0D net.wlan.nol_timeout: 1800=0D net.wlan.recv_bar: 1=0D root@g1-254:/tmp # sysctl dev.iwn.0.debug=3D0x1=0D=0D sysctl: unknown oid 'dev.iwn.0.debug': No such file or directory=0D root@g1-254:/tmp # sysctl net.wlan.0.debug=3D1=0D=0D net.wlan.0.debug: 0 -> 1=0D root@g1-254:/tmp # wlandebug +scan=0D=0D net.wlan.0.debug: 0x1 =3D> 0x200001=0D root@g1-254:/tmp # service netif stop wlan0 iwn0=0D=0D wpa_supplicant not running? (check /var/run/wpa_supplicant/wlan0.pid).=0D Stopping Network: wlan0 iwn0.=0D ifconfig: interface wlan0 does not exist=0D iwn0: flags=3D8802 metric 0 mtu 2290=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D21=0D media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)=0D status: no carrier=0D root@g1-254:/tmp # service netif start iwn0=0D=0D Starting wpa_supplicant.=0D Starting Network: iwn0.=0D iwn0: flags=3D8843 metric 0 mtu 229= 0=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D21=0D media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)=0D status: no carrier=0D root@g1-254:/tmp # ifconfig iwn0=0D=0D iwn0: flags=3D8843 metric 0 mtu 229= 0=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D21=0D media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng=0D status: associated=0D root@g1-254:/tmp # ifconfig wlan0=0D=0D wlan0: flags=3D8843 metric 0 mtu 15= 00=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D29=0D media: IEEE 802.11 Wireless Ethernet MCS mode 11ng=0D status: associated=0D ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 04:18:d6:22:22:= 1f=0D country US authmode WPA2/802.11i privacy ON deftxkey UNDEF=0D AES-CCM 2:128-bit txpower 15 bmiss 10 scanvalid 60 bgscan=0D bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 64 protmode CT= S=0D ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme=0D roaming MANUAL=0D groups: wlan =0D root@g1-254:/tmp # ifconfig -v wlan0=0D=0D wlan0: flags=3D8843 metric 0 mtu 15= 00=0D ether 00:24:e8:b5:85:46=0D nd6 options=3D29=0D media: IEEE 802.11 Wireless Ethernet MCS mode 11ng=0D status: associated=0D ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 04:18:d6:22:22:= 1f=0D regdomain 0 country US anywhere -ecm authmode WPA2/802.11i -wps -ts= n=0D privacy ON deftxkey UNDEF=0D AES-CCM 2:128-bit powersavemode OFF powersavesleep 100 txpower 15=0D txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 10=0D 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6=0D 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6=0D 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6=0D turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6=0D turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6=0D sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6=0D 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6=0D 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6=0D half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6=0D quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6=0D scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250=0D roam:11a rssi 7dBm rate 12 Mb/s=0D roam:11b rssi 7dBm rate 1 Mb/s=0D roam:11g rssi 7dBm rate 5 Mb/s=0D roam:turboA rssi 7dBm rate 12 Mb/s=0D roam:turboG rssi 7dBm rate 12 Mb/s=0D roam:sturbo rssi 7dBm rate 12 Mb/s=0D roam:11na rssi 7dBm MCS 1 =0D roam:11ng rssi 7dBm MCS 1 =0D roam:half rssi 7dBm rate 6 Mb/s=0D roam:quarter rssi 7dBm rate 3 Mb/s=0D -pureg protmode CTS ht htcompat ampdu ampdulimit 64k ampdudensity 8= =0D -amsdutx amsdurx shortgi htprotmode RTSCTS -puren -smps -rifs wme=0D -burst -dwds roaming MANUAL bintval 100=0D AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack=0D cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm=0D AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack=0D cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm=0D AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack=0D cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm=0D AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack=0D cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm=0D groups: wlan =0D root@g1-254:/tmp # ^D=08=08exit=0D Script done on Thu Mar 26 19:23:37 2015 --3m6ZAtymzEdXvUYk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=messages Content-Transfer-Encoding: quoted-printable Mar 26 19:17:38 kernel: ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsargu= ments-97) Mar 26 19:17:38 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:17:38 kernel: acquiring duplicate lock of same type: "os.lock_mt= x" Mar 26 19:17:38 kernel: 1st os.lock_mtx @ nvidia_os.c:783 Mar 26 19:17:38 kernel: 2nd os.lock_mtx @ nvidia_os.c:783 Mar 26 19:17:38 kernel: KDB: stack backtrace: Mar 26 19:17:38 kernel: db_trace_self_wrapper(c1129408,eaf21c90,0,c14dace8= ,c14dacb8,...) at 0xc0531bca =3D db_trace_self_wrapper+0x2a/frame 0xf9e57488 Mar 26 19:17:38 kernel: kdb_backtrace(c112d361,c1e37fb1,c1e37f69,30f,cf002= 2b8,...) at 0xc0b5e2ed =3D kdb_backtrace+0x2d/frame 0xf9e574f0 Mar 26 19:17:38 kernel: witness_checkorder(d0cfb580,9,c1e37f69,30f,0,...) = at 0xc0b7febe =3D witness_checkorder+0xd2e/frame 0xf9e57544 Mar 26 19:17:38 kernel: __mtx_lock_flags(d0cfb590,0,c1e37f69,30f,d2797f58,= =2E..) at 0xc0b08259 =3D __mtx_lock_flags+0x99/frame 0xf9e57578 Mar 26 19:17:38 kernel: os_acquire_spinlock(d0cfb580,d27a1000,0,cfb1f400,c= 1b5c931,...) at 0xc1d857ac =3D os_acquire_spinlock+0x2c/frame 0xf9e57590 Mar 26 19:17:38 kernel: _nv012380rm(0,1,1873f,0,0,...) at 0xc1b61ad8 =3D _= nv012380rm+0xc10/frame 0xd2797f58 Mar 26 19:17:39 kernel: ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsargu= ments-97) Mar 26 19:17:40 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:17:45 ntpd[1002]: time reset -0.383123 s Mar 26 19:17:50 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:17:50 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:17:53 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:18:03 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:18:03 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:18:05 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:18:09 kernel: battery1: battery initialization failed, giving up Mar 26 19:18:15 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:18:15 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:18:17 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:18:27 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:18:27 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:18:30 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:18:40 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:18:40 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:18:42 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:18:52 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:18:52 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:18:55 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:19:05 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:19:05 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:19:07 wpa_supplicant[354]: wlan0: Trying to associate with 04:18= :d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:19:17 wpa_supplicant[354]: wlan0: Authentication with 04:18:d6:2= 2:22:1f timed out. Mar 26 19:19:17 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D04:18:d6:22:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:19:19 wpa_supplicant[354]: wlan0: Trying to associate with 0a:18= :d6:21:22:1f (SSID=3D'lmdhw-net' freq=3D5745 MHz) Mar 26 19:19:29 wpa_supplicant[354]: wlan0: Authentication with 0a:18:d6:2= 1:22:1f timed out. Mar 26 19:19:29 wpa_supplicant[354]: wlan0: CTRL-EVENT-DISCONNECTED bssid= =3D0a:18:d6:21:22:1f reason=3D3 locally_generated=3D1 Mar 26 19:19:30 wpa_supplicant[354]: ioctl[SIOCS80211, op=3D26, val=3D0, a= rg_len=3D0]: Operation not supported Mar 26 19:19:30 wpa_supplicant[354]: ioctl[SIOCS80211, op=3D26, val=3D0, a= rg_len=3D0]: Operation not supported Mar 26 19:19:30 wpa_supplicant[354]: wlan0: CTRL-EVENT-TERMINATING=20 Mar 26 19:22:44 kernel: if_delmulti_locked: detaching ifnet instance 0xd1c= 1d400 Mar 26 19:22:44 kernel: wlan0: ieee80211_swscan_cancel_scan: called; F_SCA= N=3D0, vap=3Dmatch, CANCEL=3D0 Mar 26 19:22:44 kernel: wlan0: ieee80211_swscan_cancel_scan: called; F_SCA= N=3D0, vap=3Dmatch, CANCEL=3D0 Mar 26 19:22:58 kernel: iwn0: iwn_read_firmware: ucode rev=3D0x08530501 Mar 26 19:22:58 kernel: wlan0: bpf attached Mar 26 19:22:58 kernel: wlan0: bpf attached Mar 26 19:22:58 kernel: wlan0: Ethernet address: 00:24:e8:b5:85:46 Mar 26 19:22:58 wpa_supplicant[1526]: Successfully initialized wpa_supplic= ant Mar 26 19:22:58 wpa_supplicant[1539]: Successfully initialized wpa_supplic= ant Mar 26 19:22:58 root: /etc/rc.d/wpa_supplicant: WARNING: failed to start w= pa_supplicant Mar 26 19:23:00 wpa_supplicant[1540]: wlan0: Trying to associate with 04:1= 8:d6:22:22:1f (SSID=3D'lmdhw-net' freq=3D2412 MHz) Mar 26 19:23:00 kernel: wlan0: link state changed to UP Mar 26 19:23:00 wpa_supplicant[1540]: wlan0: Associated with 04:18:d6:22:2= 2:1f Mar 26 19:23:01 wpa_supplicant[1540]: wlan0: WPA: Key negotiation complete= d with 04:18:d6:22:22:1f [PTK=3DCCMP GTK=3DCCMP] Mar 26 19:23:01 wpa_supplicant[1540]: wlan0: CTRL-EVENT-CONNECTED - Connec= tion to 04:18:d6:22:22:1f completed [id=3D15 id_str=3D] --3m6ZAtymzEdXvUYk-- --j4ivd53YxxNwCQqF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVFMDvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7Ib0P/jTdVLJOtEewxJMT4DH8Yd1X 0x+jRzvA4TOVF1FOZnE+8JSAhb9JfxhSh+T/MN63bqVyW9+PuIIC0TV1KgsRn9vi yrY1ACuZ8bzTlJK1AvW16IuWrOlS+iBXhPHuuMOyxS9gFzqfD+68/qiSyiVKanH0 jAkvYn5hWxhux88UwKT4xBzciAxJsn33qRJGbvFjsFhFf6vBHGooLSPHAdDr038C 0Z50mHHHgHMgUCxfNBZvj6dtgaNs+uIduGTc5DrcQbwITUeQCA7147zU1w9b/UEY AhypjMZHJpHrfl4oVsOZbzxs5VEzty7Wu15ncxpv6VPIhTBHQb8ijeTMfaZ4Tb/N vGCLGsTdCRwlTBI3zoFob3Xc+HEoiMV/U4zRRId7zHnhzczuP1p5amRT0NRbcsrJ Jjmnwtt7+f/yBasWyjnuWI3cOud+72AZTlW66ehCWjGWGzx0Esh7W/uRchSgrQtz yjSu8g2qAOYJBYK/r7TXmotDbS2Axlr9P7yskAZcazIcVPPHSqCdRByFHttbDtJ5 OOy+RfxPQYENoMSwdY7j77D8ok6lbDBuJAve3EOuBJtWxkiFHJRKiF4vERl5kJrz pjTG380gYOTceQMAwUQ43JwLy3lOsgVbII4k48kWSRkf0ipFsD/1ZLcX/f0b5Tx/ Nu4MXJKSwC/ltdjpTNNh =tZ7U -----END PGP SIGNATURE----- --j4ivd53YxxNwCQqF-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 03:00:43 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D577BF8 for ; Fri, 27 Mar 2015 03:00:43 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBFD02FC for ; Fri, 27 Mar 2015 03:00:43 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2R30hvQ076429 for ; Fri, 27 Mar 2015 03:00:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 198927] if_msk TCP fragmentation causes NFS mount fail Date: Fri, 27 Mar 2015 03:00:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 03:00:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198927 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 03:01:31 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA3BC3EE for ; Fri, 27 Mar 2015 03:01:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF3C461F for ; Fri, 27 Mar 2015 03:01:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2R31VIX027631 for ; Fri, 27 Mar 2015 03:01:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 198928] mbuf tags aren't being copied from the leading fragment (header) to the subsequent fragment packets Date: Fri, 27 Mar 2015 03:01:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 03:01:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198928 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 03:02:38 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B3C94D7 for ; Fri, 27 Mar 2015 03:02:38 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1C126C9 for ; Fri, 27 Mar 2015 03:02:37 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so61765910iec.0 for ; Thu, 26 Mar 2015 20:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ERN5xEs/sSmuitbsAXVsHCF2xV/kdhbmoJ+f5JZWH9g=; b=J2Ol0/Vvz9psG0MhCi02HN36XYD4cghZ3fw2qTIJVZwquzcHYlw1W0Qz75nKrc3bxr +/FZeqBtoUL4OK6L4GeIMHgUK90vV6+yTvgD+b3tR+wJNSZG+XYQPhvtB1BRIKXVEKuN aSin+a4zYIDfv/HAnLUGysMENafEUtn6JuU3J8/GZ34W+6i2/3MegctI6LTZdNaEUNtA 70YWYbcgKXAnwPuxnz/5X82FNCidG8l+/H1ISqj380h+sDrygniKkeAvZe9C5h3RGnQP Tu3gHkWqRsiUy0fxlmdRT+1hUyr2V7KmVJS1u4XFhZ0N8W+jUhZDuR2QZUTBtl05cSDq G/nw== MIME-Version: 1.0 X-Received: by 10.107.5.131 with SMTP id 125mr25333119iof.88.1427425357268; Thu, 26 Mar 2015 20:02:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Thu, 26 Mar 2015 20:02:37 -0700 (PDT) In-Reply-To: <20150327023111.GB7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> <20150327023111.GB7594@albert.catwhisker.org> Date: Thu, 26 Mar 2015 20:02:37 -0700 X-Google-Sender-Auth: tUB6YZL5x4s8rbZxx_WlGVKFf-0 Message-ID: Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head From: Adrian Chadd To: David Wolfskill Content-Type: text/plain; charset=UTF-8 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 03:02:38 -0000 Ooooooooh. I think you're hitting the "multiple wpa_supplicant processes are running at startup" bug. :( -a From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 03:18:38 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22FAC891; Fri, 27 Mar 2015 03:18:38 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEEA782F; Fri, 27 Mar 2015 03:18:37 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2R3Iatm038438; Thu, 26 Mar 2015 20:18:36 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2R3Ia1h038437; Thu, 26 Mar 2015 20:18:36 -0700 (PDT) (envelope-from david) Date: Thu, 26 Mar 2015 20:18:36 -0700 From: David Wolfskill To: Adrian Chadd Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head Message-ID: <20150327031836.GC7594@albert.catwhisker.org> Reply-To: net@freebsd.org, David Wolfskill References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> <20150327023111.GB7594@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w9gceUn8eOVn8+8k" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 03:18:38 -0000 --w9gceUn8eOVn8+8k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2015 at 08:02:37PM -0700, Adrian Chadd wrote: > Ooooooooh. I think you're hitting the "multiple wpa_supplicant > processes are running at startup" bug. :( > .... That's certainly plausible.... And seeing changes in each of /etc/network.subr, /etc/rc.subr, and /etc/rc.d/netif between stable/10 and head, it's fairly believeable. I'll examine it more in the morning (while I'm running head again). Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --w9gceUn8eOVn8+8k Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVFMwMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7HM4P/2DyUthVI04F6Epjl2X1hZnH ifUXeE8ZdLfXkB4x8NissuJqSH3z8Vr8bLPQbiW4Q63BSCtjJoKe5Pfe6+g9S7FE M3uVg1glQKFKC6oP8SkaqEE8MRsdExm0JtFci9tZDa44zNM2XF5nc2eikV7v3zAm G6WKFkxuwCajf6cMw3FqdW8kuG9SPfI9PUV4otKKp3IWab8CDOzxzgqrCm+h4bgO phU1LpuxmwktFuhsGWy8CNx14b3Ye+XnLlmr8SpXNmS5gJlnYTT0ep/rT/T6WuRp jGrzPn+6iQFPPayWNqieFwUKf3LgHV8upsFaxmzdi5awTgvqonljI5rLmxArl9Rj 3wuIkxa43Qp9nfI+HdkMXc1aq/r/qTU4fK0wATS6u3UoNcLSQliBauqR46+741Ag i21VugHkE9StEd/BksLYW4DsfzK93WYtYMOkUpKPvJ5tx2XtuXas91kQnXpOLSMD g5nFXvw4MZi/7FrdceMaFXHx6TIH9+ULsCZxQbPUjhmQDM2OgBYoJPJiMB+GTu9e GRevaIgKJQwPVK1tr0w09YCMmVipZ9PU5fcSpSvl8n6TE+cvEA4wyrfT8l3BpIrP tJKwQHHqla6yLaxiMvRR8U0AVOeQj2AKzdc9/Ncz3hUqX2ncQXCZedOq3F0aVzZ0 hMrGD4rasR7lwMt7a4Kh =GW5S -----END PGP SIGNATURE----- --w9gceUn8eOVn8+8k-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 13:53:00 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F71AF0A; Fri, 27 Mar 2015 13:53:00 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B915076C; Fri, 27 Mar 2015 13:52:59 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t2RDqwmu050030; Fri, 27 Mar 2015 06:52:58 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t2RDqwBV050029; Fri, 27 Mar 2015 06:52:58 -0700 (PDT) (envelope-from david) Date: Fri, 27 Mar 2015 06:52:58 -0700 From: David Wolfskill To: Adrian Chadd Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head Message-ID: <20150327135258.GK7594@albert.catwhisker.org> Reply-To: David Wolfskill , "net@freebsd.org" References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> <20150327023111.GB7594@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+F2yqQIdYdj7GirX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 13:53:00 -0000 --+F2yqQIdYdj7GirX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2015 at 08:02:37PM -0700, Adrian Chadd wrote: > Ooooooooh. I think you're hitting the "multiple wpa_supplicant > processes are running at startup" bug. :( > ... During a bit of exploring this morning, I'm not seeing evidence that I recognize as corroborating that suggestion. For one thing, the messages logged by wpa_supplicant (in /var/log/messages) report just the one PID (until I manually wade in and start breaking things). For another, there is a /var/run/wpa_supplicant/wlan0.pid created & populated with the PID. (And yes, its contents match the PID logged in the above-cited messages.) During my experiments, I found some "interesting" behavior: * I set up the em0 & iwn0/wlan0 interfaces as described in the "laptop" example (31.3) at (subsitituting "em0" for "bge0"): g1-254(10.1-S)[5] egrep 'ifconfig|(em|lagg|wlan)0' rc.conf | grep -v '^#' ifconfig_em0=3D"up" ifconfig_iwn0=3D"ether 00:24:e8:b5:85:46" wlans_iwn0=3Dwlan0 ifconfig_wlan0=3D"WPA" cloned_interfaces=3D"lagg0" ifconfig_lagg0=3D"laggproto failover laggport em0 laggport wlan0 DHCP" g1-254(10.1-S)[6]=20 * Immediately subsequent to the transition from single- to multi-user mode: + em0 is active + WiFi LED is blinking rapidly (indicating failed attempts at association) + wlan0 shows "no carrier" + lagg0 shows "active", but the inet address is (still) 0.0.0.0. * If I: + "pgrep wpa_supplicant", only a single PID is returned. + "pkill wpa_supplicant", the WiFi LED goes out; if I then follow that with another "pgrep wpa_supplicant", no PID is returned. + Out of perversity, I then verified that "ifconfig wlan0" reported the status of wlan0 (implying tha wlan0 exists). + "service netif stop wlan0 iwn0", I get a whimper: wpa_supplicant not running? (check /var/run/wpa_supplicant/wlan0.pid). Stopping Network: wlan0 iwn0. ifconfig: interface wlan0 does not exist + An attempt to "ifconfig wlan0"confirms that it no longer exists. + "ifconfig" shows that em0 is still active, as is lagg0. lagg0 also still has no IP address assigned -- and it no longer has wlan0 as a component. + "service netif start iwn0" yields: Starting wpa_supplicant. Starting Network: iwn0. and wlan0 now exists -- and gets association. But wlan0 has not become part of lagg0 as a result of this. + "service netif restart lagg0" yields: Stopping dhclient. Waiting for PIDS: 1035. Stopping Network: lagg0. lagg0: flags=3D8802 metric 0 mtu 1500 options=3D4019b ether 34:e6:d7:3c:4a:93 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg=20 laggproto failover lagghash l2,l3,l4 laggport: em0 flags=3D5 Destroyed clone interfaces: lagg0. Created clone interfaces: lagg0. Starting dhclient. dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT dhclient: Leaving hostname set to=20 and the WiFi LED went from solid "on" to "blinking madly" -- and the system then locks up hard -- requiring a power-cycle to do anything. (The BIOS has an option for an "unobtrusive mode" -- if this is enabled (which I did), Fn+B will blank the screen and make all lights on the device go out. I had tried this earlier, and it seems to work as advertised; the Fn+B is a toggle. When the above-described "lock up" occurred, I tried "Fn+B".... no reaction at all. Yeah, I tried a few other things -- even switching the WiFi switch to "off" didn't stop the WiFi LED from blinking madly.) (I have a typescript showing that stuff....) Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --+F2yqQIdYdj7GirX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVFWC5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7InMP/joB1F0GJvFt7o0RPv8+Mheh Nw7ByVVaH43bAczRZTg4Ef6esmQUubhr0hjDZlKjfzLW8pHcwvO9zwN6ce+pn0+M HJFK7x2v7bEnzDUg2fUUhk4zX0exhLPe9t6f5liv1DM6FwwIcUul3pcB4DkmFN49 qzhvcMY4PZDArWmlQIvXJ+rC2Nar2+2FfMaDHczcHy+FSHdbn4AXdVWy39OVIH7t lwpael0KkfIbL4XKkE9yr0l3Nmgfaf3U9id8PEwy0pgpk9VzVjJNicF+1X/oxuOI 54EGbWFkqr8/JXcxFQG/J97eJkcuQbH0uLJi00hpYZkIaja3DWVcYLEZwJBbHw8y V84mD6z6tTgvlRs7vrVrczaegOyo6Wwvn7jM+1Sa17gEspNvrzzsDWfNdCDGfZI8 kSh08ojMAujzeqNmQ0lNwdFbF2DlNm2fvp8oYIo9GpPxyiMCTqEczKQTEOLMn9GU 4rr6RMl0pwkeTPPUiPrxm2UKa7Y8bq4Oj/NMHe5I3iRpdiLuiRrsNjZfDwZS5DSS cD05sgPQ57r+kndpBZG162M37vBaH6GX7RtKhl+2Cz65qmeDcpF1NpCoy7KCo2q4 BANHY7M3aiPWifK/MNzmb/9DS9Z1kJ0sWNeTEZi5b3VkAYcjIaofRoRA+Jil97wW ikdtpHgBUMvm108y+Tiz =eIdI -----END PGP SIGNATURE----- --+F2yqQIdYdj7GirX-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 16:49:27 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A250F2F for ; Fri, 27 Mar 2015 16:49:27 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BEABD9 for ; Fri, 27 Mar 2015 16:49:27 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so24995502igb.1 for ; Fri, 27 Mar 2015 09:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=8moepUJNCl+a9Kv1THpb3aYWGCJJWAlsKbiBT8hFZwg=; b=enApTHVWu1vJ4Dl3BCtgJtfOnmCGrmtVk70mrCQHbHwWHec2IbJupemM0ZbQdHfESO HRti5nrKlL2R9nAQjnLrRM00QTJ6uZ25p0ZRvTrnK99uBNTBhnz1kowTyGzZMvA83UDO qr1xQ9NoVtODaCnLQF4IHrCb/8WSgN+TbBcmjls3pyT1apnLRDIl/A2J5zABiwT4O+ww EY2gzJA0PuKinEZkbt9iETVY50eOHZAiygFuaGzeNQjgiVmJwRKl2ea/NqFy8wSiyWXk 403BSmABuJ3MwCSyN1nrzKc7HaDXfBz13DGJohEy7Jh97pe7y0Mgo2ljbFxT72auZX0H NdRg== MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mr45965579igb.49.1427474966410; Fri, 27 Mar 2015 09:49:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 27 Mar 2015 09:49:26 -0700 (PDT) In-Reply-To: <20150327135258.GK7594@albert.catwhisker.org> References: <20150323131918.GN7594@albert.catwhisker.org> <20150326022132.GI7594@albert.catwhisker.org> <20150327023111.GB7594@albert.catwhisker.org> <20150327135258.GK7594@albert.catwhisker.org> Date: Fri, 27 Mar 2015 09:49:26 -0700 X-Google-Sender-Auth: gZP8gvzD97syhHm9M6LbfAa9fg8 Message-ID: Subject: Re: iwn(4) works (mostly) in stable/10; fails to associate in head From: Adrian Chadd To: David Wolfskill , "net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 16:49:27 -0000 Hi, That's the firmware getting in a tizzle, because a second wpa_supplicant came along and started the interface up before deciding one was running and quitting. If you built it as a module you can kldunload if_iwn ; kldload if_iwn. Or, just run it manually. -adrian From owner-freebsd-net@FreeBSD.ORG Fri Mar 27 17:33:35 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E07BE6A; Fri, 27 Mar 2015 17:33:35 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E225B932; Fri, 27 Mar 2015 17:33:34 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 81E641092B3; Fri, 27 Mar 2015 10:33:34 -0700 (PDT) Date: Fri, 27 Mar 2015 10:33:34 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Subject: Re: em(4): difference between missed_packets and rx_overrun Message-ID: <20150327173334.GB39674@strugglingcoder.info> References: <20150326200853.GA19536@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <20150326200853.GA19536@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: jfv@freebsd.org, erj@freebsd.org, nitroboost@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Mar 2015 17:33:35 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable + jfv, erj from Intel. On 03/26/15 at 01:08P, hiren panchasara wrote: > This is what we are seeing on em(4) 82574L chipset running stable/10: >=20 > dev.em.0.mac_stats.missed_packets: 1441927 > dev.em.0.interrupts.rx_overrun: 153 >=20 > From the datasheet: > http://www.intel.com/content/www/us/en/ethernet-controllers/82574l-gbe-co= ntroller-datasheet.html >=20 > 10.2.7.4 Missed Packets Count - MPC (0x04010; R) > Counts the number of missed packets. Packets are missed when the receive > FIFO has insufficient space to store the incoming packet. This could be > caused because of too few buffers allocated, or because there is > insufficient bandwidth on the IO bus. Events setting this counter > cause RXO, the receiver overrun interrupt, to be set. This register > does not increment if receives are not enabled. >=20 > 10.2.4.1 Interrupt Cause Read Register - ICR (0x000C0; RC/WC) > RXO Receiver Overrun > Set on receive data FIFO overrun. Could be caused either because > there are no available buffers or because PCIe receive bandwidth is > inadequate. >=20 > So, first one is a count and another one is an interrupt. Are these 2 > related? Both seem to be happen when on card FIFO gets full. We see no > evidence of RX queue on the host being full based on > dev.em.0.mac_stats.recv_no_buff. >=20 > Many a times we see missed_packets increasing without rx_overrun > changing. >=20 > The spec says there is a 40KB buffer on card which seems to be used by > both RX and TX? Is is split between them for 20KB each? OR is it > possible that when we are doing high rate TX, we use up that buffer and > RX suffers from that? >=20 > Any insights would be helpful to understand the problem. >=20 > Cheers, > Hiren > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) >=20 > iQF8BAEBCgBmBQJVFGdUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 > QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l8QoH/3xKvDx9inKcwiPW1authYpw > P/o7TCALanXNp2RyRjSdLnKr1EU4Kv6Twh1qlSun3N9JuxQbVdRCJiF6bAKsdeMm > uvWXFOIOCy1rBbctiVvXUXgPMIEOhywNr7nbdEILV/dFpBMkhGxr9bZPtE7j88cK > 0sX6sO8HLE1b94s/SufMMr/cvJr4m3GbNlSxcq2NjUUKafXJohmVaXfJcp9nXRPz > 148FUCvLL5/DbatzOyg1UQOXItOk2QghIouNcRhd0ls7yTU4BjGDL2z/c/dFOvfM > OV+7jl398uy1k6XnsGDX+TmGunajtIHCPQz4gwV5CJQ0Qq/UqrPs0neBPebUGXo=3D > =3D09Jg > -----END PGP SIGNATURE----- --E13BgyNx05feLLmH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVFZRtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l/AwIAJf4S+AZkn8axYfhenwtbKUm u55Lw2hJ+ugJHM6OqoxJcbrcJ45WRHW11alNHfVrg+9HUveVWbKeTuWAiJwa3LR1 OhWWeHFPjISL5B93LvxwY+MxNwISxcHe2z9/QHbjSSXw6tnlSbUYS/293/XfdXhK 940dlUhpxq/4RpSOJBkaaqdcMC+gd6KkSeIYom5EB3U1otDDJcOshJAeWtXVCVkj nKteNnXrCEyGAqT1vz92GIAaVXpt7fgC4UM1EpFndqWlLYdWmIKp4N0bOE9h+axG pr5PgCqjjq1w+7jUPPuQ8eK3MQbXvH/lDCIwVvJ9iat3RQ0F7OxYgHB9q0/wKGs= =EZ9H -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 28 14:54:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF54EEE4 for ; Sat, 28 Mar 2015 14:54:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B23AEC98 for ; Sat, 28 Mar 2015 14:54:14 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2SEsEU7064895 for ; Sat, 28 Mar 2015 14:54:14 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2SEsEkA064894; Sat, 28 Mar 2015 14:54:14 GMT (envelope-from root) Date: Sat, 28 Mar 2015 14:54:14 +0000 To: freebsd-net@freebsd.org From: "rrs (Randall Stewart)" Subject: [Differential] [Closed] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <86a31144ec52a348d1d085ef9a3b30ca@localhost.localdomain> X-Priority: 3 Thread-Topic: D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate the callout code (and potentially for use by other tests). X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: Y2JjMTcyODJkYzgxM2NkZDFjY2RhOGRmMTlkIFUWwJY= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Mar 2015 14:54:15 -0000 rrs closed this revision. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, imp, adrian, hselasky, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net