From owner-freebsd-net@FreeBSD.ORG Sun Oct 10 07:27:30 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 726A9106566B; Sun, 10 Oct 2010 07:27:30 +0000 (UTC) Date: Sun, 10 Oct 2010 07:27:30 +0000 From: Alexey Dokuchaev To: Bernhard Schmidt Message-ID: <20101010072730.GA91527@FreeBSD.org> References: <4763016D.7060100@janh.de> <201010081944.50287.bschmidt@techwires.net> <20101009060239.GA88618@FreeBSD.org> <201010092046.41551.bschmidt@techwires.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201010092046.41551.bschmidt@techwires.net> User-Agent: Mutt/1.4.2.1i Cc: Paul B Mahol , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 07:27:30 -0000 On Sat, Oct 09, 2010 at 08:46:41PM +0200, Bernhard Schmidt wrote: > On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, > > which means it can utilize monitor mode. "ifconfig iwi0 scan" however > > does not work after that (and "list scan" returns no results) even if I > > put adapter back to normal (from promisc and monitor modes) with > > ifconfig(8). kldunloading and loading module again fixes the issue. > > Due to enqueueing the scan command in an infinite loop (yeah.. scanning > returns every frame, that's monitor mode for that device.. *sigh*) we might > increment a queue index but never actually dequeueing the command. On 'down' > we clear the command queue but not the indices resulting in the cur index > not pointing to a filled entry. Attached patch should fix that. It does, thanks! "list scan" gets populated after I -mediaopt monitor after scan; module reload is not required anymore. Do I read you correctly that seeing no results for "list scan" is OK while card is in monitor mode? > On a side note, you should never be required to run 'ifconfig dev scan', > because after 'ifconfig dev up' the device is always in SCAN state (at least > in station mode). Using 'ifconfig dev list scan' is sufficient enough. Certainly. I was meant to say that "list scan" returned no results, and "forcing" the scan (despite that background scan is in progress) would never return either. > It might be possible with lots of ugly hacks to get that device sending some > kind of frames, 'injecting' those frames via net80211 shouldn't be that hard. > At least the code is there according to comments in ieee80211_output.c. I do > not consider this worth the effort though, if someone wants to work on that, > let me know. I might want to take a look when time permits. > > Apart from that, machine seems stable, and monitor mode is fixed. Thanks > > a lot! > > You're welcome :) Hope to see the final set of patches in RELENG_7 soon. ;-) ./danfe From owner-freebsd-net@FreeBSD.ORG Sun Oct 10 07:54:21 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6EC1106566C; Sun, 10 Oct 2010 07:54:21 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19C758FC13; Sun, 10 Oct 2010 07:54:20 +0000 (UTC) Received: by fxm12 with SMTP id 12so283857fxm.13 for ; Sun, 10 Oct 2010 00:54:20 -0700 (PDT) Received: by 10.223.107.74 with SMTP id a10mr1042648fap.12.1286697260040; Sun, 10 Oct 2010 00:54:20 -0700 (PDT) Received: from julie.lab.techwires.net (dslb-094-217-132-052.pools.arcor-ip.net [94.217.132.52]) by mx.google.com with ESMTPS id m8sm2326718faj.11.2010.10.10.00.54.14 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 00:54:18 -0700 (PDT) From: Bernhard Schmidt To: Alexey Dokuchaev Date: Sun, 10 Oct 2010 09:51:38 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) References: <4763016D.7060100@janh.de> <201010092046.41551.bschmidt@techwires.net> <20101010072730.GA91527@FreeBSD.org> In-Reply-To: <20101010072730.GA91527@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201010100951.39079.bschmidt@techwires.net> Cc: Paul B Mahol , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 07:54:21 -0000 On Sunday 10 October 2010 09:27:30 Alexey Dokuchaev wrote: > On Sat, Oct 09, 2010 at 08:46:41PM +0200, Bernhard Schmidt wrote: > > On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: > > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, > > > which means it can utilize monitor mode. "ifconfig iwi0 scan" however > > > does not work after that (and "list scan" returns no results) even if I > > > put adapter back to normal (from promisc and monitor modes) with > > > ifconfig(8). kldunloading and loading module again fixes the issue. > > > > Due to enqueueing the scan command in an infinite loop (yeah.. scanning > > returns every frame, that's monitor mode for that device.. *sigh*) we > > might increment a queue index but never actually dequeueing the command. > > On 'down' we clear the command queue but not the indices resulting in > > the cur index not pointing to a filled entry. Attached patch should fix > > that. > > It does, thanks! "list scan" gets populated after I -mediaopt monitor > after scan; module reload is not required anymore. Do I read you correctly > that seeing no results for "list scan" is OK while card is in monitor mode? Yes. In monitor mode no frames are handled by net80211, frames are just passed to bpf and that's it. This also means the no scan cache is filled. > > On a side note, you should never be required to run 'ifconfig dev scan', > > because after 'ifconfig dev up' the device is always in SCAN state (at > > least in station mode). Using 'ifconfig dev list scan' is sufficient > > enough. > > Certainly. I was meant to say that "list scan" returned no results, and > "forcing" the scan (despite that background scan is in progress) would > never return either. > > > It might be possible with lots of ugly hacks to get that device sending > > some kind of frames, 'injecting' those frames via net80211 shouldn't be > > that hard. At least the code is there according to comments in > > ieee80211_output.c. I do not consider this worth the effort though, if > > someone wants to work on that, let me know. > > I might want to take a look when time permits. You might want to start by filling in the missing ic_raw_xmit function, probably by ignoring the 'raw' part of the functionality. > > > Apart from that, machine seems stable, and monitor mode is fixed. > > > Thanks a lot! > > > > You're welcome :) > > Hope to see the final set of patches in RELENG_7 soon. ;-) If there aren't any new issues coming up (I'll do some more test today), v2 + the queue fix will hit head soon. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Sun Oct 10 18:51:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8EAE106566B; Sun, 10 Oct 2010 18:51:30 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 69D608FC12; Sun, 10 Oct 2010 18:51:30 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Sun, 10 Oct 2010 14:40:41 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id EB2F133C00; Sun, 10 Oct 2010 14:40:41 -0400 (EDT) Date: Sun, 10 Oct 2010 14:40:41 -0400 From: Ed Maste To: Robert Watson Message-ID: <20101010184041.GA10473@sandvine.com> Mail-Followup-To: Ed Maste , Robert Watson , Attilio Rao , FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Attilio Rao , freebsd-net@freebsd.org, Sergey Kandaurov , FreeBSD Current Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 18:51:30 -0000 On Sat, Oct 09, 2010 at 02:15:39AM +0100, Robert Watson wrote: > Network dumps would be a great addition to the FreeBSD debugging suite! > [...] It seems that at EuroBSDCon there was a discussion of Contiki[1] and the uIPv6 stack[2] that it contains, and I think something like this could be a great future enhancement for netdump and similar consumers. Ideally I'd like to see us get to having a clean, simple API for transmitting and receiving packets and a basic stack that could be shared by netdump, as well as a network-enabled ddb, gdb backend, and perhaps console. Using the uIPv6 stack for this would get us v6 support (as the name suggests), as well as a supported / maintained stack vs. what is in netdump now. It's also BSD-licensed. This could be a good future project, although I think the current netdump implementation is worth bringing in soon (taking into account the good feedback received to date, of course). [1] http://www.sics.se/contiki/about-contiki.html [2] http://www.sics.se/contiki/contiki-6lowpan-uipv6-faq.html - Ed From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 05:22:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B4741065670 for ; Mon, 11 Oct 2010 05:22:52 +0000 (UTC) (envelope-from ethernext@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id F41888FC08 for ; Mon, 11 Oct 2010 05:22:51 +0000 (UTC) Received: by qyk1 with SMTP id 1so81781qyk.13 for ; Sun, 10 Oct 2010 22:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=UHl3Wtfv63qdg8ydZQB9DAfGN8SLANxwCJ2k/iFeLno=; b=K86dZlzyxpMY+xkQGEOjuo11cnWZx6HXx7HUvs4GdFPiX8f9JovQBKIdViahzTysBW WWxd4x/JdvAtjFe+aQAag44hyGxgcT3wU0czGSPNOjw60hXBdOwVDI6ohXWNBx6yoz1e 2rTv5P6DgXosbkl6IP3Yi76fJMavs8mWqpj9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=NSxmKnSKCwtZUC3BczEvntKeR4Hf+5xOqiWjjyTogeVS23QA8HOEvbHqJnV9Hg7kOm QeG6pu0La0mEwR95rKEcp4dboPkRaSIMGU0BtM5MSyj8ecvPdKQAyd6BJ5RI3F/I7GDu nJm3OSDTiQHRlcRqSOPxLnAHJEyU8MNVwnC6E= MIME-Version: 1.0 Received: by 10.229.212.205 with SMTP id gt13mr4691807qcb.161.1286773015763; Sun, 10 Oct 2010 21:56:55 -0700 (PDT) Sender: ethernext@gmail.com Received: by 10.229.73.199 with HTTP; Sun, 10 Oct 2010 21:56:55 -0700 (PDT) Date: Mon, 11 Oct 2010 00:56:55 -0400 X-Google-Sender-Auth: -3JjQb4IB0STQe-anpwDSb9py9s Message-ID: From: Bill Desjardins To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [cxgb] Chelsio T304 quad gig pcie adapter TSO disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 05:22:52 -0000 Hi All, I have a couple Chelsio T304 quad gigabit nics that are going into iscsi servers. I got these for the TOE capabilities, but I found in the cxgb driver code that it is explicitly disabled for > 2 port nics (line 1036 : /usr/src/sys/dev/cxgb/cxgb_main.c) . The current cxgb driver is based on the chelsio 7.8.0 firmware (11/25/09), but chelsio is up to 7.11.0 (07/20/10). I had updated the firmware using cxgbtool to 7.11, but received complaints from the driver to 'upgrade' to 7.8.0, which I did. my question is, is if the cxgb driver is being worked on to update to latest chelsio firmware and/or fix TSO for the quad port cards? I don't have the programming skill's to assist with that side of things, but I can easily provide a remote spare machine with a serial console for development and testing if its helpful. Some info: uname ----------------------- FreeBSD sas.ethernap.net 8.1-STABLE FreeBSD 8.1-STABLE #1: Sun Oct 10 05:29:41 EDT 2010 sas@sas:/usr/obj/usr/src/sys/GENERIC amd64 kernel boot (2 adapters) ----------------------- cxgbc0: mem 0xc8201000-0xc8201fff,0xc8800000-0xc8ffffff,0xc8200000-0xc8200fff irq 11 at device 0.0 on pci2 cxgbc0: Insufficient clusters and/or jumbo buffers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^???? cxgbc0: using MSI-X interrupts (9 vectors) cxgb0: on cxgbc0 cxgb0: Ethernet address: 00:07:43:05:83:16 cxgb1: on cxgbc0 cxgb1: Ethernet address: 00:07:43:05:83:17 cxgb2: on cxgbc0 cxgb2: Ethernet address: 00:07:43:05:83:18 cxgb3: on cxgbc0 cxgb3: Ethernet address: 00:07:43:05:83:19 cxgbc0: Firmware Version 7.8.0 cxgbc1: mem 0xc9101000-0xc9101fff,0xc9800000-0xc9ffffff,0xc9100000-0xc9100fff irq 11 at device 0.0 on pci8 cxgbc1: Insufficient clusters and/or jumbo buffers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^???? cxgbc1: using MSI-X interrupts (9 vectors) cxgb4: on cxgbc1 cxgb4: Ethernet address: 00:07:43:05:a3:7d cxgb5: on cxgbc1 cxgb5: Ethernet address: 00:07:43:05:a3:7e cxgb6: on cxgbc1 cxgb6: Ethernet address: 00:07:43:05:a3:7f cxgb7: on cxgbc1 cxgb7: Ethernet address: 00:07:43:05:a3:80 cxgbc1: Firmware Version 7.8.0 lspci -vvv ------------------------------------------ 02:00.0 Ethernet controller: Chelsio Communications Inc T304 1GbE Quad Port Adapter Subsystem: Chelsio Communications Inc Device 0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997FB106564A for ; Mon, 11 Oct 2010 06:51:53 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id DE2878FC18 for ; Mon, 11 Oct 2010 06:51:51 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9B6V4x2076897 for ; Mon, 11 Oct 2010 13:31:04 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CB2AF28.30309@rdtc.ru> Date: Mon, 11 Oct 2010 13:31:04 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 06:51:53 -0000 Hi! FreeBSD 8.1-STABLE: # host koin-nkz.com. koin-nkz.com has address 62.231.164.101 Host koin-nkz.com not found: 3(NXDOMAIN) This domain does not have MX records but NXDOMAIN seems to wrong return code to me. Think about MTA that does look-up for MX first, obtains NXDOMAIN and rejects mail. tcpdump shows that after MX look-up failure resolver adds my local domain suffix from /etc/resolv.conf's "search" clause and goes to my local DNS server looking for MX record for 'koin-nkz.com.my.ru.' that does not exists. Hence, NXDOMAIN. Is it a bug in our resolver? I've tested 6.4-STABLE and 7.3-STABLE, same effect. I've also tested 4.11-STABLE and it works correctly - no wrong suffix addition, no NXDOMAIN. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 08:11:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AB8F106566B for ; Mon, 11 Oct 2010 08:11:57 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id EA24A8FC08 for ; Mon, 11 Oct 2010 08:11:56 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Oct 2010 09:59:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS implementation Thread-Index: ActpGh6cxh4agpD0R+yLExsy6LiKiQ== From: "Jon Otterholm" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: VPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 08:11:57 -0000 Are there any plans or ongoing work to implement VPLS in the network stack? =20 http://en.wikipedia.org/wiki/Virtual_Private_LAN_Service =20 //JO From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 11:05:38 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E408E10656C1 for ; Mon, 11 Oct 2010 11:05:38 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 907268FC1C for ; Mon, 11 Oct 2010 11:05:38 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id o9BB5Ol6090656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 20:05:30 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 11 Oct 2010 20:05:24 +0900 Message-ID: From: Hajimu UMEMOTO To: Eugene Grosbein In-Reply-To: <4CB2AF28.30309@rdtc.ru> References: <4CB2AF28.30309@rdtc.ru> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.1-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 11 Oct 2010 20:05:30 +0900 (JST) X-Virus-Scanned: clamav-milter 0.96.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 11:05:39 -0000 Hi, >>>>> On Mon, 11 Oct 2010 13:31:04 +0700 >>>>> Eugene Grosbein said: egrosbein> FreeBSD 8.1-STABLE: egrosbein> # host koin-nkz.com. egrosbein> koin-nkz.com has address 62.231.164.101 egrosbein> Host koin-nkz.com not found: 3(NXDOMAIN) egrosbein> This domain does not have MX records but NXDOMAIN seems to wrong return egrosbein> code to me. Think about MTA that does look-up for MX first, egrosbein> obtains NXDOMAIN and rejects mail. egrosbein> tcpdump shows that after MX look-up failure resolver adds my local egrosbein> domain suffix from /etc/resolv.conf's "search" clause and egrosbein> goes to my local DNS server looking for MX record for egrosbein> 'koin-nkz.com.my.ru.' that does not exists. Hence, NXDOMAIN. egrosbein> Is it a bug in our resolver? I think no, host(1) links ISC's resolver, and it doesn't use libc's resolver. I suspect there is some problem in host(1) or ISC's resolver. egrosbein> I've tested 6.4-STABLE and 7.3-STABLE, same effect. egrosbein> I've also tested 4.11-STABLE and it works correctly - no wrong egrosbein> suffix addition, no NXDOMAIN. 4.X's host(1) is from BIND8, but it comes from BIND9 on 5.X and later. I confirmed it on my 4.11 box with our in-tree host(1). However, host(1) from ports has same behavior with 8.1. It is bind9-9.3.6.1.1. % uname -r 4.11-RELEASE-p25 % /usr/bin/host koin-nkz.com. koin-nkz.com has address 62.231.164.101 % /usr/local/bin/host koin-nkz.com. koin-nkz.com has address 62.231.164.101 Host koin-nkz.com not found: 3(NXDOMAIN) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 11:06:59 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 891931065739 for ; Mon, 11 Oct 2010 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 758D48FC14 for ; Mon, 11 Oct 2010 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9BB6xQm037617 for ; Mon, 11 Oct 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9BB6wqh037615 for freebsd-net@FreeBSD.org; Mon, 11 Oct 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Oct 2010 11:06:58 GMT Message-Id: <201010111106.o9BB6wqh037615@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150257 net [msk] watchdog timeout o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 366 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 14:56:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 766F01065672 for ; Mon, 11 Oct 2010 14:56:06 +0000 (UTC) (envelope-from cosmic17@yandex.ru) Received: from forward10.mail.yandex.net (forward10.mail.yandex.net [77.88.61.49]) by mx1.freebsd.org (Postfix) with ESMTP id 0710C8FC1B for ; Mon, 11 Oct 2010 14:56:05 +0000 (UTC) Received: from web117.yandex.ru (web117.yandex.ru [77.88.60.89]) by forward10.mail.yandex.net (Yandex) with ESMTP id 934A91F50ED2 for ; Mon, 11 Oct 2010 18:40:44 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1286808044; bh=PGt5oFZktXikyIP+EnjKY1y6jsVf2N8TzUhRmbG4aIo=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=k87j1MsEeSgZxrhQS+OgU7fz80+qPjAsUP+17knwMBFcZSJSyYLPVywYLqJYJxz52 y0fsyj9XC3tuJ9epiO3K6SQYQxURy9jLEfWdwv/o2gfvx+QwGt5vm2pzjcu/F6Z++N rBdNotyQAf2ZWc8PUR6WPufq5NFPegfOFs8ALaZ8= Received: from localhost (localhost.localdomain [127.0.0.1]) by web117.yandex.ru (Yandex) with ESMTP id 8A0071090788 for ; Mon, 11 Oct 2010 18:40:44 +0400 (MSD) X-Yandex-Spam: 0 X-Yandex-Front: web117.yandex.ru X-Yandex-TimeMark: 1286808044 Received: from [79.174.32.100] ([79.174.32.100]) by mail.yandex.ru with HTTP; Mon, 11 Oct 2010 18:40:43 +0400 From: Dmukha Nikolay To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-Id: <138981286808043@web117.yandex.ru> Date: Mon, 11 Oct 2010 18:40:43 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Subject: Strange behavior of packet scheduling in ipfw3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 14:56:06 -0000 Hello! The system is: FreeBSD mysystem 8.0-STABLE-201005 FreeBSD 8.0-STABLE-201005 #0: Wed Jul 28 12:04:29 MSD 2010 root@mysystem:/usr/src/sys/amd64/compile/MYKERNEL amd64 There is firewall "ipfw3" from Luigi Rizzo with packet scheduling. There is part of firewall config (tariff with 1Mbit/s speed, for example), below (the rules for another speeds are the same): $IPFW pipe 11 config bw 1040Kbit/s mask dst-ip 0xffffffff $IPFW pipe 12 config bw 1040Kbit/s mask src-ip 0xffffffff ########pipe 11 $IPFW sched 11 config type QFQ mask dst-ip 0xffffff00 $IPFW queue 111 config sched 11 weight 10 $IPFW queue 112 config sched 11 weight 8 $IPFW queue 113 config sched 11 weight 4 $IPFW queue 114 config sched 11 weight 1 $IPFW add queue 111 ip from any to table\(10\) via igb0 out proto udp src-port 5060 $IPFW add queue 112 ip from any to table\(10\) via igb0 out proto tcp src-port 80,443,8080 $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto icmp $IPFW add queue 114 ip from any to table\(10\) via igb0 out $IPFW add queue 111 ip from any to table\(10\) via igb2 out proto udp src-port 5060 $IPFW add queue 112 ip from any to table\(10\) via igb2 out proto tcp src-port 80,443,8080 $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto icmp $IPFW add queue 114 ip from any to table\(10\) via igb2 out ########pipe 12 $IPFW sched 12 config type QFQ mask src-ip 0xffffff00 $IPFW queue 121 config sched 12 weight 10 $IPFW queue 122 config sched 12 weight 8 $IPFW queue 123 config sched 12 weight 4 $IPFW queue 124 config sched 12 weight 1 $IPFW add queue 1210 ip from table\(11\) to any via igb1 out proto udp dst-port 5060 $IPFW add queue 122 ip from table\(11\) to any via igb1 out proto tcp dst-port 80,443,8080 $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto icmp $IPFW add queue 124 ip from table\(11\) to any via igb1 out $IPFW add queue 121 ip from table\(11\) to any via igb3 out proto udp dst-port 5060 $IPFW add queue 122 ip from table\(11\) to any via igb3 out proto tcp dst-port 80,443,8080 $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto icmp $IPFW add queue 124 ip from table\(11\) to any via igb3 out Firstly, we have been tested firewall by ourself. And we had no any bad results or any problems or maybe we have not seen them in our synthetic tests. After that we have started this firewall in production. A few months later we received a message from our subscriber with speed 1Mbit/s. He had a problems with online game (big answer delay from the server). We spent a lot of time to solve this problem. Finaly we solved it. The reason was in packet scheduling: 1. we`ve tried to give to subscriber another channel (4Mbit/s) with packet scheduling - there are no such problems; 2. we`ve tried to "turn off" the packet scheduling on 1Mbit channel - there are no such problems. The utilization of subscibers channel was always 0.4Mbit/s. But the traffic from this subscriber was go on under the packet scheduling rules. That`s very strange because of: 1. net.inet.ip.dummynet.io_fast=1; 2. subscribers channel utilization 0.4Mbit/s. As I know with this option, with this firewall config and with this channel utilization (0.4Mbit/s) traffic should bypass the pipe without packet scheduling. Why subscribers traffic with all these conditions doesn`t bypass through pipe without any delays? Why his traffic was on packet scheduling rules? Thanks. From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 15:22:12 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BF281065670 for ; Mon, 11 Oct 2010 15:22:12 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id F275F8FC0C for ; Mon, 11 Oct 2010 15:22:11 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 010D5730A4; Mon, 11 Oct 2010 17:16:10 +0200 (CEST) Date: Mon, 11 Oct 2010 17:16:09 +0200 From: Luigi Rizzo To: Dmukha Nikolay Message-ID: <20101011151609.GB41572@onelab2.iet.unipi.it> References: <138981286808043@web117.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <138981286808043@web117.yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Strange behavior of packet scheduling in ipfw3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 15:22:12 -0000 [top post as i am in a rush] first, there is (fixed in HEAD, but not yet in -stable) an issue with io_fast=1 so try to set it to 0. Secondly, because of the way scheduling works, you can't expect packets to bypass the pipe, even if the individual flow is below its share. Even the best scheduling algorithm has a worst case delay which is at least 1 max-sized packet (the constant is actually 3..6 times for QFQ). cheers luigi On Mon, Oct 11, 2010 at 06:40:43PM +0400, Dmukha Nikolay wrote: > Hello! > > The system is: > FreeBSD mysystem 8.0-STABLE-201005 FreeBSD 8.0-STABLE-201005 #0: Wed Jul 28 12:04:29 MSD 2010 root@mysystem:/usr/src/sys/amd64/compile/MYKERNEL amd64 > > There is firewall "ipfw3" from Luigi Rizzo with packet scheduling. > There is part of firewall config (tariff with 1Mbit/s speed, for example), below (the rules for another speeds are the same): > $IPFW pipe 11 config bw 1040Kbit/s mask dst-ip 0xffffffff > $IPFW pipe 12 config bw 1040Kbit/s mask src-ip 0xffffffff > ########pipe 11 > $IPFW sched 11 config type QFQ mask dst-ip 0xffffff00 > $IPFW queue 111 config sched 11 weight 10 > $IPFW queue 112 config sched 11 weight 8 > $IPFW queue 113 config sched 11 weight 4 > $IPFW queue 114 config sched 11 weight 1 > $IPFW add queue 111 ip from any to table\(10\) via igb0 out proto udp src-port 5060 > $IPFW add queue 112 ip from any to table\(10\) via igb0 out proto tcp src-port 80,443,8080 > $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 > $IPFW add queue 113 ip from any to table\(10\) via igb0 out proto icmp > $IPFW add queue 114 ip from any to table\(10\) via igb0 out > $IPFW add queue 111 ip from any to table\(10\) via igb2 out proto udp src-port 5060 > $IPFW add queue 112 ip from any to table\(10\) via igb2 out proto tcp src-port 80,443,8080 > $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 > $IPFW add queue 113 ip from any to table\(10\) via igb2 out proto icmp > $IPFW add queue 114 ip from any to table\(10\) via igb2 out > ########pipe 12 > $IPFW sched 12 config type QFQ mask src-ip 0xffffff00 > $IPFW queue 121 config sched 12 weight 10 > $IPFW queue 122 config sched 12 weight 8 > $IPFW queue 123 config sched 12 weight 4 > $IPFW queue 124 config sched 12 weight 1 > $IPFW add queue 1210 ip from table\(11\) to any via igb1 out proto udp dst-port 5060 > $IPFW add queue 122 ip from table\(11\) to any via igb1 out proto tcp dst-port 80,443,8080 > $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 > $IPFW add queue 123 ip from table\(11\) to any via igb1 out proto icmp > $IPFW add queue 124 ip from table\(11\) to any via igb1 out > $IPFW add queue 121 ip from table\(11\) to any via igb3 out proto udp dst-port 5060 > $IPFW add queue 122 ip from table\(11\) to any via igb3 out proto tcp dst-port 80,443,8080 > $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 > $IPFW add queue 123 ip from table\(11\) to any via igb3 out proto icmp > $IPFW add queue 124 ip from table\(11\) to any via igb3 out > > Firstly, we have been tested firewall by ourself. And we had no any bad results or any problems or maybe we have not seen them in our synthetic tests. After that we have started this firewall in production. A few months later we received a message from our subscriber with speed 1Mbit/s. He had a problems with online game (big answer delay from the server). We spent a lot of time to solve this problem. Finaly we solved it. The reason was in packet scheduling: > 1. we`ve tried to give to subscriber another channel (4Mbit/s) with packet scheduling - there are no such problems; > 2. we`ve tried to "turn off" the packet scheduling on 1Mbit channel - there are no such problems. > > The utilization of subscibers channel was always 0.4Mbit/s. But the traffic from this subscriber was go on under the packet scheduling rules. That`s very strange because of: > 1. net.inet.ip.dummynet.io_fast=1; > 2. subscribers channel utilization 0.4Mbit/s. > > As I know with this option, with this firewall config and with this channel utilization (0.4Mbit/s) traffic should bypass the pipe without packet scheduling. > > Why subscribers traffic with all these conditions doesn`t bypass through pipe without any delays? Why his traffic was on packet scheduling rules? > Thanks. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 16:39:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A4B41065693 for ; Mon, 11 Oct 2010 16:39:19 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8A88FC20 for ; Mon, 11 Oct 2010 16:39:18 +0000 (UTC) Received: by yxe42 with SMTP id 42so886243yxe.13 for ; Mon, 11 Oct 2010 09:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=BcGxtAnw0MOtkwnlemTitwlDrsW5bFQXNYLr/HAMKrQ=; b=BT0p+QtNDJqce8mx6F+XsgB7RpuzAcTvRqHos6k98BKgaJNZWnnfB7SzfEU/v36yBx 5qzPLxFDysimstnzvnma2WIFV09u2YgbS9OsXVanUSbiSYkH6W++XYO89YLEbLEnzf3T zI8AtINXSgUMI4JnICMsjwkbQUnSNrSoqnF+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=v76mD+rjzOCGzfJhJqHJeQdpByukGGgodiXEvCKhZ89q22Xt2VkacDrILn5ilULFtS uCSc4IgnOb74EFFOj/fYSSqH4+E8z7oJsaWytGFbvRE+8sGI/Tx2y2oCLqU0HDdpFncf MSzG76W1xWJTbAfElGVRfsm69LjwHrVedwlpM= Received: by 10.42.159.134 with SMTP id l6mr1811647icx.173.1286813496628; Mon, 11 Oct 2010 09:11:36 -0700 (PDT) Received: from itx (c-67-174-240-133.hsd1.ca.comcast.net [67.174.240.133]) by mx.google.com with ESMTPS id 8sm34641iba.4.2010.10.11.09.11.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 09:11:34 -0700 (PDT) Date: Mon, 11 Oct 2010 09:11:28 -0700 From: Navdeep Parhar To: Bill Desjardins Message-ID: <20101011161128.GA6026@itx> Mail-Followup-To: Bill Desjardins , freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: Re: [cxgb] Chelsio T304 quad gig pcie adapter TSO disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 16:39:19 -0000 On Mon, Oct 11, 2010 at 12:56:55AM -0400, Bill Desjardins wrote: > Hi All, > > I have a couple Chelsio T304 quad gigabit nics that are going into > iscsi servers. I got these for the TOE capabilities, but I found in > the cxgb driver code that it is explicitly disabled for > 2 port nics > (line 1036 : /usr/src/sys/dev/cxgb/cxgb_main.c) . The current cxgb > driver is based on the chelsio 7.8.0 firmware (11/25/09), but chelsio > is up to 7.11.0 (07/20/10). I had updated the firmware using cxgbtool > to 7.11, but received complaints from the driver to 'upgrade' to > 7.8.0, which I did. > > my question is, is if the cxgb driver is being worked on to update to > latest chelsio firmware and/or fix TSO for the quad port cards? I > don't have the programming skill's to assist with that side of things, > but I can easily provide a remote spare machine with a serial console > for development and testing if its helpful. Hello Bill, TSO is not supported on the T304 (not even with the 7.11.0 firmware). This is a 4 x gigabit card and you'll be able to max it out in either direction without TSO. > cxgbc0: Insufficient clusters and/or jumbo buffers. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^???? ^^ this indicates you need to bump up the number of clusters and jumbos. Do so in /boot/loader.conf if you load if_cxgb early, or in /etc/sysctl.conf if you load it after the system has booted up: /boot/loader.conf: kern.ipc.nmbclusters=262144 /etc/sysctl.conf: kern.ipc.nmbclusters=262144 kern.ipc.nmbjumbo9=262144 kern.ipc.nmbjumbo16=262144 Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 20:06:11 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5BC21065679 for ; Mon, 11 Oct 2010 20:06:11 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A22898FC1A for ; Mon, 11 Oct 2010 20:06:11 +0000 (UTC) Received: by vws1 with SMTP id 1so1532667vws.13 for ; Mon, 11 Oct 2010 13:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=gveUCdoqd9kEuYGxwtk833r253L1Yi/s+qGo7m6hIWg=; b=rNxrSg+tnxXkKYTJyh7UyPuQoiDDIZKfPPI877+yaJY05B0ReF/qNR5fhbJs9yG4X4 CNXPKFBW73NfZEf5vT1oTnSY8q75XG4DZ7gn0t0t7vau6FpT5xFLsp3sVzUC5pJ2dNDn L656fgUMqC+OmjtJ50Ch++Q38110by9z3SDbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=BmKYIejQEnjT3w9cMBHFlmNO9vhrvq/JWgLMpQjigfzR6Pm61TInE+v6hUN+k7fks+ w4MlUvJ+jb/S5qurlDH5ONhzzDFDtd0/o8R1c+H+Udgfl0cmwthT4Lcmwc9G4/uQRbxO Y1jUCYMR55ki/lYVPvhtmYRYTmfHCfraR8eTo= Received: by 10.220.193.137 with SMTP id du9mr2059190vcb.53.1286827570866; Mon, 11 Oct 2010 13:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.178.1 with HTTP; Mon, 11 Oct 2010 13:05:49 -0700 (PDT) From: Paul B Mahol Date: Mon, 11 Oct 2010 20:05:49 +0000 Message-ID: To: FreeBSD Net Content-Type: multipart/mixed; boundary=90e6ba53b4d63fb0ba04925ce455 Cc: Subject: if_ndis: fix for panic with VIMAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 20:06:12 -0000 --90e6ba53b4d63fb0ba04925ce455 Content-Type: text/plain; charset=ISO-8859-1 Hi, There is no single valid reason to call rt_ifmsg() in ndis_linksts_done() Patch attached. --90e6ba53b4d63fb0ba04925ce455 Content-Type: text/plain; charset=US-ASCII; name="patch.txt" Content-Disposition: attachment; filename="patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gf5rjsgo0 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvaWZfbmRpcy9pZl9uZGlzLmMgYi9zeXMvZGV2L2lmX25kaXMv aWZfbmRpcy5jCmluZGV4IDJlYzlkMGUuLmE0NjcyZTAgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvaWZf bmRpcy9pZl9uZGlzLmMKKysrIGIvc3lzL2Rldi9pZl9uZGlzL2lmX25kaXMuYwpAQCAtMTY0NCwx MCArMTY0NCw2IEBAIG5kaXNfbGlua3N0c19kb25lKGFkYXB0ZXIpCiAJZGVmYXVsdDoKIAkJYnJl YWs7CiAJfQotCi0JLyogTm90aWZ5IHBvc3NpYmxlIGxpc3RuZXJzIG9mIGludGVyZmFjZSBjaGFu Z2UuICovCi0KLQlydF9pZm1zZyhpZnApOwogfQogCiBzdGF0aWMgdm9pZAo= --90e6ba53b4d63fb0ba04925ce455-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 20:16:32 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 116271065696; Mon, 11 Oct 2010 20:16:32 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC9A28FC13; Mon, 11 Oct 2010 20:16:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9BKGVIw013247; Mon, 11 Oct 2010 20:16:31 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9BKGVwq013243; Mon, 11 Oct 2010 20:16:31 GMT (envelope-from yongari) Date: Mon, 11 Oct 2010 20:16:31 GMT Message-Id: <201010112016.o9BKGVwq013243@freefall.freebsd.org> To: pete@altadena.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/123961: [vr] [patch] Allow vr interface to handle vlans X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 20:16:32 -0000 Synopsis: [vr] [patch] Allow vr interface to handle vlans State-Changed-From-To: patched->closed State-Changed-By: yongari State-Changed-When: Mon Oct 11 20:15:37 UTC 2010 State-Changed-Why: Close, vr(4) should support VLAN oversized frame. If you happen to encounter the issue again please open a new PR. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Oct 11 20:15:37 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=123961 From owner-freebsd-net@FreeBSD.ORG Mon Oct 11 22:23:17 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C2A01065673 for ; Mon, 11 Oct 2010 22:23:17 +0000 (UTC) (envelope-from fty@cisco.com) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by mx1.freebsd.org (Postfix) with ESMTP id 5302D8FC13 for ; Mon, 11 Oct 2010 22:23:16 +0000 (UTC) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFcks0ytJV2b/2dsb2JhbACUD418cacynG+DDYI7BIpBgwk X-IronPort-AV: E=Sophos;i="4.57,316,1283731200"; d="scan'208";a="169303147" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 11 Oct 2010 21:54:39 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9BLsdWj024918 for ; Mon, 11 Oct 2010 21:54:39 GMT Received: from xmb-rcd-205.cisco.com ([72.163.62.212]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 16:54:39 -0500 Received: from 10.116.32.157 ([10.116.32.157]) by XMB-RCD-205.cisco.com ([72.163.62.212]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Oct 2010 21:54:38 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 11 Oct 2010 17:54:37 -0400 From: Frank T-Y To: Message-ID: Thread-Topic: 10GE adapters Thread-Index: ActpjuWwyWlU0uPfGkisONgAX4PG0A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Oct 2010 21:54:39.0047 (UTC) FILETIME=[E6E8A570:01CB698E] Subject: 10GE adapters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 22:23:17 -0000 Howdy - I remember seeing posts from Broadcom about the Net Extreme II 57711 (bxe) some time back - they had beta available a year or so ago but nothing since. Also, anyone know if the Qlogic QLE8152 (CNA) is on the radar? Thanks, Frank \\\\////\\\\////\\\\\////\\\\\////\\\\////\\\\//// Frank Terhaar-Yonkers W4FTY TRA 8325/L3 Cisco Systems, Inc. 7025 Kit Creek Road PO Box 14987 Research Triangle Park, North Carolina 27709 fty@cisco.com voice(919)392-2101 From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 03:32:10 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1145E1065673 for ; Tue, 12 Oct 2010 03:32:10 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 5449C8FC18 for ; Tue, 12 Oct 2010 03:32:08 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9C3W6Ex085258; Tue, 12 Oct 2010 10:32:06 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CB3D6B6.9060001@rdtc.ru> Date: Tue, 12 Oct 2010 10:32:06 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Hajimu UMEMOTO References: <4CB2AF28.30309@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 03:32:10 -0000 On 11.10.2010 18:05, Hajimu UMEMOTO wrote: > egrosbein> Is it a bug in our resolver? > > I think no, host(1) links ISC's resolver, and it doesn't use libc's > resolver. I suspect there is some problem in host(1) or ISC's > resolver. Is there a command capable of looking up MX records and linked with libc resolver in base system? It's a pity if we have no diagnostic utility that behaves just like ordinary applications like MTA dealing with DNS... How am I supposed to debug suspected MTA behavior without such utility? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 07:10:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A04A106566B for ; Tue, 12 Oct 2010 07:10:04 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 76CF58FC16 for ; Tue, 12 Oct 2010 07:10:03 +0000 (UTC) Received: (qmail 1615 invoked by uid 399); 12 Oct 2010 07:10:02 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2010 07:10:02 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB409DA.1060705@FreeBSD.org> Date: Tue, 12 Oct 2010 00:10:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CB2AF28.30309@rdtc.ru> <4CB3D6B6.9060001@rdtc.ru> In-Reply-To: <4CB3D6B6.9060001@rdtc.ru> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 07:10:04 -0000 On 10/11/2010 8:32 PM, Eugene Grosbein wrote: > On 11.10.2010 18:05, Hajimu UMEMOTO wrote: > >> egrosbein> Is it a bug in our resolver? >> >> I think no, host(1) links ISC's resolver, and it doesn't use libc's >> resolver. I suspect there is some problem in host(1) or ISC's >> resolver. > > Is there a command capable of looking up MX records and > linked with libc resolver in base system? > > It's a pity if we have no diagnostic utility that behaves just like > ordinary applications like MTA dealing with DNS... How am I supposed > to debug suspected MTA behavior without such utility? Step 1, verify that your authoritative name servers have MX records in the first place. As it turns out, they don't. The proper tool to use to diagnose DNS problems is dig. It's more complex than the tools that are designed to just give you the answer, but if everything were working right to start with you wouldn't need to diagnose anything. See how that works? :) Good luck, Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 09:25:37 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7551065674 for ; Tue, 12 Oct 2010 09:25:37 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id EA0C98FC14 for ; Tue, 12 Oct 2010 09:25:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9C95xK1026962; Tue, 12 Oct 2010 20:06:00 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 12 Oct 2010 20:05:59 +1100 (EST) From: Ian Smith To: Eugene Grosbein In-Reply-To: <4CB2AF28.30309@rdtc.ru> Message-ID: <20101012152857.X2036@sola.nimnet.asn.au> References: <4CB2AF28.30309@rdtc.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 09:25:37 -0000 On Mon, 11 Oct 2010, Eugene Grosbein wrote: > Hi! > > FreeBSD 8.1-STABLE: > > # host koin-nkz.com. > koin-nkz.com has address 62.231.164.101 > Host koin-nkz.com not found: 3(NXDOMAIN) > > This domain does not have MX records but NXDOMAIN seems to wrong return > code to me. Think about MTA that does look-up for MX first, > obtains NXDOMAIN and rejects mail. If a domain has no MX server, how's an MTA supposed to do mail with it? sola% host koin-nkz.com koin-nkz.com has address 62.231.164.101 Host koin-nkz.com not found: 2(SERVFAIL) I consistently get SERVFAIL for this one's MX server from here. Only querying its nameserver/s directly gets the proper (negative) answer: sola% dig +short koin-nkz.com ns ns.mtw.ru. ns1.mtw.ru. sola% dig +short @ns.mtw.ru koin-nkz.com 62.231.164.101 sola% dig +short @ns.mtw.ru koin-nkz.com mx sola% dig @ns.mtw.ru koin-nkz.com mx ; <<>> DiG 9.3.4-P1 <<>> @ns.mtw.ru koin-nkz.com mx ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12266 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;koin-nkz.com. IN MX ;; AUTHORITY SECTION: koin-nkz.com. 43200 IN NS ns.mtw.ru. koin-nkz.com. 43200 IN NS ns1.mtw.ru. ;; ADDITIONAL SECTION: ns.mtw.ru. 43200 IN A 194.135.30.55 ns1.mtw.ru. 43200 IN A 193.124.133.210 ;; Query time: 397 msec ;; SERVER: 194.135.30.55#53(194.135.30.55) ;; WHEN: Tue Oct 12 15:35:10 2010 ;; MSG SIZE rcvd: 103 Further, checking RDNS: sola% dig +short koin-nkz.com 62.231.164.101 sola% host 62.231.164.101 101.164.231.62.in-addr.arpa domain name pointer 62-231-164-101.rdtc.ru. sola% host 62-231-164-101.rdtc.ru. Host 62-231-164-101.rdtc.ru not found: 3(NXDOMAIN) But RDNS probably really only matters for the MX (when it gets one :) > tcpdump shows that after MX look-up failure resolver adds my local > domain suffix from /etc/resolv.conf's "search" clause and > goes to my local DNS server looking for MX record for > 'koin-nkz.com.my.ru.' that does not exists. Hence, NXDOMAIN. > > Is it a bug in our resolver? Well perhaps - but it works right when the proper DNS records exist. > I've tested 6.4-STABLE and 7.3-STABLE, same effect. Yes, same on the last 5-STABLE. > I've also tested 4.11-STABLE and it works correctly - no wrong > suffix addition, no NXDOMAIN. > > Eugene Grosbein cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 10:03:21 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCA8C1065672 for ; Tue, 12 Oct 2010 10:03:21 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 759358FC13 for ; Tue, 12 Oct 2010 10:03:21 +0000 (UTC) Received: by qyk30 with SMTP id 30so555360qyk.13 for ; Tue, 12 Oct 2010 03:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=GhM8KSxM7yB5NNdjRgQmAoMDTjhaz5aE2/p4OHmPqHM=; b=N4wF78VcTj/dcnBox8ibT34GHSuZQ/zO2knm0rnSQ5C0y2PrFdEkvbMtUu/af9JIJP U59HfgwbtCP1gdCUtVWOmdsx7ZQjv7bj2OiKvegDcqdgzGGb8hTRAUQ6QirlCEMVfwTm k5FnI/vYcUMMefAVIniSDRnLxF1udxZ9No0cM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=J1q8GAbiKhzSrwSBXnn2JqkFO/x2ZYHhaFtXR23fgfU0weVJtRxejfok1IYIJa8r46 R3tQIOLUKmdbB5Tng97OX6izSxHuU+TWDHVN/0HFHNd5X++JiGl+Nk2g48kdMpoVz+dU Nd3FNclXL3cuh1D1pcbhR2BVLk9XbtvCiwP60= MIME-Version: 1.0 Received: by 10.229.221.135 with SMTP id ic7mr6054645qcb.273.1286876369783; Tue, 12 Oct 2010 02:39:29 -0700 (PDT) Received: by 10.229.187.130 with HTTP; Tue, 12 Oct 2010 02:39:29 -0700 (PDT) In-Reply-To: <20101012152857.X2036@sola.nimnet.asn.au> References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> Date: Tue, 12 Oct 2010 10:39:29 +0100 Message-ID: From: Tom Evans To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 10:03:21 -0000 On Tue, Oct 12, 2010 at 10:05 AM, Ian Smith wrote: > On Mon, 11 Oct 2010, Eugene Grosbein wrote: > =C2=A0> Hi! > =C2=A0> > =C2=A0> FreeBSD 8.1-STABLE: > =C2=A0> > =C2=A0> # host koin-nkz.com. > =C2=A0> koin-nkz.com has address 62.231.164.101 > =C2=A0> Host koin-nkz.com not found: 3(NXDOMAIN) > =C2=A0> > =C2=A0> This domain does not have MX records but NXDOMAIN seems to wrong = return > =C2=A0> code to me. Think about MTA that does look-up for MX first, > =C2=A0> obtains NXDOMAIN and rejects mail. > > If a domain has no MX server, how's an MTA supposed to do mail with it? > The same way as has been done since they invented the MX record type - if no MX record exists, fallback to an A record. See RFC 5321, section 5.1. Cheers Tom From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 11:03:26 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 855F41065673 for ; Tue, 12 Oct 2010 11:03:26 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id E38A88FC18 for ; Tue, 12 Oct 2010 11:03:25 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9CB3Mjo088554; Tue, 12 Oct 2010 18:03:22 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CB4407A.5060907@rdtc.ru> Date: Tue, 12 Oct 2010 18:03:22 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Ian Smith References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> In-Reply-To: <20101012152857.X2036@sola.nimnet.asn.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 11:03:26 -0000 On 12.10.2010 16:05, Ian Smith wrote: > > # host koin-nkz.com. > > koin-nkz.com has address 62.231.164.101 > > Host koin-nkz.com not found: 3(NXDOMAIN) > > > > This domain does not have MX records but NXDOMAIN seems to wrong return > > code to me. Think about MTA that does look-up for MX first, > > obtains NXDOMAIN and rejects mail. > > If a domain has no MX server, how's an MTA supposed to do mail with it? Then it should try to use A record if it exists. > On Mon, 11 Oct 2010, Eugene Grosbein wrote: > > Hi! > > > > FreeBSD 8.1-STABLE: > > > Well perhaps - but it works right when the proper DNS records exist. What if koin-nkz.com.my.ru. would exist and have MX records? MX lookup would succeed... Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 12:18:15 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 242FB106564A for ; Tue, 12 Oct 2010 12:18:15 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D10D58FC12 for ; Tue, 12 Oct 2010 12:18:14 +0000 (UTC) Received: by vws1 with SMTP id 1so1931486vws.13 for ; Tue, 12 Oct 2010 05:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=m5Q8ZzVuyk22CgWBa1H1T4ZcdLvLJrGsBUTGZDiFpIM=; b=VeckomnI801/EoV07p7Y7ghCf1e0+c07ZpqMC1mos0ZE79JpTfOXE40Etar7gee8aw ljHfLNbcgrlPy0ic2h9pRse7ngEHG/fXWNE2PdztYcFlj5irS3hj9OPF8w+Pl8vvuhnF 8WXCVOkpal/nChQzWXeiH7LQlGozxzKgtBqTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dJ75YMro930EO/Qrdhbm37rOsqtu0SS82LFjjvGyaB1dsrV/hzTUZQb9Yv+1v+2oQe IrlfiBYcz9sVxnulbb1A1UNwsxkJOsDptGe+Dff1PUg2eYuFID/iD1Wnc0SyuIzeNnRt zSfVYqXv/35RqunJ2vNBOuLvVYB6zvVYKHtd4= MIME-Version: 1.0 Received: by 10.220.100.76 with SMTP id x12mr2330260vcn.65.1286885892988; Tue, 12 Oct 2010 05:18:12 -0700 (PDT) Received: by 10.220.178.1 with HTTP; Tue, 12 Oct 2010 05:18:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 12:18:12 +0000 Message-ID: From: Paul B Mahol To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: if_ndis: fix for panic with VIMAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:18:15 -0000 On 10/11/10, Paul B Mahol wrote: > Hi, > > There is no single valid reason to call rt_ifmsg() in ndis_linksts_done() > > Patch attached. > Ping. From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 12:52:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25716106566B; Tue, 12 Oct 2010 12:52:05 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 83F5C8FC18; Tue, 12 Oct 2010 12:52:04 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9CCYTFn088870; Tue, 12 Oct 2010 19:34:29 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CB455D5.1080902@rdtc.ru> Date: Tue, 12 Oct 2010 19:34:29 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Doug Barton References: <4CB2AF28.30309@rdtc.ru> <4CB3D6B6.9060001@rdtc.ru> <4CB409DA.1060705@FreeBSD.org> In-Reply-To: <4CB409DA.1060705@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:52:05 -0000 On 12.10.2010 14:10, Doug Barton wrote: >> It's a pity if we have no diagnostic utility that behaves just like >> ordinary applications like MTA dealing with DNS... How am I supposed >> to debug suspected MTA behavior without such utility? > > Step 1, verify that your authoritative name servers have MX records in > the first place. As it turns out, they don't. That is not my domain and I really don't care about its MX records/lame delegations/etc. I care about my resolver behavior. > > The proper tool to use to diagnose DNS problems is dig. It's more > complex than the tools that are designed to just give you the answer, > but if everything were working right to start with you wouldn't need to > diagnose anything. See how that works? :) Hmm, I don't want to debug DNS problems - indeed, dig is nice tool. I need to debug system resolver that is different thing, as you know. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 12:58:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 255C6106564A for ; Tue, 12 Oct 2010 12:58:20 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id 9C38B8FC0A for ; Tue, 12 Oct 2010 12:58:19 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id E4860103C53; Tue, 12 Oct 2010 14:42:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id fkXsjHVkHD7G; Tue, 12 Oct 2010 14:42:14 +0200 (CEST) Received: from [192.9.202.158] (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 85D8D103C39; Tue, 12 Oct 2010 14:42:11 +0200 (CEST) Message-ID: <4CB457C4.2020205@zirakzigil.org> Date: Tue, 12 Oct 2010 14:42:44 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: nfsv4 with kgssapi X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:58:20 -0000 I'm trying to setup a nfs server which uses the kerberized rpc header, so to overcome the problem with 16 groups: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg109809.html FreeBSD 8 amd64 stable last (yesterday) Following the man page for nfsv4 I have compiled the kernel with ----- options KGSSAPI device crypto ----- My files: /etc/exports ----- V4: /mydir -sec=krb5:krb5i:krb5p -network 192.168.0 -mask 255.255.255.0 ----- /etc/rc.conf ----- ... nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_enable="YES" gssd_enable="YES" ... ----- All daemons start ok, but in the logs I see: nfsd[...]: no gssd, using AUTH_SYS only Even though gssd is up and running. What's wrong? Thanks in advance. From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 13:25:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F08106564A for ; Tue, 12 Oct 2010 13:25:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 501898FC15 for ; Tue, 12 Oct 2010 13:25:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAAT4s0yDaFvO/2dsb2JhbACDHp8jqjiSU4EigzJ0BIpB X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="95000259" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 12 Oct 2010 08:56:23 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9889DB3F3E; Tue, 12 Oct 2010 08:56:23 -0400 (EDT) Date: Tue, 12 Oct 2010 08:56:23 -0400 (EDT) From: Rick Macklem To: Giulio Ferro Message-ID: <933937287.513420.1286888183571.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4CB457C4.2020205@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nfsv4 with kgssapi X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:25:15 -0000 > I'm trying to setup a nfs server which uses the kerberized rpc > header, so to overcome the problem with 16 groups: > > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg109809.html > > > FreeBSD 8 amd64 stable last (yesterday) > > Following the man page for nfsv4 I have compiled the kernel with > ----- > options KGSSAPI > device crypto > ----- > > My files: > > > /etc/exports > ----- > V4: /mydir -sec=krb5:krb5i:krb5p -network 192.168.0 -mask > 255.255.255.0 You also need an entry for the file system ("/mydir" ??) like: /mydir -sec=krb5:krb5i:krb5p -network 192.168.0.0 -mask 255.255.255.0 (The V4: line only sets where the NFSv4 root is, it does not actually export the file system, so something like the above line is needed as well.) > > /etc/rc.conf > ----- > ... > nfs_server_enable="YES" > nfsv4_server_enable="YES" > nfsuserd_enable="YES" > gssd_enable="YES" > ... > ----- > > All daemons start ok, but in the logs I see: > nfsd[...]: no gssd, using AUTH_SYS only > > Even though gssd is up and running. > You need an entry in your default keytab file (/etc/krb5.keytab) for the principal: nfs/@ using encryption type des-cbc-crc. If you don't have that, it might explain why it isn't working. Check /var/log/messages for any indications that there is a problem. Also, you might want to look at http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup if you haven't done so already. Good luck with it, rick ps: Kerberized NFS works for NFSv3 as well. From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 14:39:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA5F710656A4 for ; Tue, 12 Oct 2010 14:39:33 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBEA8FC17 for ; Tue, 12 Oct 2010 14:39:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9CEdVwV046340; Wed, 13 Oct 2010 01:39:31 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 13 Oct 2010 01:39:30 +1100 (EST) From: Ian Smith To: Tom Evans In-Reply-To: Message-ID: <20101013010757.N2036@sola.nimnet.asn.au> References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1241133225-1286894370=:2036" Cc: dougb@freebsd.org, net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:39:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1241133225-1286894370=:2036 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 12 Oct 2010, Tom Evans wrote: > On Tue, Oct 12, 2010 at 10:05 AM, Ian Smith wrote: > > On Mon, 11 Oct 2010, Eugene Grosbein wrote: > >  > Hi! > >  > > >  > FreeBSD 8.1-STABLE: > >  > > >  > # host koin-nkz.com. > >  > koin-nkz.com has address 62.231.164.101 > >  > Host koin-nkz.com not found: 3(NXDOMAIN) > >  > > >  > This domain does not have MX records but NXDOMAIN seems to wrong return > >  > code to me. Think about MTA that does look-up for MX first, > >  > obtains NXDOMAIN and rejects mail. > > > > If a domain has no MX server, how's an MTA supposed to do mail with it? > > > > The same way as has been done since they invented the MX record type - > if no MX record exists, fallback to an A record. See RFC 5321, section > 5.1. Well thanks Tom, I did - but which A record? Taking the '5.3. Master file example' in RFC1035, what is the A response for 'ISI.EDU.' where the domain itself has no specific A RR? Would it be that of VENERA.ISI.EDU, or that of the first A listed, ie A.ISI.EDU? And in either case - assuming a domain without any MX RR as above - why would that A response be expected to address a mail server? cc Doug for obvious reasons, ie I'm likely missing something obvious :) cheers, Ian (BTW I'd begun to reply off-list, as neither your private copy nor your reply to the list indicated cc'ing the other .. googlemail quaintness?) --0-1241133225-1286894370=:2036-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 15:30:55 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B5A1065670 for ; Tue, 12 Oct 2010 15:30:55 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3609E8FC31 for ; Tue, 12 Oct 2010 15:30:54 +0000 (UTC) Received: by qwe4 with SMTP id 4so2182147qwe.13 for ; Tue, 12 Oct 2010 08:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=luVabQMS4hLq2XkyyfDoghzgXzFQp6rhws2y+ANTdvA=; b=LRGjsB7D0WhJ8SAsG1rzsYrX/C2BuJFXreutN5gDSzB4G618bbPs26f8XRYFVqhJzw mWeTXaeqKX9e02xJlgf7KQU9mY/Z1PBGnHdpw4QU+rSZwcdXSVJYP6wgEnfd0WTxWMsN a7nB2GBQ3cCa28K3jtXE7rAEKJRAPM3uzyM3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WftZohEz7CywdTjyXAgjuuE36nWDRYNUPii1v6+3quMkiwy/PpnHQRHS9aXLMHAqDH J37Xx22uzgXxDi3nGSrPAk5TJmzdkKHbawNxHFY7a7QWplutJCuIL7eJIgLR/wylLPMb 2p4AbyBNYpFR/Mjm4UEbRYLeDi8XCChR067qs= MIME-Version: 1.0 Received: by 10.224.179.10 with SMTP id bo10mr5829324qab.297.1286897452915; Tue, 12 Oct 2010 08:30:52 -0700 (PDT) Received: by 10.229.187.130 with HTTP; Tue, 12 Oct 2010 08:30:52 -0700 (PDT) In-Reply-To: <20101013010757.N2036@sola.nimnet.asn.au> References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> <20101013010757.N2036@sola.nimnet.asn.au> Date: Tue, 12 Oct 2010 16:30:52 +0100 Message-ID: From: Tom Evans To: Ian Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dougb@freebsd.org, net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:30:55 -0000 On Tue, Oct 12, 2010 at 3:39 PM, Ian Smith wrote: > On Tue, 12 Oct 2010, Tom Evans wrote: > =C2=A0> On Tue, Oct 12, 2010 at 10:05 AM, Ian Smith wrote: > =C2=A0> > On Mon, 11 Oct 2010, Eugene Grosbein wrote: > =C2=A0> > =C2=A0> Hi! > =C2=A0> > =C2=A0> > =C2=A0> > =C2=A0> FreeBSD 8.1-STABLE: > =C2=A0> > =C2=A0> > =C2=A0> > =C2=A0> # host koin-nkz.com. > =C2=A0> > =C2=A0> koin-nkz.com has address 62.231.164.101 > =C2=A0> > =C2=A0> Host koin-nkz.com not found: 3(NXDOMAIN) > =C2=A0> > =C2=A0> > =C2=A0> > =C2=A0> This domain does not have MX records but NXDOMAIN seems= to wrong return > =C2=A0> > =C2=A0> code to me. Think about MTA that does look-up for MX fi= rst, > =C2=A0> > =C2=A0> obtains NXDOMAIN and rejects mail. > =C2=A0> > > =C2=A0> > If a domain has no MX server, how's an MTA supposed to do mail = with it? > =C2=A0> > > =C2=A0> > =C2=A0> The same way as has been done since they invented the MX record t= ype - > =C2=A0> if no MX record exists, fallback to an A record. See RFC 5321, se= ction > =C2=A0> 5.1. > > Well thanks Tom, I did - but which A record? > > Taking the '5.3. Master file example' in RFC1035, what is the A response > for 'ISI.EDU.' where the domain itself has no specific A RR? =C2=A0Would = it > be that of VENERA.ISI.EDU, or that of the first A listed, ie A.ISI.EDU? That domain has an MX record, so it wouldn't do either. When I do a dig isi.edu, I just get a single A record, so I would assume an SMTP server would attempt to deliver mail there. > > And in either case - assuming a domain without any MX RR as above - why > would that A response be expected to address a mail server? Initially, email came about just before people started using DNS, so mail servers were found using hostnames and directly delivering to the host. DNS then came into being, and you could look up a MD or MF record to find the mail host. This didn't work too well, which is why we MX records were invented. By that point, people had been relying on mail servers looking up an A record if MD/MF didn't exist, so the behaviour was preserved. > > cc Doug for obvious reasons, ie I'm likely missing something obvious :) > > cheers, Ian > > (BTW I'd begun to reply off-list, as neither your private copy nor your > reply to the list indicated cc'ing the other .. googlemail quaintness?) No gmail quaintness, PEBKAC. I replied off-list first, meaning to reply on-list, so I re-sent to list :/ Cheers Tom From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 16:30:25 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D13106566C for ; Tue, 12 Oct 2010 16:30:25 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 16F608FC12 for ; Tue, 12 Oct 2010 16:30:24 +0000 (UTC) Received: by qwe4 with SMTP id 4so2214575qwe.13 for ; Tue, 12 Oct 2010 09:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3W7EbTFVBMo4/4F0uOsTEi9TiQqmaks6Q3bezD/XAFY=; b=sO8ABhbFo1jKFsqOCfOJisvdIBtCNzEGI3GamwvVvc0Y+mhFGXGn9l5/uBWbt/GWwS ESKPyYb/U8m6+4I9y/ryCxglH16S/HPoDOuUaVCJNG1B77692Nas3oAFBe/UXWNWNjJl hxf0UtfO3xlpgpRb68vupB7s37ohKegDkQYkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gZz1cYsKj8YaOXjT9LMOhbpA83xcO4hV3qmC3KktQnM2Ngu/QWKYbqTMofV7kG/bjF elSXUO1G14/nmf2bsp9AoyxjN8TBDxI6MB2cETFIhOJluA/swhBdkxygMdS3Aj6IHPSa pxb1mKaikPacXK4qgYHPUSVgr4O+e7uZOBrV0= MIME-Version: 1.0 Received: by 10.229.238.200 with SMTP id kt8mr6490213qcb.0.1286901022688; Tue, 12 Oct 2010 09:30:22 -0700 (PDT) Received: by 10.229.187.130 with HTTP; Tue, 12 Oct 2010 09:30:22 -0700 (PDT) In-Reply-To: <09A363D1-B678-42E2-A841-D762D631D07B@mac.com> References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> <20101013010757.N2036@sola.nimnet.asn.au> <09A363D1-B678-42E2-A841-D762D631D07B@mac.com> Date: Tue, 12 Oct 2010 17:30:22 +0100 Message-ID: From: Tom Evans To: Chuck Swiger Content-Type: text/plain; charset=UTF-8 Cc: net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 16:30:25 -0000 On Tue, Oct 12, 2010 at 5:22 PM, Chuck Swiger wrote: > No, it would use the published MX records for the domain, and would first try delivering to vapor.isi.edu as the lowest precedence MX host listed: Thats what I said wasn't it? Oh wait, I missed the words 'If we assume it doesn't have an MX record' :/ >> That domain has an MX record, so it wouldn't do either. When I do a >> dig isi.edu, I just get a single A record, so I would assume an SMTP >> server would attempt to deliver mail there. Cheers Tom From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 16:43:15 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE34C106564A for ; Tue, 12 Oct 2010 16:43:15 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 9130D8FC18 for ; Tue, 12 Oct 2010 16:43:15 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LA6003R7RRI5Z40@asmtp028.mac.com> for net@freebsd.org; Tue, 12 Oct 2010 09:42:55 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-12_10:2010-10-12, 2010-10-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010120081 From: Chuck Swiger In-reply-to: Date: Tue, 12 Oct 2010 09:42:54 -0700 Message-id: <656752F9-2B23-4040-8418-5C80D7086B19@mac.com> References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> <20101013010757.N2036@sola.nimnet.asn.au> <09A363D1-B678-42E2-A841-D762D631D07B@mac.com> To: Tom Evans X-Mailer: Apple Mail (2.1081) Cc: net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 16:43:15 -0000 On Oct 12, 2010, at 9:30 AM, Tom Evans wrote: [ ... ] > Thats what I said wasn't it? > > Oh wait, I missed the words 'If we assume it doesn't have an MX record' :/ Yep. Perhaps we are in violent agreement...? :-) -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 17:23:22 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36297106566C for ; Tue, 12 Oct 2010 17:23:22 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1558FC12 for ; Tue, 12 Oct 2010 17:23:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LA600HLIQU4CB90@asmtp030.mac.com> for net@freebsd.org; Tue, 12 Oct 2010 09:22:53 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010120076 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-12_10:2010-10-12, 2010-10-12, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: Date: Tue, 12 Oct 2010 09:22:52 -0700 Message-id: <09A363D1-B678-42E2-A841-D762D631D07B@mac.com> References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> <20101013010757.N2036@sola.nimnet.asn.au> To: Tom Evans X-Mailer: Apple Mail (2.1081) Cc: Ian Smith , net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 17:23:22 -0000 On Oct 12, 2010, at 8:30 AM, Tom Evans wrote: >> Taking the '5.3. Master file example' in RFC1035, what is the A response >> for 'ISI.EDU.' where the domain itself has no specific A RR? Would it >> be that of VENERA.ISI.EDU, or that of the first A listed, ie A.ISI.EDU? > > That domain has an MX record, so it wouldn't do either. When I do a > dig isi.edu, I just get a single A record, so I would assume an SMTP > server would attempt to deliver mail there. No, it would use the published MX records for the domain, and would first try delivering to vapor.isi.edu as the lowest precedence MX host listed: % dig -t mx isi.edu ; <<>> DiG 9.6.0-APPLE-P2 <<>> -t mx isi.edu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9344 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;isi.edu. IN MX ;; ANSWER SECTION: isi.edu. 706 IN MX 30 boreas.isi.edu. isi.edu. 706 IN MX 50 yin.isi.edu. isi.edu. 706 IN MX 10 vapor.isi.edu. isi.edu. 706 IN MX 20 nitro.isi.edu. Only if no MX records were found, would an MTA fall back to using the A record here: ;; QUESTION SECTION: ;isi.edu. IN A ;; ANSWER SECTION: isi.edu. 86123 IN A 128.9.176.20 Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Oct 12 18:38:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BA8F1065670 for ; Tue, 12 Oct 2010 18:38:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF6E8FC0C for ; Tue, 12 Oct 2010 18:38:49 +0000 (UTC) Received: (qmail 10283 invoked by uid 399); 12 Oct 2010 18:38:47 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2010 18:38:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB4AB48.2050307@FreeBSD.org> Date: Tue, 12 Oct 2010 11:39:04 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Eugene Grosbein References: <4CB2AF28.30309@rdtc.ru> <4CB3D6B6.9060001@rdtc.ru> <4CB409DA.1060705@FreeBSD.org> <4CB455D5.1080902@rdtc.ru> In-Reply-To: <4CB455D5.1080902@rdtc.ru> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 18:38:50 -0000 On 10/12/2010 5:34 AM, Eugene Grosbein wrote: > On 12.10.2010 14:10, Doug Barton wrote: > >>> It's a pity if we have no diagnostic utility that behaves just like >>> ordinary applications like MTA dealing with DNS... How am I supposed >>> to debug suspected MTA behavior without such utility? >> >> Step 1, verify that your authoritative name servers have MX records in >> the first place. As it turns out, they don't. > > That is not my domain and I really don't care about > its MX records/lame delegations/etc. Ah. Sorry for the misunderstanding. > I care about my resolver behavior. Ok, well, that's working as advertised, so no problems then. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 01:57:35 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 435B9106564A for ; Wed, 13 Oct 2010 01:57:34 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3BC8FC0A for ; Wed, 13 Oct 2010 01:57:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9D1vUhd087294; Wed, 13 Oct 2010 12:57:31 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 13 Oct 2010 12:57:30 +1100 (EST) From: Ian Smith To: Tom Evans In-Reply-To: Message-ID: <20101013103715.V2036@sola.nimnet.asn.au> References: <4CB2AF28.30309@rdtc.ru> <20101012152857.X2036@sola.nimnet.asn.au> <20101013010757.N2036@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1776953488-1286935050=:2036" Cc: net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 01:57:35 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1776953488-1286935050=:2036 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Tue, 12 Oct 2010, Tom Evans wrote: > On Tue, Oct 12, 2010 at 3:39 PM, Ian Smith wrote: > > On Tue, 12 Oct 2010, Tom Evans wrote: > >  > On Tue, Oct 12, 2010 at 10:05 AM, Ian Smith wrote: [..] > >  > > If a domain has no MX server, how's an MTA supposed to do mail with it? > >  > > > >  > > >  > The same way as has been done since they invented the MX record type - > >  > if no MX record exists, fallback to an A record. See RFC 5321, section > >  > 5.1. > > > > Well thanks Tom, I did - but which A record? > > > > Taking the '5.3. Master file example' in RFC1035, what is the A response > > for 'ISI.EDU.' where the domain itself has no specific A RR?  Would it > > be that of VENERA.ISI.EDU, or that of the first A listed, ie A.ISI.EDU? > > That domain has an MX record, so it wouldn't do either. When I do a > dig isi.edu, I just get a single A record, so I would assume an SMTP > server would attempt to deliver mail there. Sorry, I didn't express that very well; I meant to literally use that example as written, um, 23 years ago, when the example had no A record for the domain itself as hostname, only for various specific hosts. It does these days of course, but it was a valid example to hand of a domain having no specific A record for the domain; not something I do, nor probably so common nowadays, though I not that infrequently find websites that only resolve with the www hostname. And then to compound the confusion, I suggested imagining a domain setup like that - having no A RR - but having no MX RRs either. From memory, I don't think an 'A' query for such a domain returns anything, but I didn't know where to find one to test offhand. > > And in either case - assuming a domain without any MX RR as above - why > > would that A response be expected to address a mail server? > > Initially, email came about just before people started using DNS, so > mail servers were found using hostnames and directly delivering to the > host. > > DNS then came into being, and you could look up a MD or MF record to > find the mail host. This didn't work too well, which is why we MX > records were invented. By that point, people had been relying on mail > servers looking up an A record if MD/MF didn't exist, so the behaviour > was preserved. Thanks. I guess if there's no A returned for the domain, or no mailserver on the A returned, our MTA will find out soon enough .. cheers, Ian --0-1776953488-1286935050=:2036-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 07:05:41 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 343CB106564A; Wed, 13 Oct 2010 07:05:41 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 93E648FC0A; Wed, 13 Oct 2010 07:05:40 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9D75bdx007584; Wed, 13 Oct 2010 14:05:37 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CB55A41.6000507@rdtc.ru> Date: Wed, 13 Oct 2010 14:05:37 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Doug Barton References: <4CB2AF28.30309@rdtc.ru> <4CB3D6B6.9060001@rdtc.ru> <4CB409DA.1060705@FreeBSD.org> <4CB455D5.1080902@rdtc.ru> <4CB4AB48.2050307@FreeBSD.org> In-Reply-To: <4CB4AB48.2050307@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 07:05:41 -0000 On 13.10.2010 01:39, Doug Barton wrote: >> I care about my resolver behavior. > > Ok, well, that's working as advertised, so no problems then. That's fine. And how about host(1)? It looks for MX record for synthetic domain names using suffixes from /etc/resolv.conf Hopefully it does not find but what if such names would exist and have MX records? host(1) would lie to me. Is it normal? $ host -v .koin-nkz.com. [skip] Trying "koin-nkz.com" Received 30 bytes from 127.0.0.1#53 in 149 ms Trying "koin-nkz.com.first.suffix.ru" Trying "koin-nkz.com.second.suffix.ru" Trying "koin-nkz.com.third.suffix.ru" Trying "koin-nkz.com.fourth.suffix.local" Host koin-nkz.com not found: 3(NXDOMAIN) Received 99 bytes from 127.0.0.1#53 in 0 ms From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 09:10:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 631DA1065672 for ; Wed, 13 Oct 2010 09:10:31 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 059228FC14 for ; Wed, 13 Oct 2010 09:10:30 +0000 (UTC) Received: (qmail invoked by alias); 13 Oct 2010 09:10:29 -0000 Received: from adsl-85.79.107.45.tellas.gr (EHLO moby.local) [79.107.45.85] by mail.gmx.com (mp-us001) with SMTP; 13 Oct 2010 05:10:29 -0400 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX18Ia8EY6FQIA3FzdL8MjkIUzsw+lAaXDOFkVJkivb nzLMFXpWBBeHXE Message-ID: <4CB57781.1030402@gmx.com> Date: Wed, 13 Oct 2010 12:10:25 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.23 (X11/20100313) MIME-Version: 1.0 To: Jon Otterholm References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org Subject: Re: VPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:10:31 -0000 Jon Otterholm wrote: > Are there any plans or ongoing work to implement VPLS in the network > stack? > > > > http://en.wikipedia.org/wiki/Virtual_Private_LAN_Service > If you don't need interoperability with others, you can theoretically achieve something like VPLS using if_bridge, if_gif, EtherIP and the "private" flag of if_bridge. Of course it would be a static setup and you'll have to create full mesh connections for all the participating nodes. Nikos From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 09:54:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E060E106566B for ; Wed, 13 Oct 2010 09:54:48 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC528FC0C for ; Wed, 13 Oct 2010 09:54:48 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2010 11:54:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPLS implementation Thread-Index: ActqupGOLIOFhHTQQiuWMdq2u68ogQAASCfA References: <4CB57781.1030402@gmx.com> <20101013.113223.74662610.sthaug@nethelp.no> From: "Jon Otterholm" To: Cc: freebsd-net@freebsd.org Subject: SV: VPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:54:49 -0000 > -----Ursprungligt meddelande----- > Fr=E5n: sthaug@nethelp.no [mailto:sthaug@nethelp.no] > Skickat: den 13 oktober 2010 11:32 > Till: Jon Otterholm > Kopia: freebsd-net@freebsd.org > =C4mne: Re: VPLS implementation >=20 > > > Are there any plans or ongoing work to implement VPLS in the = network > > > stack? > > > > > > http://en.wikipedia.org/wiki/Virtual_Private_LAN_Service > > > > If you don't need interoperability with others, you can = theoretically > > achieve something like VPLS using if_bridge, if_gif, EtherIP and the > > "private" flag of if_bridge. > > > > Of course it would be a static setup and you'll have to create full > > mesh connections for all the participating nodes. >=20 > The whole point of VPLS is to simulate a multipoint Ethernet segment, > possibly across a WAN and several MPLS PE routers. If you only have a = small > network it is usually far simpler to just set up a suitable collection = of switches > with VLAN trunks between them. >=20 > So the question is - *why* would you want FreeBSD to support VPLS? And > what exactly do you mean by implementing VPLS on FreeBSD? If you want = a > multipoint bridge across several interfaces, this can be done. If you = want > something with MPLS support (labels etc) it's a completely different = ball > game. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no I want to be able to interact with other vendors using VPLS. I am = familiar with 802.1Q, if_bridge and if_gif and its possibilities. //JO From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 09:59:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 987371065673 for ; Wed, 13 Oct 2010 09:59:05 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id CBDAF8FC12 for ; Wed, 13 Oct 2010 09:59:04 +0000 (UTC) Received: (qmail 17404 invoked from network); 13 Oct 2010 09:32:23 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Oct 2010 09:32:23 -0000 Date: Wed, 13 Oct 2010 11:32:23 +0200 (CEST) Message-Id: <20101013.113223.74662610.sthaug@nethelp.no> To: jon.otterholm@ide.resurscentrum.se From: sthaug@nethelp.no In-Reply-To: <4CB57781.1030402@gmx.com> References: <4CB57781.1030402@gmx.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:59:05 -0000 > > Are there any plans or ongoing work to implement VPLS in the network > > stack? > > > > http://en.wikipedia.org/wiki/Virtual_Private_LAN_Service > > If you don't need interoperability with others, you can > theoretically achieve something like VPLS using if_bridge, > if_gif, EtherIP and the "private" flag of if_bridge. > > Of course it would be a static setup and you'll have to create > full mesh connections for all the participating nodes. The whole point of VPLS is to simulate a multipoint Ethernet segment, possibly across a WAN and several MPLS PE routers. If you only have a small network it is usually far simpler to just set up a suitable collection of switches with VLAN trunks between them. So the question is - *why* would you want FreeBSD to support VPLS? And what exactly do you mean by implementing VPLS on FreeBSD? If you want a multipoint bridge across several interfaces, this can be done. If you want something with MPLS support (labels etc) it's a completely different ball game. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 10:36:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2EBF106564A for ; Wed, 13 Oct 2010 10:36:04 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 1BFBB8FC18 for ; Wed, 13 Oct 2010 10:36:03 +0000 (UTC) Received: (qmail 45276 invoked from network); 13 Oct 2010 10:36:02 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Oct 2010 10:36:02 -0000 Date: Wed, 13 Oct 2010 12:36:02 +0200 (CEST) Message-Id: <20101013.123602.41726980.sthaug@nethelp.no> To: jon.otterholm@ide.resurscentrum.se From: sthaug@nethelp.no In-Reply-To: References: <4CB57781.1030402@gmx.com> <20101013.113223.74662610.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: SV: VPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 10:36:05 -0000 > > So the question is - *why* would you want FreeBSD to support VPLS? And > > what exactly do you mean by implementing VPLS on FreeBSD? If you want a > > multipoint bridge across several interfaces, this can be done. If you want > > something with MPLS support (labels etc) it's a completely different ball > > game. > > > I want to be able to interact with other vendors using VPLS. I am familiar with 802.1Q, if_bridge and if_gif and its possibilities. If you want to interact with other vendors using VPLS, you need, as far as I can see, a full MPLS/VPLS implementation. I know there is some Quagga support for MPLS on Linux, don't know about FreeBSD. In any case this is a much more complex scenario than simple bridging. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 11:04:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 247CD1065670; Wed, 13 Oct 2010 11:04:57 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB3A8FC16; Wed, 13 Oct 2010 11:04:56 +0000 (UTC) Received: by gyf3 with SMTP id 3so1585862gyf.13 for ; Wed, 13 Oct 2010 04:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FmnrUex4CjnM75QJfA42JdvQTvm8kn9MiFt1JhEptUw=; b=WbAeTyOjyFs8YEucVk80GK59Dj5IgJ2AbhAmrpZp1HFgrDh0iRiBX7tqLqn1QwFMZq anJlB/0OrJYpyswC6iuChSY35VSlwyEF2fMk0JO4j+ut0s3IwaEVuZviDtkqmQa4vkZg Y4DscHfTMDKy9RNcAVRhAKHsbzs3humynHT2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AZviO6avwzfw5akY1JCjmspEyk+ISzogsT/houLAuWx+Ux/neQa3IAZTOBFf2RDMLs BXzmIJFVPyhqYN1F/xOuUMJXtZXT4+q0e4DK+udCsJ9ouoIP4akEDRysnC3rwiexmzI7 /v6bWGWQD17+SFAxpKU9cQ1EfKntob3LTNSsE= MIME-Version: 1.0 Received: by 10.151.42.5 with SMTP id u5mr819214ybj.259.1286967895490; Wed, 13 Oct 2010 04:04:55 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.150.143.19 with HTTP; Wed, 13 Oct 2010 04:04:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 13:04:54 +0200 X-Google-Sender-Auth: HVuO12zbGvEvfCtL0I3E8Q5_WfM Message-ID: From: Attilio Rao To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Nima Misaghian , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 11:04:57 -0000 2010/10/9 Robert Watson : > On Fri, 8 Oct 2010, Attilio Rao wrote: > >>> GENERAL FRAMEWORK ARCHITECTURE >>> >>> Netdump is composed, right now, by an userland "server" and a kernel >>> "client". The former is run on the target machine (where the dump will >>> phisically happen) and it is responsible for receiving =C2=A0the packet= s >>> containing coredumps frame and for correctly writing them on-disk. The >>> latter is part of the kernel installed on the source machine (where the= dump >>> is initiated) and is responsible for building correctly UDP packets >>> containing the coredump frames, pushing through the network interface a= nd >>> routing them appropriately. > > Hi Attilio: > > Network dumps would be a great addition to the FreeBSD debugging suite! = =C2=A0A > few casual comments and questions, I need to spend some more time ponderi= ng > the implications of the current netdump design later in the week. > > (1) Did you consider using tftp as the network dump protocol, rather than= a > custom protocol? =C2=A0It's also a simple UDP-based, ACKed file transfer > protocol, with the advantage that it's widely supported by exiting tftp > daemons, packet sniffers, security devices, etc. =C2=A0This wouldn't requ= ire > using a stock tftpd, although that would certainly be a benefit as well. > =C2=A0The post-processing of crashdumps that seems to happen in the netdu= mp > server could, presumably, happen "offline" as easily...? I don't understand the "offline" question but, really, I don't know why tftp wasn't considered in the first place. Let me do some small search and see how much we could benefit from it. > (2) Have you thought about adding a checksum to the dump format, since > packets are going over the wire on UDP, etc? =C2=A0Even an MD5 sum wouldn= 't be > too hard to arrange: all the code is in the kernel already, requires > relatively little state storage, and is designed for streamed data. Someone else already brought this point and I agree, we could use a checksum here. > (3) As the bounds checking/etc behavior in dumping grows more complex, it > seems a shame to replicate it in architecture-specific code. =C2=A0Could = we pull > the mediaoffset/mediasize checking into common code? =C2=A0Also, a reserv= ed > size/offset of "0" meaning "no limit" sounds slightly worrying; it might = be > slightly more conservative to add a flags field to dumperinfo and have a > flag indicating "size is no object" for netdump, rather than overloading = the > existing fields. I don't agree with you here. The real problem is that dumpsys is highly disk-specific (I've commented about it somewhere, maybe the e-mail or maybe the commit logs). What we'd need is to have something like netdumpsys() which tries to use network, but it is not short to make and the mediasize+mediaoffset concept really rappresents an higher bound which can't be 0. I think it is a reasonable compromise so far but it is subjected to further improvements for sure. > Some specific patch comments: > > + * XXX: This should be split into machdep and non-machdep parts > > What MD parts are in the file? This is just a stale comment. > The sysctl parts of the patch have a number of issues: Sysctl are still not overhauled just because I'm not sure we want to keep them. That is one of the points I raised in the main e-mail and I'd really would like to hear opinions about if we should keep them rather than having a setup userland process, etc. I'm sorry about this, but please keep in mind that the file still needs a lot of cleanup so some comments are a bit out of date and other parts may not be still perfectly overhauled. > +sysctl_force_crash(SYSCTL_HANDLER_ARGS) > > Does this belong in the netdump code? =C2=A0We already have some of these= options > in debug.kdb.*, but perhaps others should be added there as well. For this specific case, I'd really axe it out rather. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* get and fill a= header mbuf, then chain data as an > extended > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* mbuf. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MGETHDR(m, M_DONTWAIT,= MT_DATA); > > The idea of calling into the mbuf allocator in this context is just freak= y, > and may have some truly awful side effects. =C2=A0I suppose this is the c= ost of > trying to combine code paths in the network device driver rather than hav= e > an independent path in the netdump case, but it's quite unfortunate and w= ill > significantly reduce the robustness of netdumps in the face of, for examp= le, > mbuf starvation. I'm not sure in which other way we could fix that actually. Maybe a pre-allocated pool of mbufs? > + =C2=A0 =C2=A0 =C2=A0 if (ntohs(ah->ar_hrd) !=3D ARPHRD_ETHER && > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ntohs(ah->ar_hrd) !=3D ARPHRD_IEEE80= 2 && > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ntohs(ah->ar_hrd) !=3D ARPHRD_ARCNET= && > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ntohs(ah->ar_hrd) !=3D ARPHRD_IEEE13= 94) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NETDDEBUG("nd_handle_a= rp: unknown hardware address fmt " > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "0x%2D)\= n", (unsigned char *)&ah->ar_hrd, ""); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return; > + =C2=A0 =C2=A0 =C2=A0 } > > Are you sure you don't want to just check for ETHER here? I'd really like to hear Ryan's or Ed's idea here. > + =C2=A0 =C2=A0 =C2=A0 /* XXX: Probably should check if we're the recipie= nt MAC address */ > + =C2=A0 =C2=A0 =C2=A0 /* Done ethernet processing. Strip off the etherne= t header */ > > Yes, quite probably. =C2=A0What if you panic in promiscuous mode? > > + =C2=A0 =C2=A0 =C2=A0 /* > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* The first write (at offset 0) is the kerne= l dump header. =C2=A0Flag it > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* for the server to treat specially. =C2=A0X= XX: This doesn't strip out > the > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* footer KDH, although it shouldn't hurt any= thing. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > > The footer allows us to confirm that the tail end of a dump matches the > beginning; while probably not strictly necessary in this scenario, it's n= ot > a bad idea given the lack of a checksum. So I assume you are in favor of it, right? > + =C2=A0 =C2=A0 =C2=A0 /* Default the nic to the first available interfac= e */ > + =C2=A0 =C2=A0 =C2=A0 if ((ifn =3D TAILQ_FIRST(&ifnet)) !=3D NULL) do { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((ifn->if_flags & I= FF_UP) =3D=3D 0) > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 continue; > > More locking needed. Please refer to the second patch I posted. It should have proper locking and actually this code is just trimmed (more locking in V_ifnet accessings, but not in this codepath). > > - =C2=A0 =C2=A0 =C2=A0 void =C2=A0 =C2=A0*if_pspare[7]; > + =C2=A0 =C2=A0 =C2=A0 struct =C2=A0netdump_methods *if_ndumpfuncs; /* ne= tdump virtual methods > */ > + =C2=A0 =C2=A0 =C2=A0 void =C2=A0 =C2=A0*if_pspare[6]; > =C2=A0 =C2=A0 =C2=A0 =C2=A0int =C2=A0 =C2=A0 if_ispare[4]; > > In HEAD, at least, you should add your field and not use the spare. =C2= =A0The > spare should only be used on a merge to a KBI-stable branch (such as 8.x)= . Thanks, for picking this. > I need to ponder your changes to ifnet and to the drivers some more; I > recognize the benefits of maximal code alignment, but I worry a lot about > these code paths having side effects (not least, calls into memory > allocators, which in turn can enter VM, etc). =C2=A0I wonder if, given th= at, we > need to teach the mbuf allocator to be much more conservative if netdumpi= ng > is active... Sorry, which calls from drivers should get in the memory allocator? Are you just referring to the mbuf headers allocation? Changes to the drivers are mostly stright-forward -- they just try to do polling in locked or unlocked mode, following DDB entering or not (basically how other DDB-agnostic routines already do in FreeBSD for the known locking problems we discussed several times in the past). Thanks for your valuable feedback, looking forward to hear more. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 12:10:09 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86545106566C for ; Wed, 13 Oct 2010 12:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2148FC0C for ; Wed, 13 Oct 2010 12:10:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9DCA9YU069883 for ; Wed, 13 Oct 2010 12:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9DCA9Vx069882; Wed, 13 Oct 2010 12:10:09 GMT (envelope-from gnats) Date: Wed, 13 Oct 2010 12:10:09 GMT Message-Id: <201010131210.o9DCA9Vx069882@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eric Crist Cc: Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Crist List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 12:10:09 -0000 The following reply was made to PR kern/130628; it has been noted by GNATS. From: Eric Crist To: bug-followup@FreeBSD.org, bvowk@math.ualberta.ca Cc: Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R Date: Wed, 13 Oct 2010 06:51:55 -0500 Is there any follow-up to this bug? We're still seeing this (or a = similar issue) in 8.1-RELEASE.= From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 13:43:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8529B1065670; Wed, 13 Oct 2010 13:43:38 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 263488FC16; Wed, 13 Oct 2010 13:43:38 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Wed, 13 Oct 2010 09:43:37 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 6561E33C00; Wed, 13 Oct 2010 09:43:37 -0400 (EDT) Date: Wed, 13 Oct 2010 09:43:37 -0400 From: Ed Maste To: Attilio Rao Message-ID: <20101013134337.GA30028@sandvine.com> Mail-Followup-To: Ed Maste , Attilio Rao , Robert Watson , FreeBSD Current , freebsd-net@freebsd.org, Ryan Stone References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Ryan Stone , Robert Watson , FreeBSD Current Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 13:43:38 -0000 On Wed, Oct 13, 2010 at 01:04:54PM +0200, Attilio Rao wrote: > 2010/10/9 Robert Watson : > > (1) Did you consider using tftp as the network dump protocol, rather than a > > custom protocol? ??It's also a simple UDP-based, ACKed file transfer > > protocol, with the advantage that it's widely supported by exiting tftp > > daemons, packet sniffers, security devices, etc. ??This wouldn't require > > using a stock tftpd, although that would certainly be a benefit as well. > > ??The post-processing of crashdumps that seems to happen in the netdump > > server could, presumably, happen "offline" as easily...? > > I don't understand the "offline" question but, really, I don't know > why tftp wasn't considered in the first place. > Let me do some small search and see how much we could benefit from it. I think Robert means having something other than the netdump server doing the post-processing - e.g., a cron job could look in the directory where a tftp server saved a core file and run a script to extract the desired information. TFTP has a number of advantages; I'm not sure if the original author of the netdump code considered it and rejected it for some reason. I think the original implementation used a broadcast packet to locate the server though, so a custom server was required in any case. That said, I don't think it matters too much if we go ahead with the current version and switch to TFTP later on. > > (2) Have you thought about adding a checksum to the dump format, since > > packets are going over the wire on UDP, etc? ??Even an MD5 sum wouldn't be > > too hard to arrange: all the code is in the kernel already, requires > > relatively little state storage, and is designed for streamed data. > > Someone else already brought this point and I agree, we could use a > checksum here. Both a whole dump and per-packet checksum could be valuable. If we want the former I think this should be done in the dump infrastructure, so that disk dumps get it too. The latter conflicts somewhat with a desire to switch to TFTP though (other than a standard UDP packet checksum). > > The sysctl parts of the patch have a number of issues: > > Sysctl are still not overhauled just because I'm not sure we want to > keep them. That is one of the points I raised in the main e-mail and > I'd really would like to hear opinions about if we should keep them > rather than having a setup userland process, etc. > I'm sorry about this, but please keep in mind that the file still > needs a lot of cleanup so some comments are a bit out of date and > other parts may not be still perfectly overhauled. Attilio suggested adding a userland tool to configure netdump in lieu of the current sysctls. I don't have a strong opinion either way; the only real advantage to the sysctl approach that I see is that the use of the mirrored loader tunables is more obvious. > > The idea of calling into the mbuf allocator in this context is just freaky, > > and may have some truly awful side effects. ??I suppose this is the cost of > > trying to combine code paths in the network device driver rather than have > > an independent path in the netdump case, but it's quite unfortunate and will > > significantly reduce the robustness of netdumps in the face of, for example, > > mbuf starvation. > > I'm not sure in which other way we could fix that actually. Maybe a > pre-allocated pool of mbufs? Despite the freakiness, I can only offer the observation that it has worked very well for us in practise. > > + ?? ?? ?? if (ntohs(ah->ar_hrd) != ARPHRD_ETHER && > > + ?? ?? ?? ?? ?? ntohs(ah->ar_hrd) != ARPHRD_IEEE802 && > > ... > > > > Are you sure you don't want to just check for ETHER here? > > I'd really like to hear Ryan's or Ed's idea here. Interesting, I can't find this in our local version. It looks like this check was copied from if_ether.c::arpintr(). > > + ?? ?? ?? /* XXX: Probably should check if we're the recipient MAC address */ > > + ?? ?? ?? /* Done ethernet processing. Strip off the ethernet header */ > > > > Yes, quite probably. ??What if you panic in promiscuous mode? Well, the packet would get dropped at the next layer up, in nd_handle_ip. -Ed From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 16:41:30 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EFC71065672 for ; Wed, 13 Oct 2010 16:41:30 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E5E7B8FC19 for ; Wed, 13 Oct 2010 16:41:29 +0000 (UTC) Received: by fxm12 with SMTP id 12so2497564fxm.13 for ; Wed, 13 Oct 2010 09:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=AF+eaXrd55DNDy25KXLlqJdRKGuRv71OsS5C3jmfDvw=; b=cNaprVG0EXG55R9fPOfFuX4F2A7mxgzhG5tqJXYbNfNclCEonpr1mE9u/1cXoLf8Pj 4Bkr1j+A9PMJ/lyb8XlhkUKOIGzDhZj+qmGPHqeVEluVdXCBknhDG6lI3OFOpDNDZno1 yavAMvOPSU/WLULTC+Xch0y0oLmXUvGAov0HQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DZXoMHO6ibMnK+OaUvjuGWs8IR+vTIoHjEJ2kYNgb7/OThnZQEGJjwRphdMjdm2FX5 tcyUfEsHlHwrTZuLURGS8Tt3vc2Y3Pp+XSJH+zLFL4Mcj/ffufrYkDkG/fYpdHGKAVxQ X6YCTp27fTcQzEKCtWVb9agQNVZ48qT/kjKuc= MIME-Version: 1.0 Received: by 10.103.217.7 with SMTP id u7mr1507081muq.49.1286988088802; Wed, 13 Oct 2010 09:41:28 -0700 (PDT) Received: by 10.220.178.1 with HTTP; Wed, 13 Oct 2010 09:41:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 16:41:28 +0000 Message-ID: From: Paul B Mahol To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: if_ndis: fix for panic with VIMAGE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 16:41:30 -0000 On 10/12/10, Paul B Mahol wrote: > On 10/11/10, Paul B Mahol wrote: >> Hi, >> >> There is no single valid reason to call rt_ifmsg() in ndis_linksts_done() >> >> Patch attached. >> > Ping. Pong. From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 17:06:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAFA01065673 for ; Wed, 13 Oct 2010 17:06:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-7.mx.aerioconnect.net [216.240.47.67]) by mx1.freebsd.org (Postfix) with ESMTP id CB6718FC20 for ; Wed, 13 Oct 2010 17:06:48 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9DH6kRv027813; Wed, 13 Oct 2010 10:06:46 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 191C92D6017; Wed, 13 Oct 2010 10:06:45 -0700 (PDT) Message-ID: <4CB5E753.5080709@freebsd.org> Date: Wed, 13 Oct 2010 10:07:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: sthaug@nethelp.no References: <4CB57781.1030402@gmx.com> <20101013.113223.74662610.sthaug@nethelp.no> <20101013.123602.41726980.sthaug@nethelp.no> In-Reply-To: <20101013.123602.41726980.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org, jon.otterholm@ide.resurscentrum.se Subject: Re: SV: VPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 17:06:49 -0000 On 10/13/10 3:36 AM, sthaug@nethelp.no wrote: >>> So the question is - *why* would you want FreeBSD to support VPLS? And >>> what exactly do you mean by implementing VPLS on FreeBSD? If you want a >>> multipoint bridge across several interfaces, this can be done. If you want >>> something with MPLS support (labels etc) it's a completely different ball >>> game. >>> >> I want to be able to interact with other vendors using VPLS. I am familiar with 802.1Q, if_bridge and if_gif and its possibilities. > If you want to interact with other vendors using VPLS, you need, as > far as I can see, a full MPLS/VPLS implementation. > > I know there is some Quagga support for MPLS on Linux, don't know > about FreeBSD. In any case this is a much more complex scenario than > simple bridging. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > 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" > this is pretty much what netgraph was developed for. you can make a node that implements just the control part of VPLS and use the netgraph framework to hook it all together. From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 17:46:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A19106564A; Wed, 13 Oct 2010 17:46:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7761B8FC14; Wed, 13 Oct 2010 17:46:57 +0000 (UTC) Received: by ewy21 with SMTP id 21so1150113ewy.13 for ; Wed, 13 Oct 2010 10:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cVl9GYqaUJV/6wjFPm3t4KlO0pGyRLXf0fnJfrWB8QU=; b=pbjYfqg8LFKmYI2unYAO/8WAzcvFU217eRVZtUyZs2SJv/KmLWOBnaBcy1htEClx6u iwrnjhQXZ2eSFB//pQUEn6Sgg7qOHhsK9rGw7Bh52KSUD0v+7syJ7rEX88xZBWyyRL/O 6O16VncF9MrQ3fQC5iH/esNH+t4IQTCbdE/H0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uXY70TAS9Te13E/4zRMWkiC82CF9vkDz5awIvSTc3KsX2p6u6vYhifG0yb+6q3wIZ5 E6JNWtrs17RMuyNpGBkKl+1wlAwZ6KsSWxd1tHppGma1Sbkqbux377qJ5vhwoha1EbW2 Sp20bzZtJ5GdX536BDLIHYiQghRuB45zKKJPs= MIME-Version: 1.0 Received: by 10.213.27.135 with SMTP id i7mr902554ebc.29.1286992016979; Wed, 13 Oct 2010 10:46:56 -0700 (PDT) Received: by 10.213.105.208 with HTTP; Wed, 13 Oct 2010 10:46:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 13:46:56 -0400 Message-ID: From: Ryan Stone To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 17:46:59 -0000 On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote: > + /* > + * get and fill a header mbuf, then chain data as an > extended > + * mbuf. > + */ > + MGETHDR(m, M_DONTWAIT, MT_DATA); > > The idea of calling into the mbuf allocator in this context is just freaky, > and may have some truly awful side effects. I suppose this is the cost of > trying to combine code paths in the network device driver rather than have > an independent path in the netdump case, but it's quite unfortunate and will > significantly reduce the robustness of netdumps in the face of, for example, > mbuf starvation. Changing this will require very invasive changes to the network drivers. I know that the Intel drivers allocate their own mbufs for their receive rings and I imagine that all other drivers have to do something similar. Plus the drivers are responsible for freeing mbufs after they have been transmitted. It seems to me that the cost of making significant changes to the network drivers to support an alternate lifecycle for netdump mbufs far outweighs the cost of losing a couple of kernel dumps in extreme circumstances. From owner-freebsd-net@FreeBSD.ORG Wed Oct 13 19:25:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88A75106564A for ; Wed, 13 Oct 2010 19:25:11 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 3679E8FC08 for ; Wed, 13 Oct 2010 19:25:11 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward2.mail.yandex.net (Yandex) with ESMTP id A340838A89BA for ; Wed, 13 Oct 2010 23:17:39 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1286997459; bh=c+f212PwrqV0RlUa9Rih+wQJxXNDK/i6P1xlFhG0sEs=; h=Date:From:Reply-To:Message-ID:To:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=w+aWC0BQAY2WAv4n9DrBGSJGItT9BrpK5ulDD+vXwI6GCGjSV0AXc4+dhnazBUPcL jzrLgZUODY9fFYLm/0TbuaImNmKNR0QSfs/6YUpxdhNjak0HRsKS8kY60XTIaR05zD H4FQ4MHhtm86fUkyPoRT+OEcdtNgitf6wPEu2kkc= Received: from HOMEUSER (unknown [77.93.42.18]) by smtp1.mail.yandex.net (Yandex) with ESMTPA id 7068E290093 for ; Wed, 13 Oct 2010 23:17:39 +0400 (MSD) Date: Wed, 13 Oct 2010 22:17:38 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <1022300682.20101013221738@yandex.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Yandex-TimeMark: 1286997459 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Subject: src address issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:25:11 -0000 Hi, all Why with configured ip addresses fastvpn# ifconfig sis0 sis0: flags=8843 metric 0 mtu 1500 options=82008 ether 00:0b:6a:a6:0c:f0 inet 10.11.8.18 netmask 0xffffff00 broadcast 10.11.8.255 inet6 fe80::20b:6aff:fea6:cf0%sis0 prefixlen 64 scopeid 0x1 inet R.E.A.L netmask 0xfffffffc broadcast XX.XX.XX.XX nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active on other machine I got: kes# tcpdump -n -i rl0 port 1812 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 22:12:02.309034 IP R.E.A.L.19280 > 10.11.19.1.1812: RADIUS, Access Request (1), id: 0x38 length: 271 ^C How to stick mpd5 on fastvpn to send ip from 10.11.8.18 and not from R.E.A.L? PS. This seem not mpd problem, this is kernel issue, I think. -- С уважением, Коньков mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 02:59:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E041106566C for ; Thu, 14 Oct 2010 02:59:03 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 905908FC19 for ; Thu, 14 Oct 2010 02:59:02 +0000 (UTC) Received: by ewy21 with SMTP id 21so1461172ewy.13 for ; Wed, 13 Oct 2010 19:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=BdEO06knGqAv3R8Tg2ZvvEasy/Xfupql7TjvWBrjVlw=; b=ml64J6lakGK/3FroNH43kJwYpzi4F+8oo7lrTTqzcTwSIKNHv3WATkAssT0gSsOP/I NDI7UcUy+yVqPXYi1mdR2lDQ9u9kbJ7kEX8oQJqj5kbsfzZv6PEKy6T5SwLXLNmLnK+y LZ2z65Co0pzkTC0588WlPZH5AFcl/MqrLquO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=KkmITqWc3PbVEoLq2I8UMZctiuCfM7YauZobk0WoKv+17P2GkuTufoxyykT4/rBgxb THK/SV08zuBfb+zek+C/U2mD1LTO4EVT4xCyMR2xMTJnQ6oBNYsDQ4NdfWNMbMEYaYRx L8BChtOcT52144s38E3c3LorYNcgLaecizAHo= Received: by 10.213.17.12 with SMTP id q12mr1269014eba.13.1287025141437; Wed, 13 Oct 2010 19:59:01 -0700 (PDT) Received: from 76.dynamic-n195.in72.ru ([91.211.195.76]) by mx.google.com with ESMTPS id q51sm2098724eeh.4.2010.10.13.19.58.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Oct 2010 19:59:00 -0700 (PDT) Date: Thu, 14 Oct 2010 08:58:46 +0600 From: =?windows-1251?B?xOzo8vDo6SDH4Ozz8ODl4iAoRG1pdHJpeSBaYW11cmFldik=?= X-Priority: 3 (Normal) Message-ID: <641581546.20101014085846@gmail.com> To: kes-kes@yandex.ru In-Reply-To: <1022300682.20101013221738@yandex.ru> References: <1022300682.20101013221738@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: src address issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?xOzo8vDo6SDH4Ozz8ODl4iAoRG1pdHJpeSBaYW11cmFldik=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 02:59:03 -0000 you use default route from R.E.A.L IP, configure static route to network/host 10.11.19.1 via you 10.11.8.X gate. > Why with configured ip addresses > fastvpn# ifconfig sis0 > sis0: flags=3D8843 metric 0 mtu 1= 500 > options=3D82008 > ether 00:0b:6a:a6:0c:f0 > inet 10.11.8.18 netmask 0xffffff00 broadcast 10.11.8.255 > inet6 fe80::20b:6aff:fea6:cf0%sis0 prefixlen 64 scopeid 0x1 > inet R.E.A.L netmask 0xfffffffc broadcast XX.XX.XX.XX > nd6 options=3D29 > media: Ethernet autoselect (100baseTX ) > status: active > on other machine I got: > kes# tcpdump -n -i rl0 port 1812 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes > 22:12:02.309034 IP R.E.A.L.19280 > 10.11.19.1.1812: RADIUS, Access Reques= t (1), id: 0x38 length: 271 > ^C > How to stick mpd5 on fastvpn to send ip from 10.11.8.18 and not from R.E.= A.L? > PS. This seem not mpd problem, this is kernel issue, I think. From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 05:48:49 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 045BF106564A for ; Thu, 14 Oct 2010 05:48:49 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id A8AFD8FC1D for ; Thu, 14 Oct 2010 05:48:48 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward5.mail.yandex.net (Yandex) with ESMTP id EAF9E14D0561 for ; Thu, 14 Oct 2010 09:48:46 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287035326; bh=7j2CxVhDoFtbfGTaCGyfp1ICUOsuPhH7ZBQWD/oAesw=; h=Date:From:Reply-To:Message-ID:To:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=kOQyBXkfdgTztsGWzcFH4AybP2d5koPwYvURBeOk2uXR64hz9p+xMwGKa4ql3YBaQ OHZI6DFNqF08+ye66Zedi3/karlWjrJpoOmD7L1DvJfB6KWdMBZ/U2QMkeFAnVVD95 lYT+31232re94MTYB/S4SUfByMg6ElnkWkCncgHc= Received: from HOMEUSER (unknown [77.93.36.205]) by smtp4.mail.yandex.net (Yandex) with ESMTPA id B46D312808C for ; Thu, 14 Oct 2010 09:48:46 +0400 (MSD) Date: Thu, 14 Oct 2010 08:48:46 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <8710276544.20101014084846@yandex.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Yandex-TimeMark: 1287035326 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Subject: help tune X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 05:48:49 -0000 Hi, Freebsd-net. Help me pls, to tune those drops. fastvpn# netstat -s udp: 268701 datagrams received 0 with incomplete header 1 with bad data length field 12 with bad checksum 5229 with no checksum 208022 dropped due to no socket <<<<<<< 25412 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 35254 delivered 36778 datagrams output ip: 29905296 packets for this host 5251 packets for unknown/unsupported protocol 76959667 packets forwarded (0 packets fast forwarded) 29392 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 73000444 packets sent from this host 106902149 total packets received 35680 output packets dropped due to no bufs, etc. <<<<<<< I do this tuning: /etc/sysctl.conf hw.pci.enable_msix=1 hw.pci.enable_msi=1 kern.ipc.nmbclusters=262144 kern.ipc.shmall=65536 kern.ipc.shmmax=268435456 kern.ipc.somaxconn=4096 kern.ipc.semmap=512 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.ipc.maxsockets=262144 kern.coredump=1 net.graph.maxdgram=128000 net.graph.recvspace=128000 ddb.panic=5 /boot/loader.conf kern.ipc.nmbclusters=262144 kern.ipc.maxsockets=262144 net.graph.maxalloc=2048 kern.maxusers=1024 kern.ipc.maxpipekva=268435456 kern.maxfiles=204800 net.graph.maxdata=2048 kern.maxfilesperproc=200000 kern.ipc.maxsockbuf=524288 Mem: 42M Active, 183M Inact, 90M Wired, 20K Cache, 59M Buf, 170M Free Swap: 2048M Total, 2048M Free -- mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 06:03:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79655106566B for ; Thu, 14 Oct 2010 06:03:16 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 063558FC14 for ; Thu, 14 Oct 2010 06:03:15 +0000 (UTC) Received: by ewy21 with SMTP id 21so1512719ewy.13 for ; Wed, 13 Oct 2010 23:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=LEJzQYnf09zbzYxI5lm6VCImR2N900bF9zcTCLD6qus=; b=Ne7yzrwAlQrRzos2zz+xhokqaV8V3DHfLPqLQPQdBTvOo+/6nqZlt0fcxyyWQz9mx/ g5U8GR0QCnfAZs8k9+ujLqpq7CgOwLSsFjGq0F5pA1OBWDjOfEdnJroonXq4fCGSTg9M rimqK9OugUwTFdoguKpbkU6kGXG9lvHto+dI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=Fjo6EVVCWKKLbonWkRBCjIEao/uOz83ZmXHyeI3spKxSaq8aH3+7q1AyLo1MOZrdzc QKQudRokkXo3E/q52L9vwltQRswrHwezBKroZqJewrZYd86G8SteDOjMbejD7BKaBi55 BDlRbY7T+OYxhfb0IB4iT5aKQDYxyFgyu3tIg= Received: by 10.213.28.196 with SMTP id n4mr1340924ebc.48.1287036194970; Wed, 13 Oct 2010 23:03:14 -0700 (PDT) Received: from 76.dynamic-n195.in72.ru ([91.211.195.76]) by mx.google.com with ESMTPS id p53sm8836460eeh.7.2010.10.13.23.03.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Oct 2010 23:03:14 -0700 (PDT) Date: Thu, 14 Oct 2010 12:03:00 +0600 From: =?windows-1251?B?xOzo8vDo6SDH4Ozz8ODl4iAoRG1pdHJpeSBaYW11cmFldik=?= X-Priority: 3 (Normal) Message-ID: <1861551856.20101014120300@gmail.com> To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= In-Reply-To: <8710276544.20101014084846@yandex.ru> References: <8710276544.20101014084846@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: help tune X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?xOzo8vDo6SDH4Ozz8ODl4iAoRG1pdHJpeSBaYW11cmFldik=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 06:03:16 -0000 > Help me pls, to tune those drops. Clear _ALL_ tuning, use kernel-config-option maxusers 512 NOTE: kern.maxusers in /boot/loader.conf may not been used on some releases, but in newer releases must to be. > I do this tuning: > /etc/sysctl.conf > hw.pci.enable_msix=3D1 > hw.pci.enable_msi=3D1 > kern.ipc.nmbclusters=3D262144 > kern.ipc.shmall=3D65536 > kern.ipc.shmmax=3D268435456 > kern.ipc.somaxconn=3D4096 > kern.ipc.semmap=3D512 > kern.maxfiles=3D204800 > kern.maxfilesperproc=3D200000 > kern.ipc.maxsockets=3D262144 > kern.coredump=3D1 > net.graph.maxdgram=3D128000 > net.graph.recvspace=3D128000 > ddb.panic=3D5 > /boot/loader.conf > kern.ipc.nmbclusters=3D262144 > kern.ipc.maxsockets=3D262144 > net.graph.maxalloc=3D2048 > kern.maxusers=3D1024 > kern.ipc.maxpipekva=3D268435456 > kern.maxfiles=3D204800 > net.graph.maxdata=3D2048 > kern.maxfilesperproc=3D200000 > kern.ipc.maxsockbuf=3D524288 From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 06:42:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76459106564A for ; Thu, 14 Oct 2010 06:42:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 03D778FC15 for ; Thu, 14 Oct 2010 06:42:50 +0000 (UTC) Received: (qmail 26287 invoked by uid 399); 14 Oct 2010 06:42:50 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Oct 2010 06:42:50 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB6A67C.2070208@FreeBSD.org> Date: Wed, 13 Oct 2010 23:43:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Eugene Grosbein References: <4CB2AF28.30309@rdtc.ru> <4CB3D6B6.9060001@rdtc.ru> <4CB409DA.1060705@FreeBSD.org> <4CB455D5.1080902@rdtc.ru> <4CB4AB48.2050307@FreeBSD.org> <4CB55A41.6000507@rdtc.ru> In-Reply-To: <4CB55A41.6000507@rdtc.ru> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 06:42:51 -0000 On 10/13/2010 12:05 AM, Eugene Grosbein wrote: > On 13.10.2010 01:39, Doug Barton wrote: > >>> I care about my resolver behavior. >> >> Ok, well, that's working as advertised, so no problems then. > > That's fine. And how about host(1)? > It looks for MX record for synthetic domain names > using suffixes from /etc/resolv.conf You said you wanted something that exercised the resolver, make up your mind. :) > Hopefully it does not find but what if such names would exist > and have MX records? host(1) would lie to me. No, it would act the way it's supposed to. If there is an answer that you should get, it will give it to you. If you want to debug something that isn't working the way you think it should, use dig. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 08:01:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F8011065673; Thu, 14 Oct 2010 08:01:34 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 402018FC1C; Thu, 14 Oct 2010 08:01:34 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 368C646B2E; Thu, 14 Oct 2010 04:01:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 14 Oct 2010 09:01:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Stone X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 08:01:34 -0000 On 13 Oct 2010, at 18:46, Ryan Stone wrote: > On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson = wrote: >> + /* >> + * get and fill a header mbuf, then chain data as an >> extended >> + * mbuf. >> + */ >> + MGETHDR(m, M_DONTWAIT, MT_DATA); >>=20 >> The idea of calling into the mbuf allocator in this context is just = freaky, >> and may have some truly awful side effects. I suppose this is the = cost of >> trying to combine code paths in the network device driver rather than = have >> an independent path in the netdump case, but it's quite unfortunate = and will >> significantly reduce the robustness of netdumps in the face of, for = example, >> mbuf starvation. >=20 > Changing this will require very invasive changes to the network > drivers. I know that the Intel drivers allocate their own mbufs for > their receive rings and I imagine that all other drivers have to do > something similar. Plus the drivers are responsible for freeing mbufs > after they have been transmitted. It seems to me that the cost of > making significant changes to the network drivers to support an > alternate lifecycle for netdump mbufs far outweighs the cost of losing > a couple of kernel dumps in extreme circumstances. My concern is less about occasional lost dumps that destabilising the = dumping process: calls into the memory allocator can currently trigger a = lot of interesting behaviours, such as further calls back into the VM = system, which can then trigger calls into other subsystems. What I'm = suggesting is that if we want the mbuf allocator to be useful in this = context, we need to teach it about things not to do in the dumping / = crash / ... context, which probably means helping uma out a bit in that = regard. And a watchdog to make sure the dump is making progress. Robert= From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 09:43:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06ED5106566C; Thu, 14 Oct 2010 09:43:25 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 499C08FC13; Thu, 14 Oct 2010 09:43:23 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id o9E9hKRO019994; Thu, 14 Oct 2010 16:43:20 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4CB6D0B8.6090305@rdtc.ru> Date: Thu, 14 Oct 2010 16:43:20 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Doug Barton References: <4CB2AF28.30309@rdtc.ru> <4CB3D6B6.9060001@rdtc.ru> <4CB409DA.1060705@FreeBSD.org> <4CB455D5.1080902@rdtc.ru> <4CB4AB48.2050307@FreeBSD.org> <4CB55A41.6000507@rdtc.ru> <4CB6A67C.2070208@FreeBSD.org> In-Reply-To: <4CB6A67C.2070208@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 09:43:25 -0000 On 14.10.2010 13:43, Doug Barton wrote: >> Hopefully it does not find but what if such names would exist >> and have MX records? host(1) would lie to me. > > No, it would act the way it's supposed to. Is host(1) supposed to do lookups using suffixes from /etc/resolv.conf for FQDN with dot at the end? $ host koin-nkz.com. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 14:10:42 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23768106564A; Thu, 14 Oct 2010 14:10:42 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDC08FC1D; Thu, 14 Oct 2010 14:10:41 +0000 (UTC) Received: by qyk31 with SMTP id 31so51371qyk.13 for ; Thu, 14 Oct 2010 07:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=VdrfBunv2f7NPCMKPfpABT+EG3J7PPEg7UNCTulp8Ok=; b=D2qKjp2jK2BNzg9HLFqHb/wjsobhlPkrFIIE1lIRamyi/As/ZtN1qoGA5yMOMSWOEi jljDNcdOgBJk8Ip8VDO79EUGILRWAp0Wu1pexZlF8bxu0Ct5nKcaItA/4WNdKxAMtP3l MoMvZ7Vt3em2vI/PAbUm0x3CZFhgiiy77uEnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vEnv7Dz1Vr0+hEOBSCvBOwE8MoaajplkKQS0ravA623OD/+QqOzfKUyoYnSb1KEwua mF5a+nCJ7DJ1ASG0zhrnCT7rLbB1sh3mErExAbb6H3ZMQFq/Ef/kvpMGcVbh2k1cR6FN WJZTJncob71IbUbG8PUrCqJtoZ8bUBjqINB3c= MIME-Version: 1.0 Received: by 10.224.76.78 with SMTP id b14mr7891677qak.75.1287065440468; Thu, 14 Oct 2010 07:10:40 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Thu, 14 Oct 2010 07:10:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Oct 2010 16:10:26 +0200 X-Google-Sender-Auth: vsnm9Bpqhonyk5rLnsHoFrpYpkU Message-ID: From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:10:42 -0000 2010/10/14 Robert N. M. Watson : > > On 13 Oct 2010, at 18:46, Ryan Stone wrote: > >> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrot= e: >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* get and fill= a header mbuf, then chain data as an >>> extended >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* mbuf. >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MGETHDR(m, M_DONTWAI= T, MT_DATA); >>> >>> The idea of calling into the mbuf allocator in this context is just fre= aky, >>> and may have some truly awful side effects. =C2=A0I suppose this is the= cost of >>> trying to combine code paths in the network device driver rather than h= ave >>> an independent path in the netdump case, but it's quite unfortunate and= will >>> significantly reduce the robustness of netdumps in the face of, for exa= mple, >>> mbuf starvation. >> >> Changing this will require very invasive changes to the network >> drivers. =C2=A0I know that the Intel drivers allocate their own mbufs fo= r >> their receive rings and I imagine that all other drivers have to do >> something similar. =C2=A0Plus the drivers are responsible for freeing mb= ufs >> after they have been transmitted. =C2=A0It seems to me that the cost of >> making significant changes to the network drivers to support an >> alternate lifecycle for netdump mbufs far outweighs the cost of losing >> a couple of kernel dumps in extreme circumstances. > > My concern is less about occasional lost dumps that destabilising the dum= ping process: calls into the memory allocator can currently trigger a lot o= f interesting behaviours, such as further calls back into the VM system, wh= ich can then trigger calls into other subsystems. What I'm suggesting is th= at if we want the mbuf allocator to be useful in this context, we need to t= each it about things not to do in the dumping / crash / ... context, which = probably means helping uma out a bit in that regard. And a watchdog to make= sure the dump is making progress. I think that this would be way too complicated just to cope with panic within the VM/UMA (not sure what other subsystems you are referring to, wrt supposed to call). Besides, if we have a panic in the VM I'm sure that normal dumps could also be affected. When dealing with netdump, I'm not trying to fix all the bugs related to our dumping infrastructure because, as long as we already discussed, we know there are quite a few of them, but trying at least to follow the same fragile-ness than what we have today. And again, while I think the "watchdog" idea is good, I think it still applies to normal dumps too, it is not specific to netdump. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 14:23:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F781065793; Thu, 14 Oct 2010 14:23:37 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 261C58FC18; Thu, 14 Oct 2010 14:23:37 +0000 (UTC) Received: from [192.168.33.146] (lapwing-gw-1.csx.cam.ac.uk [131.111.1.66]) by cyrus.watson.org (Postfix) with ESMTPSA id AA26846B8F; Thu, 14 Oct 2010 10:23:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 14 Oct 2010 15:23:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> References: To: Attilio Rao X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:23:37 -0000 On 14 Oct 2010, at 15:10, Attilio Rao wrote: >> My concern is less about occasional lost dumps that destabilising the = dumping process: calls into the memory allocator can currently trigger a = lot of interesting behaviours, such as further calls back into the VM = system, which can then trigger calls into other subsystems. What I'm = suggesting is that if we want the mbuf allocator to be useful in this = context, we need to teach it about things not to do in the dumping / = crash / ... context, which probably means helping uma out a bit in that = regard. And a watchdog to make sure the dump is making progress. >=20 > I think that this would be way too complicated just to cope with panic > within the VM/UMA (not sure what other subsystems you are referring > to, wrt supposed to call). Besides, if we have a panic in the VM I'm > sure that normal dumps could also be affected. > When dealing with netdump, I'm not trying to fix all the bugs related > to our dumping infrastructure because, as long as we already > discussed, we know there are quite a few of them, but trying at least > to follow the same fragile-ness than what we have today. > And again, while I think the "watchdog" idea is good, I think it still > applies to normal dumps too, it is not specific to netdump. No, what I'm saying is: UMA needs to not call its drain handlers, and = ideally not call into VM to fill slabs, from the dumping context. That's = easy to implement and will cause the dump to fail rather than causing = the system to hang. Robert= From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 15:20:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC8FC1065693; Thu, 14 Oct 2010 15:20:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1196B8FC25; Thu, 14 Oct 2010 15:20:21 +0000 (UTC) Received: by qwe4 with SMTP id 4so3482780qwe.13 for ; Thu, 14 Oct 2010 08:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=aGR+ahDzDeBmYoN2FBFGhAYTsSu0bowfGBkF05Qxdp8=; b=MYEehXmmjpYjbFUjyrxhICH0fwkA9J+fZb3By1kOMJuCIzMhFcDWCWTD+lx7VGalKz wok5lZS9CNSQ9BYVDZ5vmEKY9oqr17pPclnR0DIGhT4ggGRxn+5AF95XI9Fwie7rq3YB kEoOlter0JGnzM2lFDSjd+Nx7Wm81qql150cI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OkJAU5GANxCzsAvSSffUzfry8mOndjzLWel/8gpZQbh3mVEPUnfu6dKIH/EvGewuxc Y+O8n6WJECwqNBhgjT6A8CNcWaua2wd0L2laUh4vcp6eQGNYO4Zj2xEUOR0a4RoyOK5e E+ExxR0dhuk/+Ek/Zjw/PyHiHZ+BUyYKxL/Yo= MIME-Version: 1.0 Received: by 10.224.29.4 with SMTP id o4mr830471qac.38.1287069621115; Thu, 14 Oct 2010 08:20:21 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Thu, 14 Oct 2010 08:20:19 -0700 (PDT) In-Reply-To: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> Date: Thu, 14 Oct 2010 17:20:19 +0200 X-Google-Sender-Auth: EALIKnMFJ19fQUtHNvbKXUyJay0 Message-ID: From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 15:20:23 -0000 2010/10/14 Robert N. M. Watson : > > On 14 Oct 2010, at 15:10, Attilio Rao wrote: > >>> My concern is less about occasional lost dumps that destabilising the d= umping process: calls into the memory allocator can currently trigger a lot= of interesting behaviours, such as further calls back into the VM system, = which can then trigger calls into other subsystems. What I'm suggesting is = that if we want the mbuf allocator to be useful in this context, we need to= teach it about things not to do in the dumping / crash / ... context, whic= h probably means helping uma out a bit in that regard. And a watchdog to ma= ke sure the dump is making progress. >> >> I think that this would be way too complicated just to cope with panic >> within the VM/UMA (not sure what other subsystems you are referring >> to, wrt supposed to call). Besides, if we have a panic in the VM I'm >> sure that normal dumps could also be affected. >> When dealing with netdump, I'm not trying to fix all the bugs related >> to our dumping infrastructure because, as long as we already >> discussed, we know there are quite a few of them, but trying at least >> to follow the same fragile-ness than what we have today. >> And again, while I think the "watchdog" idea is good, I think it still >> applies to normal dumps too, it is not specific to netdump. > > No, what I'm saying is: UMA needs to not call its drain handlers, and ide= ally not call into VM to fill slabs, from the dumping context. That's easy = to implement and will cause the dump to fail rather than causing the system= to hang. Ok. My point is, however, still the same: that should not happen just for the netdump specific case but for all the dumping/KDB/panic cases (I know it is unlikely current code !netdump calls into UMA but it is not an established pre-requisite and may still happen that some added code does). I still see this as a weakness on the infrastructure, independently from netdump. I can see that your point is that it is vital to netdump correct behaviour though, so I'd wonder if it worths fixing it now or later. More people's comment would be appreciated. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 17:44:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BBCA106567A for ; Thu, 14 Oct 2010 17:44:53 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward6.mail.yandex.net (forward6.mail.yandex.net [77.88.60.125]) by mx1.freebsd.org (Postfix) with ESMTP id 8F96D8FC1D for ; Thu, 14 Oct 2010 17:44:52 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward6.mail.yandex.net (Yandex) with ESMTP id 77FFDBB026D for ; Thu, 14 Oct 2010 21:44:50 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287078290; bh=1+ZBmD4c7MWigeOifqWoMtx16P5l7xfwPIC4R73qDvw=; h=Date:From:Reply-To:Message-ID:To:Subject:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WJ8ImPi3U4BTUwf0A0lgWI7yoA9O3dpRinmSPlDyKiMC/OXeWxxAlG67OEqcdeWo4 5zrMI+IGot9A09T0rUS+bT3AL32ca3STEaW0gmJ8sjbN70ZliVc0t2Vgl3Rr/YqAfd 3MxIVdBduM+HrpDIpfzVKH3mGQ5ewrGfRgfiL07A= Received: from HOMEUSER (unknown [77.93.36.205]) by smtp8.mail.yandex.net (Yandex) with ESMTPA id 0964B202809C for ; Thu, 14 Oct 2010 21:44:49 +0400 (MSD) Date: Thu, 14 Oct 2010 20:44:50 +0300 From: Eugen Konkov X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <801172760.20101014204450@yandex.ru> To: freebsd-net@freebsd.org In-Reply-To: <1861551856.20101014120300@gmail.com> References: <8710276544.20101014084846@yandex.ru> <1861551856.20101014120300@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Yandex-TimeMark: 1287078290 X-Yandex-Spam: 1 X-Yandex-Front: smtp8.mail.yandex.net Subject: problem with net subsystem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 17:44:53 -0000 Hi #top -SI last pid: 67653; load averages: 1.23, 1.12, 1.24 up 1+09:46:14 20:22:34 94 processes: 3 running, 76 sleeping, 15 waiting CPU: 0.0% user, 0.0% nice, 33.3% system, 66.7% interrupt, 0.0% idle Mem: 54M Active, 226M Inact, 103M Wired, 59M Buf, 103M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 13 root 1 106 - 0K 8K RUN 251:36 49.02% ng_queue 11 root 1 171 ki31 0K 8K RUN 21.5H 35.60% idle 12 root 15 -44 - 0K 120K WAIT 31:04 12.06% intr 0 root 9 -68 0 0K 64K - 18:13 0.49% kernel 67618 root 1 44 0 10020K 2312K ttyin 0:00 0.34% systat 18710 root 2 44 0 84660K 62868K select 16:11 0.29% mpd5 67653 root 1 44 0 9944K 2020K RUN 0:00 0.15% top there are no queues nor pipes in ipfw. #systat -v users Load Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act count All pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow total zfod ozfod . %Sys . %Intr . %User . %Nice . %Idle %ozfod | | | | | | | | | | | daefr prcfr dtbuf totfr Namei Name-cache Dir-cache desvn react Calls hits % hits % numvn pdwak frevn pdpgs intrn Disks ad0 wire KB/t act tps inact MB/s cache %busy free # vmstat -i interrupt total rate irq1: atkbd0 1203 0 irq14: ata0 139502 1 irq15: ata1 35 0 irq19: sis0 0 0 cpu0:timer 258485585 2124 Total 783059828 6436 # ifconfig sis0 sis0: flags=8843 metric 0 mtu 1500 options=82048 ether 00:0b:6a:a6:0c:f0 inet 10.11.8.18 netmask 0xffffff00 broadcast 10.11.8.255 inet6 fe80::20b:6aff:fea6:cf0%sis0 prefixlen 64 scopeid 0x1 inet R.E.A.L netmask 0xfffffffc broadcast X.X.X.X nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active #netstat -s tcp: 205416 packets sent 124715 data packets (8022081 bytes) 1425 data packets (99472 bytes) retransmitted 38 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 75509 ack-only packets (64514 delayed) 0 URG only packets 0 window probe packets 0 window update packets 3824 control packets 1653273 packets received 115656 acks (for 8017539 bytes) 1967 duplicate acks 0 acks for unsent data 104386 packets (4886466 bytes) received in-sequence 62 completely duplicate packets (1512 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 4 out-of-order packets (112 bytes) 0 packets (0 bytes) of data after window 0 window probes 3 window update packets 1 packet received after close 4 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 1441 connection requests 1091 connection accepts 0 bad connection attempts 6726 listen queue overflows 25 ignored RSTs in the windows 2530 connections established (including accepts) 111289 connections closed (including 214 drops) 2185 connections updated cached RTT on close 2267 connections updated cached RTT variance on close 1516 connections updated cached ssthresh on close 2 embryonic connections dropped 107299 segments updated rtt (of 107034 attempts) 1434 retransmit timeouts 68 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 554 correct ACK header predictions 19107 correct data packet header predictions 6278 syncache entries added 4 retransmitted 0 dupsyn 5 dropped 1091 completed 0 bucket overflow 0 cache overflow 1 reset 0 stale 6726 aborted 0 badack 0 unreach 0 zone failures 6283 cookies sent 1540 cookies received 19 SACK recovery episodes 40 segment rexmits in SACK recovery episodes 18640 byte rexmits in SACK recovery episodes 298 SACK options (SACK blocks) received 2 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 2633751 datagrams received 0 with incomplete header 1 with bad data length field 79 with bad checksum 31975 with no checksum 2172028 dropped due to no socket 158299 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 303344 delivered 316572 datagrams output 0 times multicast source filter matched sctp: ....... ip: 617221119 total packets received 99 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 66 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 33 packets reassembled ok 188676089 packets for this host 46175 packets for unknown/unsupported protocol 428113078 packets forwarded (0 packets fast forwarded) 366167 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 356645899 packets sent from this host 10295 packets sent with fabricated ip header 514772 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 88839756 output datagrams fragmented 177696236 fragments created 304600 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 2347631 calls to icmp_error 31 errors not generated in response to an icmp message Output histogram: echo reply: 2129 destination unreachable: 2346451 time exceeded: 49 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 8242 destination unreachable: 4417 routing redirect: 37388 echo: 2129 time exceeded: 7414 2129 message responses generated 0 invalid return addresses 0 no return routes ICMP address mask responses are disabled igmp: ..... arp: 825 ARP requests sent 26292 ARP replies sent 246041 ARP requests received 761 ARP replies received 246802 ARP packets received 29 total packets dropped due to no ARP entry 373 ARP entrys timed out 0 Duplicate IPs seen *6: .... all values are zero (no ipv6) pings from client machine to inet (tunnel over pptp): Ответ от 93.158.134.3: число байт=32 время=64мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=64мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=90мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=60мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=55мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=56мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=64мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=98мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=187мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=137мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=249мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=73мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=159мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=106мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=75мс TTL=55 Ответ от 93.158.134.3: число байт=32 время=58мс TTL=55 # netstat -w 1 -h -d -I sis0 9.8K 0 0 7.7M 12K 0 7.9M 0 0 9.3K 0 0 7.4M 12K 0 7.6M 0 0 7.2K 0 0 5.5M 9.1K 0 5.7M 0 0 7.5K 0 0 5.7M 8.9K 0 5.8M 0 0 8.4K 0 0 6.6M 11K 0 6.8M 0 0 8.9K 0 0 7.1M 11K 0 7.3M 0 0 8.4K 0 0 6.8M 11K 0 7.0M 0 0 input (sis0) output packets errs idrops bytes packets errs bytes colls drops 8.5K 0 0 6.8M 11K 0 7.0M 0 0 9.3K 0 0 7.4M 12K 0 7.6M 0 0 8.0K 0 0 6.4M 10K 0 6.5M 0 0 7.2K 0 0 5.6M 9.3K 0 5.8M 0 187 8.4K 0 0 6.8M 11K 0 6.9M 0 0 7.9K 0 0 6.0M 9.6K 0 6.1M 0 0 8.2K 0 0 6.4M 9.9K 0 6.5M 0 0 8.5K 0 0 6.7M 10K 0 6.8M 0 0 8.0K 0 0 6.5M 9.9K 0 6.7M 0 0 as you notice there are somitimes drops Uplink is 75Mbit/s wide. Where can be a trouble? -- Eugen Konkov mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 19:03:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17AF1065673 for ; Thu, 14 Oct 2010 19:03:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0048FC18 for ; Thu, 14 Oct 2010 19:03:24 +0000 (UTC) Received: (qmail 7705 invoked by uid 399); 14 Oct 2010 19:03:24 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Oct 2010 19:03:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB75411.20305@FreeBSD.org> Date: Thu, 14 Oct 2010 12:03:45 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Eugene Grosbein References: <4CB2AF28.30309@rdtc.ru> <4CB3D6B6.9060001@rdtc.ru> <4CB409DA.1060705@FreeBSD.org> <4CB455D5.1080902@rdtc.ru> <4CB4AB48.2050307@FreeBSD.org> <4CB55A41.6000507@rdtc.ru> <4CB6A67C.2070208@FreeBSD.org> <4CB6D0B8.6090305@rdtc.ru> In-Reply-To: <4CB6D0B8.6090305@rdtc.ru> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: strange resolver behavour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 19:03:25 -0000 On 10/14/2010 2:43 AM, Eugene Grosbein wrote: > Is host(1) supposed to do lookups using suffixes from /etc/resolv.conf > for FQDN with dot at the end? ... if only there were a document of some kind that described how the tool was supposed to work ... something like a manual ... :) Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 19:37:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE141065674 for ; Thu, 14 Oct 2010 19:37:34 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward7.mail.yandex.net (forward7.mail.yandex.net [77.88.61.37]) by mx1.freebsd.org (Postfix) with ESMTP id 572218FC17 for ; Thu, 14 Oct 2010 19:37:34 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward7.mail.yandex.net (Yandex) with ESMTP id 891D41B0829A for ; Thu, 14 Oct 2010 23:37:32 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1287085052; bh=IZUe2BktknjoFl6wkJouSqYQGfeKPM8OGADL6seBMlc=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mEdqm9s5StnmyVBJr/gC2kqoq+sm6pvPbFqDz2j+h4dkC7hs3tX3HSt634FwRY7c+ SDPRX4V5SV+uGCH7UoyMOhbaFbg6AP38bqrIiKixQyz9CGktryqPhg8PAN1Rnkuv/5 r8Ka4wqzzJpOm3/+7qHSBQnlDEyEAsgtoMEv4wIw= Received: from HOMEUSER (unknown [77.93.36.205]) by smtp8.mail.yandex.net (Yandex) with ESMTPA id 750B42028094; Thu, 14 Oct 2010 23:37:31 +0400 (MSD) Date: Thu, 14 Oct 2010 22:37:31 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <276052631.20101014223731@yandex.ru> To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= In-Reply-To: <801172760.20101014204450@yandex.ru> References: <8710276544.20101014084846@yandex.ru> <1861551856.20101014120300@gmail.com> <801172760.20101014204450@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Yandex-TimeMark: 1287085052 X-Yandex-Spam: 1 X-Yandex-Front: smtp8.mail.yandex.net Cc: freebsd-net@freebsd.org Subject: Re: problem with net subsystem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 19:37:34 -0000 Здравствуйте, Eugen. Вы писали 14 октября 2010 г., 20:44:50: EK> Hi EK> #top -SI EK> last pid: 67653; load averages: 1.23, 1.12, 1.24 up 1+09:46:14 20:22:34 EK> 94 processes: 3 running, 76 sleeping, 15 waiting EK> CPU: 0.0% user, 0.0% nice, 33.3% system, 66.7% interrupt, 0.0% idle EK> Mem: 54M Active, 226M Inact, 103M Wired, 59M Buf, 103M Free EK> Swap: 2048M Total, 2048M Free EK> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND EK> 13 root 1 106 - 0K 8K RUN 251:36 49.02% ng_queue EK> 11 root 1 171 ki31 0K 8K RUN 21.5H 35.60% idle EK> 12 root 15 -44 - 0K 120K WAIT 31:04 12.06% intr EK> 0 root 9 -68 0 0K 64K - 18:13 0.49% kernel EK> 67618 root 1 44 0 10020K 2312K ttyin 0:00 0.34% systat EK> 18710 root 2 44 0 84660K 62868K select 16:11 0.29% mpd5 EK> 67653 root 1 44 0 9944K 2020K RUN 0:00 0.15% top EK> there are no queues nor pipes in ipfw. EK> #systat -v EK> users Load EK> Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER EK> Tot Share Tot Share Free in out in out EK> Act count EK> All pages EK> Proc: Interrupts EK> r p d s w Csw Trp Sys Int Sof Flt cow total EK> zfod EK> ozfod EK> . %Sys . %Intr . %User . %Nice . %Idle %ozfod EK> | | | | | | | | | | | daefr EK> prcfr EK> dtbuf totfr EK> Namei Name-cache Dir-cache desvn react EK> Calls hits % hits % numvn pdwak EK> frevn pdpgs EK> intrn EK> Disks ad0 wire EK> KB/t act EK> tps inact EK> MB/s cache EK> %busy free EK> # vmstat -i EK> interrupt total rate EK> irq1: atkbd0 1203 0 EK> irq14: ata0 139502 1 EK> irq15: ata1 35 0 EK> irq19: sis0 0 0 EK> cpu0:timer 258485585 2124 EK> Total 783059828 6436 EK> # ifconfig sis0 EK> sis0: flags=8843 metric 0 mtu 1500 EK> options=82048 EK> ether 00:0b:6a:a6:0c:f0 EK> inet 10.11.8.18 netmask 0xffffff00 broadcast 10.11.8.255 EK> inet6 fe80::20b:6aff:fea6:cf0%sis0 prefixlen 64 scopeid 0x1 EK> inet R.E.A.L netmask 0xfffffffc broadcast X.X.X.X EK> nd6 options=29 EK> media: Ethernet autoselect (100baseTX ) EK> status: active EK> #netstat -s EK> tcp: EK> 205416 packets sent EK> 124715 data packets (8022081 bytes) EK> 1425 data packets (99472 bytes) retransmitted EK> 38 data packets unnecessarily retransmitted EK> 0 resends initiated by MTU discovery EK> 75509 ack-only packets (64514 delayed) EK> 0 URG only packets EK> 0 window probe packets EK> 0 window update packets EK> 3824 control packets EK> 1653273 packets received EK> 115656 acks (for 8017539 bytes) EK> 1967 duplicate acks EK> 0 acks for unsent data EK> 104386 packets (4886466 bytes) received in-sequence EK> 62 completely duplicate packets (1512 bytes) EK> 0 old duplicate packets EK> 0 packets with some dup. data (0 bytes duped) EK> 4 out-of-order packets (112 bytes) EK> 0 packets (0 bytes) of data after window EK> 0 window probes EK> 3 window update packets EK> 1 packet received after close EK> 4 discarded for bad checksums EK> 0 discarded for bad header offset fields EK> 0 discarded because packet too short EK> 0 discarded due to memory problems EK> 1441 connection requests EK> 1091 connection accepts EK> 0 bad connection attempts EK> 6726 listen queue overflows EK> 25 ignored RSTs in the windows EK> 2530 connections established (including accepts) EK> 111289 connections closed (including 214 drops) EK> 2185 connections updated cached RTT on close EK> 2267 connections updated cached RTT variance on close EK> 1516 connections updated cached ssthresh on close EK> 2 embryonic connections dropped EK> 107299 segments updated rtt (of 107034 attempts) EK> 1434 retransmit timeouts EK> 68 connections dropped by rexmit timeout EK> 0 persist timeouts EK> 0 connections dropped by persist timeout EK> 0 Connections (fin_wait_2) dropped because of timeout EK> 0 keepalive timeouts EK> 0 keepalive probes sent EK> 0 connections dropped by keepalive EK> 554 correct ACK header predictions EK> 19107 correct data packet header predictions EK> 6278 syncache entries added EK> 4 retransmitted EK> 0 dupsyn EK> 5 dropped EK> 1091 completed EK> 0 bucket overflow EK> 0 cache overflow EK> 1 reset EK> 0 stale EK> 6726 aborted EK> 0 badack EK> 0 unreach EK> 0 zone failures EK> 6283 cookies sent EK> 1540 cookies received EK> 19 SACK recovery episodes EK> 40 segment rexmits in SACK recovery episodes EK> 18640 byte rexmits in SACK recovery episodes EK> 298 SACK options (SACK blocks) received EK> 2 SACK options (SACK blocks) sent EK> 0 SACK scoreboard overflow EK> 0 packets with ECN CE bit set EK> 0 packets with ECN ECT(0) bit set EK> 0 packets with ECN ECT(1) bit set EK> 0 successful ECN handshakes EK> 0 times ECN reduced the congestion window EK> udp: EK> 2633751 datagrams received EK> 0 with incomplete header EK> 1 with bad data length field EK> 79 with bad checksum EK> 31975 with no checksum EK> 2172028 dropped due to no socket EK> 158299 broadcast/multicast datagrams undelivered EK> 0 dropped due to full socket buffers EK> 0 not for hashed pcb EK> 303344 delivered EK> 316572 datagrams output EK> 0 times multicast source filter matched EK> sctp: EK> ....... EK> ip: EK> 617221119 total packets received EK> 99 bad header checksums EK> 0 with size smaller than minimum EK> 0 with data size < data length EK> 0 with ip length > max ip packet size EK> 0 with header length < data size EK> 0 with data length < header length EK> 0 with bad options EK> 0 with incorrect version number EK> 66 fragments received EK> 0 fragments dropped (dup or out of space) EK> 0 fragments dropped after timeout EK> 33 packets reassembled ok EK> 188676089 packets for this host EK> 46175 packets for unknown/unsupported protocol EK> 428113078 packets forwarded (0 packets fast forwarded) EK> 366167 packets not forwardable EK> 0 packets received for unknown multicast group EK> 0 redirects sent EK> 356645899 packets sent from this host EK> 10295 packets sent with fabricated ip header EK> 514772 output packets dropped due to no bufs, etc. EK> 0 output packets discarded due to no route EK> 88839756 output datagrams fragmented EK> 177696236 fragments created EK> 304600 datagrams that can't be fragmented EK> 0 tunneling packets that can't find gif EK> 0 datagrams with bad address in header EK> icmp: EK> 2347631 calls to icmp_error EK> 31 errors not generated in response to an icmp message EK> Output histogram: EK> echo reply: 2129 EK> destination unreachable: 2346451 EK> time exceeded: 49 EK> 0 messages with bad code fields EK> 0 messages less than the minimum length EK> 0 messages with bad checksum EK> 0 messages with bad length EK> 0 multicast echo requests ignored EK> 0 multicast timestamp requests ignored EK> Input histogram: EK> echo reply: 8242 EK> destination unreachable: 4417 EK> routing redirect: 37388 EK> echo: 2129 EK> time exceeded: 7414 EK> 2129 message responses generated EK> 0 invalid return addresses EK> 0 no return routes EK> ICMP address mask responses are disabled EK> igmp: EK> ..... EK> arp: EK> 825 ARP requests sent EK> 26292 ARP replies sent EK> 246041 ARP requests received EK> 761 ARP replies received EK> 246802 ARP packets received EK> 29 total packets dropped due to no ARP entry EK> 373 ARP entrys timed out EK> 0 Duplicate IPs seen EK> *6: EK> .... all values are zero (no ipv6) EK> pings from client machine to inet (tunnel over pptp): EK> Ответ от 93.158.134.3: число байт=32 время=64мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=64мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=90мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=60мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=55мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=56мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=64мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=98мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=187мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=137мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=249мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=73мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=159мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=106мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=75мс TTL=55 EK> Ответ от 93.158.134.3: число байт=32 время=58мс TTL=55 EK> # netstat -w 1 -h -d -I sis0 EK> 9.8K 0 0 7.7M 12K 0 7.9M 0 0 EK> 9.3K 0 0 7.4M 12K 0 7.6M 0 0 EK> 7.2K 0 0 5.5M 9.1K 0 5.7M 0 0 EK> 7.5K 0 0 5.7M 8.9K 0 5.8M 0 0 EK> 8.4K 0 0 6.6M 11K 0 6.8M 0 0 EK> 8.9K 0 0 7.1M 11K 0 7.3M 0 0 EK> 8.4K 0 0 6.8M 11K 0 7.0M 0 0 EK> input (sis0) output EK> packets errs idrops bytes packets errs bytes colls drops EK> 8.5K 0 0 6.8M 11K 0 7.0M 0 0 EK> 9.3K 0 0 7.4M 12K 0 7.6M 0 0 EK> 8.0K 0 0 6.4M 10K 0 6.5M 0 0 EK> 7.2K 0 0 5.6M 9.3K 0 5.8M 0 187 EK> 8.4K 0 0 6.8M 11K 0 6.9M 0 0 EK> 7.9K 0 0 6.0M 9.6K 0 6.1M 0 0 EK> 8.2K 0 0 6.4M 9.9K 0 6.5M 0 0 EK> 8.5K 0 0 6.7M 10K 0 6.8M 0 0 EK> 8.0K 0 0 6.5M 9.9K 0 6.7M 0 0 EK> as you notice there are somitimes drops EK> Uplink is 75Mbit/s wide. EK> Where can be a trouble? last pid: 67962; load averages: 1.01, 0.97, 0.98 up 1+11:47:53 22:24:13 93 processes: 3 running, 75 sleeping, 15 waiting CPU: 0.8% user, 0.0% nice, 28.6% system, 37.6% interrupt, 32.9% idle Mem: 56M Active, 227M Inact, 103M Wired, 59M Buf, 100M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 1 171 ki31 0K 8K RUN 21.9H 64.11% idle 13 root 1 60 - 0K 8K RUN 285:50 27.10% ng_queue 12 root 15 -44 - 0K 120K WAIT 89:06 3.56% intr 67901 root 1 44 0 9944K 2020K RUN 0:01 0.10% top 18710 root 2 44 0 84660K 62876K select 17:03 0.05% mpd5 strange, but 'intr' is always 'WAIT'. and what is ng_queue? -- С уважением, Коньков mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Fri Oct 15 09:45:39 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89A50106566C; Fri, 15 Oct 2010 09:45:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB828FC12; Fri, 15 Oct 2010 09:45:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9F9jdrC044116; Fri, 15 Oct 2010 09:45:39 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9F9jdpk044112; Fri, 15 Oct 2010 09:45:39 GMT (envelope-from bz) Date: Fri, 15 Oct 2010 09:45:39 GMT Message-Id: <201010150945.o9F9jdpk044112@freefall.freebsd.org> To: lsantagostini@gmail.com, bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/133902: [tun] Killing tun0 iface ssh tunnel causes Panic String: page fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 09:45:39 -0000 Synopsis: [tun] Killing tun0 iface ssh tunnel causes Panic String: page fault State-Changed-From-To: open->closed State-Changed-By: bz State-Changed-When: Fri Oct 15 09:45:00 UTC 2010 State-Changed-Why: Duplicate of PR kern/116837. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Fri Oct 15 09:45:00 UTC 2010 Responsible-Changed-Why: Take in case of follow-ups. http://www.freebsd.org/cgi/query-pr.cgi?pr=133902 From owner-freebsd-net@FreeBSD.ORG Fri Oct 15 12:59:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17176106564A for ; Fri, 15 Oct 2010 12:59:59 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id 855488FC13 for ; Fri, 15 Oct 2010 12:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version; bh=giqIKeDtY3uC7A3IyB4yP8cFyRTJ/VlaT30FXZ0PUaA=; b=Ql15R/YfSv6T1s/rFhVC/qcodREmvgNMGXHer8eAiau6L48JK3SRV8I90Civ0j/WduTB4S2mUSCJGGfNuVcTSt+FnQPMCXGsGguITrJdM+DskHKBEvdJ6AVsZLSnj/m+; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.47]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P6jLW-000LzR-02; Fri, 15 Oct 2010 13:25:17 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Melissa Jenkins In-Reply-To: <20100904005349.GP21940@michelle.cdnetworks.com> Date: Fri, 15 Oct 2010 13:25:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BBD5E0C-06D3-4FA5-B85C-5256DA3AD483@littlebluecar.co.uk> References: <5C261F16-6530-47EE-B1C1-BA38CD6D8B01@littlebluecar.co.uk> <20100902194940.GH21940@michelle.cdnetworks.com> <20100904005349.GP21940@michelle.cdnetworks.com> To: pyunyh@gmail.com X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Cc: freebsd-net@freebsd.org Subject: Re: NFE adapter 'hangs' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 12:59:59 -0000 On 4 Sep 2010, at 01:53, Pyun YongHyeon wrote: > On Fri, Sep 03, 2010 at 07:59:26AM +0100, Melissa Jenkins wrote: >>=20 >> Thank you for your very quick response :) >>=20 >=20 > [...] >=20 >>> Also I'd like to know whether both RX and TX are dead or only one >>> RX/TX path is hung. Can you see incoming traffic with tcpdump when >>> you think the controller is in stuck? >>=20 >> Yes, though not very much. The traffic to 4800 is every second so you = can see in the following trace when it stops >>=20 >> 07:10:42.287163 IP 192.168.1.203 > 224.0.0.240: pfsync 108 >> 07:10:42.911995 >> 07:10:43.112073 STP 802.1d, Config, Flags [Topology change], = bridge-id 8000.c4:7d:4f:a9:ac:30.8008, length 43 >> 07:10:43.148659 IP 192.168.1.203.57026 > 192.168.1.255.4800: UDP, = length 60 >> 07:10:43.148684 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.129.4800: UDP, length 60 >> 07:10:43.148689 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP = 192.168.1.203.57026 > 192.168.1.1.4800: UDP, length 60 >> 07:10:43.148918 IP 192.168.1.213.40677 > 192.168.1.255.4800: UDP, = length 48 >=20 > [...] >=20 >> a bit later on, still broken, a slight odd message: >> 07:11:43.079720 IP 172.31.1.129 > 172.31.1.213: GREv0, length 52: IP = 192.168.1.129.60446 > 192.168.1.213.179: tcp 12 [bad hdr length 16 - = too short, < 20] >> 07:11:44.210794 IP 172.31.1.129 > 172.31.1.203: GREv0, length 84: IP = 192.168.1.129.64744 > 192.168.1.203.4800: UDP, length 52 >> 07:11:44.210831 IP 172.31.1.129 > 172.31.1.213: GREv0, length 84: IP = 192.168.1.129.64744 > 192.168.1.213.4800: UDP, length 52 >>=20 >> Now this really is odd, I don't recognise either of those MAC = addresses, though the SQL shown is used on this machine ( >> 07:12:13.054393 45:43:54:20:41:63 > 00:00:03:53:45:4c, ethertype = Unknown (0x6374), length 60: >> 0x0000: 556e 6971 7565 4964 2046 524f 4d20 7261 = UniqueId.FROM.ra >> 0x0010: 6461 6363 7420 2057 4845 5245 2043 616c = dacct..WHERE.Cal >> 0x0020: 6c69 6e67 5374 6174 696f 6e49 6420 = lingStationId. >=20 > Hmm, it seems you're using really complex setup. It's very hard to > narrow down guilty ones under these environments. Could you setup > simple network configuration that reproduces the issue? One of > possible cause would be wrong(garbled) data might be passed up to > upper stack. But I have no idea why you see GRE packets with > truncated TCP header(172.31.1.129 > 172.31.1.213). > How about disabling TX/RX checksum offloading as well as TSO? >=20 > [...] >=20 >>=20 >> I then restarted the interface (nfe down/up, route restart) >>=20 >> =46rom dmesg at the time (slight obfuscated) >> Sep 3 07:10:19 manch2 bgpd[89612]: neighbor XX: received = notification: HoldTimer expired, unknown subcode 0 >> Sep 3 07:10:49 manch2 bgpd[89612]: neighbor XX connect: Host is down >> # at this point I took the interface down & up and reloaded the = routing tables >> Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN >> Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN >> Sep 3 07:12:07 manch2 kernel: nfe0: link state changed to DOWN >> Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN >> Sep 3 07:12:11 manch2 kernel: nfe0: link state changed to UP =20 >> Sep 3 07:12:11 manch2 kernel: carp0: link state changed to DOWN >> Sep 3 07:12:14 manch2 kernel: carp0: link state changed to UP >=20 > Hmm, it does not look right, carp0 showed link DOWN message four > times in a row. > By the way, are you using IPMI on MCP55? nfe(4) is not ready to > handle MAC operation with IPMI. Turning off tx & rc checksum offloading seems to have resolved the = problem: ifconfig nfe0 -txcsum -rxcsum Seems to have stopped both the corruption and the interface hanging. I = ran it for about 16 hours on the FreeBSD 8 box. It also appears to have = fixed the problem on my FreeBSD 7 machine as well. =20 I didn't try turning off TSO. Thank you for your suggestion & help! Mel From owner-freebsd-net@FreeBSD.ORG Fri Oct 15 19:25:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72A04106564A; Fri, 15 Oct 2010 19:25:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 41AF28FC18; Fri, 15 Oct 2010 19:25:43 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D0DB646BA3; Fri, 15 Oct 2010 15:25:42 -0400 (EDT) Date: Fri, 15 Oct 2010 20:25:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:25:43 -0000 On Thu, 14 Oct 2010, Attilio Rao wrote: >> No, what I'm saying is: UMA needs to not call its drain handlers, and >> ideally not call into VM to fill slabs, from the dumping context. That's >> easy to implement and will cause the dump to fail rather than causing the >> system to hang. > > My point is, however, still the same: that should not happen just for the > netdump specific case but for all the dumping/KDB/panic cases (I know it is > unlikely current code !netdump calls into UMA but it is not an established > pre-requisite and may still happen that some added code does). I still see > this as a weakness on the infrastructure, independently from netdump. I can > see that your point is that it is vital to netdump correct behaviour though, > so I'd wonder if it worths fixing it now or later. Quite a bit of our kernel and dumping infrastructure special cases debugging and dumping behavior to avoid sources of non-robustness. For example, serial drivers avoid locking, and for disk dumps we bypass GEOM to avoid the memory allocation, freeing, and threading that it depends on. The goal here is to be robust when handling dumps: hanging is worse than not dumping, since you won't get the dump either way, and if you don't reboot then the system requires manual intervention to recover. Example of things that are critical to avoid include: - The dumping thread tripping over locks held by the panicked thread, or by another now-suspended thread, leading to deadlock against a suspended thread. - Corrupting dumps by increasing concurrency in the panic case. We ran into a case a year or two ago where changing VM state during the dump on amd64 caused file system corruption as the dump code assumed that the space required for a dump didn't change while dumping took place. Any code dependency we add in the panic / KDB / dump path is one more risk that we don't successfully dump and reboot, so we need to minimize that code. Robert From owner-freebsd-net@FreeBSD.ORG Fri Oct 15 19:46:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E88B9106564A; Fri, 15 Oct 2010 19:46:00 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5C948FC08; Fri, 15 Oct 2010 19:46:00 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7AE5746B32; Fri, 15 Oct 2010 15:45:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Fri, 15 Oct 2010 20:45:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93AB0F13-5995-4AAD-BEFC-A6F1317E3CA6@freebsd.org> References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:46:01 -0000 On 15 Oct 2010, at 20:39, Garrett Cooper wrote: > But there are already some cases that aren't properly handled > today in the ddb area dealing with dumping that aren't handled > properly. Take for instance the following two scenarios: > 1. Call doadump twice from the debugger. > 2. Call doadump, exit the debugger, reenter the debugger, and call > doadump again. > Both of these scenarios hang reliably for me. > I'm not saying that we should regress things further, but I'm just > noting that there are most likely a chunk of edgecases that aren't > being handled properly when doing dumps that could be handled better / > fixed. Right: one of the points I've made to Attilio is that we need to move to = a more principled model as to what sorts of things we allow in various = kernel environments. The early boot is a special environment -- so is = the debugger, but the debugger on panic is not the same as the debugger = when you can continue. Likewise, the crash dumping code is special, but = also not the same as the debugger. Right now, exceptional behaviour to = limit hangs/etc is done inconsistently. We need to develop a set of = principles that tell us what is permitted in what contexts, and then use = that to drive design decisions, normalizing what's there already. This is not dissimilar to what we do with locking already, BTW: we = define a set of kernel environments (fast interrupt handlers, = non-sleepable threads, sleepable thread holding non-sleepable locks, = etc), and based on those principles prevent significant sources of = instability that might otherwise arise in a complex, concurrent kernel. = We need to apply the same sort of approach to handling kernel debugging = and crashing. BTW, my view is that except in very exceptional cases, it should not be = possible to continue after generating a dump. Dumps often cause disk = controllers to get reset, which may leave outstanding I/O in nasty = situations. Unless the dump device and model is known not to interfere = with operation, we should set state indicating that the system is = non-continuable once a dump has occurred. Robert From owner-freebsd-net@FreeBSD.ORG Fri Oct 15 20:06:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DA78106566C; Fri, 15 Oct 2010 20:06:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE4F8FC1B; Fri, 15 Oct 2010 20:06:28 +0000 (UTC) Received: by iwn6 with SMTP id 6so811244iwn.13 for ; Fri, 15 Oct 2010 13:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=iTz6zF4dhgB8tpOCDrEMJj4b/uhGitBEZaEW9uWTgOU=; b=FDy8gw2qnyDzle46MnzDchKOooTzXHf0wk+4I0Qw0Z5euBRwEjO34FYDT9Bbqzy7d0 NzWP2RVOV+k/jUBH1mIIDy3q24OsXwHFeGdNd8JZcFLQtA8T+/WRK9NOiQE7sLp9xSaN pX0+2nrkBfWkYXnejmZhL0djBEZWJWI/luxCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cQUFAGyg84IZg+3As0GhN6Oj0UWrbKmJARmk080YUu5Ha88YF2Q3JFETj3SrIXpUSq bxbnmUMAESGeIkJ3Ymdp2D5q7OVnqao75UrhgMoZHr5x7TkgaHo0lULFop70rGWM6oLl R0Xbgil4qYNKWj/Ro7fGj6MnNoseRuKbiQkO0= MIME-Version: 1.0 Received: by 10.231.144.74 with SMTP id y10mr1143822ibu.65.1287171551591; Fri, 15 Oct 2010 12:39:11 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Fri, 15 Oct 2010 12:39:11 -0700 (PDT) In-Reply-To: References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> Date: Fri, 15 Oct 2010 12:39:11 -0700 X-Google-Sender-Auth: 6NTs1zcDiFapHTGRGuOeHVzConA Message-ID: From: Garrett Cooper To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:06:29 -0000 On Fri, Oct 15, 2010 at 12:25 PM, Robert Watson wrote= : > On Thu, 14 Oct 2010, Attilio Rao wrote: > >>> No, what I'm saying is: UMA needs to not call its drain handlers, and >>> ideally not call into VM to fill slabs, from the dumping context. That'= s >>> easy to implement and will cause the dump to fail rather than causing t= he >>> system to hang. >> >> My point is, however, still the same: that should not happen just for th= e >> netdump specific case but for all the dumping/KDB/panic cases (I know it= is >> unlikely current code !netdump calls into UMA but it is not an establish= ed >> pre-requisite and may still happen that some added code does). I still s= ee >> this as a weakness on the infrastructure, independently from netdump. I = can >> see that your point is that it is vital to netdump correct behaviour tho= ugh, >> so I'd wonder if it worths fixing it now or later. > > Quite a bit of our kernel and dumping infrastructure special cases debugg= ing > and dumping behavior to avoid sources of non-robustness. =A0For example, > serial drivers avoid locking, and for disk dumps we bypass GEOM to avoid = the > memory allocation, freeing, and threading that it depends on. > > The goal here is to be robust when handling dumps: hanging is worse than = not > dumping, since you won't get the dump either way, and if you don't reboot > then the system requires manual intervention to recover. =A0Example of th= ings > that are critical to avoid include: > > - The dumping thread tripping over locks held by the panicked thread, or = by > =A0another now-suspended thread, leading to deadlock against a suspended > =A0thread. > > - Corrupting dumps by increasing concurrency in the panic case. =A0We ran= into > a > =A0case a year or two ago where changing VM state during the dump on amd6= 4 > =A0caused file system corruption as the dump code assumed that the space > =A0required for a dump didn't change while dumping took place. > > Any code dependency we add in the panic / KDB / dump path is one more ris= k > that we don't successfully dump and reboot, so we need to minimize that > code. But there are already some cases that aren't properly handled today in the ddb area dealing with dumping that aren't handled properly. Take for instance the following two scenarios: 1. Call doadump twice from the debugger. 2. Call doadump, exit the debugger, reenter the debugger, and call doadump again. Both of these scenarios hang reliably for me. I'm not saying that we should regress things further, but I'm just noting that there are most likely a chunk of edgecases that aren't being handled properly when doing dumps that could be handled better / fixed. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Oct 16 00:58:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBC66106566B for ; Sat, 16 Oct 2010 00:58:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A56AD8FC0A for ; Sat, 16 Oct 2010 00:58:08 +0000 (UTC) Received: by pvg7 with SMTP id 7so290814pvg.13 for ; Fri, 15 Oct 2010 17:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=pSs6xpYmi7RICkCVbMqq08nwDvXNSA5Cknp8CCrodhE=; b=sQgxGbgSX5ewqaNEQ5upnxH4VHlsF0X3W7c+oZoIMUf6PWYeAM3PNFREPxezb26v1k 1Urah2dlYz1Liwqt6akW28stVbHEreiaRHgIUj2pdeKEKwYgFF3Eux45Vp7y9oiyDVuZ 5PcwikKJwhwTohdlVaCQJ9MK4xm1vwOWwMRC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Rf1cqM+Xk6rkLrGF5nBJJCjyreuj7yJhf5MX7lAgsncRuOWSVG+Di5GXO6sp7VLsP0 43IWkpGUXYntL7qGwZtoWjB0rnv7YBnaHJRIN57xBeMV4Uv9tgRwEbgaRrs3i531fM9w f6cz0siOeNU7LwHKgPwzCLFrhOLwtsjb6uWQo= Received: by 10.142.139.5 with SMTP id m5mr1216660wfd.250.1287190686966; Fri, 15 Oct 2010 17:58:06 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id t38sm16761633wfc.9.2010.10.15.17.58.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 Oct 2010 17:58:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 15 Oct 2010 17:56:24 -0700 From: Pyun YongHyeon Date: Fri, 15 Oct 2010 17:56:24 -0700 To: Melissa Jenkins Message-ID: <20101016005624.GH26174@michelle.cdnetworks.com> References: <5C261F16-6530-47EE-B1C1-BA38CD6D8B01@littlebluecar.co.uk> <20100902194940.GH21940@michelle.cdnetworks.com> <20100904005349.GP21940@michelle.cdnetworks.com> <9BBD5E0C-06D3-4FA5-B85C-5256DA3AD483@littlebluecar.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BBD5E0C-06D3-4FA5-B85C-5256DA3AD483@littlebluecar.co.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: NFE adapter 'hangs' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 00:58:08 -0000 On Fri, Oct 15, 2010 at 01:25:08PM +0100, Melissa Jenkins wrote: > > On 4 Sep 2010, at 01:53, Pyun YongHyeon wrote: > > > On Fri, Sep 03, 2010 at 07:59:26AM +0100, Melissa Jenkins wrote: > >> > >> Thank you for your very quick response :) > >> > > > > [...] > > > >>> Also I'd like to know whether both RX and TX are dead or only one > >>> RX/TX path is hung. Can you see incoming traffic with tcpdump when > >>> you think the controller is in stuck? > >> > >> Yes, though not very much. The traffic to 4800 is every second so you can see in the following trace when it stops > >> > >> 07:10:42.287163 IP 192.168.1.203 > 224.0.0.240: pfsync 108 > >> 07:10:42.911995 > >> 07:10:43.112073 STP 802.1d, Config, Flags [Topology change], bridge-id 8000.c4:7d:4f:a9:ac:30.8008, length 43 > >> 07:10:43.148659 IP 192.168.1.203.57026 > 192.168.1.255.4800: UDP, length 60 > >> 07:10:43.148684 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP 192.168.1.203.57026 > 192.168.1.129.4800: UDP, length 60 > >> 07:10:43.148689 IP 172.31.1.203 > 172.31.1.129: GREv0, length 92: IP 192.168.1.203.57026 > 192.168.1.1.4800: UDP, length 60 > >> 07:10:43.148918 IP 192.168.1.213.40677 > 192.168.1.255.4800: UDP, length 48 > > > > [...] > > > >> a bit later on, still broken, a slight odd message: > >> 07:11:43.079720 IP 172.31.1.129 > 172.31.1.213: GREv0, length 52: IP 192.168.1.129.60446 > 192.168.1.213.179: tcp 12 [bad hdr length 16 - too short, < 20] > >> 07:11:44.210794 IP 172.31.1.129 > 172.31.1.203: GREv0, length 84: IP 192.168.1.129.64744 > 192.168.1.203.4800: UDP, length 52 > >> 07:11:44.210831 IP 172.31.1.129 > 172.31.1.213: GREv0, length 84: IP 192.168.1.129.64744 > 192.168.1.213.4800: UDP, length 52 > >> > >> Now this really is odd, I don't recognise either of those MAC addresses, though the SQL shown is used on this machine ( > >> 07:12:13.054393 45:43:54:20:41:63 > 00:00:03:53:45:4c, ethertype Unknown (0x6374), length 60: > >> 0x0000: 556e 6971 7565 4964 2046 524f 4d20 7261 UniqueId.FROM.ra > >> 0x0010: 6461 6363 7420 2057 4845 5245 2043 616c dacct..WHERE.Cal > >> 0x0020: 6c69 6e67 5374 6174 696f 6e49 6420 lingStationId. > > > > Hmm, it seems you're using really complex setup. It's very hard to > > narrow down guilty ones under these environments. Could you setup > > simple network configuration that reproduces the issue? One of > > possible cause would be wrong(garbled) data might be passed up to > > upper stack. But I have no idea why you see GRE packets with > > truncated TCP header(172.31.1.129 > 172.31.1.213). > > How about disabling TX/RX checksum offloading as well as TSO? > > > > [...] > > > >> > >> I then restarted the interface (nfe down/up, route restart) > >> > >> From dmesg at the time (slight obfuscated) > >> Sep 3 07:10:19 manch2 bgpd[89612]: neighbor XX: received notification: HoldTimer expired, unknown subcode 0 > >> Sep 3 07:10:49 manch2 bgpd[89612]: neighbor XX connect: Host is down > >> # at this point I took the interface down & up and reloaded the routing tables > >> Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN > >> Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN > >> Sep 3 07:12:07 manch2 kernel: nfe0: link state changed to DOWN > >> Sep 3 07:12:07 manch2 kernel: carp0: link state changed to DOWN > >> Sep 3 07:12:11 manch2 kernel: nfe0: link state changed to UP > >> Sep 3 07:12:11 manch2 kernel: carp0: link state changed to DOWN > >> Sep 3 07:12:14 manch2 kernel: carp0: link state changed to UP > > > > Hmm, it does not look right, carp0 showed link DOWN message four > > times in a row. > > By the way, are you using IPMI on MCP55? nfe(4) is not ready to > > handle MAC operation with IPMI. > > > Turning off tx & rc checksum offloading seems to have resolved the problem: > > ifconfig nfe0 -txcsum -rxcsum > > Seems to have stopped both the corruption and the interface hanging. I ran it for about 16 hours on the FreeBSD 8 box. It also appears to have fixed the problem on my FreeBSD 7 machine as well. > Hmm, could you try the patch at the following URL? http://people.freebsd.org/~yongari/nfe/nfe.mcp55.txcsum.patch The patch ensures that the first fragment of mbuf holds ip/tcp/udp header including options. If this patch fix the issue then it means there is an issue in TX checksum offloading on MCP55. But I'm still not sure whether it makes any difference because there was no report on broken TX checksum offloading on nfe(4). At least I don't remember that kind of report so far. Note, the patch was not tested at all, I have no longer access to nfe(4) controllers so please make sure to test it first before applying the patch. > I didn't try turning off TSO. > Ok, your tcpdump shows garbled packets for non-TSO frames so the patch above does no special handling for TSO case. > Thank you for your suggestion & help! > Mel > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 16 12:41:52 2010 Return-Path: Delivered-To: net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id EFE6F1065670; Sat, 16 Oct 2010 12:41:52 +0000 (UTC) Date: Sat, 16 Oct 2010 12:41:52 +0000 From: Alexey Dokuchaev To: Bernhard Schmidt Message-ID: <20101016124152.GA95535@FreeBSD.org> References: <4763016D.7060100@janh.de> <201010081944.50287.bschmidt@techwires.net> <20101009060239.GA88618@FreeBSD.org> <201010092046.41551.bschmidt@techwires.net> <20101010072730.GA91527@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20101010072730.GA91527@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 12:41:53 -0000 On Sun, Oct 10, 2010 at 07:27:30AM +0000, Alexey Dokuchaev wrote: > On Sat, Oct 09, 2010 at 08:46:41PM +0200, Bernhard Schmidt wrote: > > On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: > > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, > > > which means it can utilize monitor mode. "ifconfig iwi0 scan" however > > > does not work after that (and "list scan" returns no results) even if I > > > put adapter back to normal (from promisc and monitor modes) with > > > ifconfig(8). kldunloading and loading module again fixes the issue. > > > > Due to enqueueing the scan command in an infinite loop (yeah.. scanning > > returns every frame, that's monitor mode for that device.. *sigh*) we > > might increment a queue index but never actually dequeueing the command. > > On 'down' we clear the command queue but not the indices resulting in > > the cur index not pointing to a filled entry. Attached patch should fix > > that. > > It does, thanks! "list scan" gets populated after I -mediaopt monitor > after scan; module reload is not required anymore. Not sure if this is a driver or ifconfig(8) problem, but after I -mediaopt monitor, ifconfig(8) still reports it in media line: media: IEEE 802.11 Wireless Ethernet autoselect However, as I said, scan list gets populated, which suggests ifconfig(8) is getting something wrong. Doing -mediaopt monitor the second time "knocks" ifconfig(8) though. ./danfe