From owner-freebsd-net@FreeBSD.ORG Sun Aug 17 00:11:11 2008 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 1D260106566C for ; Sun, 17 Aug 2008 00:11:11 +0000 (UTC) (envelope-from mo0118@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id BB6E08FC18 for ; Sun, 17 Aug 2008 00:11:10 +0000 (UTC) (envelope-from mo0118@gmail.com) Received: by wx-out-0506.google.com with SMTP id h27so595495wxd.7 for ; Sat, 16 Aug 2008 17:11:09 -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:to :subject:in-reply-to:mime-version:content-type:references; bh=NUfo/U7DBApUXxlIVQJ4dMXIqvMXH00IbCbejKnn7ag=; b=NqHRJfP2u9tPUPFghabkaDegdvt3PgaKXJDle5P13c11p+1ER/7aFIbVIf3PPeu5be D0wVMx+jX3psCUWImI0jikkYOYVBq2Iz8F18v6KdCjVLBrcGYjM+/ByF9uf2B5iDzlYe RnHbHEBPxBCZYol3YsD/rQW0CgnIcqJW9n528= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=cnUIe+3ZRPkTZVNKrlNAjcr0MkQN0AfMURU1IC2DikR0PsBwjPLx1cmq65mTKFU1lm rzZvaQ8M9/9LsBgPoJUeG3ztObBv9IrFKbYMudJhxPPH38MS6CtRWr1apX3Koi7Vq0ej 8P0ljk+al80ATEa/y7oMYv0L97dRsFmRCBkLE= Received: by 10.70.31.8 with SMTP id e8mr5319155wxe.30.1218931869339; Sat, 16 Aug 2008 17:11:09 -0700 (PDT) Received: by 10.100.191.17 with HTTP; Sat, 16 Aug 2008 17:11:09 -0700 (PDT) Message-ID: Date: Sun, 17 Aug 2008 00:11:09 +0000 From: "Jeff Mo" To: linimon@freebsd.org, freebsd-bugs@freebsd.org, freebsd-net@freebsd.org, rfrench@freebsd.org, gnn@freebsd.org, jfvogel@gmail.com, paul@gtcomm.net, viper@perm.raid.ru, brutal_hitman_@hotmail.com, pyunyh@gmail.com, naddy@mips.inka.de, andrew@modulus.org, remko@freebsd.org In-Reply-To: MIME-Version: 1.0 References: X-Mailman-Approved-At: Sun, 17 Aug 2008 00:20:29 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Need Help! 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, 17 Aug 2008 00:11:11 -0000 Dear All , After I run the following commands three times, 1 ifconfig gre0 create 2 ifconfig gre0 tunnel 10.101.1.1 10.101.1.2 netmask 255.255.255.255 3 ifconfig gre0 destroy I found something weird: 1. in /var/log/messages , line 907 , there should be TAILQ_REMOVE because of ifconfig gre0 destroy, but nothing happened. 2. when i do the command second time, ia1=0xc2df1600 supposed not be there. 3. Some thing wrong with line 914,915,920,921,931,932,937,938 4. does "ifconfig gre0 destroy" causes TAILQ_REMOVE be called? Please nicely give me some comments. Thanks and Regards Jeff /var/log/messages first time 895 Aug 16 16:30:11 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc2df1600 896 Aug 16 16:30:11 JeffMo kernel: TAILQ_INSERT_TAIL:ia->ia_ifp=0xc27d6c00 897 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00 898 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 899 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00 900 Aug 16 16:30:11 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 901 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00 902 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 903 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00 904 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 905 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600 906 Aug 16 16:30:11 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6c00 907 Aug 16 16:30:11 JeffMo kernel: second time 908 Aug 16 16:30:34 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc3144d00 909 Aug 16 16:30:34 JeffMo kernel: TAILQ_INSERT_TAIL:ia->ia_ifp=0xc27d1c00 910 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00 911 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 912 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00 913 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 914 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc2df1600 915 Aug 16 16:30:34 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0x3e391 916 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00 917 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 918 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00 919 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 920 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600 921 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0x3e391 922 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc3144d00 923 Aug 16 16:30:34 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d1c00 924 Aug 16 16:30:34 JeffMo kernel: third time 925 Aug 16 16:30:57 JeffMo kernel: TAILQ_INSERT_TAIL:ia=0xc3145800 926 Aug 16 16:30:57 JeffMo kernel: TAILQ_INSERT_TAIL:ia->ia_ifp=0xc2812400 927 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc28e6b00 928 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 929 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc298ca00 930 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 931 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1=0xc2df1600 932 Aug 16 16:30:57 JeffMo kernel: before TAILQ_FOREACH:ia1->ia_ifp=0 933 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc28e6b00 934 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc2824400 935 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc298ca00 936 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0xc27d6000 937 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1=0xc2df1600 938 Aug 16 16:30:57 JeffMo kernel: after TAILQ_FOREACH:ia1->ia_ifp=0 #diff -uw in.c.ori in.c --- in.c.ori 2008-08-16 13:50:54.000000000 +0000 +++ in.c 2008-08-16 16:43:29.000000000 +0000 @@ -320,7 +320,23 @@ ia->ia_broadaddr.sin_family = AF_INET; } ia->ia_ifp = ifp; + //add by jeff:start + printf("TAILQ_INSERT_TAIL:ia=%p\n" , ia); + printf("TAILQ_INSERT_TAIL:ia->ia_ifp=%p\n" , ia->ia_ifp); + struct in_ifaddr *ia1; + TAILQ_FOREACH(ia1, &in_ifaddrhead, ia_link) { + printf("before TAILQ_FOREACH:ia1=%p\n" , ia1); + printf("before TAILQ_FOREACH:ia1->ia_ifp=%p\n" , ia1->ia_ifp); + } + //add by jeff:end TAILQ_INSERT_TAIL(&in_ifaddrhead, ia, ia_link); + //add by jeff:start + TAILQ_FOREACH(ia1, &in_ifaddrhead, ia_link) { + printf("after TAILQ_FOREACH:ia1=%p\n" , ia1); + printf("after TAILQ_FOREACH:ia1->ia_ifp=%p\n" , ia1->ia_ifp); + } + printf("\n"); + //add by jeff:end splx(s); iaIsNew = 1; } @@ -485,6 +501,7 @@ */ s = splnet(); TAILQ_REMOVE(&ifp->if_addrhead, &ia->ia_ifa, ifa_link); + printf("TAILQ_REMOVE:ia=%p\n" , ia); TAILQ_REMOVE(&in_ifaddrhead, ia, ia_link); if (ia->ia_addr.sin_family == AF_INET) { LIST_REMOVE(ia, ia_hash); @@ -803,8 +820,9 @@ mask = target->ia_sockmask.sin_addr; prefix.s_addr &= mask.s_addr; } - TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + printf("TAILQ_FOREACH:ia=%p\n", ia); + printf("TAILQ_FOREACH:ia->ia_ifp=%p\n", ia->ia_ifp); if (rtinitflags(ia)) { p = ia->ia_addr.sin_addr; @@ -833,6 +851,7 @@ return (0); } } + printf("\n"); /* * No-one seem to have this prefix route, so we try to insert it. */ From owner-freebsd-net@FreeBSD.ORG Sun Aug 17 06:08:42 2008 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 4231B1065673 for ; Sun, 17 Aug 2008 06:08:42 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id DD0B28FC13 for ; Sun, 17 Aug 2008 06:08:41 +0000 (UTC) (envelope-from spry@anarchy.in.the.ph) Received: by fg-out-1718.google.com with SMTP id l26so2818432fgb.35 for ; Sat, 16 Aug 2008 23:08:40 -0700 (PDT) Received: by 10.86.28.2 with SMTP id b2mr3509688fgb.31.1218951810327; Sat, 16 Aug 2008 22:43:30 -0700 (PDT) Received: by 10.86.50.17 with HTTP; Sat, 16 Aug 2008 22:43:30 -0700 (PDT) Message-ID: Date: Sun, 17 Aug 2008 13:43:30 +0800 From: "Mars G Miro" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ng_btsocket_rfcomm_receive_uih: Not enough space ... 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, 17 Aug 2008 06:08:42 -0000 Hi I use a Bluetooth dongle and do an rfcomm_sppd to my 3G phone for my internet needs. It seems that after a few hours of transferring data, prolly hundreds of megabytes , at some point it Aug 17 04:17:34 firefly kernel: ng_btsocket_rfcomm_receive_uih: Not enough space in socket receive queue. Dropping UIH for dlci=2, state=4, flags=0x2, len=505, space=347 Aug 17 04:17:34 firefly kernel: ng_btsocket_rfcomm_receive_uih: Not enough space in socket receive queue. Dropping UIH for dlci=2, state=4, flags=0x2, len=667, space=347 Aug 17 04:17:34 firefly kernel: ng_btsocket_rfcomm_receive_uih: Not enough space in socket receive queue. Dropping UIH for dlci=2, state=4, flags=0x2, len=505, space=29 then chokes my ppp link: Aug 17 04:20:32 firefly ppp[2715]: tun0: Phase: Clearing choked output queue Aug 17 04:22:33 firefly ppp[2715]: tun0: Phase: Clearing choked output queue Aug 17 04:24:34 firefly ppp[2715]: tun0: Phase: Clearing choked output queue Then my ppp link becomes deaf and dumb, I'd have to kill my ppp and restart my script again. Anybody else experiencing this? This is on FreeBSD-7.0R/i386. Thanks. -- cheers mars From owner-freebsd-net@FreeBSD.ORG Sun Aug 17 19:15:20 2008 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 26DB61065671 for ; Sun, 17 Aug 2008 19:15:20 +0000 (UTC) (envelope-from freebsd@chrisbuechler.com) Received: from mail.livebsd.com (mail.livebsd.com [69.64.6.14]) by mx1.freebsd.org (Postfix) with SMTP id D80348FC16 for ; Sun, 17 Aug 2008 19:15:19 +0000 (UTC) (envelope-from freebsd@chrisbuechler.com) Received: (qmail 92550 invoked by uid 89); 17 Aug 2008 19:15:18 -0000 Received: from unknown (HELO ?10.0.64.15?) (74.130.92.110) by 172.29.29.14 with SMTP; 17 Aug 2008 19:15:18 -0000 Message-ID: <48A878C6.9000001@chrisbuechler.com> Date: Sun, 17 Aug 2008 15:15:18 -0400 From: Chris Buechler User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: repeatable scp stalls from 7.0 to 7.0 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, 17 Aug 2008 19:15:20 -0000 I've been seeing pretty frequent and repeatable scp stalls between two FreeBSD 7.0 servers (7.0-RELEASE-p2 to be exact) on a 100 Mb LAN. They're two HP servers, an Opteron 275 and a dual Xeon 3.4 (don't recall the models but I can get them if it's relevant) using the onboard bge(4) cards. The client side (builder7) SCPs a file to the server side (hosting7) about 20 times a day. The stall happens about 2-4 times a week or so, and has happened ever since we put these two boxes online in their current functions. Initially they were the original 7.0 release, prior to the TCP fix in June. It's behaved the same way both prior to and after that fix. There are no apparent network issues aside from this with either of the boxes. Since we had nothing to go on other than scp sessions going to "stalled" (no relevant logs), I setup a tcpdump on each end filtering on the TCP 22 traffic between these hosts, grabbing 100 bytes of each frame to avoid chewing up too much disk space. When it happened again I split the end out into its own file with editcap, 4.2-4.3 MB each. http://chrisbuechler.com/temp/lastcut-hosting7.pcap - server end, capture taken on host but destination IP is a jail http://chrisbuechler.com/temp/lastcut-builder7.pcap - client end, connection is initiated from the host, no jails involved. The TCP window on the ACKs from server to client start decrementing [1], to the point where it's down to a window of 0. From that point, everything the server (172.29.29.181 ) sends back to the client (172.29.29.170 ) has a window of 0. Restarting the scp makes it work again. It doesn't happen every time, somewhere around 2-3% of the time it does. I don't see any cause for the decrementing window in those captures but maybe I'm missing something. 1 - lastcut-hosting7.pcap frame #21298; lastcut-builder7.pcap #25088 These are both very stock boxes, GENERIC kernels, no significant changes in sysctl or anything else. I'm not sure where to go from here, any assistance in resolving this would be appreciated. cheers, Chris From owner-freebsd-net@FreeBSD.ORG Mon Aug 18 11:06:54 2008 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 341641065684 for ; Mon, 18 Aug 2008 11:06:54 +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 22D138FC1F for ; Mon, 18 Aug 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7IB6rv5079882 for ; Mon, 18 Aug 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7IB6rYe079878 for freebsd-net@FreeBSD.org; Mon, 18 Aug 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Aug 2008 11:06:53 GMT Message-Id: <200808181106.m7IB6rYe079878@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, 18 Aug 2008 11:06:54 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a 102 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/126339 net [ipw] ipw driver drops the connection 60 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 18 13:26:53 2008 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 6A6A71065676; Mon, 18 Aug 2008 13:26:53 +0000 (UTC) (envelope-from root@cfins.au.tsinghua.edu.cn) Received: from cfins.au.tsinghua.edu.cn (tu140247.ip.tsinghua.edu.cn [166.111.140.247]) by mx1.freebsd.org (Postfix) with ESMTP id D04C28FC1E; Mon, 18 Aug 2008 13:26:52 +0000 (UTC) (envelope-from root@cfins.au.tsinghua.edu.cn) Received: from localhost (localhost [127.0.0.1]) (uid 0) by cfins.au.tsinghua.edu.cn with local; Mon, 18 Aug 2008 21:16:51 +0800 id 001832E5.48A97643.0000079B References: <200808161237.m7GCbFY3061248@freefall.freebsd.org> In-Reply-To: <200808161237.m7GCbFY3061248@freefall.freebsd.org> From: "Intron is my alias on the Internet" To: gavin@FreeBSD.org Date: Mon, 18 Aug 2008 20:59:33 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: base64 Message-ID: Cc: freebsd-net@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: kern/126564: [ath] doesn't work with my PCI-E X1 wireless network adaptor 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, 18 Aug 2008 13:26:53 -0000 VGhlIG5ldyBIQUwgd29ya3Mgd2VsbCB3aXRoIG15IGNhcmQuClRoYW5rIHlvdS4KCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG cm9tIEJlaWppbmcsIENoaW5hCgoKZ2F2aW5ARnJlZUJTRC5vcmcg0LS1vToKCj4gU3lub3BzaXM6 IFthdGhdIGRvZXNuJ3Qgd29yayB3aXRoIG15IFBDSS1FIFgxIHdpcmVsZXNzIG5ldHdvcmsgYWRh cHRvcgo+IAo+IFN0YXRlLUNoYW5nZWQtRnJvbS1Ubzogb3Blbi0+ZmVlZGJhY2sKPiBTdGF0ZS1D aGFuZ2VkLUJ5OiBnYXZpbgo+IFN0YXRlLUNoYW5nZWQtV2hlbjogU2F0IEF1ZyAxNiAxMjozNTo0 NiBVVEMgMjAwOAo+IFN0YXRlLUNoYW5nZWQtV2h5OiAKPiBUbyBzdWJtaXR0ZXI6IGNhbiB5b3Ug dHJ5IHRoZSB1cGRhdGVkIEhBTCBmcm9tCj4gaHR0cDovL3Blb3BsZS5mcmVlYnNkLm9yZy9+c2Ft L2F0aF9oYWwtMjAwODA1MjgudGd6Cj4gKHVucGFjayBpbnRvIC91c3Ivc3JjL3N5cy9jb250cmli L2F0aCkgYW5kIHNlZSBpZiB0aGF0IGZpeGVzCj4gdGhlaW5ncyBmb3IgeW91Pwo+IAo+IAo+IFJl c3BvbnNpYmxlLUNoYW5nZWQtRnJvbS1UbzogZnJlZWJzZC1pMzg2LT5mcmVlYnNkLW5ldAo+IFJl c3BvbnNpYmxlLUNoYW5nZWQtQnk6IGdhdmluCj4gUmVzcG9uc2libGUtQ2hhbmdlZC1XaGVuOiBT YXQgQXVnIDE2IDEyOjM1OjQ2IFVUQyAyMDA4Cj4gUmVzcG9uc2libGUtQ2hhbmdlZC1XaHk6IAo+ IE92ZXIgdG8gbWFpbnRhaW5lcnMKPiAKPiBodHRwOi8vd3d3LmZyZWVic2Qub3JnL2NnaS9xdWVy eS1wci5jZ2k/cHI9MTI2NTY0Cgo= From owner-freebsd-net@FreeBSD.ORG Mon Aug 18 14:50:07 2008 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 4F2B8106564A for ; Mon, 18 Aug 2008 14:50:07 +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 3EE0E8FC2D for ; Mon, 18 Aug 2008 14:50:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7IEo67T004169 for ; Mon, 18 Aug 2008 14:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7IEo6Xc004164; Mon, 18 Aug 2008 14:50:06 GMT (envelope-from gnats) Date: Mon, 18 Aug 2008 14:50:06 GMT Message-Id: <200808181450.m7IEo6Xc004164@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gavin Atkinson Cc: Subject: Re: kern/126564: [ath] doesn't work with my PCI-E X1 wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin Atkinson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 14:50:07 -0000 The following reply was made to PR kern/126564; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126564: [ath] doesn't work with my PCI-E X1 wireless Date: Mon, 18 Aug 2008 15:11:58 +0100 (BST) ---------- Forwarded message ---------- Date: Mon, 18 Aug 2008 20:59:33 +0800 From: Intron is my alias on the Internet To: gavin@FreeBSD.org Cc: freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/126564: [ath] doesn't work with my PCI-E X1 wireless network adaptor The new HAL works well with my card. Thank you. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-net@FreeBSD.ORG Mon Aug 18 21:13:43 2008 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 5A6E1106564A; Mon, 18 Aug 2008 21:13:43 +0000 (UTC) (envelope-from rfrench@freebsd.org) Received: from oberon.wxnz.net (oberon.wxnz.net [58.28.6.13]) by mx1.freebsd.org (Postfix) with ESMTP id 13D208FC16; Mon, 18 Aug 2008 21:13:43 +0000 (UTC) (envelope-from rfrench@freebsd.org) Received: from mini-tank.local (ip-58-28-152-154.static-xdsl.xnet.co.nz [58.28.152.154]) by oberon.wxnz.net (Postfix) with ESMTP id 152F1464284; Tue, 19 Aug 2008 09:17:02 +1200 (NZST) From: Ryan French To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Date: Tue, 19 Aug 2008 09:13:39 +1200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200808190913.40316.rfrench@freebsd.org> Cc: Subject: Summer of Code is over!! 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, 18 Aug 2008 21:13:43 -0000 Hi all, As those of you involved in the Google Summer of Code know, today is the last day of coding for the project. However, I still have a lot to do on my implementation of MPLS, and will continue to work on this until it is working. I would like to say thank you to all of those who have helped me over the course of the program in trying to get this project up and running. With that in mind I have submitted the semi-finished code for trying to get sending and receiving of packets working. Unfortunately I have come up against a bit of a brick wall in terms of trying to figure out the exact inner workings of FreeBSD. At the moment, in theory at least, the sending and receiving of packets should work, however I am stuck as to how to integrate my code properly with the kernel. So far I have created a mpls_init which contains a netisr_register function, as well as inserted the appropriate code into the ether_demux function, but it still does not appear to be running the code when an MPLS packet is received. If anyone would like to look at the code and give me any feedback on how to improve it, or any ideas on how to get it working, it would be greatly appreciated, and I understand it is a very big ask of anyone to look through it, so I will thank you in advance for your time. Thank you for being such a great community and helping me get through this summer of code. No doubt you will be hearing from me on the mailing lists as I continue to try and get this project working, and possibly even move onto other projects. -Ryan French From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 00:58:08 2008 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 24680106564A for ; Tue, 19 Aug 2008 00:58:08 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from smtpout2.uunet.co.za (smtpout2.uunet.co.za [196.7.142.138]) by mx1.freebsd.org (Postfix) with ESMTP id A9FE58FC1A for ; Tue, 19 Aug 2008 00:58:07 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from nop148.nop.jnb6.za.uu.net ([196.30.158.148] helo=lap-todor.subnet.co.za) by smtp.uunet.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1KVFXx-00098n-OD for freebsd-net@freebsd.org; Tue, 19 Aug 2008 02:58:05 +0200 Message-ID: <48AA1A9D.2040607@za.verizonbusiness.com> Date: Tue, 19 Aug 2008 02:58:05 +0200 From: Todor Genov User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Possible bug - GRE tunnel routing 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, 19 Aug 2008 00:58:08 -0000 Hi everyone, I may have found a routing bug relating to GRE tunnels. Could somebody try and replicate this? As per the setup below GRE-encapsulated traffic to 194.31.254.148 should be going out via tun1, but a tcpdump shows the traffic leaving via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 goes out via tun1 as expected. Configuration: FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 tun0 - PPPoE connection to ISP tun1 - vpn connection to office PIX (via vpnc) gre0 - GRE tunnel to machine sitting behind the PIX tun0: flags=8051 metric 0 mtu 1492 inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 Opened by PID 509 tun1: flags=8051 metric 0 mtu 1500 inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 Opened by PID 984 gre0: flags=9051 metric 0 mtu 1476 tunnel inet 194.31.137.70 --> 194.31.154.148 inet 192.168.254.2 --> 192.168.254.1 netmask 0xffffff00 Routing table: Destination Gateway Flags Refs Use Netif Expire default 41.142.82.1 UGS 1 1365 tun0 41.142.82.1 41.142.82.37 UGH 1 0 tun0 192.168.254.1 192.168.254.2 UH 0 3 gre0 194.31.137.64 194.31.137.70 UH 1 0 tun1 194.31.154.148 194.31.137.64 UGS 0 0 tun1 GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed via tun0 [root@fw ~]# tcpdump -ni tun0 proto gre tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, length 64 ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is routed via tun1 [root@fw ~]# tcpdump -ni tun1 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id 10757, seq 14, length 64 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id 10757, seq 14, length 64 However, if I add a /24 route for the GRE endpoint subnet, instead of a /32 to the host: 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 and then bring up the GRE tunnel, everything works as expected and GRE traffic exits via tun1. -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543 -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543 From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 01:50:49 2008 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 A025B1065694 for ; Tue, 19 Aug 2008 01:50:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 843508FC15 for ; Tue, 19 Aug 2008 01:50:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 242692374; Mon, 18 Aug 2008 18:50:49 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 0419B2D604B; Mon, 18 Aug 2008 18:50:48 -0700 (PDT) Message-ID: <48AA26FD.20305@elischer.org> Date: Mon, 18 Aug 2008 18:50:53 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Todor Genov References: <48AA1A9D.2040607@za.verizonbusiness.com> In-Reply-To: <48AA1A9D.2040607@za.verizonbusiness.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing 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, 19 Aug 2008 01:50:49 -0000 Todor Genov wrote: > Hi everyone, > > I may have found a routing bug relating to GRE tunnels. Could somebody > try and replicate this? > > As per the setup below GRE-encapsulated traffic to 194.31.254.148 > should be going out via tun1, but a tcpdump shows the traffic leaving > via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 > goes out via tun1 as expected. > > Configuration: > FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 > tun0 - PPPoE connection to ISP > tun1 - vpn connection to office PIX (via vpnc) > gre0 - GRE tunnel to machine sitting behind the PIX > > tun0: flags=8051 metric 0 mtu 1492 > inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 > Opened by PID 509 > tun1: flags=8051 metric 0 mtu 1500 > inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 > Opened by PID 984 Point to point interfaces really don't have netmasks. Otherwise it wouldn't be "Point to Point", it would be "multicast" like ethernet. There is really only one address at this end or the other end. If you want to say that there is a network at the other end then you really need to set a route for it. but it applies equally to all three of these p2p links. so, add a route: route add 92.168.254.0/24 92.168.254.1 > gre0: flags=9051 metric 0 mtu 1476 > tunnel inet 194.31.137.70 --> 194.31.154.148 > inet 192.168.254.2 --> 92.168.254.1 netmask 0xffffff00 > > Routing table: > Destination Gateway Flags Refs Use Netif Expire > default 41.142.82.1 UGS 1 1365 tun0 > 41.142.82.1 41.142.82.37 UGH 1 0 tun0 > 192.168.254.1 192.168.254.2 UH 0 3 gre0 > 194.31.137.64 194.31.137.70 UH 1 0 tun1 > 194.31.154.148 194.31.137.64 UGS 0 0 tun1 > > GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed > via tun0 Why do you think you need -S? routing takes into account only the destination.. > > [root@fw ~]# tcpdump -ni tun0 proto gre > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes > 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP > 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, > length 64 > > > ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is > routed via tun1 > > [root@fw ~]# tcpdump -ni tun1 icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes > 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id > 10757, seq 14, length 64 > 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id > 10757, seq 14, length 64 > > > However, if I add a /24 route for the GRE endpoint subnet, instead of a > /32 to the host: > > 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 > > and then bring up the GRE tunnel, everything works as expected and GRE > traffic exits via tun1. yes.. that is as expected.. > > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 08:47:58 2008 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 4D3D51065672 for ; Tue, 19 Aug 2008 08:47:58 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from smtpout2.uunet.co.za (smtpout2.uunet.co.za [196.7.142.138]) by mx1.freebsd.org (Postfix) with ESMTP id D7BA68FC17 for ; Tue, 19 Aug 2008 08:47:57 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from nop109.nop.jnb6.za.uu.net ([196.30.158.109] helo=lap-todor.staff.uunet.co.za) by smtp.uunet.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1KVMsd-000G4e-Pm; Tue, 19 Aug 2008 10:47:55 +0200 Message-ID: <48AA88B4.6040606@za.verizonbusiness.com> Date: Tue, 19 Aug 2008 10:47:48 +0200 From: Todor Genov User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Julian Elischer References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> In-Reply-To: <48AA26FD.20305@elischer.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing 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, 19 Aug 2008 08:47:58 -0000 Hi Julian, Julian Elischer wrote: > Todor Genov wrote: >> Hi everyone, >> >> I may have found a routing bug relating to GRE tunnels. Could somebody >> try and replicate this? >> >> As per the setup below GRE-encapsulated traffic to 194.31.254.148 >> should be going out via tun1, but a tcpdump shows the traffic leaving >> via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 >> goes out via tun1 as expected. >> >> Configuration: >> FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 >> tun0 - PPPoE connection to ISP >> tun1 - vpn connection to office PIX (via vpnc) >> gre0 - GRE tunnel to machine sitting behind the PIX >> >> tun0: flags=8051 metric 0 mtu 1492 >> inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 >> Opened by PID 509 >> tun1: flags=8051 metric 0 mtu 1500 >> inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 >> Opened by PID 984 > > Point to point interfaces really don't have netmasks. > Otherwise it wouldn't be "Point to Point", it would be > "multicast" like ethernet. > > There is really only one address at this end or the other end. > If you want to say that there is a network at the other end > then you really need to set a route for it. > but it applies equally to all three of these p2p links. > > so, add a route: > > route add 92.168.254.0/24 92.168.254.1 The netmask for tun0 is automatically assigned by the ISP, and for tun1 by the VPN server. The one for gre0 is a /30 in the connect scripts - I must have changed it to /24 somewhere along the troubleshooting process - it makes no difference to the end result. The routing table does include routes to the /26 on tun1 and the /24 on gre0. I have left them out as they are not relevant to the problem. The troublesome route is the one to 194.31.154.148/32 Just noticed that the PtP address for tun1 looks incorrect - with that netmask into account .64 is the network address. I'll look into that as a possible cause. > > > >> gre0: flags=9051 metric 0 mtu >> 1476 >> tunnel inet 194.31.137.70 --> 194.31.154.148 >> inet 192.168.254.2 --> 92.168.254.1 netmask 0xffffff00 >> >> Routing table: >> Destination Gateway Flags Refs Use Netif >> Expire >> default 41.142.82.1 UGS 1 1365 tun0 >> 41.142.82.1 41.142.82.37 UGH 1 0 tun0 >> 192.168.254.1 192.168.254.2 UH 0 3 gre0 >> 194.31.137.64 194.31.137.70 UH 1 0 tun1 >> 194.31.154.148 194.31.137.64 UGS 0 0 tun1 >> >> GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed >> via tun0 > > Why do you think you need -S? routing takes into account only the > destination.. > I am using -S just to make sure that the source IP is the gre0 interface - more of a habit than any particular reason. >> >> [root@fw ~]# tcpdump -ni tun0 proto gre >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode >> listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes >> 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP >> 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777, >> length 64 >> >> >> ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is >> routed via tun1 >> >> [root@fw ~]# tcpdump -ni tun1 icmp >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode >> listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes >> 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id >> 10757, seq 14, length 64 >> 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id >> 10757, seq 14, length 64 >> >> >> However, if I add a /24 route for the GRE endpoint subnet, instead of a >> /32 to the host: >> >> 194.31.154.0/24 194.31.137.64 UGS 0 0 tun1 >> >> and then bring up the GRE tunnel, everything works as expected and GRE >> traffic exits via tun1. > > yes.. that is as expected.. It is also expected that the /32 route over tun1 to the GRE endpoint (196.31.154.148) should suffice. What puzzles me is the fact that GRE traffic to 196.31.154.138 leaves via tun0 and icmp traffic leaves via tun1. > >> >> >> > > _______________________________________________ > 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 Aug 19 09:09:57 2008 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 7DFF8106566B; Tue, 19 Aug 2008 09:09:57 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE6D8FC1B; Tue, 19 Aug 2008 09:09:56 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVMhs-000HEs-UK; Tue, 19 Aug 2008 16:36:49 +0800 Message-ID: <48AA8624.5010206@micom.mng.net> Date: Tue, 19 Aug 2008 16:36:52 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080415) MIME-Version: 1.0 To: "freebsd-net@freebsd.org" X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: thompsa@FreeBSD.org Subject: possibly bridge related problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 09:09:57 -0000 Hi, I have strange network problem on my laptop. I can't make connection to my desktop(192.168.0.18) from my laptop. However I can ping to other addresses from my laptop. I can't ping and make connection to my laptop from my desktop either. On the laptop I have bridge created at boot time. When I destroy bridge0 I can ping and make connection to my desktop. Is this known problem? If not where should I look for the problem? Or am I doing something wrong? ... devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Tue Aug 19 15:29:26 ULAT 2008 tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms ^C --- 192.168.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes ^C --- 192.168.0.18 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss devil# ifconfig -a bge0: flags=8943 metric 0 mtu 1500 options=98 ether 00:14:22:fb:32:a6 inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 00:14:22:fb:32:a6 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 2000000 member: bge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 20000 tap0: flags=8902 metric 0 mtu 1500 ether 00:bd:4b:1b:00:00 tun0: flags=8051 metric 0 mtu 1500 inet 192.168.10.34 --> 192.168.10.33 netmask 0xffffffff Opened by PID 802 devil# kldstat Id Refs Address Size Name 1 22 0xc0400000 701a64 kernel 2 1 0xc0b02000 5844 if_tap.ko 3 1 0xc0b08000 15524 snd_hda.ko 4 2 0xc0b1e000 52a08 sound.ko 5 2 0xc0b71000 10ebc drm.ko 6 1 0xc0b82000 71c4 i915.ko 7 1 0xc0b8a000 1fe68 kqemu.ko 8 1 0xc0baa000 b8c8 aio.ko 9 1 0xc0bb6000 6b3d0 acpi.ko 10 1 0xc433b000 9000 if_bridge.ko 11 1 0xc4344000 6000 bridgestp.ko 12 2 0xc44c2000 d000 ipfw.ko 13 1 0xc44fb000 4000 ipdivert.ko 14 1 0xc452a000 22000 linux.ko 15 1 0xc45a6000 e000 fuse.ko devil# more /etc/rc.conf cloned_interfaces="bridge0 tap0" firewall_enable="YES" firewall_quiet="NO" firewall_script="/etc/rc.firewall" firewall_type="open" gateway_enable="YES" hostname="devil.micom.mng.net" ifconfig_bge0="DHCP" ifconfig_bridge0="addm bge0 addm tap0 up" inetd_enable="YES" natd_enable="YES" # Enable natd (if firewall_enable == YES). natd_interface="bge0" # Public interface or IPaddress to use. openvpn_enable="YES" openvpn_if="tun" devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 00100 4 200 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 65000 383 33187 allow ip from any to any 65535 0 0 deny ip from any to any devil# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGS 0 205 bge0 127.0.0.1 127.0.0.1 UH 0 2 lo0 192.168.0.0/24 link#1 UC 0 0 bge0 192.168.0.1 00:e0:29:3b:5a:b0 UHLW 2 10 bge0 1099 192.168.10.0/24 192.168.10.33 UGS 0 0 tun0 192.168.10.33 192.168.10.34 UH 1 0 tun0 ... thanks, Ganbold -- Algol-60 surely must be regarded as the most important programming language yet developed. -- T. Cheatham From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 09:56:34 2008 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 98CCE1065674 for ; Tue, 19 Aug 2008 09:56:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5174D8FC12 for ; Tue, 19 Aug 2008 09:56:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so1034163wra.27 for ; Tue, 19 Aug 2008 02:56:33 -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:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UkiIH9JLltDikoVDWbWRIMdvX96ntoFlqWCZlE9W/rs=; b=qcMTdLeLpcrlJYHo5+o27HZf6tSjXH+my489KCJw+isGCqXFUTNvlxAp6JE6KSYOLq 3DGl4n9xlsA2T7gmfwm4LBY9ax+lINCRSsSi748sg93CJQdTpS8sfpgBtF+WFfN9ADsk OkVvjsd+tSROOpqCZuJWogt1Ir5vJmj8Wbq0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ioTMvYN50SotULIIDuFP+3u4qYrX0xeMC0+gxRiDqBgQUGLrox4I5bKVSSQG5dxCre /UxoyAsqsHYTVr6ytNEZp4qyw7ff2xUAfRUAllQvi/0SZaQ6hdceVFHFGKrUAzTTMa1F G+DSBUnTXhcpt761aLUErhiFTMQQF/L24fc4E= Received: by 10.90.67.10 with SMTP id p10mr840647aga.64.1219138050604; Tue, 19 Aug 2008 02:27:30 -0700 (PDT) Received: by 10.90.81.10 with HTTP; Tue, 19 Aug 2008 02:27:30 -0700 (PDT) Message-ID: Date: Tue, 19 Aug 2008 13:27:30 +0400 From: pluknet To: Ganbold In-Reply-To: <48AA8624.5010206@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48AA8624.5010206@micom.mng.net> Cc: "freebsd-net@freebsd.org" , thompsa@freebsd.org Subject: Re: possibly bridge related problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 09:56:34 -0000 2008/8/19 Ganbold : > Hi, > > I have strange network problem on my laptop. > I can't make connection to my desktop(192.168.0.18) from my laptop. > However I can ping to other addresses from my laptop. > I can't ping and make connection to my laptop from my desktop either. > > On the laptop I have bridge created at boot time. > When I destroy bridge0 I can ping and make connection to my desktop. > Is this known problem? If not where should I look for the problem? > Or am I doing something wrong? > > ... > devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE > #8: Tue Aug 19 15:29:26 ULAT 2008 > tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 > devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes > 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms > 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms > 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms > ^C > --- 192.168.0.1 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms > > devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes > ^C > --- 192.168.0.18 ping statistics --- > 4 packets transmitted, 0 packets received, 100.0% packet loss > > devil# ifconfig -a bge0: > flags=8943 metric 0 mtu 1500 > options=98 > ether 00:14:22:fb:32:a6 > inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (1000baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 bridge0: > flags=8843 metric 0 mtu 1500 > ether 00:14:22:fb:32:a6 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 2000000 > member: bge0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 20000 > tap0: flags=8902 metric 0 mtu 1500 > ether 00:bd:4b:1b:00:00 > tun0: flags=8051 metric 0 mtu 1500 > inet 192.168.10.34 --> 192.168.10.33 netmask 0xffffffff Opened by PID > 802 > > devil# kldstat Id Refs Address Size Name > 1 22 0xc0400000 701a64 kernel > 2 1 0xc0b02000 5844 if_tap.ko > 3 1 0xc0b08000 15524 snd_hda.ko > 4 2 0xc0b1e000 52a08 sound.ko > 5 2 0xc0b71000 10ebc drm.ko > 6 1 0xc0b82000 71c4 i915.ko > 7 1 0xc0b8a000 1fe68 kqemu.ko > 8 1 0xc0baa000 b8c8 aio.ko > 9 1 0xc0bb6000 6b3d0 acpi.ko > 10 1 0xc433b000 9000 if_bridge.ko > 11 1 0xc4344000 6000 bridgestp.ko > 12 2 0xc44c2000 d000 ipfw.ko > 13 1 0xc44fb000 4000 ipdivert.ko > 14 1 0xc452a000 22000 linux.ko > 15 1 0xc45a6000 e000 fuse.ko > > devil# more /etc/rc.conf > cloned_interfaces="bridge0 tap0" > firewall_enable="YES" > firewall_quiet="NO" > firewall_script="/etc/rc.firewall" > firewall_type="open" > gateway_enable="YES" > hostname="devil.micom.mng.net" > > ifconfig_bge0="DHCP" > ifconfig_bridge0="addm bge0 addm tap0 up" > inetd_enable="YES" > > natd_enable="YES" # Enable natd (if firewall_enable == YES). > natd_interface="bge0" # Public interface or IPaddress to use. > openvpn_enable="YES" > openvpn_if="tun" > > > devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 > 00100 4 200 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 65000 383 33187 allow ip from any to any > 65535 0 0 deny ip from any to any > > devil# netstat -rn Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.0.1 UGS 0 205 bge0 > 127.0.0.1 127.0.0.1 UH 0 2 lo0 > 192.168.0.0/24 link#1 UC 0 0 bge0 > 192.168.0.1 00:e0:29:3b:5a:b0 UHLW 2 10 bge0 1099 > 192.168.10.0/24 192.168.10.33 UGS 0 0 tun0 > 192.168.10.33 192.168.10.34 UH 1 0 tun0 > Hi, I guess you got that buggy window in 7-stable between [1] and the fix, that would come [2] in 7-stable in a few days. [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=180364 [2] http://svn.freebsd.org/viewvc/base?view=revision&revision=181824 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 10:47:19 2008 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 3C660106564A; Tue, 19 Aug 2008 10:47:19 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id C9A758FC29; Tue, 19 Aug 2008 10:47:18 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVOk4-000I8A-9j; Tue, 19 Aug 2008 18:47:12 +0800 Message-ID: <48AAA4B4.2060700@micom.mng.net> Date: Tue, 19 Aug 2008 18:47:16 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080415) MIME-Version: 1.0 To: pluknet References: <48AA8624.5010206@micom.mng.net> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , thompsa@freebsd.org Subject: Re: possibly bridge related problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2008 10:47:19 -0000 pluknet wrote: > 2008/8/19 Ganbold : > >> Hi, >> >> I have strange network problem on my laptop. >> I can't make connection to my desktop(192.168.0.18) from my laptop. >> However I can ping to other addresses from my laptop. >> I can't ping and make connection to my laptop from my desktop either. >> >> On the laptop I have bridge created at boot time. >> When I destroy bridge0 I can ping and make connection to my desktop. >> Is this known problem? If not where should I look for the problem? >> Or am I doing something wrong? >> >> ... >> devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE >> #8: Tue Aug 19 15:29:26 ULAT 2008 >> tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 >> devil# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes >> 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.920 ms >> 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=1.788 ms >> 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=1.130 ms >> ^C >> --- 192.168.0.1 ping statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.920/1.279/1.788/0.370 ms >> >> devil# ping 192.168.0.18 PING 192.168.0.18 (192.168.0.18): 56 data bytes >> ^C >> --- 192.168.0.18 ping statistics --- >> 4 packets transmitted, 0 packets received, 100.0% packet loss >> >> devil# ifconfig -a bge0: >> flags=8943 metric 0 mtu 1500 >> options=98 >> ether 00:14:22:fb:32:a6 >> inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255 >> media: Ethernet autoselect (1000baseTX ) >> status: active >> lo0: flags=8049 metric 0 mtu 16384 >> inet 127.0.0.1 netmask 0xff000000 bridge0: >> flags=8843 metric 0 mtu 1500 >> ether 00:14:22:fb:32:a6 >> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >> maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 >> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >> member: tap0 flags=143 >> ifmaxaddr 0 port 4 priority 128 path cost 2000000 >> member: bge0 flags=143 >> ifmaxaddr 0 port 1 priority 128 path cost 20000 >> tap0: flags=8902 metric 0 mtu 1500 >> ether 00:bd:4b:1b:00:00 >> tun0: flags=8051 metric 0 mtu 1500 >> inet 192.168.10.34 --> 192.168.10.33 netmask 0xffffffff Opened by PID >> 802 >> >> devil# kldstat Id Refs Address Size Name >> 1 22 0xc0400000 701a64 kernel >> 2 1 0xc0b02000 5844 if_tap.ko >> 3 1 0xc0b08000 15524 snd_hda.ko >> 4 2 0xc0b1e000 52a08 sound.ko >> 5 2 0xc0b71000 10ebc drm.ko >> 6 1 0xc0b82000 71c4 i915.ko >> 7 1 0xc0b8a000 1fe68 kqemu.ko >> 8 1 0xc0baa000 b8c8 aio.ko >> 9 1 0xc0bb6000 6b3d0 acpi.ko >> 10 1 0xc433b000 9000 if_bridge.ko >> 11 1 0xc4344000 6000 bridgestp.ko >> 12 2 0xc44c2000 d000 ipfw.ko >> 13 1 0xc44fb000 4000 ipdivert.ko >> 14 1 0xc452a000 22000 linux.ko >> 15 1 0xc45a6000 e000 fuse.ko >> >> devil# more /etc/rc.conf >> cloned_interfaces="bridge0 tap0" >> firewall_enable="YES" >> firewall_quiet="NO" >> firewall_script="/etc/rc.firewall" >> firewall_type="open" >> gateway_enable="YES" >> hostname="devil.micom.mng.net" >> >> ifconfig_bge0="DHCP" >> ifconfig_bridge0="addm bge0 addm tap0 up" >> inetd_enable="YES" >> >> natd_enable="YES" # Enable natd (if firewall_enable == YES). >> natd_interface="bge0" # Public interface or IPaddress to use. >> openvpn_enable="YES" >> openvpn_if="tun" >> >> >> devil# ipfw show 00050 224 19723 divert 8668 ip4 from any to any via bge0 >> 00100 4 200 allow ip from any to any via lo0 >> 00200 0 0 deny ip from any to 127.0.0.0/8 >> 00300 0 0 deny ip from 127.0.0.0/8 to any >> 65000 383 33187 allow ip from any to any >> 65535 0 0 deny ip from any to any >> >> devil# netstat -rn Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 192.168.0.1 UGS 0 205 bge0 >> 127.0.0.1 127.0.0.1 UH 0 2 lo0 >> 192.168.0.0/24 link#1 UC 0 0 bge0 >> 192.168.0.1 00:e0:29:3b:5a:b0 UHLW 2 10 bge0 1099 >> 192.168.10.0/24 192.168.10.33 UGS 0 0 tun0 >> 192.168.10.33 192.168.10.34 UH 1 0 tun0 >> >> > > Hi, > > I guess you got that buggy window in 7-stable between [1] and the fix, > that would come [2] in 7-stable in a few days. > > [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=180364 > [2] http://svn.freebsd.org/viewvc/base?view=revision&revision=181824 > Thanks a lot. After applying the patch it seems it is working OK now :) Ganbold > wbr, > pluknet > _______________________________________________ > 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" > > > > -- The Pig, if I am not mistaken, Gives us ham and pork and Bacon. Let others think his heart is big, I think it stupid of the Pig. -- Ogden Nash From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 13:12:15 2008 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 EE7D0106568B for ; Tue, 19 Aug 2008 13:12:15 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 69AF98FC08 for ; Tue, 19 Aug 2008 13:12:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id XAA03266; Tue, 19 Aug 2008 23:12:05 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 19 Aug 2008 23:12:04 +1000 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <48926C02.6030308@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: ipfw add skipto tablearg.... 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, 19 Aug 2008 13:12:16 -0000 On Thu, 31 Jul 2008, Julian Elischer wrote: > looking int he code I noticed that the following command gave > no error but didn't work.. > > > ipfw add 1000 skipto tablearg ip from any to table(31) Content addressible branching is an elegant and useful idea, thanks for making it work. A simple example in ipfw(8) might promote 'uptake'? > and as I have a use for that, I implemented it.. MFC to 6 possible? likely? I know there's lots of other stuff that hasn't / won't / can't be, but this one looked perhaps stand-alone .. > see attached patch... (hopefully not stripped) > > Of course it is hoped that the rules you are skipping to are nearby > as it iterates through the rules following the skipto to find the > target, Until $someone adds a direct skipto target jump at the virtual machine code level - big recalc hit when adding/deleting rules/sets I suppose - it's still the fastest way to get from a to b, where b > a Speaking of which, should ipfw whinge when asked to skip backwards, which it can't, confirmed on a recent browse re Mike's ipfw-classifyd and a local test months ago. > but.... > if you had a thousand table entries and wanted to sort them into > 20 buckets, it could save you puting them into 20 different > tables and doing 20 table lookups on them. Or even just for quick basic traffic-splitting, bogon lists, whatever .. > here I sort into two categories.. possibly already a win.. > > > julian@trafmon2:cat ipfw-test.sh > #!/bin/sh > ipfw add 100 skipto 10000 ip from any to not 1.1.1.0/24 > ipfw add 1000 skipto tablearg ip from any to "table(31)" > ipfw add 2000 drop ip from any to any > ipfw add 2001 drop ip from any to any > ipfw add 3000 drop ip from any to any > ipfw add 3001 drop ip from any to any > ipfw add 10000 count ip from any to any > ipfw table 31 add 1.1.1.1 2000 > ipfw table 31 add 1.1.1.2 3000 > > julian@trafmon2: ping 1.1.1.1 > [...] (2 packets bounced) > julian@trafmon2: ping 1.1.1.2 > [...] (12 packets bounced) > > julian@trafmon2: ipfw show > 00100 220 19633 skipto 10000 ip from any to not 1.1.1.0/24 > 01000 14 1176 skipto tablearg ip from any to table(31) > 02000 2 168 deny ip from any to any > 02001 0 0 deny ip from any to any > 03000 12 1008 deny ip from any to any > 03001 0 0 deny ip from any to any > 10000 209 18549 count ip from any to any > 65535 1751 153792 allow ip from any to any > > > comments? I like it, FWIW. > + if (tablearg != 0) { > + rulenum = (u_int16_t)tablearg; Should we check that tablearg is < 64K before merrily casting? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 13:47:03 2008 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 938211065681; Tue, 19 Aug 2008 13:47:03 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9CF8FC08; Tue, 19 Aug 2008 13:47:03 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C09E273098; Tue, 19 Aug 2008 15:31:01 +0200 (CEST) Date: Tue, 19 Aug 2008 15:31:01 +0200 From: Luigi Rizzo To: Ian Smith Message-ID: <20080819133101.GA23276@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw add skipto tablearg.... 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, 19 Aug 2008 13:47:03 -0000 On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > On Thu, 31 Jul 2008, Julian Elischer wrote: ... > > ipfw add 1000 skipto tablearg ip from any to table(31) ... > > see attached patch... (hopefully not stripped) > > > > Of course it is hoped that the rules you are skipping to are nearby > > as it iterates through the rules following the skipto to find the > > target, > > Until $someone adds a direct skipto target jump at the virtual machine > code level - big recalc hit when adding/deleting rules/sets I suppose - > it's still the fastest way to get from a to b, where b > a you mean with tables-based skipto targets ? Because the regular skipto has been a constant-time op forever, even in ipfw1 i believe, invalidating the target cache on a change and recomputing it the fly at the first request. > Speaking of which, should ipfw whinge when asked to skip backwards, > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > and a local test months ago. right... but the error can only be reliably detected in the kernel, as the rule number is not always known when the rule is added. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 18:06:21 2008 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 9F342106566B for ; Tue, 19 Aug 2008 18:06:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id EFEC28FC12 for ; Tue, 19 Aug 2008 18:06:20 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id m7JI65q3042351; Wed, 20 Aug 2008 04:06:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 20 Aug 2008 04:06:05 +1000 (EST) From: Ian Smith To: Luigi Rizzo In-Reply-To: <20080819133101.GA23276@onelab2.iet.unipi.it> Message-ID: <20080820031409.V41971@sola.nimnet.asn.au> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw add skipto tablearg.... 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, 19 Aug 2008 18:06:21 -0000 On Tue, 19 Aug 2008, Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > > On Thu, 31 Jul 2008, Julian Elischer wrote: > ... > > > ipfw add 1000 skipto tablearg ip from any to table(31) > ... > > > see attached patch... (hopefully not stripped) > > > > > > Of course it is hoped that the rules you are skipping to are nearby > > > as it iterates through the rules following the skipto to find the > > > target, > > > > Until $someone adds a direct skipto target jump at the virtual machine > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > it's still the fastest way to get from a to b, where b > a > > you mean with tables-based skipto targets ? Because the regular > skipto has been a constant-time op forever, even in ipfw1 i believe, > invalidating the target cache on a change and recomputing it the > fly at the first request. Thanks; I'd completely missed the caching of skipto targets before, and it's all so well commented too. blushing, but glad for the good news. But yes I was pondering Julian's patch, which has to lookup_next_rule every time, and also Mike's bending of divert reentry rule number in ipfw-classifyd with similar intent, which also has to hunt forward in linear time for its target rule - or am I missing something else here? > > Speaking of which, should ipfw whinge when asked to skip backwards, > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > and a local test months ago. > > right... but the error can only be reliably detected in the kernel, > as the rule number is not always known when the rule is added. Yes I meant at run-time. On second thoughts, it'd be too easy a way to spam syslogd in the general case, but maybe reporting target < current rule for such dynamic forms of skipto might highlight config errors? I should STFU and resume lurking unless I can contribute code, I know. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 18:09:27 2008 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 EC2551065676 for ; Tue, 19 Aug 2008 18:09:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 22CCC8FC23 for ; Tue, 19 Aug 2008 18:09:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 38FDB2382; Tue, 19 Aug 2008 11:09:26 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B57A12D600D; Tue, 19 Aug 2008 11:09:25 -0700 (PDT) Message-ID: <48AB0C5C.8090404@elischer.org> Date: Tue, 19 Aug 2008 11:09:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Todor Genov References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> In-Reply-To: <48AA88B4.6040606@za.verizonbusiness.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing 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, 19 Aug 2008 18:09:27 -0000 Todor Genov wrote: > Hi Julian, > > Julian Elischer wrote: >> Todor Genov wrote: >>> Hi everyone, >>> >>> I may have found a routing bug relating to GRE tunnels. Could somebody >>> try and replicate this? >>> >>> As per the setup below GRE-encapsulated traffic to 194.31.254.148 >>> should be going out via tun1, but a tcpdump shows the traffic leaving >>> via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148 >>> goes out via tun1 as expected. >>> >>> Configuration: >>> FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008 >>> tun0 - PPPoE connection to ISP >>> tun1 - vpn connection to office PIX (via vpnc) >>> gre0 - GRE tunnel to machine sitting behind the PIX >>> >>> tun0: flags=8051 metric 0 mtu 1492 >>> inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00 >>> Opened by PID 509 >>> tun1: flags=8051 metric 0 mtu 1500 >>> inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40 >>> Opened by PID 984 >> Point to point interfaces really don't have netmasks. >> Otherwise it wouldn't be "Point to Point", it would be >> "multicast" like ethernet. >> >> There is really only one address at this end or the other end. >> If you want to say that there is a network at the other end >> then you really need to set a route for it. >> but it applies equally to all three of these p2p links. >> >> so, add a route: >> >> route add 92.168.254.0/24 92.168.254.1 > > The netmask for tun0 is automatically assigned by the ISP, and for tun1 > by the VPN server. The one for gre0 is a /30 in the connect scripts - I > must have changed it to /24 somewhere along the troubleshooting process > - it makes no difference to the end result. let me rephrase that.. p2p links do not support netmasks. That's all p2p links.. ppp, slip, tun, ng, gre, etc. If you what a virtual ethernet interface you may try tap(4) but you will need to have an appropriatly capable piece of software on the other end of the link. A p2p link doesn't take any notice of what you have written as netmask and it doesn't matter what your ISP has given you, or if you type /24 or /22 or /32. The point to point interface only knows about the ONE SINGLE ADDRESS on the other end of the link. If there is a network there, which that address is a part of, then it is up to YOU to add the route that allows packets to get there. > > The routing table does include routes to the /26 on tun1 and the /24 on > gre0. I have left them out as they are not relevant to the problem. The > troublesome route is the one to 194.31.154.148/32 > > Just noticed that the PtP address for tun1 looks incorrect - with that > netmask into account .64 is the network address. I'll look into that as > a possible cause. the netmask should not be taken into account because it is ignored. >> > > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 18:21:07 2008 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 9C1171065672; Tue, 19 Aug 2008 18:21:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 634F18FC08; Tue, 19 Aug 2008 18:21:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BA5687308B; Tue, 19 Aug 2008 20:23:37 +0200 (CEST) Date: Tue, 19 Aug 2008 20:23:37 +0200 From: Luigi Rizzo To: Ian Smith Message-ID: <20080819182337.GA25703@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080820031409.V41971@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw add skipto tablearg.... 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, 19 Aug 2008 18:21:07 -0000 On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: > On Tue, 19 Aug 2008, Luigi Rizzo wrote: > > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: ... > > > Until $someone adds a direct skipto target jump at the virtual machine > > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > > it's still the fastest way to get from a to b, where b > a > > > > you mean with tables-based skipto targets ? Because the regular > > skipto has been a constant-time op forever, even in ipfw1 i believe, > > invalidating the target cache on a change and recomputing it the > > fly at the first request. > > Thanks; I'd completely missed the caching of skipto targets before, and > it's all so well commented too. blushing, but glad for the good news. > > But yes I was pondering Julian's patch, which has to lookup_next_rule > every time, and also Mike's bending of divert reentry rule number in > ipfw-classifyd with similar intent, which also has to hunt forward in > linear time for its target rule - or am I missing something else here? well, you can use a hash table to support that. It shouldn't be so bad to implement, flow tables already use hash tables so one can reuse the same code. > > > Speaking of which, should ipfw whinge when asked to skip backwards, > > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > > and a local test months ago. > > > > right... but the error can only be reliably detected in the kernel, > > as the rule number is not always known when the rule is added. > > Yes I meant at run-time. On second thoughts, it'd be too easy a way to actually you can do it at insertion time, it's just that you cannot do it in userland as other checks before inserting the rule. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 18:38:04 2008 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 D3C5D1065673 for ; Tue, 19 Aug 2008 18:38:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id BD4228FC22 for ; Tue, 19 Aug 2008 18:38:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 326F22496; Tue, 19 Aug 2008 11:38:05 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3F56A2D6088; Tue, 19 Aug 2008 11:38:04 -0700 (PDT) Message-ID: <48AB1313.5080405@elischer.org> Date: Tue, 19 Aug 2008 11:38:11 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Luigi Rizzo References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> <20080819182337.GA25703@onelab2.iet.unipi.it> In-Reply-To: <20080819182337.GA25703@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org, Ian Smith Subject: Re: ipfw add skipto tablearg.... 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, 19 Aug 2008 18:38:05 -0000 Luigi Rizzo wrote: > On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: >> On Tue, 19 Aug 2008, Luigi Rizzo wrote: >> > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > ... >> > > Until $someone adds a direct skipto target jump at the virtual machine >> > > code level - big recalc hit when adding/deleting rules/sets I suppose - >> > > it's still the fastest way to get from a to b, where b > a >> > >> > you mean with tables-based skipto targets ? Because the regular >> > skipto has been a constant-time op forever, even in ipfw1 i believe, >> > invalidating the target cache on a change and recomputing it the >> > fly at the first request. >> >> Thanks; I'd completely missed the caching of skipto targets before, and >> it's all so well commented too. blushing, but glad for the good news. >> >> But yes I was pondering Julian's patch, which has to lookup_next_rule >> every time, and also Mike's bending of divert reentry rule number in >> ipfw-classifyd with similar intent, which also has to hunt forward in >> linear time for its target rule - or am I missing something else here? > > well, you can use a hash table to support that. It shouldn't be so bad > to implement, flow tables already use hash tables so one can reuse the same code. one COULD, but I know I use this feature only with a number (20 or less) following rules, each of which is a skipto itself to some further awat location...or a simple drop.. Shall we say we "leave it as an exercise for the reader" ? > >> > > Speaking of which, should ipfw whinge when asked to skip backwards, >> > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd >> > > and a local test months ago. >> > >> > right... but the error can only be reliably detected in the kernel, >> > as the rule number is not always known when the rule is added. >> >> Yes I meant at run-time. On second thoughts, it'd be too easy a way to > > actually you can do it at insertion time, it's just that you cannot > do it in userland as other checks before inserting the rule. > > cheers > luigi From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 18:39:21 2008 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 DA8AB1065684 for ; Tue, 19 Aug 2008 18:39:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id C47258FC1C for ; Tue, 19 Aug 2008 18:39:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3B6E424A9; Tue, 19 Aug 2008 11:39:22 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3DF192D600F; Tue, 19 Aug 2008 11:39:21 -0700 (PDT) Message-ID: <48AB1360.7060908@elischer.org> Date: Tue, 19 Aug 2008 11:39:28 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Luigi Rizzo References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> <20080819182337.GA25703@onelab2.iet.unipi.it> In-Reply-To: <20080819182337.GA25703@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org, Ian Smith Subject: Re: ipfw add skipto tablearg.... 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, 19 Aug 2008 18:39:21 -0000 Luigi Rizzo wrote: > On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: >> On Tue, 19 Aug 2008, Luigi Rizzo wrote: >> > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > ... >> > > Until $someone adds a direct skipto target jump at the virtual machine >> > > code level - big recalc hit when adding/deleting rules/sets I suppose - >> > > it's still the fastest way to get from a to b, where b > a >> > >> > you mean with tables-based skipto targets ? Because the regular >> > skipto has been a constant-time op forever, even in ipfw1 i believe, >> > invalidating the target cache on a change and recomputing it the >> > fly at the first request. >> >> Thanks; I'd completely missed the caching of skipto targets before, and >> it's all so well commented too. blushing, but glad for the good news. >> >> But yes I was pondering Julian's patch, which has to lookup_next_rule >> every time, and also Mike's bending of divert reentry rule number in >> ipfw-classifyd with similar intent, which also has to hunt forward in >> linear time for its target rule - or am I missing something else here? > > well, you can use a hash table to support that. It shouldn't be so bad > to implement, flow tables already use hash tables so one can reuse the same code. > >> > > Speaking of which, should ipfw whinge when asked to skip backwards, >> > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd >> > > and a local test months ago. >> > >> > right... but the error can only be reliably detected in the kernel, >> > as the rule number is not always known when the rule is added. >> >> Yes I meant at run-time. On second thoughts, it'd be too easy a way to > > actually you can do it at insertion time, it's just that you cannot > do it in userland as other checks before inserting the rule. you can't do it at insertion time if it's a tablearg style skipto.. but such a rule will simply continue at the next rule as if it did not match. > > cheers > luigi From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 20:56:06 2008 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 82E541065673 for ; Tue, 19 Aug 2008 20:56:06 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from smtpout2.uunet.co.za (smtpout2.uunet.co.za [196.7.142.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7C68FC16 for ; Tue, 19 Aug 2008 20:56:00 +0000 (UTC) (envelope-from todor.genov@za.verizonbusiness.com) Received: from 41-195-81-86.access.uunet.co.za ([41.195.81.86] helo=lap-todor.subnet.co.za) by smtp.uunet.co.za with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1KVYFD-000EOu-9I; Tue, 19 Aug 2008 22:55:59 +0200 Message-ID: <48AB3358.4040709@za.verizonbusiness.com> Date: Tue, 19 Aug 2008 22:55:52 +0200 From: Todor Genov User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Julian Elischer References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> <48AB0C5C.8090404@elischer.org> In-Reply-To: <48AB0C5C.8090404@elischer.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing 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, 19 Aug 2008 20:56:06 -0000 Julian Elischer wrote: > Todor Genov wrote: >> Hi Julian, > let me rephrase that.. > p2p links do not support netmasks. That's all p2p links.. ppp, slip, > tun, ng, gre, etc. > > If you what a virtual ethernet interface you may try tap(4) but you will > need to have an appropriatly capable piece of software on the > other end of the link. > > > A p2p link doesn't take any notice of what you have written as netmask > and it doesn't matter what your ISP has given you, or if you > type /24 or /22 or /32. > > The point to point interface only knows about the ONE SINGLE ADDRESS > on the other end of the link. > If there is a network there, which that address is a part of, then > it is up to YOU to add the route that allows packets to get there. > > This is fully understood and taken into account. For all intended purposes I treat the tunnels as a /30 subnets (despite what ifconfig says) and as per the routing table which I pasted destinations which need to be reached over those tunnels have static routes specified: default 41.142.82.1 UGS 1 1365 tun0 41.142.82.1 41.142.82.37 UGH 1 0 tun0 192.168.254.1 192.168.254.2 UH 0 3 gre0 194.31.137.64 194.31.137.70 UH 1 0 tun1 194.31.154.148 194.31.137.64 UGS 0 0 tun1 ^^^ this is the other end of the GRE tunnel From this routing table alone there is no way that traffic destined to 196.31.154.148 should exit via tun0, but GRE traffic to 194.31.154.148 does. >> >> The routing table does include routes to the /26 on tun1 and the /24 on >> gre0. I have left them out as they are not relevant to the problem. The >> troublesome route is the one to 194.31.154.148/32 >> >> Just noticed that the PtP address for tun1 looks incorrect - with that >> netmask into account .64 is the network address. I'll look into that as >> a possible cause. > > the netmask should not be taken into account because it is ignored. I was referring to static routes, not interface addressing in the above. Those routes also exist in my routing table, even though I omitted them in my original paste 192.168.254.0/24 192.168.254.1 UGS 0 0 gre0 196.31.137.64/26 196.30.157.65 UGS 0 0 tun1 (which i omitted in my original paste). Both those routes are irrelevant as the GRE endpoint is not these subnets - it's merely reachable via tun1 -- Regards, Todor Genov Systems Operations Verizon Business South Africa (Pty) Ltd todor.genov@za.verizonbusiness.com Tel: +27 11 235 6500 Fax: 086 692 0543 From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 21:07:52 2008 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 543EB1065673 for ; Tue, 19 Aug 2008 21:07:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 3A73E8FC1F for ; Tue, 19 Aug 2008 21:07:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id D9742249E; Tue, 19 Aug 2008 14:07:52 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C5EEA2D60AC; Tue, 19 Aug 2008 14:07:51 -0700 (PDT) Message-ID: <48AB362E.2060409@elischer.org> Date: Tue, 19 Aug 2008 14:07:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Todor Genov References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> <48AB0C5C.8090404@elischer.org> <48AB3358.4040709@za.verizonbusiness.com> In-Reply-To: <48AB3358.4040709@za.verizonbusiness.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing 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, 19 Aug 2008 21:07:52 -0000 Todor Genov wrote: > Julian Elischer wrote: >> Todor Genov wrote: >>> Hi Julian, >> let me rephrase that.. >> p2p links do not support netmasks. That's all p2p links.. ppp, slip, >> tun, ng, gre, etc. >> >> If you what a virtual ethernet interface you may try tap(4) but you will >> need to have an appropriatly capable piece of software on the >> other end of the link. >> >> >> A p2p link doesn't take any notice of what you have written as netmask >> and it doesn't matter what your ISP has given you, or if you >> type /24 or /22 or /32. >> >> The point to point interface only knows about the ONE SINGLE ADDRESS >> on the other end of the link. >> If there is a network there, which that address is a part of, then >> it is up to YOU to add the route that allows packets to get there. >> >> > > This is fully understood and taken into account. > > For all intended purposes I treat the tunnels as a /30 subnets there you go again... tunnels are NOT SUBNETS OF ANY TYPE the two ends can be in completely different address spaces.. one can be 10.2.2.2 and the other end can be 192.168.2.42 there is NO SUBNETTING on point to point interfaces.. > (despite what ifconfig says) and as per the routing table which I pasted > destinations which need to be reached over those tunnels have static > routes specified: > > default 41.142.82.1 UGS 1 1365 tun0 > 41.142.82.1 41.142.82.37 UGH 1 0 tun0 > 192.168.254.1 192.168.254.2 UH 0 3 gre0 > 194.31.137.64 194.31.137.70 UH 1 0 tun1 > 194.31.154.148 194.31.137.64 UGS 0 0 tun1 > ^^^ this is the other end of the GRE tunnel > > From this routing table alone there is no way that traffic destined to > 196.31.154.148 should exit via tun0, but GRE traffic to 194.31.154.148 does. ^^^^ 196? I've deleted you original mail.. sorry.. Resend me privately the output of ifconfig -a and the FULL netstat -r output.. > > >>> The routing table does include routes to the /26 on tun1 and the /24 on >>> gre0. I have left them out as they are not relevant to the problem. The >>> troublesome route is the one to 194.31.154.148/32 >>> >>> Just noticed that the PtP address for tun1 looks incorrect - with that >>> netmask into account .64 is the network address. I'll look into that as >>> a possible cause. >> the netmask should not be taken into account because it is ignored. > > I was referring to static routes, not interface addressing in the above. so why are you setting netmasks. actually I see a bug, which is that ifconfig -a shows a netmask no matter if it makes sense.. > > Those routes also exist in my routing table, even though I omitted them > in my original paste > > 192.168.254.0/24 192.168.254.1 UGS 0 0 gre0 > 196.31.137.64/26 196.30.157.65 UGS 0 0 tun1 > (which i omitted in my original paste). > > Both those routes are irrelevant as the GRE endpoint is not these > subnets - it's merely reachable via tun1 > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 22:31:16 2008 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 C73A41065674 for ; Tue, 19 Aug 2008 22:31:16 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 917F18FC19 for ; Tue, 19 Aug 2008 22:31:16 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <48AB4562.2070203@intersonic.se> Date: Wed, 20 Aug 2008 00:12:50 +0200 From: Per olof Ljungmark User-Agent: Thunderbird 2.0.0.16 (X11/20080812) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: 7-STABLE lock order reversal 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, 19 Aug 2008 22:31:16 -0000 (Reposting to -net as suggested by Kris.) 7.0-STABLE #0: Tue Aug 19 20:39:48 CEST 2008 After system update from June 12 sources to Aug 12 I have seen frequent lockups during network operations. Compiled debugging kernel and got the below during boot. Should I open a PR? Suggestions welcome. Thanks. Aug 19 22:12:47 kreutzman kernel: uhid0: on uhub5 Aug 19 22:12:47 kreutzman kernel: lock order reversal: Aug 19 22:12:47 kreutzman kernel: 1st 0xc7077a14 rtentry (rtentry) @ /usr/src/sys/net/route.c:328 Aug 19 22:12:47 kreutzman kernel: 2nd 0xc6eee07c radix node head (radix node head) @ /usr/src/sys/net/route.c:879 Aug 19 22:12:47 kreutzman kernel: KDB: stack backtrace: Aug 19 22:12:47 kreutzman kernel: db_trace_self_wrapper(c0af8084,e71f5a4c,c07a777e,c0afa653,c6eee07c,...) at db_trace_self_wrapper+0x26 Aug 19 22:12:47 kreutzman kernel: kdb_backtrace(c0afa653,c6eee07c,c0afa6b4,c0afa6b4,c0b031c2,...) at kdb_backtrace+0x29 Aug 19 22:12:47 kreutzman kernel: witness_checkorder(c6eee07c,9,c0b031c2,36f,c6c5f2b8,...) at witness_checkorder+0x6de Aug 19 22:12:47 kreutzman kernel: _mtx_lock_flags(c6eee07c,0,c0b031c2,36f,c0af3ca5,...) at _mtx_lock_flags+0xbc Aug 19 22:12:47 kreutzman kernel: rtrequest1_fib(1,e71f5ae8,e71f5b18,0,ce,...) at rtrequest1_fib+0x82 Aug 19 22:12:47 kreutzman kernel: rtredirect_fib(e71f5bb8,e71f5ba8,0,16,e71f5b98,...) at rtredirect_fib+0x13d Aug 19 22:12:47 kreutzman kernel: in_rtredirect(e71f5bb8,e71f5ba8,0,6,e71f5b98,...) at in_rtredirect+0x34 Aug 19 22:12:47 kreutzman kernel: icmp_input(c7081d00,14,80246,c0bf53c0,e71f5c08,...) at icmp_input+0x526 Aug 19 22:12:47 kreutzman kernel: ip_input(c7081d00,14e,800,c6c89400,800,...) at ip_input+0x650 Aug 19 22:12:47 kreutzman kernel: netisr_dispatch(2,c7081d00,10,3,0,...) at netisr_dispatch+0x73 Aug 19 22:12:47 kreutzman kernel: ether_demux(c6c89400,c7081d00,3,0,3,...) at ether_demux+0x1f1 Aug 19 22:12:47 kreutzman kernel: ether_input(c6c89400,c7081d00,c0ac0c3e,c57,c6c89400,...) at ether_input+0x3d9 Aug 19 22:12:47 kreutzman kernel: bge_intr(c6c90000,0,c0af18b8,442,c6b334e8,...) at bge_intr+0x7ca Aug 19 22:12:47 kreutzman kernel: ithread_loop(c6c946d0,e71f5d38,c0af1622,305,c6c97ad0,...) at ithread_loop+0x1c5 Aug 19 22:12:47 kreutzman kernel: fork_exit(c074ce40,c6c946d0,e71f5d38) at fork_exit+0xb8 Aug 19 22:12:47 kreutzman kernel: fork_trampoline() at fork_trampoline+0x8 Aug 19 22:12:47 kreutzman kernel: --- trap 0, eip = 0, esp = 0xe71f5d70, ebp = 0 --- Aug 19 22:12:47 kreutzman kernel: Expensive timeout(9) function: 0xc068b7f0(0xc0c82f00) 0.004460343 s Aug 19 22:12:47 kreutzman savecore: no dumps found From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 02:45:24 2008 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 E2989106567E for ; Wed, 20 Aug 2008 02:45:24 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id 682578FC17 for ; Wed, 20 Aug 2008 02:45:22 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 84563 invoked by uid 1008); 20 Aug 2008 02:26:15 -0000 Received: from unknown (HELO ?10.0.1.10?) (200.243.216.68) by mail.mastercabo.com.br with SMTP; 20 Aug 2008 02:26:15 -0000 Message-ID: <48AB80BD.0@yan.com.br> Date: Tue, 19 Aug 2008 23:26:05 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: <48918DB5.7020201@wubethiopia.com> <4891CD13.20600@freebsdbrasil.com.br> <48922E9D.1020507@elischer.org> <4893328C.2040105@freebsdbrasil.com.br> <4894447C.3000800@wubethiopia.com> <48945A79.50300@wubethiopia.com> <9a542da30808081626y7ce1fe58k483494a6cdbfae60@mail.gmail.com> In-Reply-To: <9a542da30808081626y7ce1fe58k483494a6cdbfae60@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Mike Makonnen , freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2008 02:45:25 -0000 Ermal Luçi escreveu: > On Sat, Aug 2, 2008 at 3:00 PM, Mike Makonnen wrote: > >> Mike Makonnen wrote: >> >>> Patrick Tracanelli wrote: >>> >>>> To let you know of my current (real world) tests: >>>> >>>> - Wireless Internet Provider 1: >>>> - 4Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> - Classifying 100Mbit/s of dump over ssh >>>> >>>> Results in: >>>> No latency added, very low CPU usage, no packets dropping. >>>> >>>> - Wireless ISP 2: >>>> - 21 Mbit/s of Internet Traffic >>>> - Classifying default protocols + soulseek + ssh >>>> >>>> Results in: >>>> No tcp or udp traffic at all; everything that gets diverted never >>>> comes out of the divert socket, and ipfw-classifyd logs >>>> >>>> Aug 1 12:07:35 ourofino last message repeated 58 times >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent >>>> (rule 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey (rule >>>> 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack (rule >>>> 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella (rule >>>> 1000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek (rule >>>> 50000) >>>> Aug 1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh (rule >>>> 50000) >>>> Aug 1 12:18:28 ourofino ipfw-classifyd: unable to write to divert >>>> socket: Operation not permitted >>>> Aug 1 12:18:50 ourofino last message repeated 90 times >>>> >>> Hmmm... this part means that the call to sendto(2) to write the packet >>> back into network stack failed. This explains why you are not seein g any >>> traffic comming back out of the divert socket, but I don't see why it would >>> suddenly fail with a permission error. Could this be a kernel bug? >>> >>>> Aug 1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full >>>> Aug 1 12:19:11 ourofino last message repeated 94 times >>>> >>>> Raised queue len a lot (up to 40960), when the application starts it uses >>>> up to 25% CPU and a second after that, CPU usage gets lower the 0.1%. >>>> >>> This looks like a deadlock. If it weren't able to process packets fast >>> enough the cpu usage should be high even as it's spewing "packet dropped" >>> messages. Can you send me some more information like memory usage and the >>> firewall script you are using? How much of the 21Mbits/s of traffic is P2P? >>> If you reduce the number of protocols you are trying to match against does >>> the behavior change? Using netstat -w1 -I can you tell me how >>> many packets per second we're talking about for 4Mbits/s and 21Mbit/s? Also, >>> the timestamps from the log file seem to show that the daemon is running for >>> approx. 34 sec. before the first "unable to write to write to divert socket" >>> message. Is it passing traffic during this time? Thanks. >>> >>> I've uploaded a newer version. Can you try that also please. It includes: >>> o SIGHUP forces it to re-read its configuration file >>> o rc.d script >>> o minor optimization (calls pthread_cond_signal with the mutex unlocked) >>> o code cleanup >>> >>> Also, for your convenience I have attached a patch against the earlier >>> version that removes a debugging printf that should remove spammage to your >>> log files (the current version has it removed already). >>> >>> >> Ooops, a few minutes after I sent this email I found a couple of bugs (one >> major, and one minor). They were in the original tarball as well as the >> newer one I uploaded earlier today. I've uploaded a fixed version of the >> code. Can you try that instead please. >> >> Also, to help track down performance issues I've modified the Makefile to >> build a profiled version of the application so you can use gprof(1) to >> figure out where any problems lie. >> >> > > Does this sound about right for implementing the GC and implementing syntax as > $protocol = dnpipe 20 > $protocol2 = dnqueue 30 > it has some extra goos for pf(4) and altq(4) > $protocol3 = queue $queue name > $protocol4 = tag TAGNAME > $protocol5 = action block > > It adds 2 new options -e seconds for seconds before a flow is > considered expired and -n #packets proccessed before kicking the GC. > > --- classifyd_old.c 2008-08-09 00:33:04.000000000 +0000 > +++ classifyd.c 2008-08-09 00:33:34.000000000 +0000 > @@ -28,13 +28,17 @@ > > #include > #include > +#include > +#include > > +#include > #include > #include > #include > #include > #include > #include > +#include > > #include > #include > @@ -53,6 +57,7 @@ > #include > > #include "hashtable.h" > +#include "hashtable_private.h" > #include "pathnames.h" > #include "protocols.h" > > @@ -94,6 +99,7 @@ > uint32_t if_datalen; /* length in bytes of if_data */ > uint16_t if_pktcount; /* number of packets concatenated */ > uint16_t if_fwrule; /* ipfw(4) rule associated with flow */ > + time_t expire; /* flow expire time */ > }; > > /* > @@ -126,7 +132,7 @@ > static struct ic_queue outQ; > > /* divert(4) socket */ > -static int dvtS; > +static int dvtS = 0; > > /* config file path */ > static const char *conf = IC_CONFIG_PATH; > @@ -137,12 +143,25 @@ > /* List of protocols available to the system */ > struct ic_protocols *fp; > > +/* Our hashtables */ > +struct hashtable *sh = NULL, > + *th = NULL, > + *uh = NULL; > + > +/* signaled to kick garbage collector */ > +static pthread_cond_t gq_condvar; > + > +/* number of packets before kicking garbage collector */ > +static unsigned int npackets = 250; > + > +static time_t time_expire = 40; /* 40 seconds */ > /* > * Forward function declarations. > */ > void *classify_pthread(void *); > void *read_pthread(void *); > void *write_pthread(void *); > +void *garbage_pthread(void *); > static int equalkeys(void *, void *); > static unsigned int hashfromkey(void *); > static void test_re(void); > @@ -155,7 +174,7 @@ > { > struct sockaddr_in addr; > struct sigaction sa; > - pthread_t classifytd, readtd, writetd; > + pthread_t classifytd, readtd, writetd, garbagectd; > const char *errstr; > long long num; > uint16_t port, qmaxsz; > @@ -164,13 +183,27 @@ > tflag = 0; > port = IC_DPORT; > qmaxsz = IC_QMAXSZ; > - while ((ch = getopt(argc, argv, "htc:P:p:q:")) != -1) { > + while ((ch = getopt(argc, argv, "n:e:htc:P:p:q:")) != -1) { > switch(ch) { > case 'c': > conf = strdup(optarg); > if (conf == NULL) > err(EX_TEMPFAIL, "config file path"); > break; > + case 'e': > + num = strtonum((const char *)optarg, 1, 400, &errstr); > + if (num == 0 && errstr != NULL) { > + errx(EX_USAGE, "invalud expire seconds: %s", errstr); > + } > + time_expire = (time_t)num; > + break; > + case 'n': > + num = strtonum((const char *)optarg, 1, > 65535, &errstr); > + if (num == 0 && errstr != NULL) { > + errx(EX_USAGE, "invalud expire > seconds: %s", errstr); > + } > + npackets = (unsigned int)num; > + break; > case 'P': > protoDir = strdup(optarg); > if (protoDir == NULL) > @@ -230,6 +263,9 @@ > error = pthread_cond_init(&outQ.fq_condvar, NULL); > if (error != 0) > err(EX_OSERR, "unable to initialize output queue condvar"); > + error = pthread_cond_init(&gq_condvar, NULL); > + if (error != 0) > + err(EX_OSERR, "unable to initialize garbage collector > condvar"); > > /* > * Create and bind the divert(4) socket. > @@ -276,32 +312,80 @@ > if (error == -1) > err(EX_OSERR, "unable to set signal handler"); > > + /* > + * There are 3 tables: udp, tcp, and tcp syn. > + * The tcp syn table tracks connections for which a > + * SYN packet has been sent but no reply has been returned > + * yet. Once the SYN ACK reply is detected it is moved to > + * the regular tcp connection tracking table. > + */ > + sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > + if (sh == NULL) { > + syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); > + error = EX_SOFTWARE; > + goto cleanup; > + } > + th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > + if (th == NULL) { > + syslog(LOG_ERR, "unable to create TCP tracking table"); > + error = EX_SOFTWARE; > + goto cleanup; > + } > + uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > + if (uh == NULL) { > + syslog(LOG_ERR, "unable to create UDP tracking table"); > + error = EX_SOFTWARE; > + goto cleanup; > + } > + > /* > * Create the various threads. > */ > error = pthread_create(&readtd, NULL, read_pthread, NULL); > - if (error != 0) > - err(EX_OSERR, "unable to create reader thread"); > + if (error != 0) { > + syslog(LOG_ERR, "unable to create reader thread"); > + error = EX_OSERR; > + goto cleanup; > + } > error = pthread_create(&classifytd, NULL, classify_pthread, NULL); > - if (error != 0) > - err(EX_OSERR, "unable to create classifier thread"); > + if (error != 0) { > + syslog(LOG_ERR, "unable to create classifier thread"); > + error = EX_OSERR; > + goto cleanup; > + } > error = pthread_create(&writetd, NULL, write_pthread, NULL); > - if (error != 0) > - err(EX_OSERR, "unable to create writer thread"); > - > + if (error != 0) { > + syslog(LOG_ERR, "unable to create writer thread"); > + error = EX_OSERR; > + goto cleanup; > + } > + error = pthread_create(&garbagectd, NULL, garbage_pthread, NULL); > + if (error != 0) { > + syslog(LOG_ERR, "unable to create garbage collect thread"); > + error = EX_OSERR; > + goto cleanup; > + } > /* > * Wait for our threads to exit. > */ > pthread_join(readtd, NULL); > pthread_join(classifytd, NULL); > pthread_join(writetd, NULL); > - > + pthread_join(garbagectd, NULL); > /* > * Cleanup > */ > - close(dvtS); > +cleanup: > + if (dvtS > 0) > + close(dvtS); > + if (sh != NULL) > + hashtable_destroy(sh, 1); > + if (th != NULL) > + hashtable_destroy(th, 1); > + if (uh != NULL) > + hashtable_destroy(uh, 1); > > - return (0); > + return (error); > } > > void * > @@ -310,6 +394,7 @@ > struct ic_pkt *pkt; > struct ip *ipp; > int len; > + unsigned int pcktcnt = 0; > > while (1) { > pkt = (struct ic_pkt *)malloc(sizeof(struct ic_pkt)); > @@ -353,6 +438,10 @@ > STAILQ_INSERT_HEAD(&inQ.fq_pkthead, pkt, fp_link); > inQ.fq_size++; > pthread_mutex_unlock(&inQ.fq_mtx); > + if (++pcktcnt > npackets) { > + pcktcnt = 0; > + pthread_cond_signal(&gq_condvar); > + } > pthread_cond_signal(&inQ.fq_condvar); > } > > @@ -420,39 +509,19 @@ > struct tcphdr *tcp; > struct udphdr *udp; > struct ic_pkt *pkt; > - struct hashtable *sh, *th, *uh; > struct protocol *proto; > + struct timeval tv; > regmatch_t pmatch; > u_char *data, *payload; > uint16_t trycount; > int datalen, error; > > - /* > - * There are 3 tables: udp, tcp, and tcp syn. > - * The tcp syn table tracks connections for which a > - * SYN packet has been sent but no reply has been returned > - * yet. Once the SYN ACK reply is detected it is moved to > - * the regular tcp connection tracking table. > - */ > - sh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > - if (sh == NULL) { > - syslog(LOG_ERR, "unable to create TCP (SYN) tracking table"); > - exit(EX_SOFTWARE); > - } > - th = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > - if (th == NULL) { > - syslog(LOG_ERR, "unable to create TCP tracking table"); > - exit(EX_SOFTWARE); > - } > - uh = create_hashtable(IC_HASHSZ, hashfromkey, equalkeys); > - if (uh == NULL) { > - syslog(LOG_ERR, "unable to create UDP tracking table"); > - exit(EX_SOFTWARE); > - } > - > flow = NULL; > key = NULL; > while(1) { > + while(gettimeofday(&tv, NULL) != 0) > + ; > + > pthread_mutex_lock(&inQ.fq_mtx); > pkt = STAILQ_LAST(&inQ.fq_pkthead, ic_pkt, fp_link); > while (pkt == NULL) { > @@ -528,6 +597,8 @@ > free(pkt); > continue; > } > + > + flow->expire = tv.tv_sec; > goto enqueue; > /* > * Handle session tear-down. > @@ -583,8 +654,11 @@ > * collecting IC_PKTMAXMATCH packets, just pass it through. > */ > } else if (flow->if_pktcount >= IC_PKTMAXMATCH && > - flow->if_fwrule == 0) > + flow->if_fwrule == 0) { > + flow->expire = tv.tv_sec; > goto enqueue; > + } > + flow->expire = tv.tv_sec; > goto classify; > } > > @@ -630,6 +704,7 @@ > free(pkt); > continue; > } > + flow->expire = tv.tv_sec; > goto classify; > } > > @@ -688,6 +763,7 @@ > flow->if_datalen = datalen; > flow->if_pktcount = 1; > flow->if_fwrule = 0; > + flow->expire = tv.tv_sec; > if (hashtable_insert(uh, (void *)key, (void *)flow) == 0) { > syslog(LOG_WARNING, > "packet dropped: unable to insert into table"); > @@ -715,19 +791,26 @@ > flow->if_data = data; > flow->if_datalen += datalen; > flow->if_pktcount++; > + flow->expire = tv.tv_sec; > /* > * If we haven't been able to classify this flow after > * collecting IC_PKTMAXMATCH packets, just pass it through. > */ > } else if (flow->if_pktcount >= IC_PKTMAXMATCH && > - flow->if_fwrule == 0) > + flow->if_fwrule == 0) { > + flow->expire = tv.tv_sec; > goto enqueue; > + } > } else > /* Not an TCP or UDP packet. */ > goto enqueue; > > classify: > - assert(flow != NULL); > + if (flow == NULL) { > + syslog(LOG_ERR, "flow is null argghhhhhhh"); > + goto enqueue; > + } > + //assert(flow != NULL); > > /* > * Inform divert(4) what rule to send it to by > @@ -823,6 +906,80 @@ > return (NULL); > } > > +void * > +garbage_pthread(void *arg __unused) > +{ > + char errbuf[LINE_MAX]; > + struct entry *e, *f; > + unsigned int i, flows_expired, error; > + struct timeval tv; > + > + while (1) { > + flows_expired = 0; > + while (gettimeofday(&tv, NULL) != 0) > + ; > + tv.tv_sec -= time_expire; > + > + pthread_mutex_lock(&inQ.fq_mtx); > + error = pthread_cond_wait(&gq_condvar, &inQ.fq_mtx); > + if (error != 0) { > + strerror_r(error, errbuf, sizeof(errbuf)); > + syslog(EX_OSERR, "unable to wait on garbage > collection: %s", > + errbuf); > + exit(EX_OSERR); > + } > + > + for (i = 0; i < sh->tablelength; i++) { > + e = sh->table[i]; > + while (e != NULL) { > + f = e; e = e->next; > + if (((struct ip_flow *)f->v)->expire < tv.tv_sec) { > + freekey(f->k); > + sh->entrycount--; > + if (f->v != NULL) > + free(f->v); > + free(f); > + flows_expired++; > + } > + } > + } > + for (i = 0; i < th->tablelength; i++) { > + e = th->table[i]; > + while (e != NULL) { > + f = e; e = e->next; > + if (((struct ip_flow *)f->v)->expire > < tv.tv_sec) { > + freekey(f->k); > + th->entrycount--; > + if (f->v != NULL) > + free(f->v); > + free(f); > + flows_expired++; > + } > + } > + } > + for (i = 0; i < uh->tablelength; i++) { > + e = uh->table[i]; > + while (e != NULL) { > + f = e; e = e->next; > + if (((struct ip_flow *)f->v)->expire > < tv.tv_sec) { > + freekey(f->k); > + uh->entrycount--; > + if (f->v != NULL) > + free(f->v); > + free(f); > + flows_expired++; > + } > + } > + } > + > + pthread_mutex_unlock(&inQ.fq_mtx); > + > + syslog(LOG_WARNING, "expired %u flows", flows_expired); > + } > + > + return (NULL); > +} > + > /* > * NOTE: The protocol list (plist) passed as an argument is a global > * variable. It is accessed from 3 functions: classify_pthread, > @@ -840,12 +997,20 @@ > static int > read_config(const char *file, struct ic_protocols *plist) > { > + enum { bufsize = 2048 }; > struct protocol *proto; > properties props; > - const char *errmsg, *name, *value; > - int fd; > + const char *errmsg, *name; > + char *value; > + int fd, fdpf; > uint16_t rule; > + char **ap, *argv[bufsize]; > > + fdpf = open("/dev/pf", O_RDONLY); > + if (fdpf == -1) { > + syslog(LOG_ERR, "unable to open /dev/pf"); > + return (EX_OSERR); > + } > fd = open(file, O_RDONLY); > if (fd == -1) { > syslog(LOG_ERR, "unable to open configuration file"); > @@ -863,10 +1028,48 @@ > /* Do not match traffic against this pattern */ > if (value == NULL) > continue; > - rule = strtonum(value, 1, 65535, &errmsg); > - if (rule == 0) { > + for (ap = argv; (*ap = strsep(&value, " \t")) != NULL;) > + if (**ap != '\0') > + if (++ap >= &argv[bufsize]) > + break; > + if (!strncmp(argv[0], "queue", strlen("queue"))) { > + if (ioctl(fdpf, DIOCGETNAMEDALTQ, &rule)) { > + syslog(LOG_WARNING, > + "could not get ALTQ translation for" > + " queue %s", argv[1]); > + continue; > + } > + if (rule == 0) { > + syslog(LOG_WARNING, > + "queue %s does not exists!", argv[1]); > + continue; > + } > + } else if (!strncmp(argv[0], "dnqueue", strlen("dnqueue"))) > + rule = strtonum(argv[1], 1, 65535, &errmsg); > + else if (!strncmp(argv[0], "dnpipe", strlen("dnpipe"))) > + rule = strtonum(argv[1], 1, 65535, &errmsg); > + else if (!strncmp(argv[0], "tag", strlen("tag"))) { > + if (ioctl(fdpf, DIOCGETNAMEDTAG, &rule)) { > + syslog(LOG_WARNING, > + "could not get tag translation for" > + " queue %s", argv[1]); > + continue; > + } > + if (rule == 0) { > + syslog(LOG_WARNING, > + "tag %s does not exists!", argv[1]); > + continue; > + } > + } else if (!strncmp(argv[0], "action", strlen("action"))) { > + if (strncmp(argv[1], "block", strlen("block"))) > + rule = PF_DROP; > + else if (strncmp(argv[1], "allow", strlen("allow"))) > + rule = PF_PASS; > + else > + continue; > + } else { > syslog(LOG_WARNING, > - "invalid rule number for %s protocol: %s", > + "invalid action specified for %s protocol: %s", > proto->p_name, errmsg); > continue; > } > @@ -953,10 +1156,14 @@ > static void > usage(const char *arg0) > { > - printf("usage: %s [-h] [-c file] [-p port] [-P dir] [-q length]\n", > basename(arg0)); > + printf("usage: %s [-h] [-c file] [-e seconds] [-n packets] " > + "[-p port] [-P dir] [-q length]\n", basename(arg0)); > printf("usage: %s -t -P dir\n", basename(arg0)); > printf( " -c file : path to configuration file\n" > + " -e secs : number of seconds before a flow is expired\n" > " -h : this help screen\n" > + " -n packets: number of packets before the garbage collector" > + " tries to expire flows\n" > " -P dir : directory containing protocol patterns\n" > " -p port : port number of divert socket\n" > " -q length : max length (in packets) of in/out queues\n" > > Some progress in solution of presented problems ? -- Daniel From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 07:11:25 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 692B51065685 for ; Wed, 20 Aug 2008 07:11:25 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id E93A88FC1D for ; Wed, 20 Aug 2008 07:11:24 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so459490fgb.35 for ; Wed, 20 Aug 2008 00:11:23 -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:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=A5JjR/CxlPzEUgR2wTyOMNpGF5j4Nuv+/2SryAVo0I4=; b=qo31cRhjAxvGPBv9R/2IA9JNStwh8B6eQmEQxwdp1ciIigCdiMAbRjLOWqbE+tHZec iI9NVhePLZllymnU3MZWpi28CE6F/cZZZBqOzfQRY/kCfl79CwX91cvGMnwFc5qZ5Ujd SPaTANYWIcTl9+oPFB1VzkFN48uGgsbXaRiZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=dkMF+i/YIh6Oe4Pm4S2hNI/kZVjyTjsGs+6RifvilOVr7XnQIEx/LakbPrcUsMTQI1 FRqEVNKs7qz4gjS+la9WsZL+9vvqapONF2rynlqEbBFgAtBkh7T4YZcQ1Ql2CeFLXyGf 4fqUaGzSrRJtORY+9Wno+I0ofg7EVD9H1srqs= Received: by 10.86.71.1 with SMTP id t1mr6300343fga.36.1219214843680; Tue, 19 Aug 2008 23:47:23 -0700 (PDT) Received: by 10.86.62.14 with HTTP; Tue, 19 Aug 2008 23:47:23 -0700 (PDT) Message-ID: <7d6fde3d0808192347y65d1f21egf831dc18e264c510@mail.gmail.com> Date: Tue, 19 Aug 2008 23:47:23 -0700 From: "Garrett Cooper" To: pyunyh@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: net@freebsd.org Subject: Issues (again) with msk driver on 8-CURRENT amd64 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, 20 Aug 2008 07:11:25 -0000 Hi Pyun! I know it's been a while since I responded, but after reinstalling my system recently I noticed that the issue I mentioned almost a year ago (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) with my Marvell chipset card has once again returned. In the interim I was using x86, and I didn't suffer from any of the issues I have again on x64, and I was using XP x64 but now I've switched over to Vista x64 on my client box. Subsequently, the only thing that's really changed on my system is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). I'm using the 7-RELENG kernel right now (and not really enjoying it, but it works -- yay?), but I'd like to help resolve the issue with msk under CURRENT with x64 and my chipset. Standing by awaiting marching orders with tcpdump, netcat, and pciconf at my side to help debug the issue :). Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 07:14:34 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14228106564A for ; Wed, 20 Aug 2008 07:14:34 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 998B68FC12 for ; Wed, 20 Aug 2008 07:14:33 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so460700fgb.35 for ; Wed, 20 Aug 2008 00:14:32 -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:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=A5JjR/CxlPzEUgR2wTyOMNpGF5j4Nuv+/2SryAVo0I4=; b=QYjflRJ50B9+lqWz1IJcsrMA7orLssyZllsgRXYDa3cz6YIZG2IPW3I7CAsBG4t2O5 8OssAsUF/jJ/yXcXaPSLb+jvFOqWjodAaQNJpsJcbSmqOKQDdA6FOYQpUvXqsw3oZHH0 brenVnUmj3N9wZ6EWuimnqepJhT5XpLBS1mio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Nok8BMQKEI5DcG0Y78rKKj9zQ83Y9SiMxQg30SiI0vIKD6xrDPQropxh2Ej8jQW6pC KCuP3BgL+Ih9HKsY/JPksZ5t21R0aNllY8eYUiU6D86Rsm4iXzylcOVCgc6elFyUxdf6 j/+fNjH9kWsjFfZlMn507+HuWCQIBkj3Ks6eg= Received: by 10.86.29.19 with SMTP id c19mr6322980fgc.28.1219214749019; Tue, 19 Aug 2008 23:45:49 -0700 (PDT) Received: by 10.86.62.14 with HTTP; Tue, 19 Aug 2008 23:45:48 -0700 (PDT) Message-ID: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> Date: Tue, 19 Aug 2008 23:45:48 -0700 From: "Garrett Cooper" To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Issues with msk driver on 8-CURRENT amd64 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, 20 Aug 2008 07:14:34 -0000 Hi Pyun! I know it's been a while since I responded, but after reinstalling my system recently I noticed that the issue I mentioned almost a year ago (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) with my Marvell chipset card has once again returned. In the interim I was using x86, and I didn't suffer from any of the issues I have again on x64, and I was using XP x64 but now I've switched over to Vista x64 on my client box. Subsequently, the only thing that's really changed on my system is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). I'm using the 7-RELENG kernel right now (and not really enjoying it, but it works -- yay?), but I'd like to help resolve the issue with msk under CURRENT with x64 and my chipset. Standing by awaiting marching orders with tcpdump, netcat, and pciconf at my side to help debug the issue :). Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 08:30:08 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E905A1065687 for ; Wed, 20 Aug 2008 08:30:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id AE7188FC21 for ; Wed, 20 Aug 2008 08:30:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so602916rvf.43 for ; Wed, 20 Aug 2008 01:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=CZBrp5tALHJUWFqDboaT8eQR2JxO5062QAt0v5n6Rog=; b=spDoyzopB/ouCJnOyijZP9A556VtQPlzFMcnveuWPjbkQ0ENRuEos4rYATATsYuaav i9hi1cwyQPRGJoQmviSegzuSWkT0ZyprWH69fxTC3mS4oRhVNQ0dG4Xa3DYHnqDWhimp SC/ber5qdkdpmq9YFutTtaXQzSj+XNSnIdRw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=MdgBowasygSHCGHDWtJlmTGoSxaA44Z7iLFyJT+16KWvCl2SvSRwMY5ZNZFS4UxG16 NuTszwphBXJQwL31lU3HtYbjWDVlQbjFuXHm/29jMtz8Sam0pzEj9vbE2yWFrz83DxDc h4rjsPfkoc2Jx3RaaJZcRvUJ4DFoQjBsZNCBk= Received: by 10.141.76.21 with SMTP id d21mr4627605rvl.270.1219219517127; Wed, 20 Aug 2008 01:05:17 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id k2sm1788379rvb.1.2008.08.20.01.05.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Aug 2008 01:05:16 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m7K835fh088867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 17:03:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m7K834kQ088866; Wed, 20 Aug 2008 17:03:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 20 Aug 2008 17:03:04 +0900 From: Pyun YongHyeon To: Garrett Cooper Message-ID: <20080820080304.GA87443@cdnetworks.co.kr> References: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Issues with msk driver on 8-CURRENT amd64 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: Wed, 20 Aug 2008 08:30:09 -0000 On Tue, Aug 19, 2008 at 11:45:48PM -0700, Garrett Cooper wrote: > Hi Pyun! > I know it's been a while since I responded, but after > reinstalling my system recently I noticed that the issue I mentioned > almost a year ago > (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) > with my Marvell chipset card has once again returned. In the interim I > was using x86, and I didn't suffer from any of the issues I have again > on x64, and I was using XP x64 but now I've switched over to Vista x64 > on my client box. > Subsequently, the only thing that's really changed on my system > is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). > I'm using the 7-RELENG kernel right now (and not really enjoying > it, but it works -- yay?), but I'd like to help resolve the issue with > msk under CURRENT with x64 and my chipset. > Standing by awaiting marching orders with tcpdump, netcat, and > pciconf at my side to help debug the issue :). Would you please explain your issues with more information? For instance, Can you see a valid link is established by msk(4)? Did both ends agree on established speed/duplex? What speed/duplex was chosen by msk(4)? Forcing speed/duplex have any effects? Turning off checksum offload or TSO have any effects? Did you use back-to-back connection without switch? tcpdump data for a broken connection might be help too. > Thanks, > -Garrett -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 11:23:38 2008 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 771861065673 for ; Wed, 20 Aug 2008 11:23:38 +0000 (UTC) (envelope-from slawek.zak@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 011F78FC15 for ; Wed, 20 Aug 2008 11:23:37 +0000 (UTC) (envelope-from slawek.zak@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so563508fgb.35 for ; Wed, 20 Aug 2008 04:23:36 -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:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=ZQcLhDi5HXovv5fByfXuV4v9vGLcthJR2lzMa5WLsPM=; b=SUd6lZaD8lKzBk7Ndra29YRGjjRjBcM4mTBAY3Qz0TrpsodWAD5x9VaO+o7Fm/IvO5 GMWSLHi79G1jnTfB9eg0FKQEvsNIys0W/f8sH6T7s4SWMccJ+Yfnl7leEuGpzTrVf5Wz 7O780Rrd1OmEWjTelSk7vOr3LKwpX8Qf6tvq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=kWYpwsOC+2zSQjlWjer68iUd5kqFRxPvecLH6yZpcyY5k4yCBY2wnb3TYVb5PylmhS aufnWLqytu1UujMR7Yv8Xvr5byeePJAN6wXPhhCtpN1XI8S37BnpgP/fnDaYE20pgJ/1 E71P0AOD20dyxowPb2R2QA7TG4w18q37tPyVo= Received: by 10.181.25.18 with SMTP id c18mr4411579bkj.8.1219229868584; Wed, 20 Aug 2008 03:57:48 -0700 (PDT) Received: by 10.180.255.8 with HTTP; Wed, 20 Aug 2008 03:57:48 -0700 (PDT) Message-ID: <787bbe1c0808200357g745166wd5e2de142a7b3d35@mail.gmail.com> Date: Wed, 20 Aug 2008 12:57:48 +0200 From: "Slawek Zak" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Carp renaming cuts the traffic off 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, 20 Aug 2008 11:23:38 -0000 Hi, Something weird is going on with renaming of carp interfaces. I use FreeBSD stable updated on August 18. My setup: ifconfig em0 up ifconfig em1 up ifconfig lagg0 create up laggproto failover laggport em0 laggport em1 ifconfig vlan4 create up vlan 4 vlandev lagg0 192.168.0.1/24 ifconfig carp1 create up vhid 1 pass testpass 192.168.0.2/24 I ping 192.168.0.2 (carp IP addres) from external host and get replies - works fine. Now do "ifconfig carp1 name something_else" and watch the magic. I get no traffic back from the carp IP address. Does someone have any clue what's going on and why? Thank you, /S From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 13:29:18 2008 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 A002C1065689 for ; Wed, 20 Aug 2008 13:29:18 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.229]) by mx1.freebsd.org (Postfix) with ESMTP id 5068A8FC15 for ; Wed, 20 Aug 2008 13:29:18 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: by qb-out-0506.google.com with SMTP id e34so826802qbe.35 for ; Wed, 20 Aug 2008 06:29:17 -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:to :subject:mime-version:content-type; bh=CmeW8Cl0TyxYYfDqCN6pALq17ySjR9D4jxDUgmFGDoI=; b=xlaviCuPfCd6KuWTR0NhpxdGGUf31cDX/XAFC4Hc1QBkYw1l6kXQFW3NcW8Hz8XCeV 3bWOWNbT47hDSrEMDeGBxTckqiHK1gcbmlAb6zcjMJTYgf045d7yYBT2Ya24zG43p2mS zkwDjW2cSPqniFYvAG7cW/w2FuJ7w4Qyp1oSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=u506U8MqMjYqonKb2X5i9rcMjQQ773U2sboFTxZJ3BSJ2WCHISseeB8IqitYmoKKhi s3McpqMTQV9Pw7qywIgM1Qk/2ATVHevBUvLRNaKZ8lO5sBr74r0dIVAZy3hbOCC/aiJm bzuUEtqOXSX4/xCsdkqaj5QAdlt/Kj7X7DAUQ= Received: by 10.103.220.18 with SMTP id x18mr50993muq.81.1219237980993; Wed, 20 Aug 2008 06:13:00 -0700 (PDT) Received: by 10.102.247.18 with HTTP; Wed, 20 Aug 2008 06:13:00 -0700 (PDT) Message-ID: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> Date: Wed, 20 Aug 2008 15:13:00 +0200 From: "Popof Popof" To: "FreeBSD Net" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: How to make two vlans on one interface working with dhclient 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, 20 Aug 2008 13:29:18 -0000 Hi, I have a FreeBSD 6.0 box andi need to configure it in a way that I must use 2 vlans under one interface and both of them will get an address thanks to dhclient. So in order to make this job I created vlans: ifconfig rl0.100 create ifconfig rl0.2101 create The vlans are created without any problem. But I also want to retrieve an diffrent ip address from a dhcpd server on the two of them. I've made a specific dhclient.conf for each one: interface "rl0.100" { #My options } interface "rl0.2101" { #My options } When I launch dhclient on only one interface (100 or 2101) it's works fine and I get an ip address (class B on vlan 100 and class A on vlan 2101). But if I launch dhclient on the second interface it's make an error: dhclient: Can't bind to dhcp address: Address already in use. Please make sure there is no other dhcp server runing and that there's no entry for dhcp or bootp in /etc/inetd.conf Does someone had an idea about how to fix this problem and having my two vlans working with dhclient? From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 15:20:20 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F75F1065672 for ; Wed, 20 Aug 2008 15:20:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id E2ACC8FC28 for ; Wed, 20 Aug 2008 15:20:19 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so648694fgb.35 for ; Wed, 20 Aug 2008 08:20:18 -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:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=p5Z+hH5rdZ3h5md9CrgJ5Oa2T0qtx9KQTeAAFkcSPTI=; b=o7ifQ8dEUFP0pT6JgF+Ii5aN+1DuaCzIb1iU0BuSemUll5nv8qwojQg/NHDJ/gwxtS PLOCHhxaKr8gdfRfEJfyjuBlmn6Cw01NXlfAe/tW/Ni56yxu3IuScXQL+tDXbN0Sr2mY zVinGh9ofv9pXUOoFGcoyQBZ2rySeUQDA3zDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PxunQ2CAGrHv9rWkjAxW5BQuLrnWbnL4fkN4Mxnf03PayUihuFUfIenCKZf1E17Hpg EZMVxG8LWfdmazXG1W4HH0/mrB9DOcBHzndr/hSXARdGy5wwvFPU5R1aOYV415nYgeAk oM85skIWTh1n51rLxdZLiNmF8XWPDs2nsMwio= Received: by 10.86.26.11 with SMTP id 11mr156414fgz.12.1219245618680; Wed, 20 Aug 2008 08:20:18 -0700 (PDT) Received: by 10.86.62.14 with HTTP; Wed, 20 Aug 2008 08:20:18 -0700 (PDT) Message-ID: <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com> Date: Wed, 20 Aug 2008 08:20:18 -0700 From: "Garrett Cooper" To: pyunyh@gmail.com In-Reply-To: <20080820080304.GA87443@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> <20080820080304.GA87443@cdnetworks.co.kr> Cc: net@freebsd.org Subject: Re: Issues with msk driver on 8-CURRENT amd64 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, 20 Aug 2008 15:20:20 -0000 Comments inline. On Wed, Aug 20, 2008 at 1:03 AM, Pyun YongHyeon wrote: > On Tue, Aug 19, 2008 at 11:45:48PM -0700, Garrett Cooper wrote: > > Hi Pyun! > > I know it's been a while since I responded, but after > > reinstalling my system recently I noticed that the issue I mentioned > > almost a year ago > > (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) > > with my Marvell chipset card has once again returned. In the interim I > > was using x86, and I didn't suffer from any of the issues I have again > > on x64, and I was using XP x64 but now I've switched over to Vista x64 > > on my client box. > > Subsequently, the only thing that's really changed on my system > > is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). > > I'm using the 7-RELENG kernel right now (and not really enjoying > > it, but it works -- yay?), but I'd like to help resolve the issue with > > msk under CURRENT with x64 and my chipset. > > Standing by awaiting marching orders with tcpdump, netcat, and > > pciconf at my side to help debug the issue :). > > Would you please explain your issues with more information? > For instance, > Can you see a valid link is established by msk(4)? Sort of. A link between the endpoints is established, but then it stalls and fails after a "connection reset". > Did both ends agree on established speed/duplex? Yes, they did. > What speed/duplex was chosen by msk(4)? 10/100MBit and GBit duplex, respectively. > Forcing speed/duplex have any effects? Not sure, but using a 100MBit and 1GBit connection yields the same results, whereas before I just claimed it was just gigabit connections. > Turning off checksum offload or TSO have any effects? How do I do that? > Did you use back-to-back connection without switch? I'm connecting via a switch and it works perfectly fine via 7-RELENG with amd64. > tcpdump data for a broken connection might be help too. Ok. More help on trying to setup everything to debug this issue would be helpful. FWIW, the issue might be that the MTU doesn't match for Windows and FreeBSD (I remember reading that somewhere a while back)... unfortunately, my router speaks this MTU (1464?) so connections via msk don't work properly anymore on 8-CURRENT. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 21:03:48 2008 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 850A51065676 for ; Wed, 20 Aug 2008 21:03:48 +0000 (UTC) (envelope-from jav@sics.se) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 480468FC1E for ; Wed, 20 Aug 2008 21:03:48 +0000 (UTC) (envelope-from jav@sics.se) Received: from [10.131.12.250] (unknown [12.19.192.51]) by letter.sics.se (Postfix) with ESMTP id 83EF240105 for ; Wed, 20 Aug 2008 22:44:42 +0200 (CEST) From: Javier Ubillos To: freebsd-net@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vvA1bPIV4wkv8/Mvi1W1" Date: Wed, 20 Aug 2008 13:44:21 -0700 Message-Id: <1219265061.9118.29.camel@dib> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: erride default ICMP (and other protocols) default replies. 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, 20 Aug 2008 21:03:48 -0000 --=-vvA1bPIV4wkv8/Mvi1W1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi freebsd-net. (Sorry for cross posting. This time I think I found the right forum for my question) I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually NAT, but it's a good analogy for this case). I have chosen to use pcaplib to pick up the packets. I have an implementation which picks up the packets, inspects them, rewrites the destination/source ip-addresses and sends them out on the repective interface. The problem I'm facing however is that my interfaces are answering to e.g. icmp-echo (ping) automatically, and I don't know how to turn this behaviour off. What I want to happen is that if A pings C, my router B in between should simply forward the packets w/o any automatic reactions. A --> B --> C So that if e.g. C is down, no echo-reply is sent back (or if C is up, that C is actually sending the echo-reply. Does any one know how to turn off the automatic replies (ICMP and whatever else I haven't forseen yet) or does any one know where I can find out more about the issue? Thank you // Javier --=-vvA1bPIV4wkv8/Mvi1W1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIrIIlGBo5FLRz4goRAv9TAKCKrhJqaueMiFUIeMG1TQghqTSyfQCfbPMU XWdayAjd4c+tnTcL9R6fIsY= =kvgh -----END PGP SIGNATURE----- --=-vvA1bPIV4wkv8/Mvi1W1-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 21:20:28 2008 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 48E2A106569E for ; Wed, 20 Aug 2008 21:20:28 +0000 (UTC) (envelope-from jav@sics.se) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 0B96E8FC28 for ; Wed, 20 Aug 2008 21:20:27 +0000 (UTC) (envelope-from jav@sics.se) Received: from [10.131.12.250] (unknown [12.19.192.51]) by letter.sics.se (Postfix) with ESMTP id 4C4D3400D7 for ; Wed, 20 Aug 2008 22:52:00 +0200 (CEST) From: Javier Ubillos To: freebsd-net@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Lk5DLZuQh2dVjVpmdkUu" Date: Wed, 20 Aug 2008 13:51:39 -0700 Message-Id: <1219265499.9118.31.camel@dib> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Override default ICMP (and other protocols) default replies. 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, 20 Aug 2008 21:20:28 -0000 --=-Lk5DLZuQh2dVjVpmdkUu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi freebsd-net. (Sorry for cross posting. This time I think I found the right forum for my question) I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually NAT, but it's a good analogy for this case). I have chosen to use pcaplib to pick up the packets. I have an implementation which picks up the packets, inspects them, rewrites the destination/source ip-addresses and sends them out on the repective interface. The problem I'm facing however is that my interfaces are answering to e.g. icmp-echo (ping) automatically, and I don't know how to turn this behaviour off. What I want to happen is that if A pings C, my router B in between should simply forward the packets w/o any automatic reactions. A --> B --> C So that if e.g. C is down, no echo-reply is sent back (or if C is up, that C is actually sending the echo-reply. Does any one know how to turn off the automatic replies (ICMP and whatever else I haven't forseen yet) or does any one know where I can find out more about the issue? Thank you // Javier --=-Lk5DLZuQh2dVjVpmdkUu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIrIPbGBo5FLRz4goRAl4HAJ9PE8pZbl201UJw8DE00JZ+mJOtJgCeOVkX kcrQdGjvN+iw1ZLkoaNLJOg= =rB0J -----END PGP SIGNATURE----- --=-Lk5DLZuQh2dVjVpmdkUu-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 21:22:53 2008 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 5BF691065677; Wed, 20 Aug 2008 21:22:53 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 374468FC17; Wed, 20 Aug 2008 21:22:53 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from freefall.freebsd.org (scf@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7KLMrJQ093626; Wed, 20 Aug 2008 21:22:53 GMT (envelope-from scf@freefall.freebsd.org) Received: (from scf@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7KLMraF093622; Wed, 20 Aug 2008 16:22:53 -0500 (CDT) (envelope-from scf) Date: Wed, 20 Aug 2008 16:22:53 -0500 (CDT) Message-Id: <200808202122.m7KLMraF093622@freefall.freebsd.org> To: scf@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: scf@FreeBSD.org Cc: Subject: Re: kern/126695: rtfree messages and network disruption upon use of if_bridge(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2008 21:22:53 -0000 Synopsis: rtfree messages and network disruption upon use of if_bridge(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: scf Responsible-Changed-When: Wed Aug 20 16:21:37 CDT 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126695 From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 21:34:42 2008 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 A26D8106567B for ; Wed, 20 Aug 2008 21:34:42 +0000 (UTC) (envelope-from ady@ady.ro) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFFC8FC28 for ; Wed, 20 Aug 2008 21:34:41 +0000 (UTC) (envelope-from ady@ady.ro) Received: by fg-out-1718.google.com with SMTP id l26so821568fgb.35 for ; Wed, 20 Aug 2008 14:34:40 -0700 (PDT) Received: by 10.180.234.10 with SMTP id g10mr334255bkh.16.1219268080138; Wed, 20 Aug 2008 14:34:40 -0700 (PDT) Received: from ady-laptop.local ( [85.28.101.77]) by mx.google.com with ESMTPS id p9sm2480001fkb.5.2008.08.20.14.34.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Aug 2008 14:34:39 -0700 (PDT) Date: Wed, 20 Aug 2008 23:34:20 +0200 (CEST) From: Adrian Penisoara X-X-Sender: ady@ady-laptop To: Javier Ubillos In-Reply-To: <1219265499.9118.31.camel@dib> Message-ID: References: <1219265499.9118.31.camel@dib> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: Adrian Penisoara Cc: freebsd-net@freebsd.org Subject: Re: Override default ICMP (and other protocols) default replies. 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, 20 Aug 2008 21:34:42 -0000 Hi, On Wed, 20 Aug 2008, Javier Ubillos wrote: > Hi freebsd-net. > (Sorry for cross posting. This time I think I found the right forum for > my question) > > I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually > NAT, but it's a good analogy for this case). > > I have chosen to use pcaplib to pick up the packets. I have an > implementation which picks up the packets, inspects them, rewrites the > destination/source ip-addresses and sends them out on the repective > interface. Umm, this is going parallel to the real network stack. Why not try to "hijack" the packets fro the kernel to the userland process with a feature like divert in ipfw(8) ? > > The problem I'm facing however is that my interfaces are answering to > e.g. icmp-echo (ping) automatically, and I don't know how to turn this > behaviour off. This is a normal TCP/IP network stack feature in the kernel. You may also find that connecting to one of the open ports on the machine will trigger a similar effect. You need to cut off that packet before entering the upper network application layer in the kernel -- see suggestion above. Regards, Adrian. From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 00:47:25 2008 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 BCF151065680 for ; Thu, 21 Aug 2008 00:47:25 +0000 (UTC) (envelope-from freebsd@chrisbuechler.com) Received: from mail.livebsd.com (mail.livebsd.com [69.64.6.14]) by mx1.freebsd.org (Postfix) with SMTP id 7C3498FC25 for ; Thu, 21 Aug 2008 00:47:25 +0000 (UTC) (envelope-from freebsd@chrisbuechler.com) Received: (qmail 39563 invoked by uid 89); 21 Aug 2008 00:47:24 -0000 Received: from unknown (HELO ?10.0.64.15?) (74.130.92.110) by 172.29.29.14 with SMTP; 21 Aug 2008 00:47:24 -0000 Message-ID: <48ACBB1C.7080701@chrisbuechler.com> Date: Wed, 20 Aug 2008 20:47:24 -0400 From: Chris Buechler User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <48A878C6.9000001@chrisbuechler.com> In-Reply-To: <48A878C6.9000001@chrisbuechler.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: repeatable scp stalls from 7.0 to 7.0 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, 21 Aug 2008 00:47:25 -0000 Chris Buechler wrote: > I've been seeing pretty frequent and repeatable scp stalls between two > FreeBSD 7.0 servers (7.0-RELEASE-p2 to be exact) on a 100 Mb LAN. > They're two HP servers, an Opteron 275 and a dual Xeon 3.4 (don't > recall the models but I can get them if it's relevant) using the > onboard bge(4) cards. The client side (builder7) SCPs a file to the > server side (hosting7) about 20 times a day. The stall happens about > 2-4 times a week or so, and has happened ever since we put these two > boxes online in their current functions. Initially they were the > original 7.0 release, prior to the TCP fix in June. It's behaved the > same way both prior to and after that fix. There are no apparent > network issues aside from this with either of the boxes. > > Since we had nothing to go on other than scp sessions going to > "stalled" (no relevant logs), I setup a tcpdump on each end filtering > on the TCP 22 traffic between these hosts, grabbing 100 bytes of each > frame to avoid chewing up too much disk space. When it happened again > I split the end out into its own file with editcap, 4.2-4.3 MB each. > > http://chrisbuechler.com/temp/lastcut-hosting7.pcap - server end, > capture taken on host but destination IP is a jail > http://chrisbuechler.com/temp/lastcut-builder7.pcap - client end, > connection is initiated from the host, no jails involved. > > The TCP window on the ACKs from server to client start decrementing > [1], to the point where it's down to a window of 0. From that point, > everything the server (172.29.29.181) sends back to the client > (172.29.29.170) has a window of 0. Restarting the scp makes it work > again. It doesn't happen every time, somewhere around 2-3% of the time > it does. I don't see any cause for the decrementing window in those > captures but maybe I'm missing something. > > 1 - lastcut-hosting7.pcap frame #21298; lastcut-builder7.pcap #25088 > > These are both very stock boxes, GENERIC kernels, no significant > changes in sysctl or anything else. I'm not sure where to go from > here, any assistance in resolving this would be appreciated. Cut the nasty stuff above that Thunderbird threw in there on the copy/paste, sorry about that. I haven't gotten any replies, thought I would bump this. thanks, Chris From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 05:03:34 2008 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 08D871065677 for ; Thu, 21 Aug 2008 05:03:34 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id AA0B28FC14 for ; Thu, 21 Aug 2008 05:03:33 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1260556rvf.43 for ; Wed, 20 Aug 2008 22:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:x-face :x-attribution:x-os-kernel:x-os-version:x-os-architecture:x-uptime :x-url:x-mail-morse:x-openpgp-fingerprint:x-openpgp-id:face :organization:user-agent; bh=eWcwdD8UwsLNcHFmFr3fMfSMK1hwvCF30inoSIkd+A8=; b=VeKg2NEgY1wveamQQBdFWH+Iz9++lx596bthrF7/sG8LiRIHQMKQHI9ubX4ArwnQe8 qnPPdAMWHEr0Z1T/5x19pAxknh4O/tw4f7FaAOZ4LR0GSFdfWLDkb8pTjg/rBguHmey4 Yr1EZQ3d8XNRICverdxVcKGBBbaCwDtt9g6CE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:x-face:x-attribution:x-os-kernel:x-os-version :x-os-architecture:x-uptime:x-url:x-mail-morse:x-openpgp-fingerprint :x-openpgp-id:face:organization:user-agent; b=eomOmS6hNx9O18VR1TgdmVvCj0M2bHTHmoNQLxH032pMeOYoavkYI/UWDnkE81bPYJ c4s65OXRaCsC9sdNXrJL9fWnRc3lwZQlZ4otodGK3vGRMnNrGoFsFdTqujBdbaaAD36v 2KIwR+LPktn8kqxkDK8tsg9q3FetF6Inws3GM= Received: by 10.141.195.5 with SMTP id x5mr495882rvp.263.1219293515764; Wed, 20 Aug 2008 21:38:35 -0700 (PDT) Received: from chateau.d.lf ( [122.162.237.43]) by mx.google.com with ESMTPS id l31sm3665763rvb.2.2008.08.20.21.38.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Aug 2008 21:38:34 -0700 (PDT) Date: Thu, 21 Aug 2008 10:08:28 +0530 From: =?utf-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksg==?= Ashish Shukla To: freebsd-net@freebsd.org Message-ID: <20080821043828.GA42712@chateau.d.lf> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C ]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl;t7 X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= X-OS-Kernel: FreeBSD X-OS-Version: 7.0-RELEASE-p3 X-OS-Architecture: amd64 X-Uptime: 9:51AM up 2:55, 0 users, load averages: 0.30, 0.26, 0.23 X-URL: http://wahjava.wordpress.com/ X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OpenPGP-ID: 762E5E74 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEWpqambm5uHh4d7e3 ttbW1jY2Pe3t4dHR28vLygoKCenp6SkpJOTk7////9/f35+flcgqXsAAACiUlEQVQ4jX XTz0sUURwA8NlOrkS5ZqIzUO6sCTaBMKuYrVCsM7cgyJ066EUMC5KVgnoEHlY7uJTYbn loBilH6TBvL40a5goZqexl/gWHjl72O+hh8dJub1ydH5t9L4/5fvjOe9/H+1J7/wnqZD UBKnYAQNEHYJWeUPLHsUq5BqzSeWTHnQk/QGlhctKw42fZC6Y1jgxDkiTDKHQBeKBUsN N2FJ6Xi0UXDo1dSagCugIeGCd5Esfw0gXT6pGkhC0JaRhN/nH2MI92SH4lygtiYhihid MK0zyMsTqm6jNrIqlAPxyA8TjGmbp06pwgigV0zwFr5heNM+l0OiiIkg/Wh6pArZLdCx 7oHcJVUMjxjC4HKndjWhXkb6TPLbeiJxxSMoGvqSA9Lw6yVx04QGFlyb5zGc8LGysdDu yjF9o6Qr1IUZeHci0N7q+mHza81tmNL3p26daHVJvb4Myrtjc0GsnjrKq/D9x0r+Txs7 5gDgUWZczk2bcP3IpHnJ4JyhRFyY3hzqduHzCbyNalyGVR2VWe3066sMDRVch18/x3cE +13IkpAqn6iBDbfOcCTF2nszLZIxARoh3gwt5IH8PkNTmY3eyO3va8Kzjgd+IaxgoOtf dveWG/J65jEprafu2TB8ySOJCnbWGiaxe8T7RyY3BAVwg08pfmvGA1FXZ3WzFWV7kmH8 Aoy3YeF+Qv+8D8neAUTWMiHG5M+sfgvoJVJsLroRbffABM6yEmEuVa6c++iTJhlGcjAk erarJmBg/JU+dJk83Fk4QznFPdA2HS+lwtQOVIitE4l6wFMrfDcVpZLP8De1b/dp5uhj NgdlvXLp7mvXDUHm4tnwFQGRubcPIeINMAYDpffwFxLwHEb6QJ2wAAAABJRU5ErkJggg == Organization: /\/0/\/3 User-Agent: Mutt/1.5.18 (2008-05-17) Subject: rtfree: 0xffffff00030aa4b0 has 2 refs 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, 21 Aug 2008 05:03:34 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I'm getting following message in my dmesg, no. of times continuously. This = is=20 the first time, I received this message. rtfree: 0xffffff00030aa4b0 has 2 refs I received this message when I tried to connect to IPv6 internet via Hurric= ane=20 Electric's tunnel. Following are outputs of some of the commands on my box: ---->8---->8---- % dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p3 #3: Tue Jul 15 10:16:13 IST 2008 root@chateau.d.lf:/usr/obj/usr/src/sys/ULE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.02-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf43 Stepping =3D 3 Features=3D0xbfebfbff Features2=3D0x649d AMD Features=3D0x20100800 Logical CPUs per core: 2 usable memory =3D 2128392192 (2029 MB) avail memory =3D 2054033408 (1958 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2d00000f2d device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_perf1: on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2d00000f2d device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20e0-0x20e7 mem 0x88100000-0x8817ffff,0x80000000-0x87ffffff,0x88180000-0x8819ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 128M pcm0: mem 0x881a0000-0x881a= 3fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.2 on pci0 pci2: on pcib2 pcib3: at device 28.3 on pci0 pci3: on pcib3 uhci0: port 0x2080-0x209f irq 23 at device = 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2060-0x207f irq 19 at device = 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device = 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device = 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0x881a4000-0x881a43f= f irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 rl0: port 0x1000-0x10ff mem 0x88009000-0x880090= ff irq 21 at device 0.0 on pci4 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:00:21:23:cc:ed rl0: [ITHREAD] pcm1: mem 0x88000000-0x88007fff irq 22 at device 1= =2E0 on pci4 pcm1: pcm1: [ITHREAD] fxp0: port 0x1100-0x113f mem 0x88008000-0x88008fff irq 20 at device 8.0 on pci4 miibus1: on fxp0 inphy0: PHY 1 on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:13:20:b7:55:0a fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20b0-0x20bf irq 18 at device 31.1 on = pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af irq 1= 9 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A sio0: [FILTER] orm0: at iomem 0xcb000-0xcbfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub0 ugen1: on = uhub3 Timecounters tick every 1.000 msec acd0: DVDR at ata0-slave UDMA33 ad5: 238475MB at ata2-slave SATA150 ad6: 152627MB at ata3-master SATA150 pcm0: pcm0: SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad5s5 is ext2fs//var/spool/news. GEOM_LABEL: Label for provider ad5s9 is ext2fs/lectures. GEOM_LABEL: Label for provider ad5s10 is ext2fs/archives. GEOM_LABEL: Label for provider ad6s2 is ext2fs//. GEOM_JOURNAL: Journal 499229287: ad6s4a contains data. GEOM_JOURNAL: Journal 499229287: ad6s4a contains journal. GEOM_JOURNAL: Journal ad6s4a clean. GEOM_JOURNAL: Journal 4273413447: ad6s4d contains data. GEOM_JOURNAL: Journal 4273413447: ad6s4d contains journal. GEOM_JOURNAL: Journal ad6s4d clean. GEOM_JOURNAL: Journal 172646561: ad6s4e contains data. GEOM_JOURNAL: Journal 172646561: ad6s4e contains journal. GEOM_JOURNAL: Journal ad6s4e clean. WARNING: Expected rawoffset 0, found 148665509 Trying to mount root from ufs:/dev/ad6s4a.journal plip0: [GIANT-LOCKED] plip0: [ITHREAD] fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 drm0: on vgapci0 info: [drm] AGP at 0x80000000 128MB info: [drm] Initialized i915 1.5.0 20060119 drm0: [ITHREAD] drm0: [ITHREAD] fxp0: link state changed to DOWN fxp0: link state changed to UP WARNING: attempt to net_add_domain(netgraph) after domainfinalize() rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs rtfree: 0xffffff00030aa4b0 has 2 refs % ifconfig rl0: flags=3D8843 metric 0 mtu 1500 options=3D8 ether 00:00:21:23:cc:ed inet6 fe80::200:21ff:fe23:cced%rl0 prefixlen 64 scopeid 0x1 media: Ethernet autoselect (none) status: no carrier fxp0: flags=3D8843 metric 0 mtu 1500 options=3D8 ether 00:13:20:b7:55:0a inet6 fe80::213:20ff:feb7:550a%fxp0 prefixlen 64 scopeid 0x2 inet 172.16.0.2 netmask 0xffffffe0 broadcast 172.16.0.31 inet6 fdxx:xxxx:xxxx::1 prefixlen 48 inet6 2001:470:9130:8000::1 prefixlen 64 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=3D108851 = metric 0 mtu 1500 lo0: flags=3D8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 ng0: flags=3D88d1 metric 0 = mtu 1492 inet 122.162.237.43 --> 122.160.220.173 netmask 0xffffffff inet6 fe80::200:21ff:fe23:cced%ng0 prefixlen 64 scopeid 0x5 gif0: flags=3D8051 metric 0 mtu 1280 tunnel inet 122.162.237.43 --> 216.66.80.26 inet6 fe80::200:21ff:fe23:cced%gif0 prefixlen 64 scopeid 0x6 % netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 122.160.220.173 UGS 0 34827 ng0 122.160.220.173 122.162.237.43 UH 1 0 ng0 127.0.0.1 127.0.0.1 UH 0 3337 lo0 172.16.0.0/27 link#2 UC 0 0 fxp0 172.16.0.31 ff:ff:ff:ff:ff:ff UHLWb 1 1 fxp0 Internet6: Destination Gateway Flags = Netif Expire ::/96 ::1 UGRS = lo0 =3D> default 2001:470:1f08:3b7::1 UGS = gif0 ::1 ::1 UHL = lo0 ::ffff:0.0.0.0/96 ::1 UGRS = lo0 2001:470:9130:8000::/64 link#2 UC = fxp0 2001:470:9130:8000::1 00:13:20:b7:55:0a UHL = lo0 fdcf:xxxx:xxxx::/48 link#2 UC = fxp0 fdcf:xxxx:xxxx::1 00:13:20:b7:55:0a UHL = lo0 fe80::/10 ::1 UGRS = lo0 fe80::%rl0/64 link#1 UC = rl0 fe80::200:21ff:fe23:cced%rl0 00:00:21:23:cc:ed UHL = lo0 fe80::%fxp0/64 link#2 UC = fxp0 fe80::213:20ff:feb7:550a%fxp0 00:13:20:b7:55:0a UHL = lo0 fe80::%lo0/64 fe80::1%lo0 U = lo0 fe80::1%lo0 link#4 UHL = lo0 fe80::%ng0/64 link#5 UC = ng0 fe80::200:21ff:fe23:cced%ng0 link#5 UHL = lo0 fe80::%gif0/64 link#6 UC = gif0 fe80::200:21ff:fe23:cced%gif0 link#6 UHL = lo0 ff01:1::/32 link#1 UC = rl0 ff01:2::/32 link#2 UC = fxp0 ff01:4::/32 ::1 UC = lo0 ff01:5::/32 link#5 UC = ng0 ff01:6::/32 link#6 UC = gif0 ff02::/16 ::1 UGRS = lo0 ff02::%rl0/32 link#1 UC = rl0 ff02::%fxp0/32 link#2 UC = fxp0 ff02::%lo0/32 ::1 UC = lo0 ff02::%ng0/32 link#5 UC = ng0 ff02::%gif0/32 link#6 UC = gif0 % traceroute6 -I -n 2001:4860:0:2001::68 traceroute6 to 2001:4860:0:2001::68 (2001:4860:0:2001::68) from 2001:470:9130:8000::1, 64 hops max, 16 byte packets 1 2001:470:1f08:3b7::1 254.691 ms 255.460 ms 254.047 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * ^C ---->8---->8---- This configuration works fine for me, except for now. The technical support= =20 person at the HE's end told their is no problem at HE's end, and it servers= are=20 working fine. On googling I found a similar problem[1] reported on freebsd-current last y= ear.=20 And similar to what mentioned in the diff[2] in the followup[3], I found=20 following in my sys/netinet6/in6_gif.c, wondering if it has to do anything = with=20 the issue. Please note the calls to the rtfree() function. Shouldn't that c= all=20 be replaced with RTFREE_LOCKED(). This is just a guess, not sure if that ha= s=20 anything to do with it. 365 if (!rt || rt->rt_ifp !=3D ifp) { 366 #if 0 367 char ip6buf[INET6_ADDRSTRLEN]; 368 log(LOG_WARNING, "%s: packet from %s dropped " 369 "due to ingress filter\n", if_name(GIF2IFP(= sc)), 370 ip6_sprintf(ip6buf, &sin6.sin6_addr)); 371 #endif 372 if (rt) 373 rtfree(rt); 374 return 0; 375 } 376 rtfree(rt); 377 } 378 379 return 128 * 2; 380 } Refernces: [1] - http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076401= =2Ehtml [2] -=20 http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070828/1ba= d9902/rt-0001.bin [3] - =20 http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076494.html Thanks Ashish Shukla -- =C2=B7-- =C2=B7- =C2=B7=C2=B7=C2=B7=C2=B7 =C2=B7--- =C2=B7- =C2=B7=C2=B7=C2= =B7- =C2=B7- =C2=B7--=C2=B7-=C2=B7 --=C2=B7 -- =C2=B7- =C2=B7=C2=B7 =C2=B7-= =C2=B7=C2=B7 =C2=B7-=C2=B7-=C2=B7- -=C2=B7-=C2=B7 --- -- --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkis8UMACgkQHy+EEHYuXnSeUACgv7dm3lRzZLpMb6M+HShSahd7 CDoAoLuurJ3vy6EeyTNujsNXBjZ42jM3 =codE -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 05:20:29 2008 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 0A7E81065672 for ; Thu, 21 Aug 2008 05:20:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id ECD898FC20 for ; Thu, 21 Aug 2008 05:20:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E084922F5 for ; Wed, 20 Aug 2008 22:20:28 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 6396E2D6025 for ; Wed, 20 Aug 2008 22:20:28 -0700 (PDT) Message-ID: <48ACFB17.9030901@elischer.org> Date: Wed, 20 Aug 2008 22:20:23 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: m0n0wall/pfsense question. 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, 21 Aug 2008 05:20:29 -0000 Does anyone know whether the above mentionned bsd systems boot to a ram disk or keep their filesystem on teh flash/disk? From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 05:30:19 2008 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 BABF010656C7 for ; Thu, 21 Aug 2008 05:30:19 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 56C2F8FC18 for ; Thu, 21 Aug 2008 05:30:19 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 145 invoked by uid 89); 21 Aug 2008 05:37:46 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 21 Aug 2008 05:37:46 -0000 Message-ID: <48ACFDC2.10609@ibctech.ca> Date: Thu, 21 Aug 2008 01:31:46 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Julian Elischer References: <48ACFB17.9030901@elischer.org> In-Reply-To: <48ACFB17.9030901@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: m0n0wall/pfsense question. 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, 21 Aug 2008 05:30:19 -0000 Julian Elischer wrote: > > Does anyone know whether the above mentionned bsd systems boot to a ram > disk or keep their filesystem on teh flash/disk? Julian, It depends... Its been a while, but any system I've built lately (not related to the aforementioned) are easily dumped from startup->running (then pull the boot medium). I'll find out for you, but if you can provide me with the 'why' factor, it would make research easier and more focused. Steve From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 09:35:43 2008 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 AFE941065671; Thu, 21 Aug 2008 09:35:43 +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 871C98FC0C; Thu, 21 Aug 2008 09:35:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7L9ZhIl093328; Thu, 21 Aug 2008 09:35:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7L9ZhMB093324; Thu, 21 Aug 2008 09:35:43 GMT (envelope-from linimon) Date: Thu, 21 Aug 2008 09:35:43 GMT Message-Id: <200808210935.m7L9ZhMB093324@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/126688: [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and PAE 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, 21 Aug 2008 09:35:43 -0000 Old Synopsis: 1.4.7 ixgbe driver panic with 4GB and PAE New Synopsis: [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and PAE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 21 09:34:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126688 From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 09:48:14 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997821065676 for ; Thu, 21 Aug 2008 09:48:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 273BD8FC22 for ; Thu, 21 Aug 2008 09:48:13 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1143391fgb.35 for ; Thu, 21 Aug 2008 02:48:12 -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:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=3tOij3oXDpgbi4OUyKi3ah2+JzRJ4hQQfk8LXujb+8g=; b=dJwv4s2racTIxiC2LL0lX+P5s6F4nhddxJMWOY2+l0B6hQALNOf93nz8q1QQAEIYFZ ZxoiHN95f2/10r/0PvqWyGMaIlf3cGmDLncAbtauN8iQ0+JhmRY/shkLZVAtmBvykI2X 5Pf0tN/WuXlkKv8Ux+pemteMxvLN44FuJGrOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pCkw6YlZxAZdNXH2E+nLt4Hl1DRgWK72wmDrIli6qoVWs32LHxoe0UqpFVaSue95IU fGXOhz5t0RdQYOqtYEGUi30aaMy76UzUDquwI2eNQvsouzJKeVye4MWcm2LlwUqEJgV9 UQHoHKSvwq697hmO0KYk2NuorvSED9OpmHYvg= Received: by 10.86.1.11 with SMTP id 11mr957535fga.27.1219312092851; Thu, 21 Aug 2008 02:48:12 -0700 (PDT) Received: by 10.86.62.14 with HTTP; Thu, 21 Aug 2008 02:48:12 -0700 (PDT) Message-ID: <7d6fde3d0808210248i2a42c88cr378bfc5b998a236c@mail.gmail.com> Date: Thu, 21 Aug 2008 02:48:12 -0700 From: "Garrett Cooper" To: pyunyh@gmail.com In-Reply-To: <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> <20080820080304.GA87443@cdnetworks.co.kr> <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com> Cc: net@freebsd.org Subject: Re: Issues with msk driver on 8-CURRENT amd64 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, 21 Aug 2008 09:48:14 -0000 On Wed, Aug 20, 2008 at 8:20 AM, Garrett Cooper wrote: > Comments inline. > > On Wed, Aug 20, 2008 at 1:03 AM, Pyun YongHyeon wrote: >> On Tue, Aug 19, 2008 at 11:45:48PM -0700, Garrett Cooper wrote: >> > Hi Pyun! >> > I know it's been a while since I responded, but after >> > reinstalling my system recently I noticed that the issue I mentioned >> > almost a year ago >> > (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes) >> > with my Marvell chipset card has once again returned. In the interim I >> > was using x86, and I didn't suffer from any of the issues I have again >> > on x64, and I was using XP x64 but now I've switched over to Vista x64 >> > on my client box. >> > Subsequently, the only thing that's really changed on my system >> > is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc). >> > I'm using the 7-RELENG kernel right now (and not really enjoying >> > it, but it works -- yay?), but I'd like to help resolve the issue with >> > msk under CURRENT with x64 and my chipset. >> > Standing by awaiting marching orders with tcpdump, netcat, and >> > pciconf at my side to help debug the issue :). >> >> Would you please explain your issues with more information? >> For instance, >> Can you see a valid link is established by msk(4)? > > Sort of. A link between the endpoints is established, but then it > stalls and fails after a "connection reset". > >> Did both ends agree on established speed/duplex? > > Yes, they did. > >> What speed/duplex was chosen by msk(4)? > > 10/100MBit and GBit duplex, respectively. > >> Forcing speed/duplex have any effects? > > Not sure, but using a 100MBit and 1GBit connection yields the same > results, whereas before I just claimed it was just gigabit > connections. > >> Turning off checksum offload or TSO have any effects? > > How do I do that? > >> Did you use back-to-back connection without switch? > > I'm connecting via a switch and it works perfectly fine via 7-RELENG with amd64. > >> tcpdump data for a broken connection might be help too. > > Ok. > > More help on trying to setup everything to debug this issue would be helpful. > > FWIW, the issue might be that the MTU doesn't match for Windows and > FreeBSD (I remember reading that somewhere a while back)... > unfortunately, my router speaks this MTU (1464?) so connections via > msk don't work properly anymore on 8-CURRENT. > > Thanks, > -Garrett I just started tcpdump and I noticed that my FreeBSD box is doing a lot of arp who-has queries (1 host / sec). On a static, private network though this shouldn't be the case, correct? I also setup a simple echo server via python to do my bidding (echo'ing foo) and the messages go through via 7-RELENG's kernel, but I'm seeing a TON of checksum incorrect messages with the 8-CURRENT kernel. Funny though because this issue used to occur with 7-CURRENT last year, which is now 7-RELENG, so someone must have accidentally introduced some kind of regression code into msk(4) or a dependent portion of the kernel, or my compile options are causing this issue. I'm posting my simple echo protocol python script at the bottom of the message, and I'll send you the bzipped format of the tcpdump log privately to avoid spamming net@. Thanks, -Garrett ============= TEST APP =============== #!/usr/bin/env python """ Name: simple_echoer Desc: Simple echo server using a pre-agreed upon port to transmit messages between a client and server. Author: Garrett Cooper [yanegomi {{_AT__spamfree}} gmail {{_DOT__} com] Date: 2008.08.21 Example usage: Case 1 (server): simple_echoer server port_num Case 2 (client): simple_echoer client port_num [hostname|ip] """ import os import socket import sys class simple_echoer: def __init__(self, port): self.port = int(port) def server(self): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((socket.gethostname(), self.port)) s.listen(1) i = 0 while 1: cli_s, __ = s.accept() print "Data received from client socket #", i, cli_s.recv(1500) i = i+1 def client_exit(): sys.exit(0) def client(self, hostname): while 1: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((socket.gethostbyname(hostname), self.port)) s.send("foo") def usage(): print """ Usage: simple_echoer {server|client} port_num [hostname,ip] Note: hostname is only required for the client. """ sys.exit(0) if len(sys.argv) <= 1 or (type != "client" && type != "server"): usage() type = sys.argv[1] if (len(sys.argv) != 4 and type == "client") or len(sys.argv) != 3 and type != "client": usage() se = simple_echoer(sys.argv[2]) if type == "server": se.server() else: se.client(sys.argv[3]) From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 13:23:44 2008 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 848D81065692; Thu, 21 Aug 2008 13:23:44 +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 5A4FE8FC0C; Thu, 21 Aug 2008 13:23:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7LDNi2d043452; Thu, 21 Aug 2008 13:23:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7LDNien043448; Thu, 21 Aug 2008 13:23:44 GMT (envelope-from linimon) Date: Thu, 21 Aug 2008 13:23:44 GMT Message-Id: <200808211323.m7LDNien043448@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address 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, 21 Aug 2008 13:23:44 -0000 Old Synopsis: CARP interface renaming makes system no longer respond on the virtual IP address New Synopsis: [carp] CARP interface renaming makes system no longer respond on the virtual IP address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 21 13:23:18 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126714 From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 16:56:13 2008 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 8C9DD1065674 for ; Thu, 21 Aug 2008 16:56:13 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4689F8FC18 for ; Thu, 21 Aug 2008 16:56:13 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so34550yxb.13 for ; Thu, 21 Aug 2008 09:56:12 -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:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=KTD03OZncgUAOPWaUnGMXHNldrpD2X2a0iiVQb48QdQ=; b=u6JAsE/ePCqmt2RDJAX9tFXhEhQ+3MLSQGGDqobPDZafAL59/fnJT+JP16lojhfDJv BabQuA+J39WFTKjwtCzCfJoHKp7sQUkk0dCtTIXGAyEEcasAfwKIXGTGNgi6rGzgbr2V oxdsgOV0TBFGH5xEJ9IHjhaPNV2deOoxSfCQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NA+4c4oVmdyeacF/EMQg10sBYAa2CXkfkmhLE3fQnWXS0N9zYuJc0Gi0qkw1e0Z4PF gg4F9BULiFF9R5I3/yUuGGnHeT+m+K801cOBy3fqImppnPLuPvhWL/KAB/yBa6BSP+xD dkhITSWqqKqZH5wUjB1y7BoTqGqdAm84aWIcM= Received: by 10.103.247.5 with SMTP id z5mr1079722mur.24.1219336116615; Thu, 21 Aug 2008 09:28:36 -0700 (PDT) Received: by 10.103.40.12 with HTTP; Thu, 21 Aug 2008 09:28:36 -0700 (PDT) Message-ID: Date: Thu, 21 Aug 2008 12:28:36 -0400 From: "Scott Ullrich" To: "Julian Elischer" In-Reply-To: <48ACFB17.9030901@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ACFB17.9030901@elischer.org> Cc: FreeBSD Net Subject: Re: m0n0wall/pfsense question. 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, 21 Aug 2008 16:56:13 -0000 On 8/21/08, Julian Elischer wrote: > > Does anyone know whether the above mentionned bsd systems boot to a ram > disk or keep their filesystem on teh flash/disk? pfSense keeps the filesystem and m0n0wall runs out of a memory backed system. Hope this helps, Scott From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 17:36:24 2008 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 2DFB3106568A for ; Thu, 21 Aug 2008 17:36:24 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.237]) by mx1.freebsd.org (Postfix) with ESMTP id D18118FC1B for ; Thu, 21 Aug 2008 17:36:23 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: by qb-out-0506.google.com with SMTP id e34so113395qbe.35 for ; Thu, 21 Aug 2008 10:36:22 -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:to :subject:in-reply-to:mime-version:content-type:references; bh=4TpzL85nHpeb53r8Wt+FoJQT9Q6SvCVaX5jfYQXNIAg=; b=IMrtVsrrIVITnHvUVir1C7rJlnxfRn0tWgRUKXlUpWh5hReR5/VXvStMy/8a32sQOD 0by0VeoYjZed0DwfrhR2HasvHnqFDk2BVtokU9VExARGQBTdwYqgfCUY+ykaFJ8t7Zi2 8783USVpURoJfW6IoLBieHjwN/AM30so+KEHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=aFt1wN2k7iuo9UOZ25alUoyV0Ct41gTkoQVOrO4V8qSW559hVcRQIOKogKxsNjyw+t sWMc5+2zX33p/ecIvj2zov81H2X1aFPrFofWsXO4mumqOR8yZ2OYcWpzFVhRhvDRWYgO 2n3lTScSLLDeQm7+gfTpn+jrzx8VAMeP3wGDY= Received: by 10.103.20.7 with SMTP id x7mr20941mui.75.1219340182211; Thu, 21 Aug 2008 10:36:22 -0700 (PDT) Received: by 10.102.247.18 with HTTP; Thu, 21 Aug 2008 10:36:22 -0700 (PDT) Message-ID: <9196e72b0808211036j65207771sd384a376601a3a0f@mail.gmail.com> Date: Thu, 21 Aug 2008 19:36:22 +0200 From: "Popof Popof" To: dewayne_freebsd@yahoo.com, "FreeBSD Net" In-Reply-To: <506570.91627.qm@web46401.mail.sp1.yahoo.com> MIME-Version: 1.0 References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <506570.91627.qm@web46401.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: How to make two vlans on one interface working with dhclient 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, 21 Aug 2008 17:36:24 -0000 I tried to change the MAC address of rl0.2101 and rl0.100 but this not changed anything. Any other idea ? PS: The exact parameter of ifconfig is lladdr 2008/8/21 Dewayne Geraghty > --- On *Wed, 8/20/08, Popof Popof * wrote: > From: Popof Popof > Subject: How to make two vlans on one interface working with dhclient > To: "FreeBSD Net" > Date: Wednesday, August 20, 2008, 1:13 PM > > Hi, > I have a FreeBSD 6.0 box andi need to configure it in a way that I must use > 2 vlans under one interface and both of them will get an address thanks to > dhclient. > > So in order to make this job I created vlans: > > ifconfig rl0.100 create > ifconfig rl0.2101 create > The vlans are created without any problem. > But I also want to retrieve an diffrent ip address from a dhcpd server on > the two of them. > I've made a specific dhclient.conf for each one: > > interface "rl0.100" { > #My options > } > interface > "rl0.2101" { > #My options > } > > When I launch dhclient on only one interface (100 or 2101) it's works fine > and I get an ip address (class B on vlan 100 and class A on vlan 2101). > But if I launch dhclient on the second interface it's make an error: > > dhclient: Can't bind to dhcp address: Address already in use. Please make > sure there is no other dhcp server runing and that there's no entry for > dhcp > or bootp in /etc/inetd.conf > > Does someone had an idea about how to fix this problem and having my two > vlans working with dhclient? > -------------- > > Popof, > You might need to assign a different MAC address to the interface, try > ifconfig rl0.2101 laddr 00:e0:4c:08:ea:6a > > > > From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 18:43:27 2008 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 A5353106566B for ; Thu, 21 Aug 2008 18:43:27 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 221658FC18 for ; Thu, 21 Aug 2008 18:43:26 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m7LIi4qq046759; Thu, 21 Aug 2008 13:44:04 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m7LIi4q3046758; Thu, 21 Aug 2008 13:44:04 -0500 (CDT) (envelope-from brooks) Date: Thu, 21 Aug 2008 13:44:04 -0500 From: Brooks Davis To: Popof Popof Message-ID: <20080821184404.GA46725@lor.one-eyed-alien.net> References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Net Subject: Re: How to make two vlans on one interface working with dhclient 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, 21 Aug 2008 18:43:27 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 20, 2008 at 03:13:00PM +0200, Popof Popof wrote: > Hi, > I have a FreeBSD 6.0 box andi need to configure it in a way that I must u= se > 2 vlans under one interface and both of them will get an address thanks to > dhclient. >=20 > So in order to make this job I created vlans: >=20 > ifconfig rl0.100 create > ifconfig rl0.2101 create > The vlans are created without any problem. > But I also want to retrieve an diffrent ip address from a dhcpd server on > the two of them. > I've made a specific dhclient.conf for each one: >=20 > interface "rl0.100" { > #My options > } > interface "rl0.2101" { > #My options > } Unless it's absolutly necessicary I don't recommend using dhclient.conf. I don't test it. > When I launch dhclient on only one interface (100 or 2101) it's works fine > and I get an ip address (class B on vlan 100 and class A on vlan 2101). > But if I launch dhclient on the second interface it's make an error: >=20 > dhclient: Can't bind to dhcp address: Address already in use. Please make > sure there is no other dhcp server runing and that there's no entry for d= hcp > or bootp in /etc/inetd.conf > > Does someone had an idea about how to fix this problem and having my two > vlans working with dhclient? The current dhclinet scripts don't really support this case. In theory if = you removed support for default routes and resolv.conf setting it should probab= ly work, but it's certainly not something I'd expect to work. -- Brooks --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIrbdzXY6L6fI4GtQRAgP1AKC2+yhS/joHidUrcZgVzW0E0n1EOQCfax+2 vWnm46f9CGqupyAJlWOPqSE= =Nn2h -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 18:49:54 2008 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 0BC8C1065679 for ; Thu, 21 Aug 2008 18:49:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id E51B38FC34 for ; Thu, 21 Aug 2008 18:49:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 517BA2482; Thu, 21 Aug 2008 11:50:00 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 7A3382D6017; Thu, 21 Aug 2008 11:49:53 -0700 (PDT) Message-ID: <48ADB8D0.4040705@elischer.org> Date: Thu, 21 Aug 2008 11:49:52 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Brooks Davis References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <20080821184404.GA46725@lor.one-eyed-alien.net> In-Reply-To: <20080821184404.GA46725@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Popof Popof , FreeBSD Net Subject: Re: How to make two vlans on one interface working with dhclient 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, 21 Aug 2008 18:49:54 -0000 Brooks Davis wrote: > On Wed, Aug 20, 2008 at 03:13:00PM +0200, Popof Popof wrote: >> Hi, >> I have a FreeBSD 6.0 box andi need to configure it in a way that I must use >> 2 vlans under one interface and both of them will get an address thanks to >> dhclient. >> >> So in order to make this job I created vlans: >> >> ifconfig rl0.100 create >> ifconfig rl0.2101 create >> The vlans are created without any problem. >> But I also want to retrieve an diffrent ip address from a dhcpd server on >> the two of them. >> I've made a specific dhclient.conf for each one: >> >> interface "rl0.100" { >> #My options >> } >> interface "rl0.2101" { >> #My options >> } > > Unless it's absolutly necessicary I don't recommend using dhclient.conf. I > don't test it. > >> When I launch dhclient on only one interface (100 or 2101) it's works fine >> and I get an ip address (class B on vlan 100 and class A on vlan 2101). >> But if I launch dhclient on the second interface it's make an error: >> >> dhclient: Can't bind to dhcp address: Address already in use. Please make >> sure there is no other dhcp server runing and that there's no entry for dhcp >> or bootp in /etc/inetd.conf >> >> Does someone had an idea about how to fix this problem and having my two >> vlans working with dhclient? > > The current dhclinet scripts don't really support this case. In theory if you > removed support for default routes and resolv.conf setting it should probably > work, but it's certainly not something I'd expect to work. use vimage :-) > > -- Brooks From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 18:53:11 2008 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 660321065674 for ; Thu, 21 Aug 2008 18:53:11 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 4D62F8FC1E for ; Thu, 21 Aug 2008 18:53:11 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id E00AB3C049D; Thu, 21 Aug 2008 11:35:44 -0700 (PDT) Date: Thu, 21 Aug 2008 11:35:44 -0700 From: Christopher Cowart To: Javier Ubillos Message-ID: <20080821183544.GE25990@hal.rescomp.berkeley.edu> Mail-Followup-To: Javier Ubillos , freebsd-net@freebsd.org References: <1219265061.9118.29.camel@dib> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="ZRyEpB+iJ+qUx0kp" Content-Disposition: inline In-Reply-To: <1219265061.9118.29.camel@dib> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org Subject: Re: erride default ICMP (and other protocols) default replies. 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, 21 Aug 2008 18:53:11 -0000 --ZRyEpB+iJ+qUx0kp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Javier Ubillos wrote: > Hi freebsd-net. > (Sorry for cross posting. This time I think I found the right forum for > my question) >=20 > I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually > NAT, but it's a good analogy for this case). >=20 > I have chosen to use pcaplib to pick up the packets. I have an > implementation which picks up the packets, inspects them, rewrites the > destination/source ip-addresses and sends them out on the repective > interface. >=20 > The problem I'm facing however is that my interfaces are answering to > e.g. icmp-echo (ping) automatically, and I don't know how to turn this > behaviour off. >=20 > What I want to happen is that if A pings C, my router B in between > should simply forward the packets w/o any automatic reactions. >=20 > A --> B --> C >=20 > So that if e.g. C is down, no echo-reply is sent back (or if C is up, > that C is actually sending the echo-reply. >=20 > Does any one know how to turn off the automatic replies (ICMP and > whatever else I haven't forseen yet) or does any one know where I can > find out more about the issue? I'm using ipfw(8), ng_ipfw(4), ng_nat(4), and arp(8) to acheive these results. I have a transparent HTTP proxy via squid that dynamically runs code to setup 1-to-1 NAT rules for users who authenticate to our wireless network. I have a clean 7.0 build, except I patched ng_nat to 7-STABLE to get the functionality of the 'redirectaddr' message. Some relevant code snippets from the system: $onatid and $inatid are deterministic identifiers for numbering the netgraph nodes (they're a function of the public IP assigned).=20 On setup: | ngctl mkpeer ipfw: nat $onatid out | ngctl name ipfw:$onatid $name | ngctl connect ipfw: ${name}: $inatid in | ngctl msg ${name}: setaliasaddr $public_ip | ngctl msg ${name}: redirectaddr '{' \ | "local_addr=3D$private_ip" \ | "alias_addr=3D$public_ip" \ | 'description=3D"Static NAT"' \ | '}' | | # Clear any arp entries for this IP that might be in the table, just | # to keep things consistent | arp -d "$public_ip" >/dev/null 2>&1 | | # Use arp(8) to claim this public IP address | arp -s $public_ip $aux_mac pub 2>&1 | nac_log | | ipfw table $private_table add $private_ip $onatid | ipfw table $public_table add $public_ip $inatid On teardown: | arp -d "$public_ip" | ngctl shutdown ipfw:${onatid} | for table in $PRIVATE_TABLES ; do | ipfw -q table $table delete $private_ip $onatid | done | for table in $PUBLIC_TABLES ; do | ipfw -q table $table delete $public_ip $inatid | done This corresponds with the following in ipfw.rules (note by this point in the ruleset, all "management" traffic has been dealt with): | # NAT all traffic coming in from authenticated users | $cmd netgraph tablearg all from "table($TABLE_WIFI_PRIV_AUTH)" to any in | for net in $NAC_PUBLIC_NETS ; do |=20 | # NAT all traffic coming in to authenticated users | $cmd netgraph tablearg all from any to "table($TABLE_WIFI_PUB_AUTH)" \ | in via $(nac_if "$net") |=20 | # We must set interface and direction on these fwd rules. If not, they | # will match traffic from any other hosts on these subnets (including | # the router) and deflect traffic in the wrong direction. | for privnet in $NAC_PRIVATE_NETS ; do | $cmd fwd $(nac_router "$net") ip from $(nac_subnet "$net") to not= \ | $(nac_subnet "$net") in via $(nac_if "$privnet") | done | done | $cmd allow all from any to "table($TABLE_WIFI_PRIV_AUTH)" | $cmd allow all from "table($TABLE_WIFI_PUB_AUTH)" to any For each subnet I'm using, I assign an IP to this FreeBSD box so that it knows how to get to the gateway. The published arp entries take care of "claiming" the addresses that are in-use and getting the IP traffic passed up the stack. ipfw intercepts, does the packet-munging, and forwards the results. The hosts behind this box (dubbed an "aux-router" internally) see all IP traffic destined for them -- incoming ICMP or TCP or UDP all gets where it's supposed to go. There is no state across reboots. You may be able to get things working the way you want by *not* using ifconfig to assign address, but instead using this arp(8) trick. You may find the use of ng_nat suits your needs though. Let me know if any of this is unclear. --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --ZRyEpB+iJ+qUx0kp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iQIcBAEBAwAGBQJIrbWAAAoJEIGh6j3cHUNPS3oQALGw0cxnv5QMND6PmCEre00o xgdtkEboIdw8BOK28roARkTN7daXNV7L3dQFtL97kkUM6eesQITZvGk96oTLQkbx wsxAqV1Gy/0G+9T+IqYkLL4CIwf99pFN9yMnPwoxAVCT3WboWixonklj/q3iugo7 xA8QywAHaHNczEgH2oR2dwmmlcZzVzu/cqXCjEmxAczOmv3x1EsdqpZc7/j8DKwb kJh/0+4QBnJ5qj7MuAsbg+Po5N1TKPl8FWgHNpXmhqZsHG3HZWRipGukj/sIUolX CM9WUqQHiUzfhNLLp5mJ3VX3LIk29cf1hi1dpDZE+qKpLmqbzp6HEcKMpBK4DzkO jwF8Dn+2Kma6ySXQK98O9r/EczyT4vFYDkMw/jTA2j/4N1hbUau0KXKpMbjz5wJl Q3XsAvrmbjuTB9YY6+BH7SGaODNNs+2fwn6Jj+tg/AN6IfNIxuVxhhInGqUGZvRh WNXIoi212I3FrjbK7nfP0XVUY/O+pFufX8NNZGBK4GrqubBVAChuSu+t6ue9u5DX reCApsnec6Z+qiK4Lrve7rBWF32AKMRmybwN66kJE+ypgJ7XdKGoXUxKPAcFBuTN Od53KX3gyt6x8wEiv7jPUmB1+zf3SA85Q4BTpD4UsFlwuHTTXl0kz557zBxaLfQo 9csrvBge1Cchp8nNQ0O+ =Eo8z -----END PGP SIGNATURE----- --ZRyEpB+iJ+qUx0kp-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 19:03:55 2008 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 B9F481065674 for ; Thu, 21 Aug 2008 19:03:55 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6544D8FC0C for ; Thu, 21 Aug 2008 19:03:55 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: by qb-out-0506.google.com with SMTP id e34so158698qbe.35 for ; Thu, 21 Aug 2008 12:03:54 -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:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=qdpKfL1mafKw7EREFP3AuqwFLC5fvX+Jx+K1U7z/I1U=; b=lHutuEpZ+chiHkf2mae7UCfL4XH0Cihs974lpAyNVwgX8TP7glWker2BIMXuVUvGa3 SVhOeLdCCMyY+NI8AmPXhtXmrL3qrul3sSJimdMTEzJH4Ggrr3zjaFYCAT8Ot/EnD7MU FePNnmZMdMvNxrsxtGsrYJpLu+7rK/63Nkr78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=f4znxs7i77PoSLFiEX+kguX7xd3T9VDTsxW0JTwm73FI2sfMpxFdbOZCHy3AqgFnNy NUXq9HmNWJTXF/oAdBCNepgXWZFG9+Z0HLtkaL4XdNfykzRHB2D0TJYXoav3zkoJKlXQ J9aRdWPhMJIV/eOodG25ZrAIYvx0m3vcv1W2c= Received: by 10.103.170.13 with SMTP id x13mr95051muo.27.1219345433865; Thu, 21 Aug 2008 12:03:53 -0700 (PDT) Received: by 10.102.247.18 with HTTP; Thu, 21 Aug 2008 12:03:53 -0700 (PDT) Message-ID: <9196e72b0808211203j746196fdhc17a221e12e8f065@mail.gmail.com> Date: Thu, 21 Aug 2008 21:03:53 +0200 From: "Popof Popof" To: "Julian Elischer" In-Reply-To: <48ADB8D0.4040705@elischer.org> MIME-Version: 1.0 References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <20080821184404.GA46725@lor.one-eyed-alien.net> <48ADB8D0.4040705@elischer.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Brooks Davis , frankhelbert82@gmail.com Subject: Re: How to make two vlans on one interface working with dhclient 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, 21 Aug 2008 19:03:55 -0000 Here is the output from my ifconfig (I rename rl0.100 and rl0.2101 in vlan0 and vlan1, the RJ45 wire is disconected because i need internet in order to send this message :p ): rl0: flags=8843 mtu 1500 options=8 inet6 fe80::2e0:4dff:fe30:80e1%rl0 prefixlen 64 scopeid 0x1 ether 00:e0:4d:30:80:e1 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=0<> mtu 33208 vlan0: flags=8843 mtu 1500 inet6 fe80::2e0:4dff:fe30:80e1%vlan0 prefixlen 64 scopeid 0x5 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:e0:4d:30:80:a0 media: Ethernet autoselect (none) status: no carrier vlan: 100 parent interface: rl0 vlan1: flags=8843 mtu 1500 inet6 fe80::2e0:4dff:fe30:80e1%vlan1 prefixlen 64 scopeid 0x6 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:e0:4d:30:80:a1 media: Ethernet autoselect (none) status: no carrier vlan: 2101 parent interface: rl0 In order to configure my vlan i follow this guide: http://people.freebsd.org/~arved/vlan/vlan_en.html > Unless it's absolutly necessicary I don't recommend using dhclient.conf. I > don't test it. The problem is that i have to get an ip address from my FAI (i'm trying to bypass my modem, i have an optical connection with an RJ45 instead of RJ11 and I need vlan 100 for internet and 2101 for tv) > The current dhclinet scripts don't really support this case. In theory if you > removed support for default routes and resolv.conf setting it should probably > work, but it's certainly not something I'd expect to work. How do you remove support for default routes and reslov.conf ? I don't understand what do you mean > use vimage :-) If i understand well vimage is used for jail but i need to have those two vlans because my box act like a router and will send data over my switch. From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 19:12:03 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DFEB1065685 for ; Thu, 21 Aug 2008 19:12:03 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 0DFA38FC18 for ; Thu, 21 Aug 2008 19:12:03 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7LJC1Ia024676 for ; Thu, 21 Aug 2008 12:12:02 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7LJBviI080990 for ; Thu, 21 Aug 2008 12:11:57 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7LJBurm024589 for ; Thu, 21 Aug 2008 12:11:57 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 21 Aug 2008 15:11:56 -0400 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1307048 - 5fc7c4743b7e X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Subject: Small patch to multicast code... 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, 21 Aug 2008 19:12:03 -0000 Hi, Turns out there is a bug in the code that loops back multicast packets. If the underlying device driver supports checksum offloading then the packet that is looped back, when it is transmitted on the wire, is incorrect, due to the fact that the packet is not fully copied. Here is a patch. Comments welcome. Best, George Index: ip_output.c =================================================================== --- ip_output.c (revision 181731) +++ ip_output.c (working copy) @@ -1135,7 +1135,7 @@ register struct ip *ip; struct mbuf *copym; - copym = m_copy(m, 0, M_COPYALL); + copym = m_dup(m, M_DONTWAIT); if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) copym = m_pullup(copym, hlen); if (copym != NULL) { From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 20:47:39 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 037171065671 for ; Thu, 21 Aug 2008 20:47:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3DE8FC15 for ; Thu, 21 Aug 2008 20:47:38 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 877E01CE1E; Thu, 21 Aug 2008 22:47:36 +0200 (CEST) Date: Thu, 21 Aug 2008 22:47:36 +0200 From: Ed Schouten To: net@FreeBSD.org Message-ID: <20080821204736.GR99951@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mqiO+KvAMpTa4r4+" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) 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, 21 Aug 2008 20:47:39 -0000 --mqiO+KvAMpTa4r4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Before I start talking about any technical stuff, I want to mention I'm so far pretty happy with the MPSAFE TTY import. Even though I spent a lot of time close to my mailbox, the amount of troubles caused by the import have remained pretty low (there's only one open bug report, related to ucom(4)), though I'm sure I'll receive lots more the next couple of weeks. Today I thought it would be a good idea to work on my first post-import task, namely designing a hooks interface, which allows other kernel subsystems to inject/capture data. We need such an interface to implement things like snp(4), ppp(4), sl(4), ng_h4(4) and ng_tty(4). As an experiment, I tried to rewrite snp(4), which succeeded (though it needs some polishing before it can hit the tree). There are actually two things I want to discuss in this thread: - Feedback on the current design of the hooks interface. - Figure out which hooks we'll need. We need to know what data is relevant to these line disciplines. =3D=3D=3D Current design =3D=3D=3D As I said earlier, I've only got the snp(4) driver working again. A thing I liked about the snp(4) driver, is the way it binds TTY's and snoop instances together. There's this ioctl() called SNPSTTY which is called on a /dev/snp descriptor, which takes a file descriptor as an argument, pointing to the TTY. So right now the API is as follows: | static struct ttyhook myhook =3D { | .th_a_hook_we_like_1 =3D mydriver_foo, | .th_a_hook_we_like_2 =3D mydriver_bar, | ... | }; |=20 | static int | mydriver_ioctl(...) | { | struct tty *tp; | | switch (cmd) { | case MYDRIVER_CONNECT_TO_TTY: | error =3D ttyhook_register(&tp, td, *(int *)data, | &myhook, softc); | if (error !=3D 0) | return (error); | } | return (ENOTTY); | } The ttyhook_register() routine handles the filedescriptor number to TTY translation safely, so this makes it a lot better than the old programming interface in my opinion. When you want to disconnect the hook, it is often as simple as: | tty_lock(tp); | ttyhook_unregister(tp); /* This releases the lock. */ The hooks are called by the TTY layer with the per-TTY lock held. The consumer can also store 1 pointer inside the TTY structure, which can be obtained by calling ttyhook_softc(). A TTY can only have one associated hook. I think in a lot of cases drivers will just borrow the TTY's lock to lock down some private data as well. =3D=3D=3D Requirements by the NetGraph folks =3D=3D=3D So this is actually my question to the people on net@. I suspect the NetGraph bits can be restored again if I add the following hooks to the ttyhook interface: - A hook which gets called each time data arrives on the device (`rint'). When this hook is installed, data will not be delivered to the actual TTY, but diverted to the subsystem in question. - A hook which gets called when the device driver would like to have some data to transmit (`getc'). It just offers a buffer, which can be filled by the subsystem. - A hook which notifies the subsystem of a loss of carrier, device disconnected, etc. A nice thing about the new TTY layer is that we don't need to have any horrible code to convert between mbufs and clists. You can directly copy data from mbufs to the driver's buffers. I'll also document various methods to implement both flow control on input and output. So this is actually what I wanted to tell. I've already got a prototype of the ttyhook interface stored at: http://people.FreeBSD.org/~ed/mpsafetty/ The diffs as of August 21 should just apply on top of SVN. It includes a patched snp(4). Yours, --=20 Ed Schouten WWW: http://80386.nl/ --mqiO+KvAMpTa4r4+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkit1GgACgkQ52SDGA2eCwXQ5QCaAoKUFH5Hkun6b+1g2AvZhBu2 /fEAni1r4zvHLsEYWCLLU8W07OFR0YoZ =SpTe -----END PGP SIGNATURE----- --mqiO+KvAMpTa4r4+-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 20:51:59 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84248106566B; Thu, 21 Aug 2008 20:51:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 43FA48FC1E; Thu, 21 Aug 2008 20:51:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1AB7A7308B; Thu, 21 Aug 2008 22:35:19 +0200 (CEST) Date: Thu, 21 Aug 2008 22:35:19 +0200 From: Luigi Rizzo To: gnn@freebsd.org Message-ID: <20080821203519.GA51534@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Small patch to multicast code... 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, 21 Aug 2008 20:51:59 -0000 On Thu, Aug 21, 2008 at 03:11:56PM -0400, gnn@freebsd.org wrote: > Hi, > > Turns out there is a bug in the code that loops back multicast > packets. If the underlying device driver supports checksum offloading > then the packet that is looped back, when it is transmitted on the > wire, is incorrect, due to the fact that the packet is not fully > copied. > > Here is a patch. Comments welcome. > > Best, > George > > Index: ip_output.c > =================================================================== > --- ip_output.c (revision 181731) > +++ ip_output.c (working copy) > @@ -1135,7 +1135,7 @@ > register struct ip *ip; > struct mbuf *copym; > > - copym = m_copy(m, 0, M_COPYALL); > + copym = m_dup(m, M_DONTWAIT); > if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) > copym = m_pullup(copym, hlen); > if (copym != NULL) { I am slightly puzzled -- what is exactly the problem, i.e. what part of the packet on the wire is incorrect ? The IP header is within hlen so the m_pullup() should be enough to leave the original content intact. The only thing i can think of is that it's the UDP checksum, residing beyond hlen, which is overwritten somewhere in the call to if_simloop -- in which case perhaps a better fix is to m_pullup() the udp header as well ? (in any case, it is worthwhile to add a comment to explain what should be done -- the code paths using m_*() have become quite fragile with these hw support enhancements that now require selective modifications on previously shared, readonly buffers). cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Aug 21 21:59:51 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 548531065673 for ; Thu, 21 Aug 2008 21:59:51 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 1835D8FC0C for ; Thu, 21 Aug 2008 21:59:51 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7LLxnok035076; Thu, 21 Aug 2008 14:59:50 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7LLxdeU044518; Thu, 21 Aug 2008 14:59:39 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7LLxcT6067264; Thu, 21 Aug 2008 14:59:38 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 21 Aug 2008 17:59:38 -0400 Message-ID: From: gnn@freebsd.org To: Luigi Rizzo In-Reply-To: <20080821203519.GA51534@onelab2.iet.unipi.it> References: <20080821203519.GA51534@onelab2.iet.unipi.it> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1308581 - 07a3d7351bc3 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: net@freebsd.org Subject: Re: Small patch to multicast code... 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, 21 Aug 2008 21:59:51 -0000 At Thu, 21 Aug 2008 22:35:19 +0200, Luigi Rizzo wrote: > > On Thu, Aug 21, 2008 at 03:11:56PM -0400, gnn@freebsd.org wrote: > > Hi, > > > > Turns out there is a bug in the code that loops back multicast > > packets. If the underlying device driver supports checksum offloading > > then the packet that is looped back, when it is transmitted on the > > wire, is incorrect, due to the fact that the packet is not fully > > copied. > > > > Here is a patch. Comments welcome. > > > > Best, > > George > > > > Index: ip_output.c > > =================================================================== > > --- ip_output.c (revision 181731) > > +++ ip_output.c (working copy) > > @@ -1135,7 +1135,7 @@ > > register struct ip *ip; > > struct mbuf *copym; > > > > - copym = m_copy(m, 0, M_COPYALL); > > + copym = m_dup(m, M_DONTWAIT); > > if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) > > copym = m_pullup(copym, hlen); > > if (copym != NULL) { > > I am slightly puzzled -- what is exactly the problem, i.e. what part > of the packet on the wire is incorrect ? The IP header is within hlen so > the m_pullup() should be enough to leave the original content intact. > > The only thing i can think of is that it's the UDP checksum, > residing beyond hlen, which is overwritten somewhere in the > call to if_simloop -- in which case perhaps a better fix is > to m_pullup() the udp header as well ? It is the checksum that gets trashed, yes. > (in any case, it is worthwhile to add a comment to explain > what should be done -- the code paths using m_*() have become > quite fragile with these hw support enhancements that now > require selective modifications on previously shared, readonly buffers). The m_*() routines actually have reasonable comments, it just seems the wrong one was used here. Best, Gerge From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 01:28:07 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C669106566B for ; Fri, 22 Aug 2008 01:28:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 71D788FC15 for ; Fri, 22 Aug 2008 01:28:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 75256242A; Thu, 21 Aug 2008 18:14:37 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 4B90A2D6085; Thu, 21 Aug 2008 18:14:36 -0700 (PDT) Message-ID: <48AE12FC.80304@elischer.org> Date: Thu, 21 Aug 2008 18:14:36 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ed Schouten References: <20080821204736.GR99951@hoeg.nl> In-Reply-To: <20080821204736.GR99951@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) 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, 22 Aug 2008 01:28:07 -0000 Ed Schouten wrote: > Hello everyone, > > Before I start talking about any technical stuff, I want to mention I'm > so far pretty happy with the MPSAFE TTY import. Even though I spent a > lot of time close to my mailbox, the amount of troubles caused by the > import have remained pretty low (there's only one open bug report, > related to ucom(4)), though I'm sure I'll receive lots more the next > couple of weeks. > > Today I thought it would be a good idea to work on my first post-import > task, namely designing a hooks interface, which allows other kernel > subsystems to inject/capture data. We need such an interface to > implement things like snp(4), ppp(4), sl(4), ng_h4(4) and ng_tty(4). > > As an experiment, I tried to rewrite snp(4), which succeeded (though it > needs some polishing before it can hit the tree). There are actually two > things I want to discuss in this thread: > > - Feedback on the current design of the hooks interface. > - Figure out which hooks we'll need. We need to know what data is > relevant to these line disciplines. > > === Current design === > > As I said earlier, I've only got the snp(4) driver working again. A > thing I liked about the snp(4) driver, is the way it binds TTY's and > snoop instances together. There's this ioctl() called SNPSTTY which is > called on a /dev/snp descriptor, which takes a file descriptor as an > argument, pointing to the TTY. > > So right now the API is as follows: > > | static struct ttyhook myhook = { > | .th_a_hook_we_like_1 = mydriver_foo, > | .th_a_hook_we_like_2 = mydriver_bar, > | ... > | }; > | > | static int > | mydriver_ioctl(...) > | { > | struct tty *tp; > | > | switch (cmd) { > | case MYDRIVER_CONNECT_TO_TTY: > | error = ttyhook_register(&tp, td, *(int *)data, > | &myhook, softc); > | if (error != 0) > | return (error); > | } > | return (ENOTTY); > | } > > The ttyhook_register() routine handles the filedescriptor number to TTY > translation safely, so this makes it a lot better than the old > programming interface in my opinion. When you want to disconnect the > hook, it is often as simple as: > > | tty_lock(tp); > | ttyhook_unregister(tp); /* This releases the lock. */ > > The hooks are called by the TTY layer with the per-TTY lock held. The > consumer can also store 1 pointer inside the TTY structure, which can be > obtained by calling ttyhook_softc(). A TTY can only have one associated > hook. I think in a lot of cases drivers will just borrow the TTY's lock > to lock down some private data as well. > > === Requirements by the NetGraph folks === > > So this is actually my question to the people on net@. I suspect the > NetGraph bits can be restored again if I add the following hooks to the > ttyhook interface: > > - A hook which gets called each time data arrives on the device > (`rint'). When this hook is installed, data will not be delivered to > the actual TTY, but diverted to the subsystem in question. > > - A hook which gets called when the device driver would like to have > some data to transmit (`getc'). It just offers a buffer, which can be > filled by the subsystem. > > - A hook which notifies the subsystem of a loss of carrier, device > disconnected, etc. > > A nice thing about the new TTY layer is that we don't need to have any > horrible code to convert between mbufs and clists. You can directly copy > data from mbufs to the driver's buffers. I'll also document various > methods to implement both flow control on input and output. > > So this is actually what I wanted to tell. I've already got a prototype > of the ttyhook interface stored at: > > http://people.FreeBSD.org/~ed/mpsafetty/ > > The diffs as of August 21 should just apply on top of SVN. It includes a > patched snp(4). got a p4 pointer? > > Yours, From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 02:46:01 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169CD1065686; Fri, 22 Aug 2008 02:46:01 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id DCBA08FC0A; Fri, 22 Aug 2008 02:46:00 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id D34D215A231; Thu, 21 Aug 2008 22:27:13 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 21 Aug 2008 22:27:13 -0400 X-Sasl-enc: 8GHuAt3xm/LGTp47OoPbROihskpIucGBQP9kn+zB9wwr 1219372033 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1CBC020FF5; Thu, 21 Aug 2008 22:27:13 -0400 (EDT) Message-ID: <48AE23FF.9070009@FreeBSD.org> Date: Fri, 22 Aug 2008 03:27:11 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: gnn@freebsd.org References: <20080821203519.GA51534@onelab2.iet.unipi.it> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 02:46:01 -0000 gnn@freebsd.org wrote: >> The only thing i can think of is that it's the UDP checksum, >> residing beyond hlen, which is overwritten somewhere in the >> call to if_simloop -- in which case perhaps a better fix is >> to m_pullup() the udp header as well ? >> > > It is the checksum that gets trashed, yes. > ... > The m_*() routines actually have reasonable comments, it just seems > the wrong one was used here. > Actually, m_copy() has been legacy for some time now -- see comments. I'd be concerned that the change to m_dup() (which makes a full mbuf chain copy) rather than m_copym() (which bumps refcounts) is going to eat into the mbuf clusters on fast links, though it's an easy band-aid for the problem. I agree with Luigi that some of the API contract for mbuf(9) doesn't hold any more now that we have TSO and other offload. cheers BMS From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 04:10:04 2008 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 6C18A106564A for ; Fri, 22 Aug 2008 04:10:04 +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 59DA58FC1A for ; Fri, 22 Aug 2008 04:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7M4A4Qx022226 for ; Fri, 22 Aug 2008 04:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7M4A44d022225; Fri, 22 Aug 2008 04:10:04 GMT (envelope-from gnats) Date: Fri, 22 Aug 2008 04:10:04 GMT Message-Id: <200808220410.m7M4A44d022225@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/114714: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 04:10:04 -0000 The following reply was made to PR kern/114714; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/114714: commit references a PR Date: Fri, 22 Aug 2008 04:04:05 +0000 (UTC) thompsa 2008-08-22 03:55:37 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sbin/ifconfig Makefile ifconfig.8 share/man/man4 gre.4 sys/net if_gre.c if_gre.h Added files: (Branch: RELENG_7) sbin/ifconfig ifgre.c Log: SVN rev 181991 on 2008-08-22 03:55:37Z by thompsa MFC r179894, r181224 Add support for the optional key in the GRE header. PR: kern/114714 Submitted by: Cristian KLEIN Revision Changes Path 1.33.2.1 +1 -0 src/sbin/ifconfig/Makefile 1.142.2.6 +11 -1 src/sbin/ifconfig/ifconfig.8 1.1.2.1 +98 -0 src/sbin/ifconfig/ifgre.c (new) 1.7.2.1 +14 -2 src/share/man/man4/gre.4 1.46.2.5 +44 -3 src/sys/net/if_gre.c 1.13.10.2 +7 -0 src/sys/net/if_gre.h _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 05:17:08 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CF841065673 for ; Fri, 22 Aug 2008 05:17:08 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6288FC0C for ; Fri, 22 Aug 2008 05:17:08 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A9D511CE1E; Fri, 22 Aug 2008 07:17:07 +0200 (CEST) Date: Fri, 22 Aug 2008 07:17:07 +0200 From: Ed Schouten To: Julian Elischer Message-ID: <20080822051707.GU99951@hoeg.nl> References: <20080821204736.GR99951@hoeg.nl> <48AE12FC.80304@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JKz3AoCXl8aZ12np" Content-Disposition: inline In-Reply-To: <48AE12FC.80304@elischer.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: net@FreeBSD.org Subject: Re: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) 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, 22 Aug 2008 05:17:08 -0000 --JKz3AoCXl8aZ12np Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Julian Elischer wrote: > got a p4 pointer? Yes. It's just in //depot/projects/mpsafetty/..., just like where the MPSAFE TTY code used to live. --=20 Ed Schouten WWW: http://80386.nl/ --JKz3AoCXl8aZ12np Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiuS9MACgkQ52SDGA2eCwV57wCeP4qxi6r8ljoFvDymYPQYF/8a 1pQAn3R2ul2F/ocrXV/CsBwgrub6onCQ =ZFRO -----END PGP SIGNATURE----- --JKz3AoCXl8aZ12np-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 05:25:00 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31A13106567C for ; Fri, 22 Aug 2008 05:25:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 17AB38FC2E for ; Fri, 22 Aug 2008 05:24:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A7A6523F9; Thu, 21 Aug 2008 22:24:59 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C14512D602C; Thu, 21 Aug 2008 22:24:58 -0700 (PDT) Message-ID: <48AE4DAA.4080009@elischer.org> Date: Thu, 21 Aug 2008 22:24:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ed Schouten References: <20080821204736.GR99951@hoeg.nl> In-Reply-To: <20080821204736.GR99951@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: Post-MPSAFE TTY import task: fixing up line disciplines (Netgraph) 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, 22 Aug 2008 05:25:00 -0000 Ed Schouten wrote: > Hello everyone, > > Before I start talking about any technical stuff, I want to mention I'm > so far pretty happy with the MPSAFE TTY import. Even though I spent a > lot of time close to my mailbox, the amount of troubles caused by the > import have remained pretty low (there's only one open bug report, > related to ucom(4)), though I'm sure I'll receive lots more the next > couple of weeks. > > Today I thought it would be a good idea to work on my first post-import > task, namely designing a hooks interface, which allows other kernel > subsystems to inject/capture data. We need such an interface to > implement things like snp(4), ppp(4), sl(4), ng_h4(4) and ng_tty(4). > > As an experiment, I tried to rewrite snp(4), which succeeded (though it > needs some polishing before it can hit the tree). There are actually two > things I want to discuss in this thread: > > - Feedback on the current design of the hooks interface. > - Figure out which hooks we'll need. We need to know what data is > relevant to these line disciplines. > > === Current design === > > As I said earlier, I've only got the snp(4) driver working again. A > thing I liked about the snp(4) driver, is the way it binds TTY's and > snoop instances together. There's this ioctl() called SNPSTTY which is > called on a /dev/snp descriptor, which takes a file descriptor as an > argument, pointing to the TTY. > > So right now the API is as follows: > > | static struct ttyhook myhook = { > | .th_a_hook_we_like_1 = mydriver_foo, > | .th_a_hook_we_like_2 = mydriver_bar, > | ... > | }; > | > | static int > | mydriver_ioctl(...) > | { > | struct tty *tp; > | > | switch (cmd) { > | case MYDRIVER_CONNECT_TO_TTY: > | error = ttyhook_register(&tp, td, *(int *)data, > | &myhook, softc); > | if (error != 0) > | return (error); > | } > | return (ENOTTY); > | } > > The ttyhook_register() routine handles the filedescriptor number to TTY > translation safely, so this makes it a lot better than the old > programming interface in my opinion. When you want to disconnect the > hook, it is often as simple as: > > | tty_lock(tp); > | ttyhook_unregister(tp); /* This releases the lock. */ > > The hooks are called by the TTY layer with the per-TTY lock held. The > consumer can also store 1 pointer inside the TTY structure, which can be > obtained by calling ttyhook_softc(). A TTY can only have one associated > hook. I think in a lot of cases drivers will just borrow the TTY's lock > to lock down some private data as well. > > === Requirements by the NetGraph folks === > > So this is actually my question to the people on net@. I suspect the > NetGraph bits can be restored again if I add the following hooks to the > ttyhook interface: > > - A hook which gets called each time data arrives on the device > (`rint'). When this hook is installed, data will not be delivered to > the actual TTY, but diverted to the subsystem in question. yes, though the old interface would only call us once the 'terminator' character was received.. you could make each calling module supply its own "decide if to call yet" function.. so that the heavy calls were not done every time... > > - A hook which gets called when the device driver would like to have > some data to transmit (`getc'). It just offers a buffer, which can be > filled by the subsystem. > yep > - A hook which notifies the subsystem of a loss of carrier, device > disconnected, etc. a nice interface to set the hardware operating parameters (e.g baud, bits) might be nice too but I don't know if we would use it. > > A nice thing about the new TTY layer is that we don't need to have any > horrible code to convert between mbufs and clists. You can directly copy > data from mbufs to the driver's buffers. I'll also document various > methods to implement both flow control on input and output. having done this sort of hting before, the thing you want is th have an interface where you can pass to the tty system, the following things: A pointer to a number of bytes The number of the bytes A function to call when the tty system has finished with the buffer (maybe mfree()) An argument to give to that function. (probably the mbuf) to the tty subsystem, it's a buffer of bytes to the net system it's an mbuf. the 4 arguments could be separately done, or they could be bundled together in a small structure.. your choice. it might be overkill however if ther ewas just one byte to send, so a way to send up to 4 bytes in one simple call might be nice... > > So this is actually what I wanted to tell. I've already got a prototype > of the ttyhook interface stored at: > > http://people.FreeBSD.org/~ed/mpsafetty/ > > The diffs as of August 21 should just apply on top of SVN. It includes a > patched snp(4). > > Yours, From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 07:14:39 2008 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 700C2106567F for ; Fri, 22 Aug 2008 07:14:39 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.232]) by mx1.freebsd.org (Postfix) with ESMTP id 213B18FC1D for ; Fri, 22 Aug 2008 07:14:38 +0000 (UTC) (envelope-from popofnewslists@gmail.com) Received: by qb-out-0506.google.com with SMTP id e34so521716qbe.35 for ; Fri, 22 Aug 2008 00:14:38 -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:to :subject:in-reply-to:mime-version:content-type:references; bh=sav+63EusvJL/B4xo1qDew+Sn4Zrb23U2brKX5QVEkE=; b=if84kkqceahSbSS+1NrKfVjlaDhYwA4MeiDb25UzWXW5PqWF/mPUoJT2CdrOZ9WGON 6C+wNiSIblVpeqlEplbXfbniVW9B0tA/X0gFGHRvjfRRvk/iFNP24f+xQ3ZYmdxpVAkF Edz3+NoLwm+dkFdlCLtkcVLkHuSF4hLf/jppc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=DWMKuEDrufbyeWl8ZH8YbkGeZ9z71zz/nQAhWhXdRZ/zhxcOsHCfKsIwHIq4J1fU21 WPwU5Evx3h/WikA3sRLONQ7vvQleHlsbYcHANCqsvcLK+tB9GyWchadiqVzlL1IsyMKH c0DaGVJyKqCrFpc0i/O8oEiV/SFhGLFuxoEpc= Received: by 10.103.222.12 with SMTP id z12mr464235muq.12.1219389277700; Fri, 22 Aug 2008 00:14:37 -0700 (PDT) Received: by 10.102.247.18 with HTTP; Fri, 22 Aug 2008 00:14:37 -0700 (PDT) Message-ID: <9196e72b0808220014k4b917a08pac2261af88007819@mail.gmail.com> Date: Fri, 22 Aug 2008 09:14:37 +0200 From: "Popof Popof" To: "Frank Helbert" , "FreeBSD Net" In-Reply-To: MIME-Version: 1.0 References: <9196e72b0808200613q4557b034t9ab3e80d0ff1ec08@mail.gmail.com> <20080821184404.GA46725@lor.one-eyed-alien.net> <48ADB8D0.4040705@elischer.org> <9196e72b0808211203j746196fdhc17a221e12e8f065@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: How to make two vlans on one interface working with dhclient 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, 22 Aug 2008 07:14:39 -0000 Yes, i applied the modifications at the level of dhclient.conf 2008/8/21 Frank Helbert > Have you tried? > > interface "vlan0" { > #My options > } > interface "vlan1" { > #My options > } > > Thats the way you identify your vlan nics... > > Frank > > On Thu, Aug 21, 2008 at 4:03 PM, Popof Popof > wrote: > > Here is the output from my ifconfig (I rename rl0.100 and rl0.2101 in > vlan0 > > and vlan1, the RJ45 wire is disconected because i need internet in order > to > > send this message :p ): > > > > rl0: flags=8843 mtu 1500 > > options=8 > > inet6 fe80::2e0:4dff:fe30:80e1%rl0 prefixlen 64 scopeid 0x1 > > ether 00:e0:4d:30:80:e1 > > media: Ethernet autoselect (none) > > status: no carrier > > lo0: flags=8049 mtu 16384 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > inet 127.0.0.1 netmask 0xff000000 > > pflog0: flags=0<> mtu 33208 > > vlan0: flags=8843 mtu 1500 > > inet6 fe80::2e0:4dff:fe30:80e1%vlan0 prefixlen 64 scopeid 0x5 > > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > > ether 00:e0:4d:30:80:a0 > > media: Ethernet autoselect (none) > > status: no carrier > > vlan: 100 parent interface: rl0 > > vlan1: flags=8843 mtu 1500 > > inet6 fe80::2e0:4dff:fe30:80e1%vlan1 prefixlen 64 scopeid 0x6 > > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > > ether 00:e0:4d:30:80:a1 > > media: Ethernet autoselect (none) > > status: no carrier > > vlan: 2101 parent interface: rl0 > > > > In order to configure my vlan i follow this guide: > > http://people.freebsd.org/~arved/vlan/vlan_en.html > > > >> Unless it's absolutly necessicary I don't recommend using dhclient.conf. > >> I > >> don't test it. > > > > The problem is that i have to get an ip address from my FAI (i'm trying > to > > bypass my modem, i have an optical connection with an RJ45 instead of > RJ11 > > and I need vlan 100 for internet and 2101 for tv) > > > >> The current dhclinet scripts don't really support this case. In theory > if > >> you > >> removed support for default routes and resolv.conf setting it should > >> probably > >> work, but it's certainly not something I'd expect to work. > > > > How do you remove support for default routes and reslov.conf ? I don't > > understand what do you mean > > > >> use vimage :-) > > > > If i understand well vimage is used for jail but i need to have those two > > vlans because my box act like a router and will send data over my switch. > > > > > From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 08:27:47 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D0AB1065682; Fri, 22 Aug 2008 08:27:47 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C1EB28FC12; Fri, 22 Aug 2008 08:27:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3BE6C7308B; Fri, 22 Aug 2008 10:30:20 +0200 (CEST) Date: Fri, 22 Aug 2008 10:30:20 +0200 From: Luigi Rizzo To: "Bruce M. Simpson" Message-ID: <20080822083020.GA57441@onelab2.iet.unipi.it> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AE23FF.9070009@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: gnn@freebsd.org, net@freebsd.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 08:27:47 -0000 On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote: > gnn@freebsd.org wrote: > >>The only thing i can think of is that it's the UDP checksum, > >>residing beyond hlen, which is overwritten somewhere in the > >>call to if_simloop -- in which case perhaps a better fix is > >>to m_pullup() the udp header as well ? > >> > > > >It is the checksum that gets trashed, yes. > >... > >The m_*() routines actually have reasonable comments, it just seems > >the wrong one was used here. > > > > Actually, m_copy() has been legacy for some time now -- see comments. The API is undocumented, but in this specific function the reason for using one rather than the other is undocumented. Especially, if you use m_dup() then the call to m_pullup should be unnecessary. That's why I suggested to explain clearly what is wrong in the original code, so even if now we only apply a temporary bandaid (for lack of time, etc.) hopefully later this can be reverted to something more efficient such as pulling up the UDP header as well. cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 14:48:05 2008 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 806BF106567C for ; Fri, 22 Aug 2008 14:48:05 +0000 (UTC) (envelope-from mays@win.net) Received: from nb-209.win.net (nb-209.win.net [216.24.27.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5F58FC0A for ; Fri, 22 Aug 2008 14:48:05 +0000 (UTC) (envelope-from mays@win.net) Received: from engineering01 (216-24-33-10.ip.win.net [216.24.33.10]) by nb-209.win.net (Postfix) with SMTP id C09F9C601E for ; Fri, 22 Aug 2008 10:18:16 -0400 (EDT) Message-ID: <006e01c90462$339fb320$0a2118d8@engineering01> From: "Joseph Mays" To: Date: Fri, 22 Aug 2008 10:20:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Kernel Panic in SCTP 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, 22 Aug 2008 14:48:05 -0000 Hello. We've recently written an extensive software system that uses SCTP as a critical component. We've started to run into an issue where the box kenel panics after throwing an error message from sctp_timer.c that says "Our list is out of order? Out of order list". Can anyone here shed light on what's going on, or give us a clue how to debug this? http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 Joe Mays From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 15:45:10 2008 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 F1E4A1065681 for ; Fri, 22 Aug 2008 15:45:10 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id AACAC8FC19 for ; Fri, 22 Aug 2008 15:45:10 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from cmb.rambler.ramblermedia.com (unknown [81.19.91.60]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 9082A17083 for ; Fri, 22 Aug 2008 19:33:22 +0400 (MSD) Message-ID: <48AEDC40.6030901@citrin.ru> Date: Fri, 22 Aug 2008 19:33:20 +0400 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: bug in unix sockets garbage collector 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, 22 Aug 2008 15:45:11 -0000 On servers where used unix sockets, sometimes thread taskq start to eat 100% CPU: http://docs.FreeBSD.org/cgi/mid.cgi?474EFC5C.9060508 Addition info about this problem - when this occurs sysctl net.local.inflight show negative number. % sysctl net.local.inflight net.local.inflight: -3 And this condition become always true: if (local_unp_rights) taskqueue_enqueue(taskqueue_thread, &unp_gc_task); It seems, that unp_rights decremented more often than incremented, or some race exist. -- Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 16:42:52 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4EA4106564A; Fri, 22 Aug 2008 16:42:52 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 845318FC0A; Fri, 22 Aug 2008 16:42:52 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m7MGRPWU094848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2008 09:27:25 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48AEE8ED.7000301@freebsd.org> Date: Fri, 22 Aug 2008 09:27:25 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Luigi Rizzo References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <20080822083020.GA57441@onelab2.iet.unipi.it> In-Reply-To: <20080822083020.GA57441@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: gnn@freebsd.org, "Bruce M. Simpson" , net@freebsd.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 16:42:52 -0000 Luigi Rizzo wrote: > On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote: > >> gnn@freebsd.org wrote: >> >>>> The only thing i can think of is that it's the UDP checksum, >>>> residing beyond hlen, which is overwritten somewhere in the >>>> call to if_simloop -- in which case perhaps a better fix is >>>> to m_pullup() the udp header as well ? >>>> >>>> >>> It is the checksum that gets trashed, yes. >>> ... >>> The m_*() routines actually have reasonable comments, it just seems >>> the wrong one was used here. >>> >>> >> Actually, m_copy() has been legacy for some time now -- see comments. >> > > The API is undocumented, but in this specific function the reason > for using one rather than the other is undocumented. Especially, > if you use m_dup() then the call to m_pullup should be > unnecessary. > > That's why I suggested to explain clearly what is wrong in the original > code, so even if now we only apply a temporary bandaid (for lack of time, > etc.) hopefully later this can be reverted to something more efficient > such as pulling up the UDP header as well. > > I agree that doing the deep copy is just papering over a bigger problem. Sam From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 17:43:17 2008 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 8788D106568D for ; Fri, 22 Aug 2008 17:43:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3DCC28FC08 for ; Fri, 22 Aug 2008 17:43:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7MHJYXO053199 for ; Fri, 22 Aug 2008 13:19:34 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7MHJY25090566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Aug 2008 13:19:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808221719.m7MHJY25090566@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Aug 2008 13:19:36 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Subject: strange TCP issue on RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 17:43:17 -0000 On one of our sendmail boxes that we are running RELENG_7, we have noticed an odd issue triggered or noticed by our monitoring system (bigbrother in this case). The seems to have been happening ever since we installed it, so its not a recent commit issue. Every 5 min, one of our monitoring stations connects to the box on port 25 The connection process is pretty simple. It connects and sends a QUIT and if that works, all is "ok". Here is a normal exchange 17:44:27.966100 IP 192.168.1.2.59586 > 192.168.1.9.25: S 1590561033:1590561033(0) win 65535 17:44:27.966119 IP 192.168.1.9.25 > 192.168.1.2.59586: S 2644498016:2644498016(0) ack 1590561034 win 65535 17:44:27.966649 IP 192.168.1.2.59586 > 192.168.1.9.25: . ack 1 win 8326 17:44:27.966664 IP 192.168.1.2.59586 > 192.168.1.9.25: P 1:12(11) ack 1 win 8326 17:44:27.969087 IP 192.168.1.9.25 > 192.168.1.2.59586: P 1:186(185) ack 12 win 8326 17:44:27.969119 IP 192.168.1.9.25 > 192.168.1.2.59586: F 186:186(0) ack 12 win 8326 17:44:27.969642 IP 192.168.1.2.59586 > 192.168.1.9.25: . ack 187 win 8326 17:44:27.969657 IP 192.168.1.2.59586 > 192.168.1.9.25: F 12:12(0) ack 187 win 8326 17:44:27.969668 IP 192.168.1.9.25 > 192.168.1.2.59586: . ack 13 win 8325 But, perhaps twice a day, or once every 2 days, I will see an RST from the host being monitored for some reason?! It looks like 17:49:27.496803 IP (tos 0x0, ttl 64, id 8521, offset 0, flags [DF], proto TCP (6), length 60) 199.212.134.2.65013 > 199.212.134.9.25: S, cksum 0xabde (correct), 2204170858:2204170858(0) win 65535 17:49:27.496829 IP (tos 0x0, ttl 64, id 42946, offset 0, flags [DF], proto TCP (6), length 60) 199.212.134.9.25 > 199.212.134.2.65013: S, cksum 0xfe09 (correct), 3523370477:3523370477(0) ack 2204170859 win 65535 17:49:27.497260 IP (tos 0x0, ttl 64, id 8522, offset 0, flags [DF], proto TCP (6), length 52) 199.212.134.2.65013 > 199.212.134.9.25: ., cksum 0x0c4c (correct), 1:1(0) ack 1 win 8326 17:49:27.497268 IP (tos 0x0, ttl 64, id 42948, offset 0, flags [DF], proto TCP (6), length 40) 199.212.134.9.25 > 199.212.134.2.65013: R, cksum 0xe62b (correct), 3523370478:3523370478(0) win 0 17:49:27.497270 IP (tos 0x0, ttl 64, id 8523, offset 0, flags [DF], proto TCP (6), length 63) 199.212.134.2.65013 > 199.212.134.9.25: P, cksum 0xb803 (correct), 1:12(11) ack 1 win 8326 17:49:27.497277 IP (tos 0x0, ttl 64, id 42949, offset 0, flags [DF], proto TCP (6), length 40) 199.212.134.9.25 > 199.212.134.2.65013: R, cksum 0xe62b (correct), 3523370478:3523370478(0) win 0 17:49:34.690828 IP (tos 0x0, ttl 64, id 45325, offset 0, flags [DF], proto TCP (6), length 60) 199.212.134.9.65077 > 199.212.134.2.25: S, cksum 0x3e26 (correct), 2116235846:2116235846(0) win 65535 I dont ever see this on RELENG_6, only on RELENG_7. It doesnt seem to be load related as I will see it at various times of the day both busy and quiet and sendmail is not complaining about too many connections which it will when there are. 192.168.1.2 is the monitoring host running bb and 192.168.1.9 is the smtp server being tested. I do have pf on the box, but pf isnt set to send RSTs and I think if there is a state mismatch, it will just drop the packet and not send the RST. I have tried with and without scrub but no obvious difference Rules are simple set skip on lo0 scrub in all block in log on {em0,em1} pass in on {em0,em1} proto {tcp,udp} from pass in on {em0,em1,lo0} proto tcp from any to any port {25,53,587} pass in on {em0,em1,lo0} proto udp from any to any port {53} pass in on {em0,em1} proto icmp from any to any pass out on {em0,em1} proto {icmp,tcp,udp} from any to any -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 17:44:06 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ED86106570F for ; Fri, 22 Aug 2008 17:44:06 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 7E90D8FC13 for ; Fri, 22 Aug 2008 17:44:06 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7MHi2hC091803; Fri, 22 Aug 2008 10:44:05 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7MHi1mZ060925; Fri, 22 Aug 2008 10:44:01 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (ip-64-139-15-210.dsl.sca.megapath.net [64.139.15.210]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7MHhwVD015412; Fri, 22 Aug 2008 10:44:01 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 22 Aug 2008 10:43:57 -0700 Message-ID: From: gnn@FreeBSD.org To: "Bruce M. Simpson" In-Reply-To: <48AE23FF.9070009@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1315654 - f81ec9e17d3c X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Luigi Rizzo , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 17:44:06 -0000 At Fri, 22 Aug 2008 03:27:11 +0100, Bruce M. Simpson wrote: > > gnn@freebsd.org wrote: > >> The only thing i can think of is that it's the UDP checksum, > >> residing beyond hlen, which is overwritten somewhere in the > >> call to if_simloop -- in which case perhaps a better fix is > >> to m_pullup() the udp header as well ? > >> > > > > It is the checksum that gets trashed, yes. > > ... > > The m_*() routines actually have reasonable comments, it just seems > > the wrong one was used here. > > > > Actually, m_copy() has been legacy for some time now -- see comments. > > I'd be concerned that the change to m_dup() (which makes a full mbuf > chain copy) rather than m_copym() (which bumps refcounts) is going to > eat into the mbuf clusters on fast links, though it's an easy band-aid > for the problem. I gather you mean that a fast link on which also we're looping back the packet will be an issue? Since this packet is only going into the simloop() routine. > I agree with Luigi that some of the API contract for mbuf(9) doesn't > hold any more now that we have TSO and other offload. I was actually hoping, as the person who last hacked this code, that you might have a suggestion as to a "right" fix. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 18:43:06 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEB92106568B; Fri, 22 Aug 2008 18:43:06 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A1FD08FC20; Fri, 22 Aug 2008 18:43:06 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1032215B3A6; Fri, 22 Aug 2008 14:43:06 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 22 Aug 2008 14:43:06 -0400 X-Sasl-enc: pgmncLnmLhtU0R0Acgti6jVd4+nFVPMWa4nkeoLq2vBS 1219430585 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 633E8FC63; Fri, 22 Aug 2008 14:43:05 -0400 (EDT) Message-ID: <48AF08B7.4090804@FreeBSD.org> Date: Fri, 22 Aug 2008 19:43:03 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: gnn@FreeBSD.org References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 18:43:07 -0000 gnn@FreeBSD.org wrote: > I gather you mean that a fast link on which also we're looping back > the packet will be an issue? Since this packet is only going into the > simloop() routine. > We end up calling if_simloop() from a few "interesting" places, in particular the kernel PIM packet handler. In this particular case we're going to take a full mbuf chain copy every time we send a packet which needs to be looped back to userland. > > I was actually hoping, as the person who last hacked this code, that > you might have a suggestion as to a "right" fix. > It's been a while since I've done any in-depth FreeBSD work other than hacking on the IGMPv3 snap, and my time is largely tied up with other work these days, sadly. It doesn't seem right to my mind that we need to make a full copy of an mbuf chain with m_dup() to workaround this kind of problem. Whilst it may suffice for a band-aid workaround, we may see mbuf pool fragmentation as packet rates go up. However we are now in a "new world order" where mbuf chains may be very tied to the device where they've originated or to where they're going. It isn't clear to me where this kind of intrusion is happening. In the case of ip_mloopback(), somehow we are stomping on a read-only copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine according to the documented uses of mbuf(9), although as Luigi pointed out, most likely we need to look at the upper-layer protocol too, e.g. where UDP checksums are also being offloaded. Some of the code in the IGMPv3 branch actually reworks how loopback happens i.e. the preference is not to loop back wherever possible because of the locking implications. Check the bms_netdev branch history for more info. cheers BMS From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 19:12:39 2008 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 9A56210656CC for ; Fri, 22 Aug 2008 19:12:39 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 569E78FC0C for ; Fri, 22 Aug 2008 19:12:39 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CF17B41C7BD; Fri, 22 Aug 2008 21:12:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ERfB9qvZWZa1; Fri, 22 Aug 2008 21:12:37 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 63DE041C7B7; Fri, 22 Aug 2008 21:12:37 +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 5FE4C44487F; Fri, 22 Aug 2008 19:12:26 +0000 (UTC) Date: Fri, 22 Aug 2008 19:12:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mike Tancsa In-Reply-To: <200808221719.m7MHJY25090566@lava.sentex.ca> Message-ID: <20080822191146.T66593@maildrop.int.zabbadoz.net> References: <200808221719.m7MHJY25090566@lava.sentex.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 19:12:39 -0000 On Fri, 22 Aug 2008, Mike Tancsa wrote: > On one of our sendmail boxes that we are running RELENG_7, we have noticed an > odd issue triggered or noticed by our monitoring system (bigbrother in this > case). The seems to have been happening ever since we installed it, so its > not a recent commit issue. > > Every 5 min, one of our monitoring stations connects to the box on port 25 > > The connection process is pretty simple. It connects and sends a QUIT and if > that works, all is "ok". > > Here is a normal exchange > ... > > > But, perhaps twice a day, or once every 2 days, I will see an RST from the > host being monitored for some reason?! > It looks like > > ... > > I dont ever see this on RELENG_6, only on RELENG_7. It doesnt seem to be load > related as I will see it at various times of the day both busy and quiet and > sendmail is not complaining about too many connections which it will when > there are. > > 192.168.1.2 is the monitoring host running bb and 192.168.1.9 is the smtp > server being tested. I do have pf on the box, but pf isnt set to send RSTs > and I think if there is a state mismatch, it will just drop the packet and > not send the RST. I have tried with and without scrub but no obvious > difference > > Rules are simple > > > set skip on lo0 > scrub in all > > block in log on {em0,em1} > pass in on {em0,em1} proto {tcp,udp} from > pass in on {em0,em1,lo0} proto tcp from any to any port {25,53,587} > pass in on {em0,em1,lo0} proto udp from any to any port {53} > pass in on {em0,em1} proto icmp from any to any > pass out on {em0,em1} proto {icmp,tcp,udp} from any to any can you make sure you have this? http://svn.freebsd.org/changeset/base/181596 -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 19:22:42 2008 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 987A51065677 for ; Fri, 22 Aug 2008 19:22:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 62EF48FC2C for ; Fri, 22 Aug 2008 19:22:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7MJMdn2078597; Fri, 22 Aug 2008 15:22:39 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7MJMcUN091064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2008 15:22:39 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808221922.m7MJMcUN091064@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Aug 2008 15:22:41 -0400 To: "Bjoern A. Zeeb" From: Mike Tancsa In-Reply-To: <20080822191146.T66593@maildrop.int.zabbadoz.net> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 19:22:42 -0000 At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: >can you make sure you have this? > >http://svn.freebsd.org/changeset/base/181596 Hi, I do. I am running a GENERIC kernel but with inet6 disabled from yesterday 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 and with the patch below as TOE seems to be broken for my workload # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 +++ sys/netinet/tcp_offload.c.disable 2008-08-22 15:16:50.000000000 -0400 @@ -58,6 +58,8 @@ struct rtentry *rt; int error; + return (EINVAL); + /* * Look up the route used for the connection to * determine if it uses an interface capable of I can try changing to ipfw and see if that makes a difference ? But the RST doesnt sound like a pf issue no ? I would have thought it would just blackhole the packet. ---Mike From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 19:39:25 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BF9F106567B; Fri, 22 Aug 2008 19:39:25 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id E0EC28FC1D; Fri, 22 Aug 2008 19:39:24 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3AFF073098; Fri, 22 Aug 2008 21:42:00 +0200 (CEST) Date: Fri, 22 Aug 2008 21:42:00 +0200 From: Luigi Rizzo To: "Bruce M. Simpson" Message-ID: <20080822194200.GC63527@onelab2.iet.unipi.it> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AF08B7.4090804@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: gnn@freebsd.org, net@freebsd.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 19:39:25 -0000 On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: > gnn@FreeBSD.org wrote: > >I gather you mean that a fast link on which also we're looping back > >the packet will be an issue? Since this packet is only going into the > >simloop() routine. > > > > We end up calling if_simloop() from a few "interesting" places, in > particular the kernel PIM packet handler. > > In this particular case we're going to take a full mbuf chain copy every > time we send a packet which needs to be looped back to userland. ... > In the case of ip_mloopback(), somehow we are stomping on a read-only > copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine > according to the documented uses of mbuf(9), although as Luigi pointed > out, most likely we need to look at the upper-layer protocol too, e.g. > where UDP checksums are also being offloaded. in fact, george, if you have an easy way to reproduce the error, could you see if reverting your change and instead adding sizeof(struct udphdr) to the length argument in the call to m_pullup() fixes the problem ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 20:05:06 2008 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 CEFA41065689 for ; Fri, 22 Aug 2008 20:05:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 89A838FC17 for ; Fri, 22 Aug 2008 20:05:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B9AE141C7AE; Fri, 22 Aug 2008 22:05:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id WGjhRAxZ9x9a; Fri, 22 Aug 2008 22:05:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 6550B41C7A4; Fri, 22 Aug 2008 22:05:05 +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 14F4D44487F; Fri, 22 Aug 2008 20:01:53 +0000 (UTC) Date: Fri, 22 Aug 2008 20:01:52 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mike Tancsa In-Reply-To: <200808221922.m7MJMcUN091064@lava.sentex.ca> Message-ID: <20080822195923.X66593@maildrop.int.zabbadoz.net> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 20:05:07 -0000 On Fri, 22 Aug 2008, Mike Tancsa wrote: > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: > >> can you make sure you have this? >> >> http://svn.freebsd.org/changeset/base/181596 > > Hi, > I do. I am running a GENERIC kernel but with inet6 disabled from yesterday > > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 > > and with the patch below as TOE seems to be broken for my workload okay. Does netstat -s -p tcp should any obvious error counters raising? I just try to get the easy things sorted out before anyone starts to debug more TCP... /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 20:05:35 2008 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 B4D82106567C; Fri, 22 Aug 2008 20:05:35 +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 8BE458FC20; Fri, 22 Aug 2008 20:05:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7MK5ZRB082831; Fri, 22 Aug 2008 20:05:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7MK5ZDP082827; Fri, 22 Aug 2008 20:05:35 GMT (envelope-from linimon) Date: Fri, 22 Aug 2008 20:05:35 GMT Message-Id: <200808222005.m7MK5ZDP082827@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 20:05:35 -0000 Old Synopsis: kernel panic when sending file via ng_ubt New Synopsis: [panic] kernel panic when sending file via ng_ubt(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 22 20:02:51 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126742 From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 20:15:29 2008 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 0B66B106566B for ; Fri, 22 Aug 2008 20:15:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id CD5828FC08 for ; Fri, 22 Aug 2008 20:15:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7MKFQmP087126; Fri, 22 Aug 2008 16:15:26 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7MKFPp8091270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2008 16:15:25 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808222015.m7MKFPp8091270@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Aug 2008 16:15:28 -0400 To: "Bjoern A. Zeeb" From: Mike Tancsa In-Reply-To: <20080822195923.X66593@maildrop.int.zabbadoz.net> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <20080822195923.X66593@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 20:15:29 -0000 At 04:01 PM 8/22/2008, Bjoern A. Zeeb wrote: >On Fri, 22 Aug 2008, Mike Tancsa wrote: > >>At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: >> >>>can you make sure you have this? >>>http://svn.freebsd.org/changeset/base/181596 >> >>Hi, >>I do. I am running a GENERIC kernel but with inet6 disabled from yesterday >> >>7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 >> >>and with the patch below as TOE seems to be broken for my workload > >okay. > >Does netstat -s -p tcp should any obvious error counters raising? > >I just try to get the easy things sorted out before anyone starts >to debug more TCP... Not sure, what is obvious :) This host is part of the primary MX list for a lot of inbound traffic, so there will be all sorts of hosts using all sorts of stacks connecting to it. netstat -ni shows no errors as do the stats from the em driver (below) tcp: 26989994 packets sent 17034559 data packets (84842431 bytes) 101073 data packets (20893246 bytes) retransmitted 4586 data packets unnecessarily retransmitted 2 resends initiated by MTU discovery 6523153 ack-only packets (333850 delayed) 0 URG only packets 0 window probe packets 1016646 window update packets 2314525 control packets 27848527 packets received 15078177 acks (for 78677787 bytes) 830948 duplicate acks 4689 acks for unsent data 11374257 packets (4127132455 bytes) received in-sequence 40287 completely duplicate packets (30901526 bytes) 921 old duplicate packets 352 packets with some dup. data (179712 bytes duped) 225759 out-of-order packets (276463593 bytes) 8 packets (0 bytes) of data after window 0 window probes 710635 window update packets 298525 packets received after close 849 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 5855 discarded due to memory problems 855019 connection requests 1091001 connection accepts 0 bad connection attempts 10943 listen queue overflows 79448 ignored RSTs in the windows 1944666 connections established (including accepts) 2088626 connections closed (including 516007 drops) 840374 connections updated cached RTT on close 842332 connections updated cached RTT variance on close 60049 connections updated cached ssthresh on close 1201 embryonic connections dropped 14026440 segments updated rtt (of 12656642 attempts) 157370 retransmit timeouts 7412 connections dropped by rexmit timeout 1 persist timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 886 keepalive timeouts 13 keepalive probes sent 873 connections dropped by keepalive 110658 correct ACK header predictions 7810293 correct data packet header predictions 1114950 syncache entries added 63212 retransmitted 35592 dupsyn 77 dropped 1091001 completed 0 bucket overflow 0 cache overflow 4908 reset 8260 stale 10943 aborted 0 badack 174 unreach 0 zone failures 1115027 cookies sent 361 cookies received 2843 SACK recovery episodes 2620 segment rexmits in SACK recovery episodes 3722090 byte rexmits in SACK recovery episodes 35491 SACK options (SACK blocks) received 162860 SACK options (SACK blocks) sent 0 SACK scoreboard overflow Aug 22 16:13:28 smtp2 kernel: em0: Excessive collisions = 0 Aug 22 16:13:28 smtp2 kernel: em0: Sequence errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Defer count = 0 Aug 22 16:13:28 smtp2 kernel: em0: Missed Packets = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive No Buffers = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive Length Errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Receive errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Crc errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Alignment errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: Collision/Carrier extension errors = 0 Aug 22 16:13:28 smtp2 kernel: em0: RX overruns = 0 Aug 22 16:13:28 smtp2 kernel: em0: watchdog timeouts = 0 Aug 22 16:13:28 smtp2 kernel: em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Aug 22 16:13:28 smtp2 kernel: em0: XON Rcvd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XON Xmtd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XOFF Rcvd = 0 Aug 22 16:13:28 smtp2 kernel: em0: XOFF Xmtd = 0 Aug 22 16:13:28 smtp2 kernel: em0: Good Packets Rcvd = 16920559 Aug 22 16:13:28 smtp2 kernel: em0: Good Packets Xmtd = 16025617 Aug 22 16:13:28 smtp2 kernel: em0: TSO Contexts Xmtd = 0 Aug 22 16:13:28 smtp2 kernel: em0: TSO Contexts Failed = 0 Aug 22 16:13:31 smtp2 kernel: em1: Excessive collisions = 0 Aug 22 16:13:31 smtp2 kernel: em1: Sequence errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Defer count = 0 Aug 22 16:13:31 smtp2 kernel: em1: Missed Packets = 0 Aug 22 16:13:31 smtp2 kernel: em1: Receive No Buffers = 0 Aug 22 16:13:31 smtp2 kernel: em1: Receive Length Errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Receive errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Crc errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Alignment errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: Collision/Carrier extension errors = 0 Aug 22 16:13:31 smtp2 kernel: em1: RX overruns = 0 Aug 22 16:13:31 smtp2 kernel: em1: watchdog timeouts = 0 Aug 22 16:13:31 smtp2 kernel: em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Aug 22 16:13:31 smtp2 kernel: em1: XON Rcvd = 0 Aug 22 16:13:31 smtp2 kernel: em1: XON Xmtd = 0 Aug 22 16:13:31 smtp2 kernel: em1: XOFF Rcvd = 0 Aug 22 16:13:31 smtp2 kernel: em1: XOFF Xmtd = 0 Aug 22 16:13:31 smtp2 kernel: em1: Good Packets Rcvd = 13566035 Aug 22 16:13:31 smtp2 kernel: em1: Good Packets Xmtd = 14313612 Aug 22 16:13:31 smtp2 kernel: em1: TSO Contexts Xmtd = 0 Aug 22 16:13:31 smtp2 kernel: em1: TSO Contexts Failed = 0 From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 21:34:07 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF1291065678; Fri, 22 Aug 2008 21:34:07 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id CAF308FC0C; Fri, 22 Aug 2008 21:34:07 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7MLY6Gk007749; Fri, 22 Aug 2008 14:34:06 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7MLXZ39050592; Fri, 22 Aug 2008 14:33:35 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (ppp-71-139-4-101.dsl.snfc21.pacbell.net [71.139.4.101]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7MLXNpQ073052; Fri, 22 Aug 2008 14:33:36 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 22 Aug 2008 14:33:23 -0700 Message-ID: From: gnn@freebsd.org To: Luigi Rizzo In-Reply-To: <20080822194200.GC63527@onelab2.iet.unipi.it> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <20080822194200.GC63527@onelab2.iet.unipi.it> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1317745 - 9869d50b11c0 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: "Bruce M. Simpson" , net@freebsd.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 21:34:08 -0000 At Fri, 22 Aug 2008 21:42:00 +0200, Luigi Rizzo wrote: > > On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: > > gnn@FreeBSD.org wrote: > > >I gather you mean that a fast link on which also we're looping back > > >the packet will be an issue? Since this packet is only going into the > > >simloop() routine. > > > > > > > We end up calling if_simloop() from a few "interesting" places, in > > particular the kernel PIM packet handler. > > > > In this particular case we're going to take a full mbuf chain copy every > > time we send a packet which needs to be looped back to userland. > ... > > In the case of ip_mloopback(), somehow we are stomping on a read-only > > copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine > > according to the documented uses of mbuf(9), although as Luigi pointed > > out, most likely we need to look at the upper-layer protocol too, e.g. > > where UDP checksums are also being offloaded. > > in fact, george, if you have an easy way to reproduce the error, > could you see if reverting your change and instead adding > sizeof(struct udphdr) to the length argument in the call to m_pullup() > fixes the problem ? I don't have sample code I can give but it's simple to set up and test. On machine A set up a sender and a listener for the same multicast group/port. On machine B set up a listener. Send from A with the listener on. B should see nothing and its "bad checksums" counter should increase. Turn off listener on A. Send again, B should get the packet. If you listen to the traffic with tcpdump on a 3rd machine you'll see that the checksum is constant, even if the data in the packet, like the ports, is not. Your ethernet cards have to have hardware checksum offloading. I'm using em/igb in 7-STABLE. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 21:40:05 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 495A3106564A; Fri, 22 Aug 2008 21:40:05 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 278F28FC22; Fri, 22 Aug 2008 21:40:04 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7MLe2Xj008278; Fri, 22 Aug 2008 14:40:04 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7MLdTjt052740; Fri, 22 Aug 2008 14:39:29 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (ppp-71-139-4-101.dsl.snfc21.pacbell.net [71.139.4.101]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7MLdSWT074357; Fri, 22 Aug 2008 14:39:29 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 22 Aug 2008 14:39:27 -0700 Message-ID: From: gnn@FreeBSD.org To: "Bruce M. Simpson" In-Reply-To: <48AF08B7.4090804@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1317801 - 8a2c231cbb4a X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Luigi Rizzo , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 21:40:05 -0000 At Fri, 22 Aug 2008 19:43:03 +0100, Bruce M. Simpson wrote: > > We end up calling if_simloop() from a few "interesting" places, in > particular the kernel PIM packet handler. > > In this particular case we're going to take a full mbuf chain copy every > time we send a packet which needs to be looped back to userland. Right, I know the penalty. > It's been a while since I've done any in-depth FreeBSD work other > than hacking on the IGMPv3 snap, and my time is largely tied up with > other work these days, sadly. > > It doesn't seem right to my mind that we need to make a full copy of > an mbuf chain with m_dup() to workaround this kind of problem. > > Whilst it may suffice for a band-aid workaround, we may see mbuf > pool fragmentation as packet rates go up. > > However we are now in a "new world order" where mbuf chains may be > very tied to the device where they've originated or to where they're > going. It isn't clear to me where this kind of intrusion is > happening. > > In the case of ip_mloopback(), somehow we are stomping on a > read-only copy of an mbuf chain. The use of m_copy() with m_pullup() > there is fine according to the documented uses of mbuf(9), although > as Luigi pointed out, most likely we need to look at the upper-layer > protocol too, e.g. where UDP checksums are also being offloaded. > > Some of the code in the IGMPv3 branch actually reworks how loopback > happens i.e. the preference is not to loop back wherever possible > because of the locking implications. Check the bms_netdev branch > history for more info. Well, what I suspect is the problem are these bits: udp_output(): /* * Set up checksum and output datagram. */ if (udp_cksum) { if (inp->inp_flags & INP_ONESBCAST) faddr.s_addr = INADDR_BROADCAST; ui->ui_sum = in_pseudo(ui->ui_src.s_addr, faddr.s_addr, htons((u_short)len + sizeof(struct udphdr) + IPPROTO_UDP)); m->m_pkthdr.csum_flags = CSUM_UDP; m->m_pkthdr.csum_data = offsetof(struct udphdr, uh_sum); } else ip_mloopback(): copym = m_copy(m, 0, M_COPYALL); if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen)) copym = m_pullup(copym, hlen); if (copym != NULL) { /* If needed, compute the checksum and mark it as valid. */ if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { in_delayed_cksum(copym); copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; copym->m_pkthdr.csum_flags |= CSUM_DATA_VALID | CSUM_PSEUDO_HDR; copym->m_pkthdr.csum_data = 0xffff; } and: in_delayed_cksum(struct mbuf *m) { struct ip *ip; u_short csum, offset; ip = mtod(m, struct ip *); offset = ip->ip_hl << 2 ; csum = in_cksum_skip(m, ip->ip_len, offset); if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0) csum = 0xffff; offset += m->m_pkthdr.csum_data; /* checksum offset */ Somehow the data that the device needs to do the proper checksum offload is getting trashed here. Now, since it's clear we need a writable packet structure so that we don't trash the original, I'm wondering if the m_pullup() will be sufficient. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 21:43:43 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DD121065672; Fri, 22 Aug 2008 21:43:43 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id D4A688FC18; Fri, 22 Aug 2008 21:43:42 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E09C413FB48; Fri, 22 Aug 2008 17:43:41 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 22 Aug 2008 17:43:41 -0400 X-Sasl-enc: YghMKL1JlI5bbDccfdCZnC9i+ENY/DY7dIdsmXbjsXXe 1219441421 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3F31913080; Fri, 22 Aug 2008 17:43:41 -0400 (EDT) Message-ID: <48AF330B.4010802@FreeBSD.org> Date: Fri, 22 Aug 2008 22:43:39 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: gnn@FreeBSD.org References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 21:43:43 -0000 gnn@FreeBSD.org wrote: > Somehow the data that the device needs to do the proper checksum > offload is getting trashed here. Now, since it's clear we need a > writable packet structure so that we don't trash the original, I'm > wondering if the m_pullup() will be sufficient. > If it's serious enough to break UDP checksumming on the wire, perhaps we should just swallow the mbuf allocator heap churn and do the m_dup() for now, but slap in a big comment about why it's there. BMS From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 22:04:04 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C00AA106567B; Fri, 22 Aug 2008 22:04:04 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 9D13B8FC25; Fri, 22 Aug 2008 22:04:04 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7MM42Hw009563; Fri, 22 Aug 2008 15:04:03 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7MM3Uqb060736; Fri, 22 Aug 2008 15:03:30 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (ppp-71-139-4-101.dsl.snfc21.pacbell.net [71.139.4.101]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7MM3UAs079032; Fri, 22 Aug 2008 15:03:30 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 22 Aug 2008 15:03:30 -0700 Message-ID: From: gnn@FreeBSD.org To: "Bruce M. Simpson" In-Reply-To: <48AF330B.4010802@FreeBSD.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1317975 - c04b33cd274d X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Luigi Rizzo , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 22 Aug 2008 22:04:04 -0000 At Fri, 22 Aug 2008 22:43:39 +0100, Bruce M. Simpson wrote: > > gnn@FreeBSD.org wrote: > > Somehow the data that the device needs to do the proper checksum > > offload is getting trashed here. Now, since it's clear we need a > > writable packet structure so that we don't trash the original, I'm > > wondering if the m_pullup() will be sufficient. > > > > If it's serious enough to break UDP checksumming on the wire, perhaps we > should just swallow the mbuf allocator heap churn and do the m_dup() for > now, but slap in a big comment about why it's there. I think if none of us finds a better way before early next week that's what I'll do so that this at least works in 7.1. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Aug 22 22:30:04 2008 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 F26A71065677 for ; Fri, 22 Aug 2008 22:30:04 +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 D6BF68FC16 for ; Fri, 22 Aug 2008 22:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7MMU4HG095696 for ; Fri, 22 Aug 2008 22:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7MMU4au095695; Fri, 22 Aug 2008 22:30:04 GMT (envelope-from gnats) Date: Fri, 22 Aug 2008 22:30:04 GMT Message-Id: <200808222230.m7MMU4au095695@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2008 22:30:05 -0000 The following reply was made to PR kern/126742; it has been noted by GNATS. From: Alex To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Date: Fri, 22 Aug 2008 22:27:39 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: 7-STABLE >Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: ok. one last try. i'll simply attach the dmesg output as a file. >How-To-Repeat: >Fix: Patch attached with submission follows: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (2997.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2086535168 (1989 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] uhci0: port 0xe200-0xe21f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe000-0xe01f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe100-0xe11f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf8205000-0xf82053ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcm0: mem 0xf8200000-0xf8203fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 atapci0: port 0xd000-0xd007,0xd100-0xd103,0xd200-0xd207,0xd300-0xd303,0xd400-0xd40f mem 0xf8000000-0xf8001fff irq 19 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xf8204000-0xf82043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 ath0: mem 0xf8100000-0xf810ffff irq 19 at device 1.0 on pci5 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0f:b5:82:07:c8 ath0: mac 7.9 phy 4.5 radio 5.6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f,0xfc00-0xfc0f at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xe700-0xe707,0xe800-0xe803,0xe900-0xe907,0xea00-0xea03,0xeb00-0xeb0f,0xec00-0xec0f irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est0 attach returned 6 p4tcc0: on cpu0 coretemp0: on cpu0 acpi_button0: on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ums0: on uhub1 ums0: 7 buttons and Z dir. ukbd0: on uhub1 kbd0 at ukbd0 Timecounter "TSC" frequency 2997020286 Hz quality 800 Timecounters tick every 1.000 msec ad0: 238474MB at ata0-master SATA300 ad8: 6105MB at ata4-master UDMA33 acd0: DVDR at ata4-slave UDMA33 pcm0: pcm0: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 WARNING: WITNESS option enabled, expect reduced performance. cd0 at ata4 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [344984 x 2048 byte records] Trying to mount root from ufs:/dev/ad8s1a WARNING: / was not properly dismounted Loading configuration files. kernel dumps on /dev/ad0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 00:03:56 2008 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 70584106567E for ; Sat, 23 Aug 2008 00:03:56 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 26D908FC1B for ; Sat, 23 Aug 2008 00:03:55 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so361374yxb.13 for ; Fri, 22 Aug 2008 17:03:55 -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:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Zm630ovC4587LSbk0pE32mJ8KMJGQWHtYhzJVksu8Tk=; b=SKCYJeFvpN7nYUisg1dTWpTI+Lyk2zAEcOCrM3D48mXN+VIo6TNpzU2GFyhXsKCEfa 5dU+IM+6bNQ6aBbOse4VcUZz+vnJUuipyHtphUen+QMATiU+EFiZnCbFvq+HMnS6h9VJ i2y17bjL9RyXZpPl38J8y54GrJLtMwd776wK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BLI/6h1aBlhfDHMtPrsrgpXEb85FqX928KCB/ZSU6qjcKa/Fyqd5EPDq4xCQ5NaiW2 tIShURwMxvQaeVFqKaiqTLFhhS4mJVJVJglyTrJ7tI2vH+o83DxREGAMpND/DQSPpgep tgKnRVJwvPzxvoAH1Ha/q3zRTl8Q/uUwTFU3E= Received: by 10.151.156.19 with SMTP id i19mr2720622ybo.176.1219448454512; Fri, 22 Aug 2008 16:40:54 -0700 (PDT) Received: by 10.151.8.7 with HTTP; Fri, 22 Aug 2008 16:40:54 -0700 (PDT) Message-ID: <4ad871310808221640r4bb078sb2e303f49863350d@mail.gmail.com> Date: Fri, 22 Aug 2008 19:40:54 -0400 From: "Glen Barber" To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org In-Reply-To: <20080316164226.GA658@orion.hexidigital.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200803132256.01197.glen.j.barber@gmail.com> <20080316164226.GA658@orion.hexidigital.org> Cc: Subject: Re: ndis0 no link on 6.3-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 00:03:56 -0000 Hi everyone. Sorry to bump such an old post, but I have figured out a 'hack' to get this driver to work, and figured I'd post here, in case it may help someone else. Previously, I said the following, about a Broadcom 4318 chipset on a Dell Inspiron b120: "Upon 'kldunload bcmwl5.ko; kldload bcmwl5.ko', my ndis0 card looses all WPA capabilities." The fix is as follows, as I have been unable to find anything relevant regarding netif, dhclient, wpa_supplicant or ndis: Step 1: Create /etc/rc.local, with '/sbin/kldload /boot/modules/bcmwl5_sys.ko' Step 2: Edit /etc/wpa_supplicant.conf as needed Step 3: Echo 'ifconfig_ndis0="WPA DHCP"' to /etc/rc.conf Outcome: System boots, loading netif, dhclient, and wpa_supplicant. Next, after the other three are running, the rc.local script loads the ndis0 driver. On my system (and surrounding networks) my system tries to authenticate against any available network, but then finally reads wpa_supplicant.conf, and uses my network. As I said, sorry to bump an old thread, but hopefully this will help someone else, regardless of how crude of a hack it is. Regards, -- Glen Barber From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 01:25:06 2008 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 4B1EE106564A for ; Sat, 23 Aug 2008 01:25:06 +0000 (UTC) (envelope-from adrian@thearle.com.au) Received: from albert.thearle.com.au (albert.thearle.com.au [150.101.115.54]) by mx1.freebsd.org (Postfix) with ESMTP id AAA3D8FC08 for ; Sat, 23 Aug 2008 01:25:05 +0000 (UTC) (envelope-from adrian@thearle.com.au) Received: from [192.168.123.148] (unknown [192.168.123.148]) (Authenticated sender: adrian@thearle.com.au) by albert.thearle.com.au (Postfix) with ESMTPSA id 89DA5C5 for ; Sat, 23 Aug 2008 11:06:29 +1000 (EST) Message-ID: <48AF6293.4000002@thearle.com.au> Date: Sat, 23 Aug 2008 11:06:27 +1000 From: Adrian Thearle User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.93.3/8076/Sat Aug 23 08:15:54 2008 on albert.thearle.com.au X-Virus-Status: Clean Subject: Wireless and Broadcast packets problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 01:25:06 -0000 Hi Guys I am having a problem with my wireless network. The Issue is that clients connected to the wireless LAN cannot _see_ other clients. My understanding of 802.11 was that clients could talk to other clients, except all traffic would go via the access point and that the AP would forward on the packets. This also ensures that encryption works as expected as well as other RF issues. One thing that I can see is going wrong is that clients on the Wireless Lan sending Broadcast packets, but they are not being forwarded by the AP to anyone else... Wireless clients also cannot ping each other (mainly because their ARP requests are not being answered) Below is a simplified system diagram. AdriansPC AlbertAP \|/ --------- 192.168.123/24 ------------ | | |--LAN------bge0-| |---| ral0 (192.168.124/24) |________| |____________|----------tun0--->PPPoE(bge0) Windows FreeBSD Sneaky \|/ --------- | | |---| 192.168.124.2 (Static IP address) |________| ral0 FreeBSD Laptop \|/ --------- | | |---| 192.168.124.150 (DHCP) |________| Windows When running TCPDump on AlbertAP I can see plenty of wireless traffic going around the place. Wireless Clients are able to connect and have their session is encrypted with WPA. This all seems to work, wireless clients are able to browse the net. (Those that can get an IP address anyway, which happens to be the windows machines) *Problem* I have run tcpdump on both AlbertAP and Sneaky and seem some interesting omissions. When I ping Sneaky from Laptop I see on Albert the ARP request come out from Laptop asking for Sneaky's MAC address. AlbertAP> tcpdump -i ral0 10:27:51.979664 arp who-has 192.168.124.2 tell 192.168.124.150 10:27:51.979684 arp who-has 192.168.124.2 tell 192.168.124.150 But on Sneaky I cannot see these packets comming in... All I get is random EAP traffic Sneaky> tcpdump -i ral0 10:30:32.987961 EAP code=2 id=3 length=123 10:30:32.988383 EAP code=1 id=3 length=95 10:30:32.990557 EAP code=2 id=3 length=135 10:30:32.991548 EAP code=1 id=3 length=95 However if a Wired client like AdriansPC tries to ping Laptop then things work. Albert knows the MAC address of the Wireless client to send the ping packet to and so just sends it off. *Problem* The other thing I see alot of is netbios broadcast traffic coming from the Laptop on the wireless. Albert can see all this traffic coming in, but none of it gets forwarded to Sneaky, (nothing about netbios from a tcpdump on sneaky). The same can be said for a particular client doing DHCP/BOOTP. On AlbertAP, I see the request come in and see the response go out (the response goes to 255.255.255.255) but I do not see this on sneaky (I should right, its a broadcast address). Oh and I don't think this client is actually getting a response as I can't do much with it(ie ping). (Its a wireless print server) Interestingly enough DHCP does seem to work to Laptop. I believe that this is because windows is doing DHCP, where as my print server is doing BOOTP. *It does work* Just so you believe me that normal traffic does get around, here is a ping from sneaky to albert. Sneaky> tcpdump -i ral0 10:36:11.243678 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.244634 arp reply 192.168.124.1 is-at 00:1a:ee:00:d5:c0 (oui Unknown) 10:36:11.244693 IP 192.168.124.2 > 192.168.124.1: ICMP echo request, id 18949, seq 0, length 64 10:36:11.251920 IP 192.168.124.1 > 192.168.124.2: ICMP echo reply, id 18949, seq 0, length 64 AlbertAP> tcpdump -i ral0 10:36:11.241001 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.241017 arp who-has 192.168.124.1 tell 192.168.124.2 10:36:11.241042 arp reply 192.168.124.1 is-at 00:1a:ee:00:d5:c0 (oui Unknown) 10:36:11.248582 IP 192.168.124.2 > 192.168.124.1: ICMP echo request, id 18949, seq 0, length 64 10:36:11.248600 IP 192.168.124.1 > 192.168.124.2: ICMP echo reply, id 18949, seq 0, length 64 *Discussion Point* I find it interesting that sneaky asks for 192.168.124.1's MAC address with an ARP request, but albert got two of them... *System Details* Things are basically setup as detailed in the Handbook, with the wireless LAN on a different Subnet to the wired one. I have also had a go at bridging the two interfaces but ran into trouble so didn't spend long there. I expect I would have the same issues. AlbertAP> uname -a FreeBSD albertAP 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #2: Mon Jul 14 09:00:17 EST 2008 adrian@albertAP:/usr/obj/usr/src/sys/AdriansKernel i386 AlbertAP> ifconfig bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:85:b3:a2:7e inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255 media: Ethernet autoselect (100baseTX ) status: active ral0: flags=8943 metric 0 mtu 2290 ether 00:1a:ee:00:d5:c0 inet 192.168.124.1 netmask 0xffffff00 broadcast 192.168.124.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid Wireless channel 3 (2422 Mhz 11g) bssid 00:1a:ee:00:d5:c0 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 50 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS dtimperiod 1 plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8051 metric 0 mtu 1492 inet 111.111.111.11 --> 222.22.222.222 netmask 0xffffffff (sanatised) Opened by PID 433 ifconfig_ral0="inet 192.168.124.1 ssid Wireless channel 3 mode 11g mediaopt hostap up" hostapd_enable="YES" ipfw Firewall rules ipfw add 007 allow all from any to any via ral0 So is there any chance there is a magic sysctl or ifconfig switch that will make these broadcast packets go to everyone...? or is there another problem? or is this just all the FreeBSD supports at the moment? or am I just dumb... Your help is appreciated Adrian From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 02:20:04 2008 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 562DF106566C for ; Sat, 23 Aug 2008 02:20:04 +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 445078FC12 for ; Sat, 23 Aug 2008 02:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7N2K4es017090 for ; Sat, 23 Aug 2008 02:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7N2K4OI017089; Sat, 23 Aug 2008 02:20:04 GMT (envelope-from gnats) Date: Sat, 23 Aug 2008 02:20:04 GMT Message-Id: <200808230220.m7N2K4OI017089@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 02:20:04 -0000 The following reply was made to PR kern/126742; it has been noted by GNATS. From: Alex To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Date: Sat, 23 Aug 2008 02:13:27 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: 7-STABLE >Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: is there a reason that the problem report database ignores any text if there's a line with a single dot (".") and nothing else in it? i know that in 'mail' that's the way to end your text, but as you can see it's not very useful in the case of this problem report. cheers. >How-To-Repeat: >Fix: From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 08:30:05 2008 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 C51D7106564A for ; Sat, 23 Aug 2008 08:30:05 +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 B10718FC12 for ; Sat, 23 Aug 2008 08:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7N8U5NX081335 for ; Sat, 23 Aug 2008 08:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7N8U5aH081332; Sat, 23 Aug 2008 08:30:05 GMT (envelope-from gnats) Date: Sat, 23 Aug 2008 08:30:05 GMT Message-Id: <200808230830.m7N8U5aH081332@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2008 08:30:05 -0000 The following reply was made to PR kern/126742; it has been noted by GNATS. From: Alex To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) Date: Sat, 23 Aug 2008 08:21:45 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: 7-STABLE >Environment: FreeBSD moshnroll 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: this should work. i simply replaced the lines with a single dot (".") in it with "DOT". --- dmesg begins here --- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Tue Aug 19 21:20:04 CEST 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (2997.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2086535168 (1989 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] uhci0: port 0xe200-0xe21f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe000-0xe01f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe100-0xe11f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf8205000-0xf82053ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcm0: mem 0xf8200000-0xf8203fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 atapci0: port 0xd000-0xd007,0xd100-0xd103,0xd200-0xd207,0xd300-0xd303,0xd400-0xd40f mem 0xf8000000-0xf8001fff irq 19 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xf8204000-0xf82043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 ath0: mem 0xf8100000-0xf810ffff irq 19 at device 1.0 on pci5 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0f:b5:82:07:c8 ath0: mac 7.9 phy 4.5 radio 5.6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f,0xfc00-0xfc0f at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xe700-0xe707,0xe800-0xe803,0xe900-0xe907,0xea00-0xea03,0xeb00-0xeb0f,0xec00-0xec0f irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 925092506000925 device_attach: est0 attach returned 6 p4tcc0: on cpu0 coretemp0: on cpu0 acpi_button0: on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ums0: on uhub1 ums0: 7 buttons and Z dir. ukbd0: on uhub1 kbd0 at ukbd0 Timecounter "TSC" frequency 2997020286 Hz quality 800 Timecounters tick every 1.000 msec ad0: 238474MB at ata0-master SATA300 ad8: 6105MB at ata4-master UDMA33 acd0: DVDR at ata4-slave UDMA33 pcm0: pcm0: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 WARNING: WITNESS option enabled, expect reduced performance. cd0 at ata4 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [344984 x 2048 byte records] Trying to mount root from ufs:/dev/ad8s1a WARNING: / was not properly dismounted Loading configuration files. kernel dumps on /dev/ad0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart DOT swapon: adding /dev/ad0s1b as swap device Starting file system checks: /dev/ad8s1a: 13332 files, 368195 used, 2657168 free (8032 frags, 331142 blocks, 0.3% fragmentation) /dev/ad0s1a: DEFER FOR BACKGROUND CHECKING Setting hostuuid: 00000000-0000-0000-0000-001a4d4bb4eb. Setting hostid: 0x52f33628. Mounting local file systems: WARNING: /usr was not properly dismounted DOT Setting hostname: moshnroll. kern.sync_on_panic: 0 -> 1 kern.ipc.shmmax: 33554432 -> 67108864 kern.ipc.shmall: 8192 -> 32768 vfs.usermount: 0 -> 1 net.inet.tcp.blackhole: 0 -> 1 kern.ipc.shm_allow_removed: 0 -> 1 /etc/rc: WARNING: Values of network_interfaces other than AUTO are deprecated ath0: flags=8843 metric 0 mtu 1500 ether 00:0f:b5:82:07:c8 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b (DS/11Mbps) status: no carrier ssid cookiebox channel 11 (2462 Mhz 11g) authmode SHARED privacy ON deftxkey 1 wepkey 1:104-bit wepkey 2:104-bit wepkey 3:104-bit wepkey 4:104-bit txpower 31.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 add net default: gateway 192.168.1.1 Additional routing options: ignore ICMP redirect=YES log ICMP redirect=YES DOT Starting devd. WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() discon_compl: - invalid connection handle=42 Starting ums0 moused: DOT Configuring keyboard: keymap keyrate keybell DOT hw.acpi.cpu.cx_lowest: C1 -> C1 Additional IP options: drop SYN+FIN packets=YES DOT Mounting NFS file systems: DOT ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib /usr/local/lib/compat /usr/local/lib/compat/pkg /usr/local/lib/qt4 /usr/local/lib/wine a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Clearing /tmp. Creating and/or trimming log files: DOT Starting syslogd. Checking for core dump on /dev/ad0s1b... savecore: reboot after panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 Aug 22 17:54:47 moshnroll savecore: reboot after panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 savecore: writing core to vmcore.0 Initial i386 initialization: DOT Additional ABI support: linux DOT Setting date via ntp. Error : hostname nor servname provided, or not known 22 Aug 17:55:46 ntpdate[592]: can't find host rustime01.rus.uni-stuttgart.de 22 Aug 17:55:46 ntpdate[592]: no servers can be used, exiting Starting hcsecd. Starting local daemons: DOT Updating motd DOT Mounting late file systems: DOT Starting powerd. Starting sdpd. Starting smartd. Starting musicpd. Avahi: Failed to create client: Daemon not running Starting fetchmail. fetchmail: no mailservers have been specified. Starting cupsd. Configuring syscons: keymap keyrate keybell cursor font8x16 font8x14 font8x8 blanktime DOT Starting cron. Local package initialization: DOT Starting background file system checks in 60 seconds. Fri Aug 22 17:55:52 CEST 2008 ath0: link state changed to UP --- dmesg ends here --- --- crash begins here --- GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: sblastmbufchk: sb_mb 0xc91a5300 sb_mbtail 0 last 0xc91a5300 packet tree: 0xc91a5300 panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 cpuid = 0 Syncing disks, buffers remaining... 7171 7168 7168 7168 7168 7168 7168 7167 7169 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 Giving up on 7167 buffers Uptime: 2d18h9m43s Physical memory: 2030 MB Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Dump complete panic: 5 vncache entries remaining cpuid = 0 Uptime: 2d18h9m47s Physical memory: 2030 MB Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/cd9660.ko...Reading symbols from /boot/kernel/cd9660.ko.symbols...done. done. Loaded symbols for /boot/kernel/cd9660.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from /boot/kernel/pseudofs.ko.symbols...done. done. Loaded symbols for /boot/kernel/pseudofs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/procfs.ko...Reading symbols from /boot/kernel/procfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/procfs.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/ums.ko...Reading symbols from /boot/kernel/ums.ko.symbols...done. done. Loaded symbols for /boot/kernel/ums.ko Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko Reading symbols from /boot/kernel/cam.ko...Reading symbols from /boot/kernel/cam.ko.symbols...done. done. Loaded symbols for /boot/kernel/cam.ko Reading symbols from /boot/kernel/random.ko...Reading symbols from /boot/kernel/random.ko.symbols...done. done. Loaded symbols for /boot/kernel/random.ko Reading symbols from /boot/kernel/wlan_wep.ko...Reading symbols from /boot/kernel/wlan_wep.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_wep.ko Reading symbols from /boot/kernel/wlan_scan_sta.ko...Reading symbols from /boot/kernel/wlan_scan_sta.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_scan_sta.ko Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ubt.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_bluetooth.ko Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_hci.ko Reading symbols from /boot/kernel/ng_l2cap.ko...Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_l2cap.ko Reading symbols from /boot/kernel/ng_btsocket.ko...Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_btsocket.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko #0 doadump () at pcpu.h:195 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc04daa4e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc07d73e4 in pfs_vncache_unload () at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs_vncache.c:102 #4 0xc07d6515 in pfs_modevent (mod=0xc54b8280, evt=2, arg=0x0) at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs.c:438 #5 0xc04cd318 in module_shutdown (arg1=0x0, arg2=) at /usr/src/sys/kern/kern_module.c:105 #6 0xc04daaef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:421 #7 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 #8 0xc052d79b in sblastmbufchk (sb=0x0, file=0xc06838ad "/usr/src/sys/kern/uipc_sockbuf.c", line=794) at /usr/src/sys/kern/uipc_sockbuf.c:425 #9 0xc052eed0 in sbcompress (sb=0xc8cb11f0, m=0x0, n=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:794 #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 #11 0xc052f041 in sbappendrecord (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:610 #12 0xc5a2f8fe in ng_btsocket_l2cap_input (context=0x0, pending=1) at /usr/src/sys/modules/netgraph/bluetooth/socket/../../../../netgraph/bluetooth/socket/ng_btsocket_l2cap.c:1458 #13 0xc050cd1b in taskqueue_run (queue=0xc556b500) at /usr/src/sys/kern/subr_taskqueue.c:282 #14 0xc050cf53 in taskqueue_swi_giant_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:336 #15 0xc04be975 in ithread_loop (arg=0xc55d7160) at /usr/src/sys/kern/kern_intr.c:1088 #16 0xc04bc258 in fork_exit (callout=0xc04be7b0 , arg=0xc55d7160, frame=0xe5b12d38) at /usr/src/sys/kern/kern_fork.c:781 #17 0xc06348b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 --- crash ends here --- --- ARUNDEL begins here --- cpu I686_CPU ident ARUNDEL #maxusers 10 makeoptions DEBUG=-g #makeoptions CONF_CFLAGS=-fno-builtin #options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table #options CPU_SUSP_HLT #options CPU_UPGRADE_HW_CACHE #options CPU_FASTER_5X86_FPU options ATA_STATIC_ID #options MSDOSFS #options CD9660 #options USB_DEBUG #options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN #options HZ=100 #options PREEMPTION #options IPI_PREEMPTION options SCHED_4BSD #4BSD scheduler #options SCHED_ULE options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_43TTY #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options COMPAT_FREEBSD5 #Compatible with FreeBSD5 options COMPAT_FREEBSD6 #Compatible with FreeBSD6 options SC_HISTORY_SIZE=1000 #number of history buffer lines #options KDB #Compile with kernel debugger related code #options KDB_TRACE #Print a stack trace of the current thread on the console for a panic. #options KTRACE #ktrace(1) support #options DDB options INVARIANTS options INVARIANT_SUPPORT options SOCKBUF_DEBUG options WITNESS options WITNESS_SKIPSPIN options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV #install a CDEV entry in /dev options UKBD_DFLT_KEYMAP #specify the built-in keymap makeoptions UKBD_DFLT_KEYMAP="german.iso" #options AUTO_EOI_1 #options AUTO_EOI_2 #options ADAPTIVE_GIANT # Giant mutex is adaptive. #options STOP_NMI # Stop CPUS using NMI instead of IPI options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC #devices device eisa device pci device ata device atadisk device atapicd device usb device uhci device ehci device vga device sc device ukbd device ulpt device ath device ath_hal device ath_rate_sample device wlan device cpufreq device coretemp #pseudo devices device loop device ether device pty --- ARUNDEL ends here --- --- ps begins here --- USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 10 78,9 0,0 0 8 ?? RL 5:54pm 12:54,60 [idle: cpu0] root 874 7,1 1,9 311952 39548 v0 S 5:56pm 0:33,92 X :0 -auth /home/arundel/.serverauth.855 (Xorg) arundel 716 0,4 0,3 9288 6460 ?? S 5:55pm 0:27,85 /usr/local/bin/mpd /usr/local/etc/mpd.conf root 30 0,1 0,0 0 8 ?? RL 5:54pm 0:10,86 [irq22: pcm0] root 946 0,0 0,6 14436 12000 ?? Ss 6:01pm 0:02,30 xterm root 0 0,0 0,0 0 0 ?? WLs 5:54pm 0:00,00 [swapper] root 1 0,0 0,0 1888 448 ?? ILs 5:54pm 0:00,01 /sbin/init -- root 2 0,0 0,0 0 8 ?? DL 5:54pm 0:00,17 [g_event] root 3 0,0 0,0 0 8 ?? DL 5:54pm 0:08,86 [g_up] root 4 0,0 0,0 0 8 ?? DL 5:54pm 0:06,24 [g_down] root 5 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [acpi_task_0] root 6 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [acpi_task_1] root 7 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [acpi_task_2] root 8 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [kqueue taskq] root 9 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [xpt_thrd] root 11 0,0 0,0 0 8 ?? WL 5:54pm 0:00,10 [swi1: net] root 12 0,0 0,0 0 8 ?? RL 5:54pm 0:03,43 [swi4: clock] root 13 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi3: vm] root 14 0,0 0,0 0 8 ?? DL 5:54pm 0:00,54 [yarrow] root 15 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi6: Giant taskq] root 16 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi6: task queue] root 17 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi5: +] root 18 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [swi2: cambio] root 19 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [thread taskq] root 20 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq9: acpi0] root 21 0,0 0,0 0 8 ?? WL 5:54pm 0:00,32 [irq16: nvidia0+] root 22 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb0] root 23 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usbtask-hc] root 24 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usbtask-dr] root 25 0,0 0,0 0 8 ?? WL 5:54pm 0:00,47 [irq21: uhci1] root 26 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb1] root 27 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq18: uhci2 ehci+] root 28 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb2] root 29 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb3] root 31 0,0 0,0 0 8 ?? WL 5:54pm 0:01,68 [irq19: ath0 uhci4*] root 32 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq23: uhci3 ehci1] root 33 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb4] root 34 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb5] root 35 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb6] root 36 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [usb7] root 37 0,0 0,0 0 8 ?? DL 5:54pm 0:01,27 [ath0 taskq] root 38 0,0 0,0 0 8 ?? WL 5:54pm 0:03,42 [irq14: ata0] root 39 0,0 0,0 0 8 ?? WL 5:54pm 0:00,00 [irq15: ata1] root 40 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [pagedaemon] root 41 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [vmdaemon] root 42 0,0 0,0 0 8 ?? DL 5:54pm 0:00,00 [pagezero] root 43 0,0 0,0 0 8 ?? DL 5:54pm 0:01,57 [bufdaemon] root 44 0,0 0,0 0 8 ?? DL 5:54pm 0:00,38 [syncer] root 45 0,0 0,0 0 8 ?? DL 5:54pm 0:00,02 [vnlru] root 46 0,0 0,0 0 8 ?? DL 5:54pm 0:00,74 [softdepflush] root 47 0,0 0,0 0 8 ?? DL 5:54pm 0:00,16 [schedcpu] root 184 0,0 0,0 1368 796 ?? Is 5:54pm 0:00,00 adjkerntz -i root 401 0,0 0,1 3256 1088 ?? Ss 5:54pm 0:04,47 /usr/sbin/moused -z4 -r 1600 -a 0.2,0.2 -F 6400 -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid root 461 0,0 0,0 1888 544 ?? Is 5:54pm 0:00,00 /sbin/devd root 579 0,0 0,1 3172 1232 ?? Ss 5:54pm 0:00,02 /usr/sbin/syslogd -s root 640 0,0 0,0 3128 1012 ?? Is 5:55pm 0:00,00 /usr/sbin/hcsecd -f /etc/bluetooth/hcsecd.conf root 673 0,0 0,0 3172 1008 ?? Ss 5:55pm 0:00,91 /usr/sbin/powerd nobody 683 0,0 0,1 3116 1148 ?? Is 5:55pm 0:00,00 /usr/sbin/sdpd -c /var/run/sdp -g nobody -u nobody root 699 0,0 0,1 4292 2036 ?? I 5:55pm 0:00,01 /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/etc/smartd.conf arundel 712 0,0 0,2 9288 3928 ?? S 5:55pm 0:00,29 /usr/local/bin/mpd /usr/local/etc/mpd.conf arundel 714 0,0 0,3 9288 5928 ?? S 5:55pm 0:02,50 /usr/local/bin/mpd /usr/local/etc/mpd.conf root 727 0,0 0,1 5868 3012 ?? Ss 5:55pm 0:00,04 sendmail: accepting connections (sendmail) smmsp 733 0,0 0,2 5868 3124 ?? Is 5:55pm 0:00,00 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) root 757 0,0 0,2 5340 3400 ?? Is 5:55pm 0:00,02 /usr/local/sbin/cupsd root 782 0,0 0,1 3200 1288 ?? Is 5:55pm 0:00,01 /usr/sbin/cron -s arundel 840 0,0 0,1 6048 2544 ?? Is 5:55pm 0:00,11 /usr/local/bin/fetchmail root 842 0,0 0,1 5776 2484 ?? Is 5:55pm 0:00,25 /usr/local/bin/scmpc --config-file /home/arundel/.scmpcrc root 844 0,0 0,1 4772 1704 ?? Is 5:55pm 0:00,00 /usr/local/bin/obexapp -u arundel -r /var/spool/obex -s -C1 root 884 0,0 0,6 14436 11904 ?? Ss 5:56pm 0:01,46 xterm arundel 908 0,0 0,1 3452 1476 ?? Is 5:59pm 0:00,06 /bin/sh /usr/local/bin/firefox3 arundel 912 0,0 0,1 3452 1512 ?? I 5:59pm 0:00,03 /bin/sh /usr/local/lib/firefox3/run-mozilla.sh /usr/local/lib/firefox3/firefox-bin arundel 917 0,0 3,4 84620 71296 ?? I 5:59pm 0:37,97 /usr/local/lib/firefox3/firefox-bin arundel 919 0,0 0,2 6008 3252 ?? S 5:59pm 0:00,09 /usr/local/libexec/gconfd-2 16 root 971 0,0 0,6 14436 11992 ?? Ss 6:04pm 0:00,41 xterm root 845 0,0 0,1 3612 1624 v0 Is 5:55pm 0:00,12 login [pam] (login) arundel 853 0,0 0,1 4384 2304 v0 I 5:56pm 0:00,08 -bash (bash) arundel 855 0,0 0,1 3452 1476 v0 I+ 5:56pm 0:00,04 /bin/sh /usr/local/bin/startx arundel 873 0,0 0,1 4124 1492 v0 I+ 5:56pm 0:00,01 xinit /home/arundel/.xinitrc -- -auth /home/arundel/.serverauth.855 arundel 879 0,0 0,1 3488 1456 v0 I 5:56pm 0:00,00 sh /home/arundel/.xinitrc arundel 882 0,0 0,5 15352 11076 v0 S 5:56pm 0:01,89 /usr/local/bin/awesome root 846 0,0 0,1 3172 1080 v1 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv1 root 847 0,0 0,1 3172 1080 v2 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv2 root 848 0,0 0,1 3172 1080 v3 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv3 root 849 0,0 0,1 3172 1080 v4 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv4 root 850 0,0 0,1 3172 1080 v5 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv5 root 851 0,0 0,1 3172 1080 v6 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv6 root 852 0,0 0,1 3172 1080 v7 Is+ 5:55pm 0:00,00 /usr/libexec/getty Pc ttyv7 arundel 886 0,0 0,1 4384 2352 p0 Is 5:56pm 0:00,08 -bash (bash) arundel 906 0,0 0,1 3368 1804 p0 I+ 5:58pm 0:00,10 edit crash arundel 948 0,0 0,1 4384 2348 p1 Ss 6:01pm 0:00,14 -bash (bash) arundel 1110 0,0 0,1 3268 1208 p1 R+ 6:10pm 0:00,02 ps aux arundel 973 0,0 0,1 4384 2348 p2 Is+ 6:04pm 0:00,04 -bash (bash) --- ps ends here --- cheers. >How-To-Repeat: >Fix: From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 18:51:27 2008 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 14C261065681 for ; Sat, 23 Aug 2008 18:51:27 +0000 (UTC) (envelope-from jfmays@launchpad.win.net) Received: from nb-209.win.net (nb-209.win.net [216.24.27.209]) by mx1.freebsd.org (Postfix) with ESMTP id E4A958FC0C for ; Sat, 23 Aug 2008 18:51:26 +0000 (UTC) (envelope-from jfmays@launchpad.win.net) Received: from launchpad02 (tractor.launchpad.win.net [216.24.24.68]) by nb-209.win.net (Postfix) with SMTP id 762DEC5F8C for ; Sat, 23 Aug 2008 14:28:01 -0400 (EDT) Message-ID: <000501c9054d$cb43ab00$441818d8@launchpad02> From: "Joe Mays" To: Date: Sat, 23 Aug 2008 14:26:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1933 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 Subject: Fw: Kernel Panic in SCTP 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, 23 Aug 2008 18:51:27 -0000 Just thought I'd put this out there again. Is there anyone who was involved in the SCTP installation on list? > Hello. > > We've recently written an extensive software system that uses SCTP as a > critical component. We've started to run into an issue where the box kenel > panics after throwing an error message from sctp_timer.c that says "Our list > is out of order? Out of order list". Can anyone here shed light on what's > going on, or give us a clue how to debug this? > > http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 Joe Mays From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 21:29:30 2008 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 D710A106567D for ; Sat, 23 Aug 2008 21:29:30 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0938FC24 for ; Sat, 23 Aug 2008 21:29:30 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id 6787B33C73 for ; Sun, 24 Aug 2008 01:29:29 +0400 (MSD) Message-ID: <48B07DC5.2030203@localhost.inse.ru> Date: Sun, 24 Aug 2008 01:14:45 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------020709070808060601010408" Subject: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] 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, 23 Aug 2008 21:29:30 -0000 This is a multi-part message in MIME format. --------------020709070808060601010408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The IPFW_DEFAULT_RULE is also the max allowed rule number. This value should be definitely public, so here is the patch, if there is no objections I'll commit it within a couple of days. After that, I plan to fix a couple of tools that need to know this value. Best regards, rik --------------020709070808060601010408 Content-Type: text/plain; name="patch_fbsd_2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch_fbsd_2" Index: ip_fw.h =================================================================== --- ip_fw.h (revision 182080) +++ ip_fw.h (working copy) @@ -29,6 +29,11 @@ #define _IPFW2_H /* + * The default rule number. It is also the max possible rule number. + */ +#define IPFW_DEFAULT_RULE 65535 + +/* * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF * instructions), which specify which fields of the packet Index: ip_fw2.c =================================================================== --- ip_fw2.c (revision 182080) +++ ip_fw2.c (working copy) @@ -122,7 +122,6 @@ static struct callout ipfw_timeout; static uma_zone_t ipfw_dyn_rule_zone; -#define IPFW_DEFAULT_RULE 65535 /* * Data structure to cache our ucred related --------------020709070808060601010408-- From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 21:35:41 2008 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 C2A0C106566B for ; Sat, 23 Aug 2008 21:35:41 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 791028FC13 for ; Sat, 23 Aug 2008 21:35:37 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id 5639B33C57 for ; Sun, 24 Aug 2008 01:18:31 +0400 (MSD) Message-ID: <48B07B32.4040008@localhost.inse.ru> Date: Sun, 24 Aug 2008 01:03:46 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------060005050808040906070906" Subject: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private 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, 23 Aug 2008 21:35:41 -0000 This is a multi-part message in MIME format. --------------060005050808040906070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The IPFW_DEFAULT_RULE is also the max allowed rule number. This value should be definitely public, so here is the patch, if there is no objections I'll commit it within a couple of days. After that, I plan to fix a couple of tools that need to know this value. Best regards, rik --------------060005050808040906070906 Content-Type: text/plain; name="patch_fbsd_2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch_fbsd_2" Index: ip_fw.h =================================================================== --- ip_fw.h (revision 182080) +++ ip_fw.h (working copy) @@ -29,6 +29,11 @@ #define _IPFW2_H /* + * The default rule number. It is also the max possible rule number. + */ +#define IPFW_DEFAULT_RULE 65535 + +/* * The kernel representation of ipfw rules is made of a list of * 'instructions' (for all practical purposes equivalent to BPF * instructions), which specify which fields of the packet Index: ip_fw2.c =================================================================== --- ip_fw2.c (revision 182080) +++ ip_fw2.c (working copy) @@ -122,7 +122,6 @@ static struct callout ipfw_timeout; static uma_zone_t ipfw_dyn_rule_zone; -#define IPFW_DEFAULT_RULE 65535 /* * Data structure to cache our ucred related --------------060005050808040906070906-- From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 21:42:17 2008 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 62E00106564A for ; Sat, 23 Aug 2008 21:42:17 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 19D0D8FC16 for ; Sat, 23 Aug 2008 21:42:16 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 74EB573098; Sat, 23 Aug 2008 23:44:52 +0200 (CEST) Date: Sat, 23 Aug 2008 23:44:52 +0200 From: Luigi Rizzo To: Roman Kurakin Message-ID: <20080823214452.GA75815@onelab2.iet.unipi.it> References: <48B07DC5.2030203@localhost.inse.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B07DC5.2030203@localhost.inse.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] 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, 23 Aug 2008 21:42:17 -0000 On Sun, Aug 24, 2008 at 01:14:45AM +0400, Roman Kurakin wrote: > Hi, > > The IPFW_DEFAULT_RULE is also the max allowed rule number. > This value should be definitely public, so here is the patch, if there is > no objections I'll commit it within a couple of days. > After that, I plan to fix a couple of tools that need to know this value. unless the tools you have in mind already include ip_fw.h (in which case the change is harmless and I have no objection), i think it would be better to export the value in a sysctl and let the tools fetch it from there, so they do not need to include the header. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 22:18:37 2008 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 929B11065679 for ; Sat, 23 Aug 2008 22:18:37 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4B42B8FC14 for ; Sat, 23 Aug 2008 22:18:37 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id EF88733C73; Sun, 24 Aug 2008 02:18:35 +0400 (MSD) Message-ID: <48B08946.6030109@localhost.inse.ru> Date: Sun, 24 Aug 2008 02:03:50 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Luigi Rizzo References: <48B07DC5.2030203@localhost.inse.ru> <20080823214452.GA75815@onelab2.iet.unipi.it> In-Reply-To: <20080823214452.GA75815@onelab2.iet.unipi.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] 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, 23 Aug 2008 22:18:37 -0000 Luigi Rizzo wrote: > On Sun, Aug 24, 2008 at 01:14:45AM +0400, Roman Kurakin wrote: > >> Hi, >> >> The IPFW_DEFAULT_RULE is also the max allowed rule number. >> This value should be definitely public, so here is the patch, if there is >> no objections I'll commit it within a couple of days. >> After that, I plan to fix a couple of tools that need to know this value. >> > > unless the tools you have in mind already include ip_fw.h (in which case > the change is harmless and I have no objection), i think it would be better > to export the value in a sysctl and let the tools fetch it from there, > so they do not need to include the header. > In fact, I am talking about ipfw(8) and natd(8). The first one uses hard-coded value, the last one pass rulenumbers to libalias(3) without a check, libalias(3) flushes rules also without a check. Thus if you erroneously set -punch_fw for natd(8) as 50000:60000 (and not 50000:10000) you will have to get to the remote server to set back all flashed rules at the beginning of the list. Yes, such fix will not save from such stupidities but can decrease the number of them. IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would be better to export this value via sysctl, not compiled in via #include<> for it. The only thing is binary portability, but expecting this from system utility that not just reads smth but also writes is wrong. Anyway, if you aware of some ports, for which this value would be useful sysctl also could be added but we do not have much time before code-freeze. Best regards, rik > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 23:11:31 2008 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 99AEC1065673 for ; Sat, 23 Aug 2008 23:11:31 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6086A8FC2F for ; Sat, 23 Aug 2008 23:11:30 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C0D007309D; Sun, 24 Aug 2008 01:14:07 +0200 (CEST) Date: Sun, 24 Aug 2008 01:14:07 +0200 From: Luigi Rizzo To: Roman Kurakin Message-ID: <20080823231407.GA76471@onelab2.iet.unipi.it> References: <48B07DC5.2030203@localhost.inse.ru> <20080823214452.GA75815@onelab2.iet.unipi.it> <48B08946.6030109@localhost.inse.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B08946.6030109@localhost.inse.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] 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, 23 Aug 2008 23:11:31 -0000 On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: ... > >unless the tools you have in mind already include ip_fw.h (in which case > >the change is harmless and I have no objection), i think it would be better > >to export the value in a sysctl and let the tools fetch it from there, > >so they do not need to include the header. > > > In fact, I am talking about ipfw(8) and natd(8). The first one uses > hard-coded value, the last one > pass rulenumbers to libalias(3) without a check, libalias(3) flushes ... > IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would > be better to export > this value via sysctl, not compiled in via #include<> for it. The only because ip_fw.h has a lot of stuff in it which in turn is likely to require more headers to build correctly. This is unnecessary bloat at compile time, and also less practical than the sysctl-based approach because it requires a binary update if the value ever changes. Besides, implementing the sysctl does not require to change the headers (thus saving rebuilds of the objects that depend on it), is one line in one file (ip_fw2.c) in the kernel, and one line to call sysctlbyname() in each of the userland program, which you'd need to change anyways; and because both ipfw(8) and natd(8) already use sysctl/sysctlbyname to read/write other similar values from the kernel, you are more consistent with the existing code and don't even need additional headers. At runtime the sysctl is obviously more expensive than reading a hardwired constant, but still a whole lot cheaper than the subsequent action (adding a rule to the firewall) so one won't notice. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 23:33:24 2008 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 BB3EE106567C for ; Sat, 23 Aug 2008 23:33:24 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 777148FC13 for ; Sat, 23 Aug 2008 23:33:24 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id 1C9C833C57; Sun, 24 Aug 2008 03:33:23 +0400 (MSD) Message-ID: <48B09ACD.1050600@localhost.inse.ru> Date: Sun, 24 Aug 2008 03:18:37 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Luigi Rizzo References: <48B07DC5.2030203@localhost.inse.ru> <20080823214452.GA75815@onelab2.iet.unipi.it> <48B08946.6030109@localhost.inse.ru> <20080823231407.GA76471@onelab2.iet.unipi.it> In-Reply-To: <20080823231407.GA76471@onelab2.iet.unipi.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] 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, 23 Aug 2008 23:33:24 -0000 Luigi Rizzo wrote: > On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: > ... > >>> unless the tools you have in mind already include ip_fw.h (in which case >>> the change is harmless and I have no objection), i think it would be better >>> to export the value in a sysctl and let the tools fetch it from there, >>> so they do not need to include the header. >>> >>> >> In fact, I am talking about ipfw(8) and natd(8). The first one uses >> hard-coded value, the last one >> pass rulenumbers to libalias(3) without a check, libalias(3) flushes >> > ... > >> IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would >> be better to export >> this value via sysctl, not compiled in via #include<> for it. The only >> > > because ip_fw.h has a lot of stuff in it which in turn is likely > to require more headers to build correctly. This is unnecessary bloat > at compile time, and also less practical than the sysctl-based approach > because it requires a binary update if the value ever changes. > > Besides, implementing the sysctl does not require to change the > headers (thus saving rebuilds of the objects that depend on it), > is one line in one file (ip_fw2.c) in the kernel, and one line to > call sysctlbyname() in each of the userland program, which you'd > need to change anyways; and because both ipfw(8) and natd(8) already > use sysctl/sysctlbyname to read/write other similar values from the > kernel, you are more consistent with the existing code and don't > even need additional headers. > Agreed, but including ip_fw.h for natd.c does not require any additional headers. All that needed looks like already there. If some one point me to other utilities that need to be fixed I'll also a sysctl for them. These two already include enough of netinet includes, so if you not strictly against adding just one more include for natd, I'll prefer not to add a sysctl by right now. rik > At runtime the sysctl is obviously more expensive than reading a > hardwired constant, but still a whole lot cheaper than the subsequent > action (adding a rule to the firewall) so one won't notice. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Aug 23 23:49:59 2008 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 7CA551065670 for ; Sat, 23 Aug 2008 23:49:59 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 13BCA8FC18 for ; Sat, 23 Aug 2008 23:49:59 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-055-028.pools.arcor-ip.net [88.66.55.28]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1KX2rl1fKZ-0000Xp; Sun, 24 Aug 2008 01:49:58 +0200 Received: (qmail 93593 invoked from network); 23 Aug 2008 23:49:57 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 23 Aug 2008 23:49:57 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sun, 24 Aug 2008 01:49:56 +0200 User-Agent: KMail/1.10.0 (FreeBSD/8.0-CURRENT; KDE/4.1.0; i386; ; ) References: <48B07DC5.2030203@localhost.inse.ru> <20080823231407.GA76471@onelab2.iet.unipi.it> <48B09ACD.1050600@localhost.inse.ru> In-Reply-To: <48B09ACD.1050600@localhost.inse.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808240149.56698.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/vtfRphMS76os3fF3PuJ2sMmWePt5u5f6wnmS E+BH3UMUt4UOEe1g4xnSSGefO7ExSJVuk10RMEYghp1h0RUKyf vSboaHiZkG3YjjvoQF6hg== Cc: Roman Kurakin , Luigi Rizzo Subject: Re: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] 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, 23 Aug 2008 23:49:59 -0000 On Sunday 24 August 2008 01:18:37 Roman Kurakin wrote: > Luigi Rizzo wrote: > > On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: > > ... > > > >>> unless the tools you have in mind already include ip_fw.h (in which > >>> case the change is harmless and I have no objection), i think it would > >>> be better to export the value in a sysctl and let the tools fetch it > >>> from there, so they do not need to include the header. > >> > >> In fact, I am talking about ipfw(8) and natd(8). The first one uses > >> hard-coded value, the last one > >> pass rulenumbers to libalias(3) without a check, libalias(3) flushes > > > > ... > > > >> IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would > >> be better to export > >> this value via sysctl, not compiled in via #include<> for it. The only > > > > because ip_fw.h has a lot of stuff in it which in turn is likely > > to require more headers to build correctly. This is unnecessary bloat > > at compile time, and also less practical than the sysctl-based approach > > because it requires a binary update if the value ever changes. > > > > Besides, implementing the sysctl does not require to change the > > headers (thus saving rebuilds of the objects that depend on it), > > is one line in one file (ip_fw2.c) in the kernel, and one line to > > call sysctlbyname() in each of the userland program, which you'd > > need to change anyways; and because both ipfw(8) and natd(8) already > > use sysctl/sysctlbyname to read/write other similar values from the > > kernel, you are more consistent with the existing code and don't > > even need additional headers. > > Agreed, but including ip_fw.h for natd.c does not require any additional > headers. > All that needed looks like already there. > If some one point me to other utilities that need to be fixed I'll also > a sysctl for them. > These two already include enough of netinet includes, so if you not > strictly against adding > just one more include for natd, I'll prefer not to add a sysctl by right > now. There is no guarantee that the kernel or ipfw module you are running was built with the installed ip_fw.h or that IPFW_DEFAULT_RULE wasn't defined differently in the build environment. So a sysctl (or the like) is the *only* correct approach. Please fix it for real and don't just slap band-aid at it. Nice catch, by the way! > rik > > > At runtime the sysctl is obviously more expensive than reading a > > hardwired constant, but still a whole lot cheaper than the subsequent > > action (adding a rule to the firewall) so one won't notice. > > > > cheers > > luigi > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News