From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 00:06: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 E84FF106566B for ; Sun, 11 Apr 2010 00:06:42 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id A51C48FC15 for ; Sun, 11 Apr 2010 00:06:42 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 7B9FA439E38; Sat, 10 Apr 2010 19:07:08 -0500 (CDT) Message-ID: <4BC12097.4030508@fuujingroup.com> Date: Sat, 10 Apr 2010 19:06:31 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4BBED9A4.3080303@fuujingroup.com> <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> In-Reply-To: <20100410212520.GB6481@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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, 11 Apr 2010 00:06:43 -0000 Pyun YongHyeon wrote: > On Sat, Apr 10, 2010 at 12:13:07AM -0600, Erich Jenkins, Fuujin Group Ltd wrote: >> Pyun YongHyeon wrote: >>> On Fri, Apr 09, 2010 at 02:13:00AM -0600, Erich Jenkins, Fuujin Group Ltd >>> wrote: >>>> Evgenii Davidov wrote: >>>>> ????????????, >>>>> >>>>> On Fri, Apr 09, 2010 at 01:39:16AM -0600, Erich Jenkins, Fuujin Group >>>>> Ltd ?????: >>>>> >>>>>> We were previously running 5.3 on this box (I know, VERY old), but >>>>>> never had a problem. The link now fails to come up. I've tried forcing >>>>>> the port out of auto (media 1000baseSX mediaopt full-duplex) and as >>>>>> long as the port doesn't have an IP assigned via rc.conf on system >>>>>> boot, I can get the switch to see it (Cisco 6505), but no traffic to >>>>>> flow. I've checked all the obvious things (duplex setting on switch, >>>>>> cable failure, etc.), all to no avail. I fiddled with the knobs in the >>>>>> driver (rxcsum, vlan_mtu, etc) with no changes either. >>>>> sorry for silly ansver but is your interface UP ? (ifconfig bge0 up) >>>>> >>>> Actually, I was silly for not mentioning that in the original post, but >>>> yes, it's up. I've even tried up/down/up on the card a few times after >>>> fiddling with the driver knobs, but the same thing happened, no link on >>>> the switch. >>>> >>>> I've also tested this back-to-back with two machines and the same cards. >>>> Same result: no transmission of data. Interestingly enough, the link >>>> lite is lit on the cards (in back-to-back) and on the card but not the >>>> switch. Not sure if that's significant or not. In the interest if >>>> completeness, here's ifconfig output for that card: >>>> >>>> bge0: flags=8843 metric 0 mtu 1500 >>>> options=9b >>>> ether 00:08:02:28:76:4d >>>> inet 10.222.222.144 netmask 0xffffff00 broadcast 10.222.222.255 >>>> media: Ethernet 1000baseSX >>>> status: active >>>> >>>> I also verified the MTU size to ensure the switch ports weren't >>>> configured for jumbo frames. They are correctly set on the switch and on >>>> the FreeBSD box, but no traffic flows. >>>> >>> Would you try booting to latest 7.3-RELEASE and check whether you >>> still see the issue? >>> If you see the same issue please show me verbose boot message of >>> bge(4) and its PHY driver. >>> _______________________________________________ >>> 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" >> Just finished the install, and ended up with the same result. I >> installed OpenBSD on this box just to be sure there wasn't something >> unrelated to the driver causing the issue. OpenBSD works fine. >> >> Where to from here? >> > > It seems there is async link state change issue for BCM5701 TBI > case. Link state handling is one of the most complex thing in > bge(4) so I'm not sure whether attached patch is right thing. > Public data sheet seems to indicate bit 0 of BGE_MI_STS should be > set to enable link to the MAC state machine if autopolling is > disabled so resetting the bit to 0 does not look right to me. > Try attached patch. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" Thanks for the patch, but I'm sorry to report there is no change. Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 08:15:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BBFB1065672 for ; Sun, 11 Apr 2010 08:15:27 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id 5346D8FC13 for ; Sun, 11 Apr 2010 08:15:26 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 256F7439E38; Sun, 11 Apr 2010 03:15:53 -0500 (CDT) Message-ID: <4BC19324.3050800@fuujingroup.com> Date: Sun, 11 Apr 2010 03:15:16 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4BBED9A4.3080303@fuujingroup.com> <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> In-Reply-To: <4BC12097.4030508@fuujingroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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, 11 Apr 2010 08:15:27 -0000 I've been muddling around in src/sys/dev on the old system and the new system and there appear to be rather major changes to MII and bge, possibly the whole stack? There are a number of things that seem to have been merged with other parts of the network stack, or perhaps written into the individual drivers (someone working on the net stack would have to verify that). For instance, some files called in 5.3-REL seem to have gone away completely, and in the new (unpatched) version of if_bge.c under 7.3-REL, calls to these modules are gone: - #include /* for vtophys */ - #include /* for vtophys */ - #include /* for DELAY */ - #include - #include (called but something changed in here) - #include (ditto above) It appears that the checksum features have been completely rewritten, and some of the ring settings have changed. It's interesting that the driver only fills 256 of the rx rings in the hopes that the cpu is "fast enough to keep up with the NIC". Would a subroutine here to grab the cpu clock and count (number of procs/pipelines) be more trouble than it's worth to "automagically" increase the number of rx rings the driver fills based on the system in which it's installed? Something also changed in pci/pcireg.h and pci/pcivar.h, but I haven't had the time to hunt down and expand the source tree from the 5.3-REL branch yet. I have other machines with copper nics utilizing the bge driver, and there are no issues at all. Perhaps I'm getting ahead of things, but since this seems to have been broken through several releases, would it make any sense to split the support between the BCM5701KHB chipset and the more recent BCM chipset to avoid causing issues with cards/systems not currently experiencing troubles? Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 12:35: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 4DF74106566C; Sun, 11 Apr 2010 12:35:04 +0000 (UTC) (envelope-from jille@quis.cx) Received: from mulgore.hexon-is.nl (mulgore.hexon-is.nl [82.94.237.14]) by mx1.freebsd.org (Postfix) with ESMTP id DD38A8FC08; Sun, 11 Apr 2010 12:35:03 +0000 (UTC) Received: from hinterlands.hexon-is.nl (hinterlands.hexon-is.nl [82.94.237.6]) by mulgore.hexon-is.nl (8.14.3/8.14.3) with ESMTP id o3BC3Lfh021761; Sun, 11 Apr 2010 14:03:21 +0200 MIME-Version: 1.0 Date: Sun, 11 Apr 2010 14:03:21 +0200 From: Jille Timmermans To: , Message-ID: <8d194046e93da0b44295f29a75a5775f@imap.hexon.cx> X-Sender: jille@quis.cx User-Agent: RoundCube Webmail/0.2.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-Hexon-MailScanner-Information: Please contact the ISP for more information X-Hexon-MailScanner-ID: o3BC3Lfh021761 X-Hexon-MailScanner: Found to be clean X-Hexon-MailScanner-From: jille@quis.cx X-Hexon-MailScanner-Watermark: 1271592202.73004@bnkzIcjHfemPkIezA1LqTg Cc: Subject: Panic with VIMAGE and pf 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, 11 Apr 2010 12:35:04 -0000 Hello, I was trying to enable VIMAGE (for use with jails) but stumbled upon the following panic: Fatal trap 12: page fault while in kernel mode fault virtual address: 0x28 current proceess = 38 (pfctl) db> bt pfil_head_get() at +0x41 pfioctl() at +0x11f2 devfs_ioctl_f() at +0x77 kern_ioctl() at +0xf6 ioctl() at +0xf0 syscall() +0x137 I can easily reproduce this in single user mode using: # kldload pf # pfctl -f /etc/pf.conf I disabled VIMAGE and the panic didn't occur anymore. I'm running amd64 stable/8; r206458. (I also tried this 3 weeks ago; but had the same problem) I'm not able to get a dump; the memory dump-thing stalls after printing the first mark. -- Jille From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 12:45:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E0B106564A; Sun, 11 Apr 2010 12:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id B14098FC1A; Sun, 11 Apr 2010 12:45:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BF19A41C707; Sun, 11 Apr 2010 14:45:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id AMsm5N6KJwda; Sun, 11 Apr 2010 14:45:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 063CF41C6A1; Sun, 11 Apr 2010 14:45:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7B01D4448EC; Sun, 11 Apr 2010 12:43:42 +0000 (UTC) Date: Sun, 11 Apr 2010 12:43:42 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jille Timmermans In-Reply-To: <8d194046e93da0b44295f29a75a5775f@imap.hexon.cx> Message-ID: <20100411124229.Q40281@maildrop.int.zabbadoz.net> References: <8d194046e93da0b44295f29a75a5775f@imap.hexon.cx> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Panic with VIMAGE and pf 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, 11 Apr 2010 12:45:08 -0000 On Sun, 11 Apr 2010, Jille Timmermans wrote: Hi, > I was trying to enable VIMAGE (for use with jails) but stumbled upon the > following panic: > > Fatal trap 12: page fault while in kernel mode > fault virtual address: 0x28 > current proceess = 38 (pfctl) > > db> bt > pfil_head_get() at +0x41 > pfioctl() at +0x11f2 > devfs_ioctl_f() at +0x77 > kern_ioctl() at +0xf6 > ioctl() at +0xf0 > syscall() +0x137 > > I can easily reproduce this in single user mode using: > # kldload pf > # pfctl -f /etc/pf.conf > > I disabled VIMAGE and the panic didn't occur anymore. > > I'm running amd64 stable/8; r206458. (I also tried this 3 weeks ago; but > had the same problem) > > I'm not able to get a dump; the memory dump-thing stalls after printing > the first mark. This is a FAQ. pf hasn't been virtulaized (in-tree) yet. See http://lists.freebsd.org/pipermail/freebsd-virtualization/2010-February/000449.html for how far it is and how to get it. That might, btw., be the better list to ask VIMAGE questions;) /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Sun Apr 11 18:49:58 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 C2BDE106564A; Sun, 11 Apr 2010 18:49:58 +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 9A01F8FC1B; Sun, 11 Apr 2010 18:49:58 +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 o3BInwRE056680; Sun, 11 Apr 2010 18:49:58 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3BInw5l056676; Sun, 11 Apr 2010 18:49:58 GMT (envelope-from bz) Date: Sun, 11 Apr 2010 18:49:58 GMT Message-Id: <201004111849.o3BInw5l056676@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic 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, 11 Apr 2010 18:49:58 -0000 Synopsis: [tun] [panic] [patch] ifconfig tunX destroy: panic Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sun Apr 11 18:49:46 UTC 2010 Responsible-Changed-Why: Take at least temporary. http://www.freebsd.org/cgi/query-pr.cgi?pr=116837 From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 01:57:05 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 06D85106566C; Mon, 12 Apr 2010 01:57:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D1CD78FC13; Mon, 12 Apr 2010 01:57:04 +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 o3C1v422024362; Mon, 12 Apr 2010 01:57:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3C1v4pb024358; Mon, 12 Apr 2010 01:57:04 GMT (envelope-from linimon) Date: Mon, 12 Apr 2010 01:57:04 GMT Message-Id: <201004120157.o3C1v4pb024358@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145621: [bge] [panic] bge watchdog timeout --resetting -> crash 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, 12 Apr 2010 01:57:05 -0000 Old Synopsis: BGE watchdog timeout --resetting -> crash New Synopsis: [bge] [panic] bge watchdog timeout --resetting -> crash Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 12 01:56:25 UTC 2010 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=145621 From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 11:07: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 BC380106564A for ; Mon, 12 Apr 2010 11:07:05 +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 A92208FC23 for ; Mon, 12 Apr 2010 11:07:05 +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 o3CB75c1042505 for ; Mon, 12 Apr 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3CB745L042503 for freebsd-net@FreeBSD.org; Mon, 12 Apr 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Apr 2010 11:07:04 GMT Message-Id: <201004121107.o3CB745L042503@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, 12 Apr 2010 11:07:05 -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/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system 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 kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter 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 o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. o kern/144494 net [ixgbe] ixgbe driver not built as module f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem 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] allow Atheros watchdog timeout to be tun 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/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 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/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon 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/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron 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/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu 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/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC 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/140326 net [em] em0: watchdog timeout when communicating to windo 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/140051 net [bce] [arp] ARP not sent through Bridge Firewall with 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/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir 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 kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom 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/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? 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/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex 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/137317 net [tcp] logs full of syncache problems o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ 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/136876 net [bge] bge will not resume properly after suspend 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/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se 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/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/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 kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) 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/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/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 bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/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/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup 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/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/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/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/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/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o 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/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/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/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 406 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 17:57:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979B91065672 for ; Mon, 12 Apr 2010 17:57:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 02D628FC0A for ; Mon, 12 Apr 2010 17:57:06 +0000 (UTC) Received: by bwz8 with SMTP id 8so3308482bwz.3 for ; Mon, 12 Apr 2010 10:57:05 -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=S4G8FicKEI8Zi+aHYL8RQZzXk9Yt/b5Knt5uAg6IJqo=; b=E7fG6f7kiyItthPNCkqANtCYbGmAAMfztwTKpkfR4k2u8JQWyzgzMF97OqJ+kiheMZ 6FJAn+KnHw4UWG1uyKKKxhg72MB5in3V5VCZqd4qtbggYixLyOqb2kNIugt514IzqjY3 rbFqOliiauYh6M8Y61eQ+iAvwH3ziCxHFVNpA= 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=vmTaG67Q9G3msJxOIPAauD24iQzOSuL5XisjTV6qqGZKJ0cRbzXV281tSTiCqemjU1 2oeUxxLVK6fTfL4L5qO3MdGrmqfCuAVJHfM2+YnU861UqAtciuh1kkFMlC5gGLyvBvug GBbCpK63E3cSldJXcwqCLcSRNz1B1CCnAkrLQ= Received: by 10.204.141.27 with SMTP id k27mr5328231bku.26.1271095025833; Mon, 12 Apr 2010 10:57:05 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 15sm1903399bwz.8.2010.04.12.10.57.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Apr 2010 10:57:03 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 12 Apr 2010 10:57:01 -0700 From: Pyun YongHyeon Date: Mon, 12 Apr 2010 10:57:01 -0700 To: "Erich Jenkins, Fuujin Group Ltd" Message-ID: <20100412175701.GC1444@michelle.cdnetworks.com> References: <4BBED9A4.3080303@fuujingroup.com> <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> <4BC19324.3050800@fuujingroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC19324.3050800@fuujingroup.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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: Mon, 12 Apr 2010 17:57:07 -0000 On Sun, Apr 11, 2010 at 03:15:16AM -0600, Erich Jenkins, Fuujin Group Ltd wrote: > I've been muddling around in src/sys/dev on the old system and the new > system and there appear to be rather major changes to MII and bge, > possibly the whole stack? > It was not completely rewritten but many improvements were made. > There are a number of things that seem to have been merged with other > parts of the network stack, or perhaps written into the individual > drivers (someone working on the net stack would have to verify that). > > For instance, some files called in 5.3-REL seem to have gone away > completely, and in the new (unpatched) version of if_bge.c under > 7.3-REL, calls to these modules are gone: > > - #include /* for vtophys */ > - #include /* for vtophys */ One of the most significant changes would be bus_dma(9) conversion which is required to all drivers to make it work correctly on a variety of platforms. bus_dma(9) does not directly use vtophys anymore so these headers were nuked. > - #include /* for DELAY */ > - #include > > - #include (called but something changed in here) > - #include (ditto above) > No, these headers are still present. > It appears that the checksum features have been completely rewritten, Checksum offloading was not completely rewritten but workaround for buggy controllers was added. > and some of the ring settings have changed. It's interesting that the > driver only fills 256 of the rx rings in the hopes that the cpu is "fast > enough to keep up with the NIC". Would a subroutine here to grab the cpu That magic number 256 is adequate for most cases but it may not be enough to handle heavy loads. Internally the controller use fixed 512 RX buffers but bge(4) used only half of the buffers to save resources. I think you can increase SSLOTS to 512 to get full 512 RX buffers. > clock and count (number of procs/pipelines) be more trouble than it's > worth to "automagically" increase the number of rx rings the driver > fills based on the system in which it's installed? > Dynamically increasing number of RX buffers is doable but it would add much more code. If there is high demand for that I would just increase number of RX buffers to 512. Controller can't be configured to have more than 512 RX buffers. > Something also changed in pci/pcireg.h and pci/pcivar.h, but I haven't > had the time to hunt down and expand the source tree from the 5.3-REL > branch yet. > > I have other machines with copper nics utilizing the bge driver, and > there are no issues at all. Perhaps I'm getting ahead of things, but Yes that is expected one. :-) > since this seems to have been broken through several releases, would it > make any sense to split the support between the BCM5701KHB chipset and > the more recent BCM chipset to avoid causing issues with cards/systems > not currently experiencing troubles? > I'd like to if I can. Supporting huge number of different controllers in single driver is maintenance nightmare. However, rewriting some part that require special handling for certain controller/revision is too risky because I don't have access to most controllers. One theory for the issue I got while reading the code is link state handling. As I said in previous mail, link state handling for TBI is somewhat tricky in bge(4) and driver seemed to rely on periodic register access to keep track of link state. I guess polling(4) may give different behavior on link state handling as it does not rely on interrupts at all. So would you try to use polling(4) and see that make any difference on your box? From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 19:42: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 644C21065672 for ; Mon, 12 Apr 2010 19:42:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id CC6998FC0A for ; Mon, 12 Apr 2010 19:42:17 +0000 (UTC) Received: by bwz8 with SMTP id 8so3425860bwz.3 for ; Mon, 12 Apr 2010 12:42:17 -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=8eeIJEDtuoFa4RZ84A25HqgF1ZXOeY8m7lIh+Hch/yA=; b=nIVcL/YXTBqCRnU33vj03zP2eV+HEKgXWsxf0V+kzif45lZBo8UyOTTWDql0mYTHZr yuhymrLNCuxWQxcbQrFmNncvTXJsLWQtjKVxDOAlVx1hRRqZ2RpxMnOtQyJG+6kHtB6C JeoAFfyYGPXnMXe5vMkBtc0s6VIk/MLjOylgU= 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=iT1hVlKW9pLCkBG5u9kuO3ohCEnFu0x19K2HDby0pULvAc/l5q2teO9XnPfy7MX4UZ bfCaojm9zjlN8qavE6urEbr0p8+YtkanG2UwJRQreW6Iflrb01mu0vkimEqpb/NBWi3K RJMDlc7Vc0TISncbdYx01nvP7QBVyL2khsuVE= Received: by 10.204.39.203 with SMTP id h11mr5481079bke.10.1271101336989; Mon, 12 Apr 2010 12:42:16 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 14sm1956989bwz.2.2010.04.12.12.42.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Apr 2010 12:42:15 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 12 Apr 2010 12:42:09 -0700 From: Pyun YongHyeon Date: Mon, 12 Apr 2010 12:42:09 -0700 To: "Erich Jenkins, Fuujin Group Ltd" Message-ID: <20100412194209.GF1444@michelle.cdnetworks.com> References: <4BBED9A4.3080303@fuujingroup.com> <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> <4BC19324.3050800@fuujingroup.com> <20100412175701.GC1444@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20100412175701.GC1444@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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: Mon, 12 Apr 2010 19:42:19 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 12, 2010 at 10:57:01AM -0700, Pyun YongHyeon wrote: > On Sun, Apr 11, 2010 at 03:15:16AM -0600, Erich Jenkins, Fuujin Group Ltd wrote: > > I've been muddling around in src/sys/dev on the old system and the new > > system and there appear to be rather major changes to MII and bge, > > possibly the whole stack? > > > > It was not completely rewritten but many improvements were made. > > > There are a number of things that seem to have been merged with other > > parts of the network stack, or perhaps written into the individual > > drivers (someone working on the net stack would have to verify that). > > > > For instance, some files called in 5.3-REL seem to have gone away > > completely, and in the new (unpatched) version of if_bge.c under > > 7.3-REL, calls to these modules are gone: > > > > - #include /* for vtophys */ > > - #include /* for vtophys */ > > One of the most significant changes would be bus_dma(9) conversion > which is required to all drivers to make it work correctly on a > variety of platforms. bus_dma(9) does not directly use vtophys > anymore so these headers were nuked. > > > - #include /* for DELAY */ > > - #include > > > > - #include (called but something changed in here) > > - #include (ditto above) > > > > No, these headers are still present. > > > It appears that the checksum features have been completely rewritten, > > Checksum offloading was not completely rewritten but workaround > for buggy controllers was added. > > > and some of the ring settings have changed. It's interesting that the > > driver only fills 256 of the rx rings in the hopes that the cpu is "fast > > enough to keep up with the NIC". Would a subroutine here to grab the cpu > > That magic number 256 is adequate for most cases but it may not be > enough to handle heavy loads. Internally the controller use fixed > 512 RX buffers but bge(4) used only half of the buffers to save > resources. I think you can increase SSLOTS to 512 to get full 512 > RX buffers. > > > clock and count (number of procs/pipelines) be more trouble than it's > > worth to "automagically" increase the number of rx rings the driver > > fills based on the system in which it's installed? > > > > Dynamically increasing number of RX buffers is doable but it would > add much more code. If there is high demand for that I would just > increase number of RX buffers to 512. Controller can't be > configured to have more than 512 RX buffers. > > > Something also changed in pci/pcireg.h and pci/pcivar.h, but I haven't > > had the time to hunt down and expand the source tree from the 5.3-REL > > branch yet. > > > > I have other machines with copper nics utilizing the bge driver, and > > there are no issues at all. Perhaps I'm getting ahead of things, but > > Yes that is expected one. :-) > > > since this seems to have been broken through several releases, would it > > make any sense to split the support between the BCM5701KHB chipset and > > the more recent BCM chipset to avoid causing issues with cards/systems > > not currently experiencing troubles? > > > > I'd like to if I can. Supporting huge number of different > controllers in single driver is maintenance nightmare. However, > rewriting some part that require special handling for certain > controller/revision is too risky because I don't have access to > most controllers. > > One theory for the issue I got while reading the code is link state > handling. As I said in previous mail, link state handling for TBI > is somewhat tricky in bge(4) and driver seemed to rely on periodic > register access to keep track of link state. I guess polling(4) may > give different behavior on link state handling as it does not rely > on interrupts at all. So would you try to use polling(4) and see > that make any difference on your box? If polling(4) make it work, try attached patch. --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.5701.diff2" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 206498) +++ sys/dev/bge/if_bge.c (working copy) @@ -3711,6 +3711,7 @@ { struct bge_softc *sc = xsc; struct mii_data *mii = NULL; + int armintr; BGE_LOCK_ASSERT(sc); @@ -3739,18 +3740,16 @@ * link status manually. Here we register pending link event * and trigger interrupt. */ + #ifdef DEVICE_POLLING /* In polling mode we poll link state in bge_poll(). */ - if (!(sc->bge_ifp->if_capenable & IFCAP_POLLING)) + armintr = (sc->bge_ifp->if_capenable & IFCAP_POLLING) == 0; +#else + armintr = 1; #endif - { sc->bge_link_evt++; - if (sc->bge_asicrev == BGE_ASICREV_BCM5700 || - sc->bge_flags & BGE_FLAG_5788) + if (armintr != 0) BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); - else - BGE_SETBIT(sc, BGE_HCC_MODE, BGE_HCCMODE_COAL_NOW); - } } bge_asf_driver_up(sc); --wRRV7LY7NUeQGEoC-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 22:23: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 2B8CA106564A for ; Mon, 12 Apr 2010 22:23:31 +0000 (UTC) (envelope-from vineetd@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 D3D448FC0A for ; Mon, 12 Apr 2010 22:23:30 +0000 (UTC) Received: by gyh20 with SMTP id 20so3397007gyh.13 for ; Mon, 12 Apr 2010 15:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=dOOpb3d2RZysww2nJ0LZAKeTi36EORFw7pnLV1jBQ14=; b=M0vDqNprFFdqop6ezDGTx22Va2vB9QeR8OkMwtM/gm/Q8kHNkjNgOeKNl33QzZSkqj F138DOUGlIm383+E586RKUjENQiPUuzmT85BO/cRfcgqEKm2+/sDxxDHPQqMB9oGDhWC EIBGIpGHzx3595f9GAw3jZSFWoWwS7+A0LbR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OmS2aVciRVEUsbKzCI3kpwjTeMsV3899IJvyurNQX8Vh9+AOgQRgFYKnFdvnAhlCVN s0qSjn46W0lYmvk+Cguobnw5voKEltA4SCRlFQfAMdWJ6xy7zatO4Ihczwx21U+jQIVM 325KZzLFbV/yMCBVZzoeY4BJVew4rHlTntXlM= MIME-Version: 1.0 Received: by 10.100.137.5 with HTTP; Mon, 12 Apr 2010 14:54:47 -0700 (PDT) Date: Mon, 12 Apr 2010 14:54:47 -0700 Received: by 10.101.28.5 with SMTP id f5mr7593267anj.35.1271109287433; Mon, 12 Apr 2010 14:54:47 -0700 (PDT) Message-ID: From: Vineet Dixit To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Host only TCP/IP implementation based on FreeBSD 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, 12 Apr 2010 22:23:31 -0000 Hi - My apologies in advance in case my question in not appropriate for this list. I am evaluating TCP/IP stack implementation for a device which requires only the end-device network features. I am keen on FreeBSD's TCP/IP implementation due to it's long history of development, use on wide range of devices and code maturity. However my requirements are limited to only transport protocols, IPv4 and IPv6, ARP, DHCP client and so on. I don't need advanced routing and forwarding, multicast, IPSec, QoS which are part of the distribution. FreeBSD's SMP support and fine-grained locking are certainly a bonus but isn't part of MUST have features. Is there an implementation that is a trimmed down TCP/IP stack based on BSD which I could port to another RTOS? Looking for either commercial or open source implementation. Thanks. -- Vineet From owner-freebsd-net@FreeBSD.ORG Mon Apr 12 23:10: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 EA91E106564A for ; Mon, 12 Apr 2010 23:10:41 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id BFBDD8FC18 for ; Mon, 12 Apr 2010 23:10:41 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 9252C439E38; Mon, 12 Apr 2010 18:11:07 -0500 (CDT) Message-ID: <4BC3B676.3070503@fuujingroup.com> Date: Mon, 12 Apr 2010 18:10:30 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4BBED9A4.3080303@fuujingroup.com> <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> <4BC19324.3050800@fuujingroup.com> <20100412175701.GC1444@michelle.cdnetworks.com> <20100412194209.GF1444@michelle.cdnetworks.com> In-Reply-To: <20100412194209.GF1444@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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, 12 Apr 2010 23:10:42 -0000 Pyun YongHyeon wrote: > On Mon, Apr 12, 2010 at 10:57:01AM -0700, Pyun YongHyeon wrote: >> On Sun, Apr 11, 2010 at 03:15:16AM -0600, Erich Jenkins, Fuujin Group Ltd wrote: >>> I've been muddling around in src/sys/dev on the old system and the new >>> system and there appear to be rather major changes to MII and bge, >>> possibly the whole stack? >>> >> It was not completely rewritten but many improvements were made. >> >>> There are a number of things that seem to have been merged with other >>> parts of the network stack, or perhaps written into the individual >>> drivers (someone working on the net stack would have to verify that). >>> >>> For instance, some files called in 5.3-REL seem to have gone away >>> completely, and in the new (unpatched) version of if_bge.c under >>> 7.3-REL, calls to these modules are gone: >>> >>> - #include /* for vtophys */ >>> - #include /* for vtophys */ >> One of the most significant changes would be bus_dma(9) conversion >> which is required to all drivers to make it work correctly on a >> variety of platforms. bus_dma(9) does not directly use vtophys >> anymore so these headers were nuked. >> >>> - #include /* for DELAY */ >>> - #include >>> >>> - #include (called but something changed in here) >>> - #include (ditto above) >>> >> No, these headers are still present. >> >>> It appears that the checksum features have been completely rewritten, >> Checksum offloading was not completely rewritten but workaround >> for buggy controllers was added. >> >>> and some of the ring settings have changed. It's interesting that the >>> driver only fills 256 of the rx rings in the hopes that the cpu is "fast >>> enough to keep up with the NIC". Would a subroutine here to grab the cpu >> That magic number 256 is adequate for most cases but it may not be >> enough to handle heavy loads. Internally the controller use fixed >> 512 RX buffers but bge(4) used only half of the buffers to save >> resources. I think you can increase SSLOTS to 512 to get full 512 >> RX buffers. >> >>> clock and count (number of procs/pipelines) be more trouble than it's >>> worth to "automagically" increase the number of rx rings the driver >>> fills based on the system in which it's installed? >>> >> Dynamically increasing number of RX buffers is doable but it would >> add much more code. If there is high demand for that I would just >> increase number of RX buffers to 512. Controller can't be >> configured to have more than 512 RX buffers. >> >>> Something also changed in pci/pcireg.h and pci/pcivar.h, but I haven't >>> had the time to hunt down and expand the source tree from the 5.3-REL >>> branch yet. >>> >>> I have other machines with copper nics utilizing the bge driver, and >>> there are no issues at all. Perhaps I'm getting ahead of things, but >> Yes that is expected one. :-) >> >>> since this seems to have been broken through several releases, would it >>> make any sense to split the support between the BCM5701KHB chipset and >>> the more recent BCM chipset to avoid causing issues with cards/systems >>> not currently experiencing troubles? >>> >> I'd like to if I can. Supporting huge number of different >> controllers in single driver is maintenance nightmare. However, >> rewriting some part that require special handling for certain >> controller/revision is too risky because I don't have access to >> most controllers. >> >> One theory for the issue I got while reading the code is link state >> handling. As I said in previous mail, link state handling for TBI >> is somewhat tricky in bge(4) and driver seemed to rely on periodic >> register access to keep track of link state. I guess polling(4) may >> give different behavior on link state handling as it does not rely >> on interrupts at all. So would you try to use polling(4) and see >> that make any difference on your box? > > If polling(4) make it work, try attached patch. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" I'll get this set up. I've got a jail issues on 7.0-REL that I'm trying to figure out too, so it might take a few hours before I get to this. I just checked on a reported iSCSI error on a machine using a BCM5721 nic (copper gigE) and I'm seeing issues like this: Apr 11 06:24:59 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad "Opcode": Got 0 expected 5. Apr 11 06:24:59 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** iscsi_write_data_decap() failed Apr 11 16:51:52 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad "Opcode": Got 0 expected 5. Apr 11 16:51:52 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** iscsi_write_data_decap() failed Apr 12 10:32:49 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad "Opcode": Got 0 expected 5. Apr 12 10:32:49 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** iscsi_write_data_decap() failed Apr 12 11:55:42 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad "Opcode": Got 0 expected 5. Apr 12 11:55:42 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** iscsi_write_data_decap() failed Apr 12 14:07:13 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad "Opcode": Got 0 expected 5. Apr 12 14:07:13 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** iscsi_write_data_decap() failed Any chance this could be because of the NIC chipset? I don't see this on any of the machines configured identically, using the em driver for Intel GigE nics. Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 00:02: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 F1659106564A for ; Tue, 13 Apr 2010 00:02:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.221.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2DA8FC08 for ; Tue, 13 Apr 2010 00:02:59 +0000 (UTC) Received: by qyk5 with SMTP id 5so7089017qyk.3 for ; Mon, 12 Apr 2010 17:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=HG3jeTU5T48qQUXYkdMC4FkAHLIyxs5ZyAZ71m9hcyk=; b=CJY1k9FhGw6SADV8SXJUOj0xGeUD0j4MoT65pvNp3aW4DgniaFH0zgSuAIbOMyC6ps HGfI+D04CQ55vY8gJrvgH4AuRYf0YSvLV7xWgTGMQgHtQW2CJ6bBzBmtvtZX7i+30rb7 6HyCMrcmn3Fg9dpjDSs4Io9tc7WNtFxAJkCNY= 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=gVUkOAcc597B2eoIgZPdkFECwK5qigVS0BEAcn6JIPKtqZ6/a+ObwaDeqMr4drb6y2 Z8mKOw0ndX4wAeuEuP0orzEEQlgMpVBpMYJGFjxJQFAMysTxh+bCOb+I+27SUC+vVEOo 7NE2UIWW7Z0aQQZrmCrmkic5c73B0ohLwss+M= Received: by 10.229.182.4 with SMTP id ca4mr4070685qcb.90.1271116977609; Mon, 12 Apr 2010 17:02:57 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id x34sm6753693qce.21.2010.04.12.17.02.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Apr 2010 17:02:55 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 12 Apr 2010 17:02:55 -0700 From: Pyun YongHyeon Date: Mon, 12 Apr 2010 17:02:55 -0700 To: "Erich Jenkins, Fuujin Group Ltd" Message-ID: <20100413000255.GH1444@michelle.cdnetworks.com> References: <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> <4BC19324.3050800@fuujingroup.com> <20100412175701.GC1444@michelle.cdnetworks.com> <20100412194209.GF1444@michelle.cdnetworks.com> <4BC3B676.3070503@fuujingroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC3B676.3070503@fuujingroup.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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: Tue, 13 Apr 2010 00:03:00 -0000 On Mon, Apr 12, 2010 at 06:10:30PM -0600, Erich Jenkins, Fuujin Group Ltd wrote: > Pyun YongHyeon wrote: > >On Mon, Apr 12, 2010 at 10:57:01AM -0700, Pyun YongHyeon wrote: > >>On Sun, Apr 11, 2010 at 03:15:16AM -0600, Erich Jenkins, Fuujin Group Ltd > >>wrote: > >>>I've been muddling around in src/sys/dev on the old system and the new > >>>system and there appear to be rather major changes to MII and bge, > >>>possibly the whole stack? > >>> > >>It was not completely rewritten but many improvements were made. > >> > >>>There are a number of things that seem to have been merged with other > >>>parts of the network stack, or perhaps written into the individual > >>>drivers (someone working on the net stack would have to verify that). > >>> > >>>For instance, some files called in 5.3-REL seem to have gone away > >>>completely, and in the new (unpatched) version of if_bge.c under > >>>7.3-REL, calls to these modules are gone: > >>> > >>>- #include /* for vtophys */ > >>>- #include /* for vtophys */ > >>One of the most significant changes would be bus_dma(9) conversion > >>which is required to all drivers to make it work correctly on a > >>variety of platforms. bus_dma(9) does not directly use vtophys > >>anymore so these headers were nuked. > >> > >>>- #include /* for DELAY */ > >>>- #include > >>> > >>>- #include (called but something changed in here) > >>>- #include (ditto above) > >>> > >>No, these headers are still present. > >> > >>>It appears that the checksum features have been completely rewritten, > >>Checksum offloading was not completely rewritten but workaround > >>for buggy controllers was added. > >> > >>>and some of the ring settings have changed. It's interesting that the > >>>driver only fills 256 of the rx rings in the hopes that the cpu is "fast > >>>enough to keep up with the NIC". Would a subroutine here to grab the cpu > >>That magic number 256 is adequate for most cases but it may not be > >>enough to handle heavy loads. Internally the controller use fixed > >>512 RX buffers but bge(4) used only half of the buffers to save > >>resources. I think you can increase SSLOTS to 512 to get full 512 > >>RX buffers. > >> > >>>clock and count (number of procs/pipelines) be more trouble than it's > >>>worth to "automagically" increase the number of rx rings the driver > >>>fills based on the system in which it's installed? > >>> > >>Dynamically increasing number of RX buffers is doable but it would > >>add much more code. If there is high demand for that I would just > >>increase number of RX buffers to 512. Controller can't be > >>configured to have more than 512 RX buffers. > >> > >>>Something also changed in pci/pcireg.h and pci/pcivar.h, but I haven't > >>>had the time to hunt down and expand the source tree from the 5.3-REL > >>>branch yet. > >>> > >>>I have other machines with copper nics utilizing the bge driver, and > >>>there are no issues at all. Perhaps I'm getting ahead of things, but > >>Yes that is expected one. :-) > >> > >>>since this seems to have been broken through several releases, would it > >>>make any sense to split the support between the BCM5701KHB chipset and > >>>the more recent BCM chipset to avoid causing issues with cards/systems > >>>not currently experiencing troubles? > >>> > >>I'd like to if I can. Supporting huge number of different > >>controllers in single driver is maintenance nightmare. However, > >>rewriting some part that require special handling for certain > >>controller/revision is too risky because I don't have access to > >>most controllers. > >> > >>One theory for the issue I got while reading the code is link state > >>handling. As I said in previous mail, link state handling for TBI > >>is somewhat tricky in bge(4) and driver seemed to rely on periodic > >>register access to keep track of link state. I guess polling(4) may > >>give different behavior on link state handling as it does not rely > >>on interrupts at all. So would you try to use polling(4) and see > >>that make any difference on your box? > > > >If polling(4) make it work, try attached patch. > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >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" > > I'll get this set up. I've got a jail issues on 7.0-REL that I'm trying > to figure out too, so it might take a few hours before I get to this. > I beleive bge(4) in 7.0-RELEASE and 7.3-RELEASE is quite different. So I'm not sure whether the patch works on 7.0-RELEASE. > I just checked on a reported iSCSI error on a machine using a BCM5721 > nic (copper gigE) and I'm seeing issues like this: > > Apr 11 06:24:59 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > "Opcode": Got 0 expected 5. > Apr 11 06:24:59 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > iscsi_write_data_decap() failed > Apr 11 16:51:52 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > "Opcode": Got 0 expected 5. > Apr 11 16:51:52 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > iscsi_write_data_decap() failed > Apr 12 10:32:49 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > "Opcode": Got 0 expected 5. > Apr 12 10:32:49 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > iscsi_write_data_decap() failed > Apr 12 11:55:42 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > "Opcode": Got 0 expected 5. > Apr 12 11:55:42 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > iscsi_write_data_decap() failed > Apr 12 14:07:13 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > "Opcode": Got 0 expected 5. > Apr 12 14:07:13 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > iscsi_write_data_decap() failed > > Any chance this could be because of the NIC chipset? I don't see this on > any of the machines configured identically, using the em driver for > Intel GigE nics. > Have no idea what happens here. Does this also happen on 7.3-RELEASE? From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 00:05:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76190106566C for ; Tue, 13 Apr 2010 00:05:22 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC248FC15 for ; Tue, 13 Apr 2010 00:05:22 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 6C2D8439E38; Mon, 12 Apr 2010 19:05:48 -0500 (CDT) Message-ID: <4BC3C347.3010701@fuujingroup.com> Date: Mon, 12 Apr 2010 19:05:11 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> <4BC19324.3050800@fuujingroup.com> <20100412175701.GC1444@michelle.cdnetworks.com> <20100412194209.GF1444@michelle.cdnetworks.com> <4BC3B676.3070503@fuujingroup.com> <20100413000255.GH1444@michelle.cdnetworks.com> In-Reply-To: <20100413000255.GH1444@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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, 13 Apr 2010 00:05:22 -0000 Pyun YongHyeon wrote: > On Mon, Apr 12, 2010 at 06:10:30PM -0600, Erich Jenkins, Fuujin Group Ltd wrote: >> Pyun YongHyeon wrote: >>> On Mon, Apr 12, 2010 at 10:57:01AM -0700, Pyun YongHyeon wrote: >>>> On Sun, Apr 11, 2010 at 03:15:16AM -0600, Erich Jenkins, Fuujin Group Ltd >>>> wrote: >>>>> I've been muddling around in src/sys/dev on the old system and the new >>>>> system and there appear to be rather major changes to MII and bge, >>>>> possibly the whole stack? >>>>> >>>> It was not completely rewritten but many improvements were made. >>>> >>>>> There are a number of things that seem to have been merged with other >>>>> parts of the network stack, or perhaps written into the individual >>>>> drivers (someone working on the net stack would have to verify that). >>>>> >>>>> For instance, some files called in 5.3-REL seem to have gone away >>>>> completely, and in the new (unpatched) version of if_bge.c under >>>>> 7.3-REL, calls to these modules are gone: >>>>> >>>>> - #include /* for vtophys */ >>>>> - #include /* for vtophys */ >>>> One of the most significant changes would be bus_dma(9) conversion >>>> which is required to all drivers to make it work correctly on a >>>> variety of platforms. bus_dma(9) does not directly use vtophys >>>> anymore so these headers were nuked. >>>> >>>>> - #include /* for DELAY */ >>>>> - #include >>>>> >>>>> - #include (called but something changed in here) >>>>> - #include (ditto above) >>>>> >>>> No, these headers are still present. >>>> >>>>> It appears that the checksum features have been completely rewritten, >>>> Checksum offloading was not completely rewritten but workaround >>>> for buggy controllers was added. >>>> >>>>> and some of the ring settings have changed. It's interesting that the >>>>> driver only fills 256 of the rx rings in the hopes that the cpu is "fast >>>>> enough to keep up with the NIC". Would a subroutine here to grab the cpu >>>> That magic number 256 is adequate for most cases but it may not be >>>> enough to handle heavy loads. Internally the controller use fixed >>>> 512 RX buffers but bge(4) used only half of the buffers to save >>>> resources. I think you can increase SSLOTS to 512 to get full 512 >>>> RX buffers. >>>> >>>>> clock and count (number of procs/pipelines) be more trouble than it's >>>>> worth to "automagically" increase the number of rx rings the driver >>>>> fills based on the system in which it's installed? >>>>> >>>> Dynamically increasing number of RX buffers is doable but it would >>>> add much more code. If there is high demand for that I would just >>>> increase number of RX buffers to 512. Controller can't be >>>> configured to have more than 512 RX buffers. >>>> >>>>> Something also changed in pci/pcireg.h and pci/pcivar.h, but I haven't >>>>> had the time to hunt down and expand the source tree from the 5.3-REL >>>>> branch yet. >>>>> >>>>> I have other machines with copper nics utilizing the bge driver, and >>>>> there are no issues at all. Perhaps I'm getting ahead of things, but >>>> Yes that is expected one. :-) >>>> >>>>> since this seems to have been broken through several releases, would it >>>>> make any sense to split the support between the BCM5701KHB chipset and >>>>> the more recent BCM chipset to avoid causing issues with cards/systems >>>>> not currently experiencing troubles? >>>>> >>>> I'd like to if I can. Supporting huge number of different >>>> controllers in single driver is maintenance nightmare. However, >>>> rewriting some part that require special handling for certain >>>> controller/revision is too risky because I don't have access to >>>> most controllers. >>>> >>>> One theory for the issue I got while reading the code is link state >>>> handling. As I said in previous mail, link state handling for TBI >>>> is somewhat tricky in bge(4) and driver seemed to rely on periodic >>>> register access to keep track of link state. I guess polling(4) may >>>> give different behavior on link state handling as it does not rely >>>> on interrupts at all. So would you try to use polling(4) and see >>>> that make any difference on your box? >>> If polling(4) make it work, try attached patch. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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" >> I'll get this set up. I've got a jail issues on 7.0-REL that I'm trying >> to figure out too, so it might take a few hours before I get to this. >> > > I beleive bge(4) in 7.0-RELEASE and 7.3-RELEASE is quite different. > So I'm not sure whether the patch works on 7.0-RELEASE. > >> I just checked on a reported iSCSI error on a machine using a BCM5721 >> nic (copper gigE) and I'm seeing issues like this: >> >> Apr 11 06:24:59 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad >> "Opcode": Got 0 expected 5. >> Apr 11 06:24:59 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** >> iscsi_write_data_decap() failed >> Apr 11 16:51:52 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad >> "Opcode": Got 0 expected 5. >> Apr 11 16:51:52 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** >> iscsi_write_data_decap() failed >> Apr 12 10:32:49 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad >> "Opcode": Got 0 expected 5. >> Apr 12 10:32:49 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** >> iscsi_write_data_decap() failed >> Apr 12 11:55:42 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad >> "Opcode": Got 0 expected 5. >> Apr 12 11:55:42 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** >> iscsi_write_data_decap() failed >> Apr 12 14:07:13 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad >> "Opcode": Got 0 expected 5. >> Apr 12 14:07:13 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** >> iscsi_write_data_decap() failed >> >> Any chance this could be because of the NIC chipset? I don't see this on >> any of the machines configured identically, using the em driver for >> Intel GigE nics. >> > > Have no idea what happens here. Does this also happen on > 7.3-RELEASE? > _______________________________________________ > 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" Sorry, I meant to say I'd reinstall 7.3-REL to test this. The iSCSI issues are happening on 8.0-REL. Are there any major differences between 7.3 and 8.0 in the bge driver or network stack that could be contributing to this? Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 00:25:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE8201065678 for ; Tue, 13 Apr 2010 00:25:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5945A8FC1D for ; Tue, 13 Apr 2010 00:25:01 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so2168221qwi.7 for ; Mon, 12 Apr 2010 17:25:01 -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=fT5Zx0uJpTqijycEZwJlo/5GJWCOfkoc+RazPQjNjcU=; b=nNuSg2yJwM+0G0jyyuGoVwZrLCHaoNze5TX+LxLlLZ3zgau0wWzPp6vh1aPYDoi0Fv 7C/lZ2/g37HT+NPyjI+unoEsRP/U5UYaiAp/D66vPxLY9mLSUb9axJVP7xS8FnVrVzlo xQWqWeDmqHRHdhfZKwF9/uY2EF3dDk3iXeq4E= 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=lqjlsB9UMEfk/UGOVvNvkQQB6JOTVrbc8TNYFvfsThQSY1kS8lPPYnxrAdD0vryrGJ 9DjdjFFIfZ/qd5OlCgEFHExqCWOlNYLQ2GNclOYVJVDZweWCfwzbQY4YLU0ASarjStF3 PIftwwgSDneQMOupebN3Aa57pJboff/Vhlf00= Received: by 10.229.227.149 with SMTP id ja21mr3213524qcb.74.1271118301236; Mon, 12 Apr 2010 17:25:01 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y41sm6774527qce.17.2010.04.12.17.24.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Apr 2010 17:24:59 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 12 Apr 2010 17:24:59 -0700 From: Pyun YongHyeon Date: Mon, 12 Apr 2010 17:24:59 -0700 To: "Erich Jenkins, Fuujin Group Ltd" Message-ID: <20100413002459.GI1444@michelle.cdnetworks.com> References: <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> <4BC19324.3050800@fuujingroup.com> <20100412175701.GC1444@michelle.cdnetworks.com> <20100412194209.GF1444@michelle.cdnetworks.com> <4BC3B676.3070503@fuujingroup.com> <20100413000255.GH1444@michelle.cdnetworks.com> <4BC3C347.3010701@fuujingroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC3C347.3010701@fuujingroup.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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: Tue, 13 Apr 2010 00:25:02 -0000 On Mon, Apr 12, 2010 at 07:05:11PM -0600, Erich Jenkins, Fuujin Group Ltd wrote: > Pyun YongHyeon wrote: > >On Mon, Apr 12, 2010 at 06:10:30PM -0600, Erich Jenkins, Fuujin Group Ltd > >wrote: > >>Pyun YongHyeon wrote: > >>>On Mon, Apr 12, 2010 at 10:57:01AM -0700, Pyun YongHyeon wrote: > >>>>On Sun, Apr 11, 2010 at 03:15:16AM -0600, Erich Jenkins, Fuujin Group > >>>>Ltd wrote: > >>>>>I've been muddling around in src/sys/dev on the old system and the new > >>>>>system and there appear to be rather major changes to MII and bge, > >>>>>possibly the whole stack? > >>>>> > >>>>It was not completely rewritten but many improvements were made. > >>>> > >>>>>There are a number of things that seem to have been merged with other > >>>>>parts of the network stack, or perhaps written into the individual > >>>>>drivers (someone working on the net stack would have to verify that). > >>>>> > >>>>>For instance, some files called in 5.3-REL seem to have gone away > >>>>>completely, and in the new (unpatched) version of if_bge.c under > >>>>>7.3-REL, calls to these modules are gone: > >>>>> > >>>>>- #include /* for vtophys */ > >>>>>- #include /* for vtophys */ > >>>>One of the most significant changes would be bus_dma(9) conversion > >>>>which is required to all drivers to make it work correctly on a > >>>>variety of platforms. bus_dma(9) does not directly use vtophys > >>>>anymore so these headers were nuked. > >>>> > >>>>>- #include /* for DELAY */ > >>>>>- #include > >>>>> > >>>>>- #include (called but something changed in here) > >>>>>- #include (ditto above) > >>>>> > >>>>No, these headers are still present. > >>>> > >>>>>It appears that the checksum features have been completely rewritten, > >>>>Checksum offloading was not completely rewritten but workaround > >>>>for buggy controllers was added. > >>>> > >>>>>and some of the ring settings have changed. It's interesting that the > >>>>>driver only fills 256 of the rx rings in the hopes that the cpu is > >>>>>"fast enough to keep up with the NIC". Would a subroutine here to grab > >>>>>the cpu > >>>>That magic number 256 is adequate for most cases but it may not be > >>>>enough to handle heavy loads. Internally the controller use fixed > >>>>512 RX buffers but bge(4) used only half of the buffers to save > >>>>resources. I think you can increase SSLOTS to 512 to get full 512 > >>>>RX buffers. > >>>> > >>>>>clock and count (number of procs/pipelines) be more trouble than it's > >>>>>worth to "automagically" increase the number of rx rings the driver > >>>>>fills based on the system in which it's installed? > >>>>> > >>>>Dynamically increasing number of RX buffers is doable but it would > >>>>add much more code. If there is high demand for that I would just > >>>>increase number of RX buffers to 512. Controller can't be > >>>>configured to have more than 512 RX buffers. > >>>> > >>>>>Something also changed in pci/pcireg.h and pci/pcivar.h, but I haven't > >>>>>had the time to hunt down and expand the source tree from the 5.3-REL > >>>>>branch yet. > >>>>> > >>>>>I have other machines with copper nics utilizing the bge driver, and > >>>>>there are no issues at all. Perhaps I'm getting ahead of things, but > >>>>Yes that is expected one. :-) > >>>> > >>>>>since this seems to have been broken through several releases, would > >>>>>it make any sense to split the support between the BCM5701KHB chipset > >>>>>and the more recent BCM chipset to avoid causing issues with > >>>>>cards/systems not currently experiencing troubles? > >>>>> > >>>>I'd like to if I can. Supporting huge number of different > >>>>controllers in single driver is maintenance nightmare. However, > >>>>rewriting some part that require special handling for certain > >>>>controller/revision is too risky because I don't have access to > >>>>most controllers. > >>>> > >>>>One theory for the issue I got while reading the code is link state > >>>>handling. As I said in previous mail, link state handling for TBI > >>>>is somewhat tricky in bge(4) and driver seemed to rely on periodic > >>>>register access to keep track of link state. I guess polling(4) may > >>>>give different behavior on link state handling as it does not rely > >>>>on interrupts at all. So would you try to use polling(4) and see > >>>>that make any difference on your box? > >>>If polling(4) make it work, try attached patch. > >>> > >>> > >>>------------------------------------------------------------------------ > >>> > >>>_______________________________________________ > >>>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" > >>I'll get this set up. I've got a jail issues on 7.0-REL that I'm trying > >>to figure out too, so it might take a few hours before I get to this. > >> > > > >I beleive bge(4) in 7.0-RELEASE and 7.3-RELEASE is quite different. > >So I'm not sure whether the patch works on 7.0-RELEASE. > > > >>I just checked on a reported iSCSI error on a machine using a BCM5721 > >>nic (copper gigE) and I'm seeing issues like this: > >> > >>Apr 11 06:24:59 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > >>"Opcode": Got 0 expected 5. > >>Apr 11 06:24:59 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > >>iscsi_write_data_decap() failed > >>Apr 11 16:51:52 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > >>"Opcode": Got 0 expected 5. > >>Apr 11 16:51:52 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > >>iscsi_write_data_decap() failed > >>Apr 12 10:32:49 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > >>"Opcode": Got 0 expected 5. > >>Apr 12 10:32:49 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > >>iscsi_write_data_decap() failed > >>Apr 12 11:55:42 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > >>"Opcode": Got 0 expected 5. > >>Apr 12 11:55:42 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > >>iscsi_write_data_decap() failed > >>Apr 12 14:07:13 san0 iscsi-target: pid 863:iscsi.c:1149: ***ERROR*** Bad > >>"Opcode": Got 0 expected 5. > >>Apr 12 14:07:13 san0 iscsi-target: pid 863:target.c:1317: ***ERROR*** > >>iscsi_write_data_decap() failed > >> > >>Any chance this could be because of the NIC chipset? I don't see this on > >>any of the machines configured identically, using the em driver for > >>Intel GigE nics. > >> > > > >Have no idea what happens here. Does this also happen on > >7.3-RELEASE? > >_______________________________________________ > >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" > > Sorry, I meant to say I'd reinstall 7.3-REL to test this. > > The iSCSI issues are happening on 8.0-REL. Are there any major > differences between 7.3 and 8.0 in the bge driver or network stack that > could be contributing to this? > 7.3-RELEASE has more recent bge(4) changes. Most changes are related with RX buffer handling and bus_dma(9) fixes. See CVS web interface for more details. 8.0 has new network stack that has some nice/experimental features. But I guess it wouldn't affect iscsi behavior. It's just wild guess, I have no experience on iscsi so others can point out iscsi differences between 7.3-RELEASE and 8.0-RELEASE. From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 02:26: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 566691065670 for ; Tue, 13 Apr 2010 02:26:52 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from mailfilter45.ihug.co.nz (mailfilter45.ihug.co.nz [203.109.136.45]) by mx1.freebsd.org (Postfix) with ESMTP id EC3998FC13 for ; Tue, 13 Apr 2010 02:26:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJZrw0t2XRqM/2dsb2JhbACPaotZcrwfhQwEi0Y X-IronPort-AV: E=Sophos;i="4.52,193,1270382400"; d="scan'208";a="26247524" Received: from 118-93-26-140.dsl.dyn.ihug.co.nz (HELO spandex.luckie.org.nz) ([118.93.26.140]) by cust.filter1.content.vf.net.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2010 13:57:03 +1200 Received: from mjl by spandex.luckie.org.nz with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1VN7-000GFX-OY for freebsd-net@freebsd.org; Tue, 13 Apr 2010 13:57:01 +1200 Date: Tue, 13 Apr 2010 13:57:01 +1200 From: Matthew Luckie To: freebsd-net@freebsd.org Message-ID: <20100413015701.GA62420@spandex.luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: reassembled packets and pfil 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, 13 Apr 2010 02:26:52 -0000 Hi Reassembled packets are not passed to the packet filter interface for both IPv4 and IPv6, so a firewall has no effect if the packets arrive in fragments. Here is a patch to fix this for IPv6. The patch for IPv4 is similarly trivial, but I have not written / tested it yet. Is there any particular reason why reassembled packets were not checked? If the answer is no, I'll send in a PR. I've tested the patch below. Matthew --- sys/netinet6/frag6.c.orig 2008-11-25 15:59:29.000000000 +1300 +++ sys/netinet6/frag6.c 2010-04-13 13:21:02.000000000 +1200 @@ -46,6 +46,7 @@ __FBSDID("$FreeBSD: src/sys/netinet6/fra #include #include +#include #include #include @@ -568,6 +569,13 @@ insert: *offp = offset; IP6Q_UNLOCK(); + + if (PFIL_HOOKED(&inet6_pfil_hook) && + (pfil_run_hooks(&inet6_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL) || + m == NULL)) { + return IPPROTO_DONE; + } + return nxt; dropfrag: From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 04:15:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97CB106564A for ; Tue, 13 Apr 2010 04:15:13 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2DC8FC12 for ; Tue, 13 Apr 2010 04:15:13 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 3D877439E38; Mon, 12 Apr 2010 23:15:39 -0500 (CDT) Message-ID: <4BC3FDD6.6080109@fuujingroup.com> Date: Mon, 12 Apr 2010 23:15:02 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20100409070147.GA77350@korolev-net.ru> <4BBEE18C.6040204@fuujingroup.com> <20100409173821.GD1085@michelle.cdnetworks.com> <4BC016F3.4020300@fuujingroup.com> <20100410212520.GB6481@michelle.cdnetworks.com> <4BC12097.4030508@fuujingroup.com> <4BC19324.3050800@fuujingroup.com> <20100412175701.GC1444@michelle.cdnetworks.com> <20100412194209.GF1444@michelle.cdnetworks.com> <4BC3B676.3070503@fuujingroup.com> <20100413000255.GH1444@michelle.cdnetworks.com> <4BC3C347.3010701@fuujingroup.com> In-Reply-To: <4BC3C347.3010701@fuujingroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Evgenii Davidov Subject: Re: Broadcom BCM5701 / HP NC6770 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, 13 Apr 2010 04:15:13 -0000 Erich Jenkins, Fuujin Group Ltd wrote: > Pyun YongHyeon wrote: >> On Mon, Apr 12, 2010 at 06:10:30PM -0600, Erich Jenkins, Fuujin Group >> Ltd wrote: >>> Pyun YongHyeon wrote: >>>> On Mon, Apr 12, 2010 at 10:57:01AM -0700, Pyun YongHyeon wrote: >>>>> On Sun, Apr 11, 2010 at 03:15:16AM -0600, Erich Jenkins, Fuujin >>>>> Group Ltd wrote: >>>>>> I've been muddling around in src/sys/dev on the old system and the >>>>>> new system and there appear to be rather major changes to MII and >> >> Have no idea what happens here. Does this also happen on >> 7.3-RELEASE? >> _______________________________________________ >> 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" > > Sorry, I meant to say I'd reinstall 7.3-REL to test this. > > The iSCSI issues are happening on 8.0-REL. Are there any major > differences between 7.3 and 8.0 in the bge driver or network stack that > could be contributing to this? > > > Erich M. Jenkins > Fuujin Group Limited > > "You should never, never doubt what no one is sure about." > -- Gene Wilder > _______________________________________________ > 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" Well, after a reinstall of 7.3-REL and trying polling, there seems to be no difference in network connectivity using th BCM5701 GigE nics. Is this a problem worth fighting considering how many different cards with broadcom chipsets might be affected by changes without splitting the driver? Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 05:16: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 7DA151065673 for ; Tue, 13 Apr 2010 05:16:59 +0000 (UTC) (envelope-from iwan.ilt@gmail.com) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.211.193]) by mx1.freebsd.org (Postfix) with ESMTP id 33C568FC0C for ; Tue, 13 Apr 2010 05:16:58 +0000 (UTC) Received: by ywh31 with SMTP id 31so1790506ywh.3 for ; Mon, 12 Apr 2010 22:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=GaNl1YEa9v2CweeUJ5XVSaMbs+ahMuCVbZZ8RwtPlQI=; b=qNWnKOovf8iMXTgFva4Iy0aE6xr+7NFvSzkzHCTXV65lVU2vHGMJNAxQzSiogN9cWr JmVHfS4TigyYbxnq1xGu5RjWS3geP36Cd44d1+vwbKxvqJllivgh7FxfEVzpibdR0Qmk K2r9cbhhKv0fcriHTgzFUaoFDh7aHVzk2JoOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iIFjljoSgspvMGY7cZMAb/SBwBxsOgk++AyjhOCXhR/kxDTokSJWZgExLS2RbRlQuu MFIkvRIhZJs1PEYVJwg+ofwmL+LsbYM7CAZBIJanNjWAhTUISJoT/3mGZ4ERkoGm8zVU XQfGscTTC+ZLCGkdoB1pVntgC0U62hmZQohcM= Received: by 10.150.214.13 with SMTP id m13mr1870322ybg.134.1271134112866; Mon, 12 Apr 2010 21:48:32 -0700 (PDT) Received: from [192.168.1.38] ([118.96.230.203]) by mx.google.com with ESMTPS id 9sm1289600yxf.47.2010.04.12.21.48.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Apr 2010 21:48:32 -0700 (PDT) Message-ID: <4BC3F7D2.50303@gmail.com> Date: Tue, 13 Apr 2010 11:49:22 +0700 From: Iwan Budi Kusnanto User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Vineet Dixit References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Host only TCP/IP implementation based on FreeBSD 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, 13 Apr 2010 05:16:59 -0000 Vineet Dixit wrote: > Hi - > > My apologies in advance in case my question in not appropriate for this list. > > I am evaluating TCP/IP stack implementation for a device which > requires only the end-device network features. I am keen on FreeBSD's > TCP/IP implementation due to it's long history of development, use on > wide range of devices and code maturity. However my requirements are > limited to only transport protocols, IPv4 and IPv6, ARP, DHCP client > and so on. I don't need advanced routing and forwarding, multicast, > IPSec, QoS which are part of the distribution. FreeBSD's SMP support > and fine-grained locking are certainly a bonus but isn't part of MUST > have features. > > Is there an implementation that is a trimmed down TCP/IP stack based > on BSD which I could port to another RTOS? Looking for either > commercial or open source implementation. http://en.wikipedia.org/wiki/LwIP lwIP (lightweight IP) is a widely used open source TCP/IP stack designed for embedded systems. lwIP was originally developed by Adam Dunkels at the Swedish Institute of Computer Science and is now developed and maintained by a world wide network of developers led by Kieran Mansley. lwIP is used by many manufacturers of embedded systems. Examples include Altera (in the Nios II operating system), Analog Devices (for the Blackfin DSP chip), Xilinx and Honeywell (for some of their FAA certified avionics systems). The focus of the lwIP TCP/IP implementation is to reduce resource usage while still having a full scale TCP. This makes lwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM ....... > > Thanks. > > -- Vineet > _______________________________________________ > 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" > -- Iwan Budi Kusnanto From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 06:47:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22FA81065670 for ; Tue, 13 Apr 2010 06:47:09 +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 C8A1B8FC1E for ; Tue, 13 Apr 2010 06:47:08 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 64A8473098; Tue, 13 Apr 2010 08:57:32 +0200 (CEST) Date: Tue, 13 Apr 2010 08:57:32 +0200 From: Luigi Rizzo To: Matthew Luckie Message-ID: <20100413065732.GB3063@onelab2.iet.unipi.it> References: <20100413015701.GA62420@spandex.luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100413015701.GA62420@spandex.luckie.org.nz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: reassembled packets and pfil 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, 13 Apr 2010 06:47:09 -0000 On Tue, Apr 13, 2010 at 01:57:01PM +1200, Matthew Luckie wrote: > Hi > > Reassembled packets are not passed to the packet filter interface for > both IPv4 and IPv6, so a firewall has no effect if the packets arrive > in fragments. Here is a patch to fix this for IPv6. The patch for > IPv4 is similarly trivial, but I have not written / tested it yet. > > Is there any particular reason why reassembled packets were not > checked? If the answer is no, I'll send in a PR. I think it was just a random decision -- either pass packets to the firewall before reassembly as we do, or after reassembly, as linux does. Both have pros and cons. Going through the firewall twice, however, is problematic because far too many things (counters, dummynet, etc.) expect to see each packet only once. I think that a patch like the one you propose is very useful (for ipv4 as well) but it requires a sysctl or other mechanism to make sure that when it is enabled we don't pass fragments through the firewall. cheers luigi > I've tested the patch below. > > Matthew > > --- sys/netinet6/frag6.c.orig 2008-11-25 15:59:29.000000000 +1300 > +++ sys/netinet6/frag6.c 2010-04-13 13:21:02.000000000 +1200 > @@ -46,6 +46,7 @@ __FBSDID("$FreeBSD: src/sys/netinet6/fra > > #include > #include > +#include > > #include > #include > @@ -568,6 +569,13 @@ insert: > *offp = offset; > > IP6Q_UNLOCK(); > + > + if (PFIL_HOOKED(&inet6_pfil_hook) && > + (pfil_run_hooks(&inet6_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL) || > + m == NULL)) { > + return IPPROTO_DONE; > + } > + > return nxt; > > dropfrag: > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 07:36: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 4ACC2106566B for ; Tue, 13 Apr 2010 07:36:57 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from mailfilter66.ihug.co.nz (mailfilter66.ihug.co.nz [203.109.136.66]) by mx1.freebsd.org (Postfix) with ESMTP id D512E8FC16 for ; Tue, 13 Apr 2010 07:36:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEe7w0t2XRqM/2dsb2JhbACbQnK7bIUMBItQ X-IronPort-AV: E=Sophos;i="4.52,196,1270382400"; d="scan'208";a="271639111" Received: from 118-93-26-140.dsl.dyn.ihug.co.nz (HELO spandex.luckie.org.nz) ([118.93.26.140]) by cust.filter2.content.vf.net.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2010 19:36:54 +1200 Received: from mylar.luckie.org.nz ([192.168.1.24]) by spandex.luckie.org.nz with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1ag1-000H53-Si; Tue, 13 Apr 2010 19:36:53 +1200 Message-ID: <4BC41F17.5000201@luckie.org.nz> Date: Tue, 13 Apr 2010 19:36:55 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100406 Thunderbird/3.0.4 MIME-Version: 1.0 To: Luigi Rizzo References: <20100413015701.GA62420@spandex.luckie.org.nz> <20100413065732.GB3063@onelab2.iet.unipi.it> In-Reply-To: <20100413065732.GB3063@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: reassembled packets and pfil 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, 13 Apr 2010 07:36:57 -0000 >> Is there any particular reason why reassembled packets were not >> checked? If the answer is no, I'll send in a PR. > > I think it was just a random decision -- either pass packets to > the firewall before reassembly as we do, or after reassembly, as > linux does. Both have pros and cons. > Going through the firewall twice, however, is problematic because > far too many things (counters, dummynet, etc.) expect to see each > packet only once. ok, thanks for letting me know. > I think that a patch like the one you propose is very useful (for > ipv4 as well) but it requires a sysctl or other mechanism to make > sure that when it is enabled we don't pass fragments through the > firewall. i've looked further into this and I now wonder if is a byproduct of my use of ipfw. the problem seems to be that offset will always be non-zero with any packet with a v6 fragment header, so a rule requiring offset to be zero is never run. i'll spend a bit more time on this tomorrow, and come back with a patch for ipfw. Note this code: offset = ((struct ip6_frag *)ulp)->ip6f_offlg & IP6F_OFF_MASK; /* Add IP6F_MORE_FRAG for offset of first * fragment to be != 0. */ offset |= ((struct ip6_frag *)ulp)->ip6f_offlg & IP6F_MORE_FRAG; if (offset == 0) { printf("IPFW2: IPV6 - Invalid Fragment Header\n"); if (fw_deny_unknown_exthdrs) return (IP_FW_DENY); break; } This code seems to be incorrect, per rfc 2460: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. A stack can send an IPv6 packet with a fragment header attached that does not have the MF bit set. I'm 90% sure that FreeBSD itself will do this when it receives a PTB with an MTU value of (say) 1000. Matthew From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 07:41: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 E9EF01065674 for ; Tue, 13 Apr 2010 07:41:11 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 76E8F8FC19 for ; Tue, 13 Apr 2010 07:41:11 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so1278776fge.13 for ; Tue, 13 Apr 2010 00:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=hpX+n5a6tqJ+ahRFNKc7h4ZM/KXE05ZwWE9FNl8VESE=; b=HIHl/B+pGkZwBlbA+K3EYh4Fad96CkEfsSCajfdat9r/yy2TRKesMLU4TalPSl73ng rkD+Ex55LUCekNXKTEYa6kTzkIpXwNk47lTvFd1Uu20IujWj5PEdiIw1wume3eWDTDe2 Dbs+LUlpRkko5ud5DsaadvtEc2h4oQhWiGj+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=uJEPMKMQ+z3uz8z63fqMYX2vXyZqbZKZMQxHQl/HYdj6t+yYwx56LWiI1TzRatJbwl qlbhNVbwvab8bl01jYjIELCzQrR9mF5eCQe9p9vcBH9qZTvEkfVefXT+4f6+xpws1TJr JBC6n8Gpc+i9aGH1kPHEb6POTT7WwCTiRjWog= MIME-Version: 1.0 Received: by 10.223.124.4 with HTTP; Tue, 13 Apr 2010 00:17:51 -0700 (PDT) In-Reply-To: References: From: Ivo Vachkov Date: Tue, 13 Apr 2010 10:17:51 +0300 Received: by 10.223.15.21 with SMTP id i21mr3120434faa.58.1271143091183; Tue, 13 Apr 2010 00:18:11 -0700 (PDT) Message-ID: To: Vineet Dixit Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Host only TCP/IP implementation based on FreeBSD 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, 13 Apr 2010 07:41:12 -0000 Hello, You can look at http://www.rtems.com/ Their TCP/IP stack is derived from FreeBSD and is probably better suited for 'extraction' than current FreeBSD TCP/IP implementation. Also, the QNX public SVN repository should contain QNX's fork of the NetBSD network stack as separate resource manager. On Tue, Apr 13, 2010 at 12:54 AM, Vineet Dixit wrote: > Hi - > > My apologies in advance in case my question in not appropriate for this l= ist. > > I am evaluating TCP/IP stack implementation =C2=A0for a device which > requires only the end-device network features. I am keen on FreeBSD's > TCP/IP implementation due to it's long history of development, use on > wide range of devices and code maturity. However my requirements are > limited to only transport protocols, IPv4 and IPv6, ARP, DHCP client > and so on. I don't need advanced routing and forwarding, multicast, > IPSec, QoS which are part of the distribution. FreeBSD's SMP support > and fine-grained locking are certainly a bonus but isn't part of MUST > have features. > > Is there an implementation that is a trimmed down TCP/IP stack based > on BSD which I could port to another RTOS? Looking for either > commercial or open source implementation. > > Thanks. > > -- Vineet > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 12:00:14 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABC251065704 for ; Tue, 13 Apr 2010 12:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9BE7F8FC29 for ; Tue, 13 Apr 2010 12:00:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3DC0ELq066763 for ; Tue, 13 Apr 2010 12:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3DC0ElS066762; Tue, 13 Apr 2010 12:00:14 GMT (envelope-from gnats) Date: Tue, 13 Apr 2010 12:00:14 GMT Message-Id: <201004131200.o3DC0ElS066762@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/145462 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 12:00:14 -0000 The following reply was made to PR kern/145462; it has been noted by GNATS. From: Gleb Smirnoff To: Aleksey Cc: bug-followup@FreeBSD.org Subject: Re: kern/145462 Date: Tue, 13 Apr 2010 15:36:58 +0400 IMO, this patch would be better: Index: ng_ipfw.c =================================================================== --- ng_ipfw.c (revision 206495) +++ ng_ipfw.c (working copy) @@ -264,11 +264,8 @@ * Node must be loaded and corresponding hook must be present. */ if (fw_node == NULL || - (hook = ng_ipfw_findhook1(fw_node, fwa->rule.info)) == NULL) { - if (tee == 0) - m_freem(*m0); + (hook = ng_ipfw_findhook1(fw_node, fwa->rule.info)) == NULL) return (ESRCH); /* no hook associated with this rule */ - } /* * We have two modes: in normal mode we add a tag to packet, which is Can you please test it and if you don't mind I will commit it. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 12:43: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 A7D07106564A for ; Tue, 13 Apr 2010 12:43:19 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.221.175]) by mx1.freebsd.org (Postfix) with ESMTP id 6A97D8FC1A for ; Tue, 13 Apr 2010 12:43:18 +0000 (UTC) Received: by qyk5 with SMTP id 5so7699939qyk.3 for ; Tue, 13 Apr 2010 05:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.84 with HTTP; Tue, 13 Apr 2010 05:18:52 -0700 (PDT) X-Originating-IP: [59.124.10.59] In-Reply-To: References: Date: Tue, 13 Apr 2010 20:18:52 +0800 Received: by 10.229.213.208 with SMTP id gx16mr5715225qcb.35.1271161132183; Tue, 13 Apr 2010 05:18:52 -0700 (PDT) Message-ID: From: Lin Jui-Nan Eric To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: pf stalls connection when using route-to 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, 13 Apr 2010 12:43:19 -0000 Hi listers, We recently found that when the traffic passes pf with route-to, the connection stalls. Turning off TSO solves the problem. Our pf.conf is very simple: table const {10/8, 172.16/12, 192.168/16} pass out quick route-to (em0 10.1.1.1) from to ! no state And we have a tcpdump capture file. It shows that there's lots of duplicate packets and retransmissions while TSO is enabled. Our NIC is an Intel PRO/1000: em0: port 0x2000-0x201f mem 0xdf200000-0xdf21ffff irq 18 at device 0.0 on pci4 em0: Using MSI interrupt em0: [FILTER] Screenshot: http://cf.files.jnlin.org/with-tso.png Any suggestion? I just turn off the TSO, but I think it is only a workaroun= d. Sincerely, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jui-Nan From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 13:30: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 279641065675 for ; Tue, 13 Apr 2010 13:30:50 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7B4B8FC22 for ; Tue, 13 Apr 2010 13:30:49 +0000 (UTC) Received: by wyb28 with SMTP id 28so1420024wyb.13 for ; Tue, 13 Apr 2010 06:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=YjKs5JgxHLWUH2GfeM0bxOzSGK8TyWSEYuW9EOzYuz0=; b=IdRzqOrCB2WxJ6PDLxDNcws1l/cJwRnHGg3NFGvjKy2LdaYMi1n1WXgkVqq+jZ7DqZ bhxRQ6VH/CJKHzwG7R12EiISlijcRw4XjBhWR9o/tHTWhzx2qZA0yBTvWI953WUMynD+ t/VnIbp8BzVCDHJ/+bQ33Rhi3Hg+/ctjoHY7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LGabtBI7W0l7UjUp43myOVob6kpRfBma+Qd7skZQvmXQiFCgFTUbWGX5TQTgdogMcB GcWWGz/EkNHEonhEZXVLApdcxeWtKY4VzVrAKVDXDQI1EEFrunYRzNvSODau97qljvsK oEO5aCnSE+OTCrsR13nfsDxgWsMCgNUK1wrIc= MIME-Version: 1.0 Received: by 10.216.12.78 with HTTP; Tue, 13 Apr 2010 06:30:42 -0700 (PDT) Date: Tue, 13 Apr 2010 15:30:42 +0200 Received: by 10.216.90.141 with SMTP id e13mr3372955wef.166.1271165446311; Tue, 13 Apr 2010 06:30:46 -0700 (PDT) Message-ID: From: Jacques Fourie To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: m_copymdata() bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:30:50 -0000 It seems as if the m_copymdata() function defined in uipc_mbuf.c has a bug. It uses m_apply to copy data from the source mbuf to the target but in the callback function m_bcopyxxx() the arguments are interpreted in the wrong order. Swapping the 's' and 't' arguments in the declaration of m_bcopyxxx() fixes the problem for me. From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 14:41:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 267531065672 for ; Tue, 13 Apr 2010 14:41:10 +0000 (UTC) (envelope-from sz3003@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id A50D38FC19 for ; Tue, 13 Apr 2010 14:41:09 +0000 (UTC) Received: by ewy24 with SMTP id 24so1503744ewy.33 for ; Tue, 13 Apr 2010 07:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=4T6+/KQ2JNZtyVj2YakoL30AR0oXZMZ2ME2KqVlxaeE=; b=brM/WIwYOHbamEaYjJUn8zXIN6yiJz9T1opxiumnbE82242DwDxyNnrNNLPWONEvnG Qr6EpcSm+b+qPMMN8VG0XWDMFeXE2CSkzgyKIeO9iaorJlaJoVVlJSDetViW2fFphoBO M3v19/nn0rmFXcMTQmxW4cOT2Z96NUlW94OUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZOU3FZF1qI8UgXGdPTfg7LsvxmKWtAEuhJFh8UKUk0U5HoO9XWoMRi0gg383KM+doY oIEt4DA6n4HKzmZXWbXfx46j570eVuDtLs8fkFgyjT0UoKhrx4jIAE6CDbtx4nV6Ghv3 3955Wqg182OD8V64G0HnOEOeege8AVep+i/C4= MIME-Version: 1.0 Received: by 10.103.107.19 with HTTP; Tue, 13 Apr 2010 07:41:08 -0700 (PDT) Date: Tue, 13 Apr 2010 16:41:08 +0200 Received: by 10.103.84.21 with SMTP id m21mr3192141mul.106.1271169668118; Tue, 13 Apr 2010 07:41:08 -0700 (PDT) Message-ID: From: serena zanetta To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kernel - userspace communication, ng_socket 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, 13 Apr 2010 14:41:10 -0000 I have a question involving the userspace and kernel communication. I need to get a point where I can exchange data between netgraph nodes and = a program in the userland. I have a netgraph node which receives network packets and sends them to the program to be processed. The modified packets are then sent back to the sam= e node. I thought to do it with the ng_socket node type. I=92ve written a program t= hat creates two sockets (data and control) as reported in =93All about netgraph= =94. Then I=92ve tried to assign the node a name with bind(), as follow: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define NGSA_OVERHEAD (offsetof(struct sockaddr_ng, sg_data)) int main() { int s_control =3D -1, s_data =3D -1; struct sockaddr_ng *sg; s_control =3D socket(PF_NETGRAPH,SOCK_DGRAM,NG_CONTROL); strcpy(sg->sg_data,"SOCKET"); sg->sg_family =3D AF_NETGRAPH; sg->sg_len =3D strlen(sg->sg_data) + 1 + NGSA_OVERHEAD; bind(s_control,(struct sockaddr *)sg,sg->sg_len)<0); =85 return 0; } If I look at ngctl to verify the ng_socket creation, no trace of it can be found. So I don't know how to proceed .. any suggestion? Thank you, Serena From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 15:53:44 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 336BA1065673; Tue, 13 Apr 2010 15:53:44 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id D82FC8FC24; Tue, 13 Apr 2010 15:53:43 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so2407017qwi.7 for ; Tue, 13 Apr 2010 08:53:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.84 with HTTP; Tue, 13 Apr 2010 08:53:42 -0700 (PDT) X-Originating-IP: [59.120.212.57] In-Reply-To: <20100413151933.GA20976@icarus.home.lan> References: <20100413151933.GA20976@icarus.home.lan> Date: Tue, 13 Apr 2010 23:53:42 +0800 Received: by 10.229.217.206 with SMTP id hn14mr8281980qcb.70.1271174022509; Tue, 13 Apr 2010 08:53:42 -0700 (PDT) Message-ID: From: Lin Jui-Nan Eric To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, stable@freebsd.org Subject: Re: pf stalls connection when using route-to 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, 13 Apr 2010 15:53:44 -0000 On Tue, Apr 13, 2010 at 11:19 PM, Jeremy Chadwick wrote: > > What FreeBSD version? =A0uname -a output please. > I have tried 7.2-R and 8.0-R. Both version stalls, too. 8.0-RELEASE: # uname -a FreeBSD bsd8 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #3: Wed Mar 3 17:15:52 CST 2010 root@bsd8:/usr/obj/usr/src/sys/KERNEL amd64 We only added "carp" in kernel config for HA. # cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1.2.1 2009/10/25 01:10:29 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes t= hat # are being run under another UID. #security.bsd.see_other_uids=3D0 debug.bootverbose=3D1 kern.ipc.maxsockbuf=3D2097152 kern.ipc.somaxconn=3D8192 kern.maxfiles=3D65536 kern.maxfilesperproc=3D32768 kern.maxprocperuid=3D65536 net.inet.tcp.delayed_ack=3D0 debug.bootverbose=3D1 kern.ipc.maxsockbuf=3D2097152 kern.ipc.somaxconn=3D8192 kern.maxfiles=3D65536 kern.maxfilesperproc=3D32768 kern.maxprocperuid=3D65536 net.inet.tcp.delayed_ack=3D0 net.inet.carp.preempt=3D1 net.inet.carp.arpbalance=3D1 kern.randompid=3D99999 net.inet.flowtable.enable=3D0 # cat /boot/loader.conf # coretemp_load=3D"YES" geom_mirror_load=3D"YES" geom_stripe_load=3D"YES" if_em_load=3D"YES" kbdmux_load=3D"YES" random_load=3D"YES" ukdb_load=3D"YES" zfs_load=3D"YES" # kern.ipc.nmbclusters=3D"0" kern.maxproc=3D"65536" net.inet.tcp.reass.maxsegments=3D"1600" 7.2-RELEASE: # uname -a FreeBSD bsd7 7.2-RELEASE-p7 FreeBSD 7.2-RELEASE-p7 #0: Fri Feb 26 22:28:05 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # cat /etc/sysctl.conf debug.bootverbose=3D1 kern.ipc.maxsockbuf=3D2097152 kern.ipc.somaxconn=3D32768 kern.maxfiles=3D65536 kern.maxfilesperproc=3D32768 kern.maxprocperuid=3D65536 kern.randompid=3D99999 net.inet.icmp.icmplim=3D65536 net.inet.ip.fastforwarding=3D1 net.inet.ip.portrange.first=3D4096 net.inet.tcp.delayed_ack=3D0 net.inet.tcp.fast_finwait2_recycle=3D1 net.inet.tcp.maxtcptw=3D65535 net.inet.tcp.msl=3D1500 net.inet.tcp.nolocaltimewait=3D1 vfs.lookup_shared=3D1 vfs.nfs.prime_access_cache=3D0 vm.pmap.shpgperproc=3D2000 # cat /boot/loader.conf # coretemp_load=3D"YES" geom_mirror_load=3D"YES" geom_stripe_load=3D"YES" kbdmux_load=3D"YES" random_load=3D"YES" ukdb_load=3D"YES" zfs_load=3D"YES" # kern.ipc.nmbclusters=3D"0" kern.maxproc=3D"65536" vfs.zfs.prefetch_disable=3D"1" vm.kmem_size=3D"1G" vm.kmem_size_max=3D"1G" net.inet.tcp.reass.maxsegments=3D"1600" From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 19:28:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41AE4106564A; Tue, 13 Apr 2010 19:28:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD928FC21; Tue, 13 Apr 2010 19:28:34 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 7BEE9A56640; Wed, 14 Apr 2010 03:28:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id fdt3aPiB8c18; Wed, 14 Apr 2010 03:28:28 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 6104FA56631; Wed, 14 Apr 2010 03:28:26 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:x-enigmail-version:openpgp:content-type; b=iPoDgSDcFwF2Cv1XSyKfTbovhPNs2s3yB09hp29mE+jN+gWYHLxj8HH3NVPos91ZQ QduYDshPjG9/gT/ye6Xsw== Message-ID: <4BC4C5D6.9040605@delphij.net> Date: Tue, 13 Apr 2010 12:28:22 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100408 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------070803070007030308020202" Cc: John Baldwin , bschmidt@FreeBSD.ORG Subject: [PATCH FOR REVIEW] Fix SIOCGIFDESCR when buffer is too small X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 19:28:35 -0000 This is a multi-part message in MIME format. --------------070803070007030308020202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here is a patch that addressed the issue, where when SIOCGIFDESCR is fed with a smaller buffer. As reported by Bernhard, this would cause an infinite loop in ifconfig(8). The previous implementation claims that the 'length' field would be set to the number of length returned, and an error is returned. However, our ioctl(2) system call will not do copyout if there is errno being set, as discussed on -arch@ and thus the API needs to be tweaked. To minimize impact on ABI I have choose to use buffer as an indicator that the buffer length from userland is not sufficient, instead of returning ENAMETOOLONG. I'll also submit a patch for libpcap if this proposed change is considered be a good one. The libpcap in contrib/libpcap is not affected since it doesn't support dynamic length description. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLxMXWAAoJEATO+BI/yjfBWc4H/jO7i2Rm+GqeYXX2eNWUjE2W 5dpNFq0kxqQWpLTr8qPskQ7o/ZDIl8ASbNJPdr/G+U1mYGVwNWVa6z0TR3huZZCB gPnR+84a+C/8rwtJjhOuyFKt/fdZfD4kI+rnWB+9Cq/uLX4aqziY1YO7SIAtb/1b RrjyM6rgYsMcnrqJKrmAQQEU1k6Yqkcy5PEEzU6MTSsHYL4wuKujZzmIYdZRg4rI OLSdLQEWq+u4PuOnrRMrvrrZZCObOURCWpjnJiP1yyMBE/ZW6itfMp6BE6k29vUz vZcDtqUFj3j1tVvaA4MzuX+isMUqnO8DvcnIawjwefs9Rq0mWY796kGSEjZYxuQ= =lyPJ -----END PGP SIGNATURE----- --------------070803070007030308020202 Content-Type: text/plain; name="ifdescr.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ifdescr.diff" SW5kZXg6IHNiaW4vaWZjb25maWcvaWZjb25maWcuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmlu L2lmY29uZmlnL2lmY29uZmlnLmMJKHJldmlzaW9uIDIwNjU1OCkKKysrIHNiaW4vaWZjb25m aWcvaWZjb25maWcuYwkod29ya2luZyBjb3B5KQpAQCAtOTIyLDE5ICs5MjIsMjEgQEAKIAkJ CWlmci5pZnJfYnVmZmVyLmJ1ZmZlciA9IGRlc2NyOwogCQkJaWZyLmlmcl9idWZmZXIubGVu Z3RoID0gZGVzY3JsZW47CiAJCQlpZiAoaW9jdGwocywgU0lPQ0dJRkRFU0NSLCAmaWZyKSA9 PSAwKSB7Ci0JCQkJaWYgKHN0cmxlbihkZXNjcikgPiAwKQotCQkJCQlwcmludGYoIlx0ZGVz Y3JpcHRpb246ICVzXG4iLCBkZXNjcik7Ci0JCQkJYnJlYWs7Ci0JCQl9IGVsc2UgaWYgKGVy cm5vID09IEVOQU1FVE9PTE9ORykKLQkJCQlkZXNjcmxlbiA9IGlmci5pZnJfYnVmZmVyLmxl bmd0aDsKLQkJCWVsc2UKLQkJCQlicmVhazsKLQkJfSBlbHNlIHsKKwkJCQlpZiAoaWZyLmlm cl9idWZmZXIuYnVmZmVyID09IGRlc2NyKSB7CisJCQkJCWlmIChzdHJsZW4oZGVzY3IpID4g MCkKKwkJCQkJCXByaW50ZigiXHRkZXNjcmlwdGlvbjogJXNcbiIsCisJCQkJCQkgICAgZGVz Y3IpOworCQkJCQlicmVhazsKKwkJCQl9IGVsc2UgaWYgKGlmci5pZnJfYnVmZmVyLmxlbmd0 aCA+IGRlc2NybGVuKSB7CisJCQkJCWRlc2NybGVuID0gaWZyLmlmcl9idWZmZXIubGVuZ3Ro OworCQkJCQljb250aW51ZTsKKwkJCQl9CisJCQl9CisJCX0gZWxzZQogCQkJd2FybigidW5h YmxlIHRvIGFsbG9jYXRlIG1lbW9yeSBmb3IgaW50ZXJmYWNlIgogCQkJICAgICJkZXNjcmlw dGlvbiIpOwotCQkJYnJlYWs7Ci0JCX0KLQl9OworCQlicmVhazsKKwl9CiAKIAlpZiAoaW9j dGwocywgU0lPQ0dJRkNBUCwgKGNhZGRyX3QpJmlmcikgPT0gMCkgewogCQlpZiAoaWZyLmlm cl9jdXJjYXAgIT0gMCkgewpJbmRleDogc2hhcmUvbWFuL21hbjQvbmV0aW50cm8uNAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzaGFyZS9tYW4vbWFuNC9uZXRpbnRyby40CShyZXZpc2lvbiAyMDY1 NTgpCisrKyBzaGFyZS9tYW4vbWFuNC9uZXRpbnRyby40CSh3b3JraW5nIGNvcHkpCkBAIC0y OTIsOCArMjkyLDExIEBACiBzdHJ1Y3QgcGFzc2VkIGluIGFzIHBhcmFtZXRlciwgYW5kIHRo ZSBsZW5ndGggd291bGQgaW5jbHVkZQogdGhlIHRlcm1pbmF0aW5nIG51bCBjaGFyYWN0ZXIu CiBJZiB0aGVyZSBpcyBub3QgZW5vdWdoIHNwYWNlIHRvIGhvbGQgdGhlIGludGVyZmFjZSBs ZW5ndGgsCi1ubyBjb3B5IHdvdWxkIGJlIGRvbmUgYW5kIGFuCi1lcnJvciB3b3VsZCBiZSBy ZXR1cm5lZC4KK25vIGNvcHkgd291bGQgYmUgZG9uZSBhbmQgdGhlCisuVmEgYnVmZmVyCitm aWVsZCBvZgorLlZhIGlmcnVfYnVmZmVyCit3b3VsZCBiZSBzZXQgdG8gTlVMTC4KIFRoZSBr ZXJuZWwgd2lsbCBzdG9yZSB0aGUgYnVmZmVyIGxlbmd0aCBpbiB0aGUKIC5WYSBsZW5ndGgK IGZpZWxkIHVwb24gcmV0dXJuLCByZWdhcmRsZXNzIHdoZXRoZXIgdGhlIGJ1ZmZlciBpdHNl bGYgaXMKSW5kZXg6IHN5cy9uZXQvaWYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L2lm LmMJKHJldmlzaW9uIDIwNjU1OCkKKysrIHN5cy9uZXQvaWYuYwkod29ya2luZyBjb3B5KQpA QCAtMjA0OSwxNCArMjA0OSwxMyBAQAogCWNhc2UgU0lPQ0dJRkRFU0NSOgogCQllcnJvciA9 IDA7CiAJCXN4X3Nsb2NrKCZpZmRlc2NyX3N4KTsKLQkJaWYgKGlmcC0+aWZfZGVzY3JpcHRp b24gPT0gTlVMTCkgewotCQkJaWZyLT5pZnJfYnVmZmVyLmxlbmd0aCA9IDA7CisJCWlmIChp ZnAtPmlmX2Rlc2NyaXB0aW9uID09IE5VTEwpCiAJCQllcnJvciA9IEVOT01TRzsKLQkJfSBl bHNlIHsKKwkJZWxzZSB7CiAJCQkvKiBzcGFjZSBmb3IgdGVybWluYXRpbmcgbnVsICovCiAJ CQlkZXNjcmxlbiA9IHN0cmxlbihpZnAtPmlmX2Rlc2NyaXB0aW9uKSArIDE7CiAJCQlpZiAo aWZyLT5pZnJfYnVmZmVyLmxlbmd0aCA8IGRlc2NybGVuKQotCQkJCWVycm9yID0gRU5BTUVU T09MT05HOworCQkJCWlmci0+aWZyX2J1ZmZlci5idWZmZXIgPSBOVUxMOwogCQkJZWxzZQog CQkJCWVycm9yID0gY29weW91dChpZnAtPmlmX2Rlc2NyaXB0aW9uLAogCQkJCSAgICBpZnIt Pmlmcl9idWZmZXIuYnVmZmVyLCBkZXNjcmxlbik7Cg== --------------070803070007030308020202-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 13 22:32: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 6020D1065672 for ; Tue, 13 Apr 2010 22:32:49 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from mailfilter68.ihug.co.nz (mailfilter68.ihug.co.nz [203.109.136.68]) by mx1.freebsd.org (Postfix) with ESMTP id B6E1A8FC17 for ; Tue, 13 Apr 2010 22:32:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADaOxEt2XRqM/2dsb2JhbACbTnK9U4UNBItR X-IronPort-AV: E=Sophos;i="4.52,200,1270382400"; d="scan'208";a="274577464" Received: from 118-93-26-140.dsl.dyn.ihug.co.nz (HELO spandex.luckie.org.nz) ([118.93.26.140]) by smtp.mailfilter5.ihug.co.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2010 10:36:40 +1200 Received: from mjl by spandex.luckie.org.nz with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1odU-000Puc-Oy; Wed, 14 Apr 2010 10:31:12 +1200 Date: Wed, 14 Apr 2010 10:31:12 +1200 From: Matthew Luckie To: Luigi Rizzo Message-ID: <20100413223112.GA99546@spandex.luckie.org.nz> References: <20100413015701.GA62420@spandex.luckie.org.nz> <20100413065732.GB3063@onelab2.iet.unipi.it> <4BC41F17.5000201@luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC41F17.5000201@luckie.org.nz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: reassembled packets and pfil 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, 13 Apr 2010 22:32:49 -0000 > >I think that a patch like the one you propose is very useful (for > >ipv4 as well) but it requires a sysctl or other mechanism to make > >sure that when it is enabled we don't pass fragments through the > >firewall. > > i've looked further into this and I now wonder if is a byproduct of my > use of ipfw. the problem seems to be that offset will always be > non-zero with any packet with a v6 fragment header, so a rule requiring > offset to be zero is never run. i'll spend a bit more time on this > tomorrow, and come back with a patch for ipfw. Here's a patch to ipfw. We keep a copy of the MF bit for IPv6 fragments so it can be passed to ipfw_log. Otherwise, the offset field no longer has the MF bit embedded in it as before. Note that apart from the various transport-layer checks that require offset to be zero, the O_FRAG opcode now has a different behaviour. Only subsequent fragments will match this rule. If you want the exact same behaviour as before, then case O_FRAG: match = (offset != 0); break; should become case O_FRAG: match = (offset != 0 || ext_hd & EXT_FRAGMENT); break; If you are generally happy with this patch, let me know and I'll file a PR so it doesn't get lost. --- ip_fw2.c.orig 2008-11-25 15:59:29.000000000 +1300 +++ ip_fw2.c 2010-04-14 10:05:46.000000000 +1200 @@ -758,6 +758,7 @@ ipfw_log(struct ip_fw *f, u_int hlen, st char *action; int limit_reached = 0; char action2[40], proto[128], fragment[32]; + u_short mf = 0; fragment[0] = '\0'; proto[0] = '\0'; @@ -903,6 +904,8 @@ ipfw_log(struct ip_fw *f, u_int hlen, st snprintf(dst, sizeof(dst), "[%s]", ip6_sprintf(ip6buf, &args->f_id.dst_ip6)); + mf = offset & IP6F_MORE_FRAG; + offset &= IP6F_OFF_MASK; ip6 = (struct ip6_hdr *)ip; tcp = (struct tcphdr *)(((char *)ip) + hlen); udp = (struct udphdr *)(((char *)ip) + hlen); @@ -972,13 +975,13 @@ ipfw_log(struct ip_fw *f, u_int hlen, st #ifdef INET6 if (IS_IP6_FLOW_ID(&(args->f_id))) { - if (offset & (IP6F_OFF_MASK | IP6F_MORE_FRAG)) + if (offset || mf) snprintf(SNPARGS(fragment, 0), " (frag %08x:%d@%d%s)", args->f_id.frag_id6, ntohs(ip6->ip6_plen) - hlen, - ntohs(offset & IP6F_OFF_MASK) << 3, - (offset & IP6F_MORE_FRAG) ? "+" : ""); + ntohs(offset) << 3, + mf ? "+" : ""); } else #endif { @@ -2151,16 +2154,13 @@ ipfw_chk(struct ip_fw_args *args) /* * offset The offset of a fragment. offset != 0 means that - * we have a fragment at this offset of an IPv4 packet. - * offset == 0 means that (if this is an IPv4 packet) - * this is the first or only fragment. - * For IPv6 offset == 0 means there is no Fragment Header. - * If offset != 0 for IPv6 always use correct mask to - * get the correct offset because we add IP6F_MORE_FRAG - * to be able to dectect the first fragment which would - * otherwise have offset = 0. + * we have a fragment at this offset. + * offset == 0 means that this is the first or only fragment. + * + * mf The MF bit masked out of IPv6 packets. */ u_short offset = 0; + u_short mf = 0; /* * Local copies of addresses. They are only valid if we have @@ -2311,17 +2311,8 @@ do { \ proto = ((struct ip6_frag *)ulp)->ip6f_nxt; offset = ((struct ip6_frag *)ulp)->ip6f_offlg & IP6F_OFF_MASK; - /* Add IP6F_MORE_FRAG for offset of first - * fragment to be != 0. */ - offset |= ((struct ip6_frag *)ulp)->ip6f_offlg & + mf = ((struct ip6_frag *)ulp)->ip6f_offlg & IP6F_MORE_FRAG; - if (offset == 0) { - printf("IPFW2: IPV6 - Invalid Fragment " - "Header\n"); - if (fw_deny_unknown_exthdrs) - return (IP_FW_DENY); - break; - } args->f_id.frag_id6 = ntohl(((struct ip6_frag *)ulp)->ip6f_ident); ulp = NULL; @@ -2904,7 +2895,7 @@ check_body: case O_LOG: if (fw_verbose) ipfw_log(f, hlen, args, m, - oif, offset, tablearg, ip); + oif, offset|mf, tablearg, ip); match = 1; break; From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 13:00: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 2FC05106566C for ; Wed, 14 Apr 2010 13:00:16 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id DBDD88FC14 for ; Wed, 14 Apr 2010 13:00:15 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O22CJ-0002pp-Us; Wed, 14 Apr 2010 17:00:03 +0400 Date: Wed, 14 Apr 2010 16:59:27 +0400 From: Ruslan Ermilov To: "Li, Qing" Message-ID: <20100414125927.GA4425@edoofus.dev.vega.ru> References: <005801cad03c$5f5128d0$1df37a70$@kawasaki-tn.com> <201003302120.o2ULKwTT071015@lava.sentex.ca> <20100331004822.GA49860@edoofus.dev.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "J. English" , freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Workaround for mpd5 and 8.0 broken proxy arp? 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, 14 Apr 2010 13:00:16 -0000 Hi Qing, On Tue, Mar 30, 2010 at 06:25:48PM -0700, Li, Qing wrote: > > Yes, it's still broken (it's a regression compared to 7.x). A > > workaround I've found working after analyzing the newer kernel > > code is to ALWAYS use the same IP address for the local end of > > the tunnel as of the corresponding ARP capable interface. > > > > Are you using VLANs? > > Were you getting the following error message? > "cannot intuit interface index and type for x.x.x.x" > > Could you please revert back to your original configuration > and give the following patch try (in addition to the patches > mentioned by Mike) ? > > http://people.freebsd.org/~qingli/mpd-patch.diff Doesn't seem to have any effect. Please see http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024728.html on how to reproduce. If you change the ifconfig command shown there so that the local end of a P2P interface is assigned the same IP address 10.25.1.244 as of vlan408, it will work as expected. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 00:48: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 107D31065672; Thu, 15 Apr 2010 00:48:02 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 38DC38FC21; Thu, 15 Apr 2010 00:48:01 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o3F0m10h008412; Wed, 14 Apr 2010 17:48:01 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 17:47:45 -0700 Message-ID: In-Reply-To: <20100414125927.GA4425@edoofus.dev.vega.ru> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Workaround for mpd5 and 8.0 broken proxy arp? Thread-Index: Acrb0mzatXY6bHnZRJqorqLom4hAyAAYnt+Q References: <005801cad03c$5f5128d0$1df37a70$@kawasaki-tn.com> <201003302120.o2ULKwTT071015@lava.sentex.ca> <20100331004822.GA49860@edoofus.dev.vega.ru> <20100414125927.GA4425@edoofus.dev.vega.ru> From: "Li, Qing" To: "Ruslan Ermilov" Cc: "J. English" , freebsd-net@freebsd.org, Mike Tancsa Subject: RE: Workaround for mpd5 and 8.0 broken proxy arp? 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, 15 Apr 2010 00:48:03 -0000 Hi Ruslan, Yes, I can reproduce this issue. The patch is still necessary, however,=20 it does not resolve the if_ng issue because if_ng is a virtual interface that is not really associated with any physical nic. The physical NIC is where all of the entries (including the proxied entries) are kept. Let me put some thoughts into how to resolve this problem. >=20 > If you change the ifconfig command shown there so that the local end > of a P2P interface is assigned the same IP address 10.25.1.244 as of > vlan408, it will work as expected. >=20 Right, doing so allow the networking kernel to find the correct physical NIC. -- Qing From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 14:28:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C262106564A; Thu, 15 Apr 2010 14:28:14 +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 4359B8FC17; Thu, 15 Apr 2010 14:28:14 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 5A93F9629F; Thu, 15 Apr 2010 16:28:12 +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 5f2EfKmIA5V1; Thu, 15 Apr 2010 16:28:09 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id B721396295; Thu, 15 Apr 2010 16:28:09 +0200 (CEST) Message-ID: <4BC72276.6080003@zirakzigil.org> Date: Thu, 15 Apr 2010 16:28:06 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 Thunderbird/3.0.1 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: NFS permission strangeness 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, 15 Apr 2010 14:28:14 -0000 Here's the setup: server : NFS server machine (fb 8 stable amd64 ) client : NFS client machine (as above) server and client are both sharing the same permission database through ldap: Both have in /etc/nsswitch.conf ... group: files ldap ... passwd: files ldap This issue isn't related to ldap, however. I get the same result if I manually add groups to /etc/group file (read on) Let's suppose I have user "giulio" configured in my system. giulio is also part (-G) of groups: group1, group2, group3, ... , group10 server is exporting the directory /path/to/root (on zfs) the directory /path/to/root/dir/etc/subdir1 has permission 770 and group ownership "group3" I login as user "giulio" on server I can enter "subdir1" directory, since I'm member of group "group3" I then login as user "giulio" on client, and I can do the same (as expected). When groups are more than a few, however, I get this strange behavior: let's suppose the directory: /path/to/root/dir/etc/subdir2 has permission 770 and group ownership "group10" What happens is that I can access "subdir2" on the server machine when I login as "giulio", but when I try to access that same dir on the client machine I get: $ cd /path/to/root/dir/etc (ok) $ cd subdir2 subdir2/: Permission denied. if I issue this command on the client: $ id I get : uid=1000 (giulio), gid=1000 (giuliogroup), groups=group1(1001), group2(1002), group3(1003),...,group10(1010) So there shouldn't really be any reason for me not to be able to access that dir... Any idea? From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 15:24:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935C51065675 for ; Thu, 15 Apr 2010 15:24:22 +0000 (UTC) (envelope-from j_english@kawasaki-tn.com) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by mx1.freebsd.org (Postfix) with SMTP id 5368A8FC27 for ; Thu, 15 Apr 2010 15:24:21 +0000 (UTC) Received: (qmail 18965 invoked by uid 0); 15 Apr 2010 15:24:22 -0000 Received: from unknown (HELO host372.hostmonster.com) (66.147.240.172) by oproxy1.bluehost.com.bluehost.com with SMTP; 15 Apr 2010 15:24:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kawasaki-tn.com; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:x-cr-hashedpuzzle:x-cr-puzzleid:X-Identified-User; b=jRpPxJwSoe0+28xCdqkvx21Jl88k2iilGTRFfk2LWFh5ox/Wr688qK2Zoe8Th6Dxq1f8b0Zq8wqJc5bK6e6pmMQ0OEWTUqziVzmGdMFU6Sv3gQ/Db3NqxGn8LwOe+L4X; Received: from [63.246.241.41] (helo=JE) by host372.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1O2QvU-0005sE-QZ for freebsd-net@freebsd.org; Thu, 15 Apr 2010 09:24:21 -0600 From: "J. English" To: References: <005801cad03c$5f5128d0$1df37a70$@kawasaki-tn.com> <201003302120.o2ULKwTT071015@lava.sentex.ca> <20100331004822.GA49860@edoofus.dev.vega.ru> <20100414125927.GA4425@edoofus.dev.vega.ru> In-Reply-To: Date: Thu, 15 Apr 2010 11:24:19 -0400 Message-ID: <000f01cadcaf$b897bce0$29c736a0$@kawasaki-tn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIY2rnqEdIDggrjMLxUKuDpMYFs7AJL3BEgAcDSXPICqf5QJgJHn/lVAknJpvEB8fhsdg== Content-Language: en-us x-cr-hashedpuzzle: A+7l BXsV B9q3 CEGI CH9q CKBX CZpF DF8V EKdM ELUM EoRV GJpP HRIA HWl+ IxHz KsrX; 1; ZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {6BC88BAA-02BA-420F-AED8-46F7F573E656}; agBfAGUAbgBnAGwAaQBzAGgAQABrAGEAdwBhAHMAYQBrAGkALQB0AG4ALgBjAG8AbQA=; Thu, 15 Apr 2010 15:24:17 GMT; UgBFADoAIABXAG8AcgBrAGEAcgBvAHUAbgBkACAAZgBvAHIAIABtAHAAZAA1ACAAYQBuAGQAIAA4AC4AMAAgAGIAcgBvAGsAZQBuACAAcAByAG8AeAB5ACAAYQByAHAAPwA= x-cr-puzzleid: {6BC88BAA-02BA-420F-AED8-46F7F573E656} X-Identified-User: {1530:host372.hostmonster.com:kawasak2:kawasaki-tn.com} {sentby:smtp auth 63.246.241.41 authed with j_english@kawasaki-tn.com} Subject: RE: Workaround for mpd5 and 8.0 broken proxy arp? 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, 15 Apr 2010 15:24:22 -0000 Ended up going back to FreeBSD 7.3 with mpd 5.5. Everything works like a charm now. Jonathon -- From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 17:04: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 7C1DE1065740; Thu, 15 Apr 2010 17:04:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id A99D68FC0C; Thu, 15 Apr 2010 17:04:19 +0000 (UTC) Received: by ewy24 with SMTP id 24so576579ewy.33 for ; Thu, 15 Apr 2010 10:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=syMLDIza2vMbgDjFQC3FUOA9K/21O2qrsj6GCD2bQBA=; b=iWCXijL5OsATgIyHuEEu/2IVjiL092/gidMby0n+P57PdEh15oBNUzRW3NdCir3T5G ZULQix+hHXmn7jqZC8BR1E1GFSS+Hp0XYLZmVXwWoURmXUSnhbW8n3uAXPCvj2gqbFOB JRu+3Xp+tU37NfAKWQQ4/R62qqHRAzafxFMRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=jUmOEaSn+4ryy2HIP8aBFqCv/RmkqY2Xh+SBkg41DZ/1wHGNfUehxZ6HEkljPTzIXz Yryd56yTJDYiU/t6WG6fw8UnjWmVVxbRp8l2xZ1KotXeUnT23r3QA1dqfxNxM+76ZLBf 9sFv+V3BywEZU74kIFonv0zDJoBI/z5ydRw6s= Received: by 10.102.15.22 with SMTP id 22mr288408muo.7.1271351058393; Thu, 15 Apr 2010 10:04:18 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y2sm9166932mug.21.2010.04.15.10.04.17 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 10:04:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BC74709.4000201@FreeBSD.org> Date: Thu, 15 Apr 2010 20:04:09 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: freebsd-net , freebsd-sparc64@FreeBSD.org, freebsd-arm@FreeBSD.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: net/mpd5 now works on other archs 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, 15 Apr 2010 17:04:20 -0000 Hi. I've just merged to 8-STABLE set of Netgraph fixes, required to run net/mpd5 on architectures with strict memory access alignment. I have successfully tested it on arm and sparc64 systems, and I hope it should work on others. Let me know if you find any more issues there. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 17:49: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 A0B201065673; Thu, 15 Apr 2010 17:49:25 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 836378FC1D; Thu, 15 Apr 2010 17:49:25 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o3FHnPcW012803; Thu, 15 Apr 2010 10:49:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Apr 2010 10:49:08 -0700 Message-ID: In-Reply-To: <20100414125927.GA4425@edoofus.dev.vega.ru> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Workaround for mpd5 and 8.0 broken proxy arp? Thread-Index: Acrb0mzatXY6bHnZRJqorqLom4hAyAA8SSBA References: <005801cad03c$5f5128d0$1df37a70$@kawasaki-tn.com> <201003302120.o2ULKwTT071015@lava.sentex.ca> <20100331004822.GA49860@edoofus.dev.vega.ru> <20100414125927.GA4425@edoofus.dev.vega.ru> From: "Li, Qing" To: "Ruslan Ermilov" Cc: freebsd-net@freebsd.org Subject: RE: Workaround for mpd5 and 8.0 broken proxy arp? 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, 15 Apr 2010 17:49:25 -0000 Hi Ruslan, >=20 > Doesn't seem to have any effect. Please see > http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024728.html > on how to reproduce. >=20 Could you please try the patch at: http://people.freebsd.org/~qingli/ng-patch.diff I was able to reproduce the problem and the patch appears to fix this if_ng issue now. I also tested a couple of other reported cases and those continue to function. Please give this new patch a try and let me know how it works out. Thank you. -- Qing From owner-freebsd-net@FreeBSD.ORG Thu Apr 15 19:24:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A82106566B; Thu, 15 Apr 2010 19:24:58 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5C36C8FC08; Thu, 15 Apr 2010 19:24:57 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id E64C9A56FE5; Fri, 16 Apr 2010 03:24:55 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id 5HqhStlET1eE; Fri, 16 Apr 2010 03:24:50 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id BE1E0A56FF8; Fri, 16 Apr 2010 03:24:49 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=GVW+60Y3RRBo998qf6X5twTTMVtcFlpYvnrzyCIJuEox/Y2yMwOG4j4ZgMO5u1Cry vx0IttfgQPSr3rdz+epGQ== Message-ID: <4BC767FE.4060504@delphij.net> Date: Thu, 15 Apr 2010 12:24:46 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100408 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-ports@freebsd.org, freebsd-net@freebsd.org X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Recent nc(1) changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 19:24:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks to Dima Panov, we have now figured out a behavior change that could break some ports. I'd like to give some more details for the record. In the past, nc(1) would give a message like "Connection to xxx xxx port [tcp/*] succeeded" if either -v or -z is specified in stdout. In newer nc(1) from OpenBSD, this has been changed to stderr. In -CURRENT, we have followed OpenBSD's behavior. I think, that this behavior is more sensible since one can, say, filter stdout and stderr to two programs/logs to fill their need. This unfortunately would break some ports that uses nc -z's standard output as an indicator of whether the connection is succeeded. To solve this, one can modify the script to use "2>&1" when getting the output, which is compatible to the old nc(1) as well. Another change is that nc(1) now considers '-o' as deprecated. My plan is to remove this option before 9.0-RELEASE. Will this removal be a problem for anyone? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLx2f+AAoJEATO+BI/yjfBkKMH/2R4J82mJkWJkddZ/XjlmoQq VruKRMu06w3pXpqzMyqt0MXMII8v5x1jRrhusrZnNJ3dLXjpBHj9WqBYLVCskDdf 3etDE4gKK4DH2hhLuK4HOT4fM70OSN/18fDcpbZ7zrIRWoSheQXESZKy9po99y69 ENUhuxgyzDKzOqccArttJbiz6+jrcoDOjRf7ULnegIKaE4B58fAcpqO9A+6UZBHc Rh2OdnQgYI2wpKxihZiklgK7VDQx09Qvl+4UacDC08uu7rBh3cD09UziQHGjnicV MLhFSN/LGNNc2BVb0z4mFOtaP4efYu9Rxuyy1idOJCPg/HD/+2CECNlZm2BWRe8= =azZK -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 00:45:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE97F106566C for ; Fri, 16 Apr 2010 00:45:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 748658FC13 for ; Fri, 16 Apr 2010 00:45:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAONIx0uDaFvH/2dsb2JhbACba3G+VYJ2AYIXBA X-IronPort-AV: E=Sophos;i="4.52,215,1270440000"; d="scan'208";a="72497346" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 15 Apr 2010 20:16:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 0F5B110845E0; Thu, 15 Apr 2010 20:16:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5BhLYEeWpYj; Thu, 15 Apr 2010 20:16:46 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 0778410845AC; Thu, 15 Apr 2010 20:16:46 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o3G0Ugw01978; Thu, 15 Apr 2010 20:30:42 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 15 Apr 2010 20:30:42 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Giulio Ferro In-Reply-To: <4BC72276.6080003@zirakzigil.org> Message-ID: References: <4BC72276.6080003@zirakzigil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org Subject: Re: NFS permission strangeness 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, 16 Apr 2010 00:45:47 -0000 On Thu, 15 Apr 2010, Giulio Ferro wrote: > Here's the setup: > server : NFS server machine (fb 8 stable amd64 ) > client : NFS client machine (as above) > > server and client are both sharing the same permission database through ldap: > > Both have in /etc/nsswitch.conf > ... > group: files ldap > ... > passwd: files ldap > > This issue isn't related to ldap, however. I get the same result if I > manually add > groups to /etc/group file (read on) > > Let's suppose I have user "giulio" configured in my system. > giulio is also part (-G) of groups: > group1, group2, group3, ... , group10 > > server is exporting the directory > /path/to/root (on zfs) > > the directory > /path/to/root/dir/etc/subdir1 > has permission 770 and group ownership "group3" > > I login as user "giulio" on server I can enter "subdir1" directory, since I'm > member of group "group3" > > I then login as user "giulio" on client, and I can do the same (as expected). > > > When groups are more than a few, however, I get this strange behavior: > > let's suppose the directory: > /path/to/root/dir/etc/subdir2 > has permission 770 and group ownership "group10" > > What happens is that I can access "subdir2" on the server machine when I > login as "giulio", but when I try to access that same dir on the client > machine > I get: > $ cd /path/to/root/dir/etc > (ok) > $ cd subdir2 > subdir2/: Permission denied. > Yes, it should work. I just tried the same thing with a server running UFS/FFS and it worked fine, so I think that the problem might be ZFS related. (You will get into trouble with more than 16 groups, since that is all that AUTH_SYS for Sun RPC handles, but I did 10 like your example and it worked ok for me, using FreeBSD-CURRENT client/server, except that my server uses UFS/FFS.) Hopefully someone with ZFS expertise can help out here? If you can conveniently do the same test using a server that exports a UFS/FFS file system, that would be helpful w.r.t. isolating the problem. rick From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 08:24:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EFEE106566C; Fri, 16 Apr 2010 08:24:27 +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 14A7C8FC23; Fri, 16 Apr 2010 08:24:26 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id B6DE195D38; Fri, 16 Apr 2010 10:24:23 +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 1R6VECXyl13v; Fri, 16 Apr 2010 10:24:20 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 7216C95D2C; Fri, 16 Apr 2010 10:24:20 +0200 (CEST) Message-ID: <4BC81EB2.9070107@zirakzigil.org> Date: Fri, 16 Apr 2010 10:24:18 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 Thunderbird/3.0.1 MIME-Version: 1.0 To: Rick Macklem References: <4BC72276.6080003@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org Subject: Re: NFS permission strangeness 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, 16 Apr 2010 08:24:27 -0000 On 16.04.2010 02:30, Rick Macklem wrote: >> login as "giulio", but when I try to access that same dir on the >> client machine >> I get: >> $ cd /path/to/root/dir/etc >> (ok) >> $ cd subdir2 >> subdir2/: Permission denied. >> > What happens is that I can access "subdir2" on the server machine when I > > Yes, it should work. I just tried the same thing with a server running > UFS/FFS and it worked fine, so I think that the problem might be ZFS > related. (You will get into trouble with more than 16 groups, since > that is all that AUTH_SYS for Sun RPC handles, but I did 10 like your > example and it worked ok for me, using FreeBSD-CURRENT client/server, > except that my server uses UFS/FFS.) > > Hopefully someone with ZFS expertise can help out here? > > If you can conveniently do the same test using a server that exports > a UFS/FFS file system, that would be helpful w.r.t. isolating the > problem. > > rick Yes, I have more than 16 groups, 22 actually... However I still think this might be a NFS problem, since when I login on the server machine I can access that directory all right, the problem arises only when I try to access that dir in the client machine... Giulio From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 08:33:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF5F1106564A; Fri, 16 Apr 2010 08:33:21 +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 621098FC1A; Fri, 16 Apr 2010 08:33:21 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id E0CD195DF9; Fri, 16 Apr 2010 10:33:19 +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 NX7Qj7rtM29R; Fri, 16 Apr 2010 10:33:16 +0200 (CEST) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 57CD195DDD; Fri, 16 Apr 2010 10:33:16 +0200 (CEST) Message-ID: <4BC820CA.8030002@zirakzigil.org> Date: Fri, 16 Apr 2010 10:33:14 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 Thunderbird/3.0.1 MIME-Version: 1.0 To: Sean , "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org References: <4BC72276.6080003@zirakzigil.org> <4BC81EB2.9070107@zirakzigil.org> <6AB6F56B-5FDF-4926-B631-F933E9C7FCD2@gothic.net.au> In-Reply-To: <6AB6F56B-5FDF-4926-B631-F933E9C7FCD2@gothic.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: NFS permission strangeness 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, 16 Apr 2010 08:33:21 -0000 On 16.04.2010 10:29, Sean wrote: > >> Yes, I have more than 16 groups, 22 actually... >> > Then there's nothing "wrong" per se, you're just hitting the fact that NFS v2 and v3 only support 16 groups on the wire. That's just the way the protocol is defined. > > Ops, I didn't know that... Is there any solution solid enough for a production environment. Maybe nfs4? Please advice... Giulio. From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 13:53:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9EBE1065670; Fri, 16 Apr 2010 13:53:23 +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 449308FC08; Fri, 16 Apr 2010 13:53:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF8IyEuDaFvI/2dsb2JhbACbc3G+GoJ2AYIXBA X-IronPort-AV: E=Sophos;i="4.52,219,1270440000"; d="scan'208";a="73018492" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 16 Apr 2010 09:53:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 73DEE940169; Fri, 16 Apr 2010 09:53:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiY7i08NQJTp; Fri, 16 Apr 2010 09:53:15 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id B6286940165; Fri, 16 Apr 2010 09:53:15 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o3GE7DO03453; Fri, 16 Apr 2010 10:07:13 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 16 Apr 2010 10:07:13 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Giulio Ferro In-Reply-To: <4BC81EB2.9070107@zirakzigil.org> Message-ID: References: <4BC72276.6080003@zirakzigil.org> <4BC81EB2.9070107@zirakzigil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org Subject: Re: NFS permission strangeness 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, 16 Apr 2010 13:53:23 -0000 On Fri, 16 Apr 2010, Giulio Ferro wrote: > > Yes, I have more than 16 groups, 22 actually... > > However I still think this might be a NFS problem, since when I login on > the server machine I can access that directory all right, the problem arises > only when I try to access that dir in the client machine... > The problem is that the specification of the RPC header used by NFS for authentication unless you are using krb5 is limited to a gid + 16 additional groups (a lot of implementations put the gid in the first entry of the additional groups list, so 16 is the safe limit and 17 might work). So, you could call it a problem w.r.t. the specification of the RPC protocol that is used for NFS RPCs, but it would be a bug in the implementation to handle more than the 16 additional groups. (Admittedly, it just silently truncates at 16, but I don't think automatically failing an RPC with more than 16 groups in its cred would be better?) So, yes, it is an NFS problem, but intrisic to the protocol spec, rick From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 13:56:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5727A106566C for ; Fri, 16 Apr 2010 13:56:45 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0CFCB8FC20 for ; Fri, 16 Apr 2010 13:56:44 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O2m2F-0002y3-IM for freebsd-net@freebsd.org; Fri, 16 Apr 2010 15:56:43 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Apr 2010 15:56:43 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Apr 2010 15:56:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org connect(): No such file or directory From: Ivan Voras Date: Fri, 16 Apr 2010 15:56:31 +0200 Lines: 27 Message-ID: References: <4BC72276.6080003@zirakzigil.org> <4BC81EB2.9070107@zirakzigil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 In-Reply-To: X-Enigmail-Version: 1.0.1 Cc: freebsd-stable@freebsd.org Subject: Re: NFS permission strangeness 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, 16 Apr 2010 13:56:45 -0000 On 04/16/10 16:07, Rick Macklem wrote: > > > On Fri, 16 Apr 2010, Giulio Ferro wrote: > >> >> Yes, I have more than 16 groups, 22 actually... >> >> However I still think this might be a NFS problem, since when I login on >> the server machine I can access that directory all right, the problem >> arises >> only when I try to access that dir in the client machine... >> > The problem is that the specification of the RPC header used by NFS for > authentication unless you are using krb5 is limited to a gid + 16 > additional groups (a lot of implementations put the gid in the first > entry of the additional groups list, so 16 is the safe limit and 17 > might work). So, you could call it a problem w.r.t. the specification > of the RPC protocol that is used for NFS RPCs, but it would be a bug > in the implementation to handle more than the 16 additional groups. > (Admittedly, it just silently truncates at 16, but I don't think > automatically failing an RPC with more than 16 groups in its cred > would be better?) > > So, yes, it is an NFS problem, but intrisic to the protocol spec, rick Can NFSv4 get around it? From owner-freebsd-net@FreeBSD.ORG Fri Apr 16 13:57:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B633C106564A; Fri, 16 Apr 2010 13:57:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6998FC19; Fri, 16 Apr 2010 13:57:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABgJyEuDaFvG/2dsb2JhbACbc3G+HoUOBA X-IronPort-AV: E=Sophos;i="4.52,219,1270440000"; d="scan'208";a="72556661" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 16 Apr 2010 09:57:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 5F2182101BD; Fri, 16 Apr 2010 09:57:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hbLGZs3ATHt; Fri, 16 Apr 2010 09:57:20 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 4AA3321017A; Fri, 16 Apr 2010 09:57:20 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o3GEBIW04010; Fri, 16 Apr 2010 10:11:18 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 16 Apr 2010 10:11:18 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Giulio Ferro In-Reply-To: <4BC820CA.8030002@zirakzigil.org> Message-ID: References: <4BC72276.6080003@zirakzigil.org> <4BC81EB2.9070107@zirakzigil.org> <6AB6F56B-5FDF-4926-B631-F933E9C7FCD2@gothic.net.au> <4BC820CA.8030002@zirakzigil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , Sean , freebsd-stable@freebsd.org Subject: Re: NFS permission strangeness 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, 16 Apr 2010 13:57:22 -0000 On Fri, 16 Apr 2010, Giulio Ferro wrote: > On 16.04.2010 10:29, Sean wrote: >> >>> Yes, I have more than 16 groups, 22 actually... >>> >> Then there's nothing "wrong" per se, you're just hitting the fact that NFS >> v2 and v3 only support 16 groups on the wire. That's just the way the >> protocol is defined. >> >> > > Ops, I didn't know that... > > Is there any solution solid enough for a production environment. Maybe nfs4? > Well, when you use sec=krb5[ip] on NFSv3 or NFSv4, the limitation of 16/17 groups goes away. However, this has a lot of other implications. (NFSv4 uses the same RPC protocol as NFSv2,3 and it is the specification of the authentication header for what is called AUTH_SYS, which is the problem. AUTH_SYS authenticators simply list a uid, gid and groups<16> #s in the RPC header. rick From owner-freebsd-net@FreeBSD.ORG Sat Apr 17 06:21:05 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 391E9106566C; Sat, 17 Apr 2010 06:21:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0FEA08FC0C; Sat, 17 Apr 2010 06:21:05 +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 o3H6L4PL015783; Sat, 17 Apr 2010 06:21:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3H6L4qj015779; Sat, 17 Apr 2010 06:21:04 GMT (envelope-from linimon) Date: Sat, 17 Apr 2010 06:21:04 GMT Message-Id: <201004170621.o3H6L4qj015779@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145736: [netinet] [patch] Access to freed mbuf in ip_forward with IPSEC enabled 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, 17 Apr 2010 06:21:05 -0000 Old Synopsis: Access to freed mbuf in ip_forward with IPSEC enabled New Synopsis: [netinet] [patch] Access to freed mbuf in ip_forward with IPSEC enabled Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 17 06:20:25 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145736 From owner-freebsd-net@FreeBSD.ORG Sat Apr 17 06:21:46 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 E855C106567A; Sat, 17 Apr 2010 06:21:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AB8FB8FC24; Sat, 17 Apr 2010 06:21:46 +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 o3H6LkWQ015833; Sat, 17 Apr 2010 06:21:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3H6LkmF015829; Sat, 17 Apr 2010 06:21:46 GMT (envelope-from linimon) Date: Sat, 17 Apr 2010 06:21:46 GMT Message-Id: <201004170621.o3H6LkmF015829@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145737: [netinet] [patch] Wrong UDP checksum not ignored as expected in UDP encapsuladed ESP packet 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, 17 Apr 2010 06:21:47 -0000 Old Synopsis: Wrong UDP checksum not ignored as expected in UDP encapsuladed ESP packet New Synopsis: [netinet] [patch] Wrong UDP checksum not ignored as expected in UDP encapsuladed ESP packet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 17 06:21:27 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145737 From owner-freebsd-net@FreeBSD.ORG Sat Apr 17 12:27: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 B68F9106564A for ; Sat, 17 Apr 2010 12:27:30 +0000 (UTC) (envelope-from marcin.nowak@simplusnet.pl) Received: from mx2.plusnet.pl (mx2.plusnet.pl [212.2.119.215]) by mx1.freebsd.org (Postfix) with ESMTP id 781C28FC0A for ; Sat, 17 Apr 2010 12:27:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: Text/Plain; charset=iso-8859-2 Received: from laptop.localnet ([78.8.86.150]) by mta1.plusnet.pl (Sun JES Messaging Server) with ESMTPSA id <0L10008E4RF2WSA0@plusnet.pl> for freebsd-net@freebsd.org; Sat, 17 Apr 2010 13:47:26 +0200 (CEST) From: Marcin Nowak Organization: ADB To: freebsd-net@freebsd.org Date: Sat, 17 Apr 2010 13:47:33 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.5; i386; ; ) Message-id: <201004171347.34158.marcin.nowak@simplusnet.pl> Subject: kern/138427: [wpi] [panic] Kernel panic after trying set monitor wlanmode on Intel 3945 ABG (wpi driver) 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, 17 Apr 2010 12:27:30 -0000 Hello Patch attached by Henry Hu - for me - fixes this bug. Would you merge it with the current? Greets Marcin Nowak From owner-freebsd-net@FreeBSD.ORG Sat Apr 17 12:51: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 5E1D6106566B for ; Sat, 17 Apr 2010 12:51:31 +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 9DA0F8FC22 for ; Sat, 17 Apr 2010 12:51:30 +0000 (UTC) Received: (qmail 666 invoked from network); 17 Apr 2010 12:51:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Apr 2010 12:51:28 -0000 Date: Sat, 17 Apr 2010 14:51:28 +0200 (CEST) Message-Id: <20100417.145128.74659691.sthaug@nethelp.no> To: freebsd-net@freebsd.org From: 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 Subject: IPv4 vs. IPv6 ping -s inconsistency 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, 17 Apr 2010 12:51:31 -0000 For IPv4 I have to be root to ping with a payload larger than 56 bytes: sthaug@lab1% ping -s 1472 ftp.funet.fi ping: packet size too large: 1472 > 56: Operation not permitted However, for IPv6 the corresponding operation works just fine: sthaug@lab1% ping6 -s 1452 -m ftp.funet.fi PING6(1500=40+8+1452 bytes) 2001:8c0:8b00:1::2 --> 2001:708:10:9::20:2 1460 bytes from 2001:708:10:9::20:2, icmp_seq=0 hlim=57 time=15.730 ms 1460 bytes from 2001:708:10:9::20:2, icmp_seq=1 hlim=57 time=15.770 ms I find this highly inconsistent. My *personal* preference would be to remove the IPv4 check. Alternatively, the IPv6 ping should be changed to have the same limitation as the IPv4 ping. I realize that the IPv4 limitation is there to make it *slightly* more difficult to use FreeBSD boxes to perform DoS attacks and the like. Personally I believe this is misguided, since there are plenty of other ways to send large (interface MTU) packets. Oh yeah, I also find it inconsistent/undesriable that ping6 needs the -m option to send packets larger than the minimum IPv6 MTU. But that is a different discussion... Comments? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat Apr 17 14:56:29 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 121F1106566B; Sat, 17 Apr 2010 14:56:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD3D98FC19; Sat, 17 Apr 2010 14:56:28 +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 o3HEuSpa087416; Sat, 17 Apr 2010 14:56:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3HEuSHq087412; Sat, 17 Apr 2010 14:56:28 GMT (envelope-from linimon) Date: Sat, 17 Apr 2010 14:56:28 GMT Message-Id: <201004171456.o3HEuSHq087412@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145777: [wpi] Intel 3945ABG driver breaks the connection after about 10 minutes of inactivity 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, 17 Apr 2010 14:56:29 -0000 Synopsis: [wpi] Intel 3945ABG driver breaks the connection after about 10 minutes of inactivity Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 17 14:56:17 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145777 From owner-freebsd-net@FreeBSD.ORG Sat Apr 17 15:47: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 D4EA41065673; Sat, 17 Apr 2010 15:47: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 ABC218FC18; Sat, 17 Apr 2010 15:47: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 o3HFld2T031009; Sat, 17 Apr 2010 15:47:39 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3HFlc6C031005; Sat, 17 Apr 2010 15:47:38 GMT (envelope-from bz) Date: Sat, 17 Apr 2010 15:47:38 GMT Message-Id: <201004171547.o3HFlc6C031005@freefall.freebsd.org> To: peter@molnar.cc, bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/145736: [netinet] [patch] Access to freed mbuf in ip_forward with IPSEC enabled 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, 17 Apr 2010 15:47:39 -0000 Synopsis: [netinet] [patch] Access to freed mbuf in ip_forward with IPSEC enabled State-Changed-From-To: open->analyzed State-Changed-By: bz State-Changed-When: Sat Apr 17 15:46:55 UTC 2010 State-Changed-Why: This seems to be the correct conclusion and it seems to be still true in HEAD. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Apr 17 15:46:55 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=145736 From owner-freebsd-net@FreeBSD.ORG Sat Apr 17 15:48:02 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 695C4106566B; Sat, 17 Apr 2010 15:48:02 +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 408528FC15; Sat, 17 Apr 2010 15:48:02 +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 o3HFm2UN031060; Sat, 17 Apr 2010 15:48:02 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3HFm2h3031056; Sat, 17 Apr 2010 15:48:02 GMT (envelope-from bz) Date: Sat, 17 Apr 2010 15:48:02 GMT Message-Id: <201004171548.o3HFm2h3031056@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/145737: [netinet] [patch] Wrong UDP checksum not ignored as expected in UDP encapsuladed ESP packet 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, 17 Apr 2010 15:48:02 -0000 Synopsis: [netinet] [patch] Wrong UDP checksum not ignored as expected in UDP encapsuladed ESP packet Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Apr 17 15:47:48 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=145737