From owner-freebsd-net@FreeBSD.ORG Sun Jul 2 11:31:57 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67D2A16A416 for ; Sun, 2 Jul 2006 11:31:57 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 645EE44465 for ; Sun, 2 Jul 2006 11:31:55 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k62BVQqx071390 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 2 Jul 2006 13:31:37 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <200606271813.29980.mi+mx@aldan.algebra.com> References: <200606271813.29980.mi+mx@aldan.algebra.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7024797F-62A3-43C0-A119-50A3DD34B279@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Sun, 2 Jul 2006 13:30:56 +0200 To: Mikhail Teterin X-Mailer: Apple Mail (2.752.2) Cc: rizzo@icir.org, net@freebsd.org Subject: Re: using ipfw seems to interfere with socket communication 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, 02 Jul 2006 11:31:57 -0000 Am 28.06.2006 um 00:13 schrieb Mikhail Teterin: > fconfigure $sock -blocking 0 > lappend result c:[gets $sock] > > was always returning empty string, instead of the string "two", > that was > written into the socket and flushed. > > Is the test wrong, and such result is possible, or is dummynet > triggering a > bug? Unloading the dummynet module allows the test to succeed... The test is wrong. See recvfrom(2), which the gets will eventually invoke: If no messages are available at the socket, the receive call waits for a message to arrive, unless the socket is nonblocking (see fcntl (2)) in which case the value -1 is returned and the external variable errno set to EAGAIN. And Tcl gets(n): If end of file occurs while scanning for an end of line, the command returns whatever input is available up to the end of file. If chan- nelId is in nonblocking mode and there is not a full line of input available, the command returns an empty string and does not consume any input. If varName is specified and an empty string is returned in var- Name because of end-of-file or because of insufficient data in non- blocking mode, then the return count is -1. Note that if varName is not specified then the end-of-file and no-full-line-available cases can produce the same results as if there were an input line consisting only of the end-of-line character(s). Essentially, dummynet delays processing of that "two" line just long enough to break the code's assumption that TCP over the loopback interface is instantaneous. If my fading memory of TCP/IP Illustrated Vol 2 serves me right, that was actually the case at least back then: the sendto system call would push the data all the way down to lo0, which would immediately pass it back up until it ended up in the receiving socket buffer. Dummynet will queue the packet, regardless, so it won't get delivered until the next time dummynet processes queues. In non-blocking mode, you must always be prepared to wait for data. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Sun Jul 2 11:37:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6D7416A403 for ; Sun, 2 Jul 2006 11:37:06 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 248CD44356 for ; Sun, 2 Jul 2006 11:37:05 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2006 04:37:05 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="1834478942:sNHT84636148" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k62Bb5Ji008357; Sun, 2 Jul 2006 04:37:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62Bb4cL023110; Sun, 2 Jul 2006 04:37:04 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Jul 2006 04:37:04 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Jul 2006 04:37:03 -0700 Message-ID: <44A7AFDF.50303@cisco.com> Date: Sun, 02 Jul 2006 07:37:03 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yann Berthier References: <44A552FA.2030302@cisco.com> <20060701182815.GD1788@bashibuzuk.net> In-Reply-To: <20060701182815.GD1788@bashibuzuk.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2006 11:37:04.0095 (UTC) FILETIME=[D7322EF0:01C69DCB] DKIM-Signature: a=rsa-sha1; q=dns; l=3343; t=1151840225; x=1152704225; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20SCTP; X=v=3Dcisco.com=3B=20h=3DeFwn8yHouLxYzxwWS0cbAORTlr0=3D; b=cxhxi7Hur4J8i9HKomJNHbAFFg8Ko3/L5f8x/AaXxXj/fiUsW9YUJ0SMho77IwiGPwpc5EOo TOedvMW6u0cY5E6J1EFf/RxCeDsruxC07XiC6970fvl72Gjh9qZkrQlk; Authentication-Results: sj-dkim-8.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org Subject: Re: 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: Sun, 02 Jul 2006 11:37:06 -0000 Yann: Sorry for the delay.. I would have responded quicker but we have company for this long weekend in the US :-D This is definetly a pilot error on my part.. but I can't figure out how... it appears (in the patch) that all the files are there... But.. I am wondering.. in your source netinet/ and netinet6/ directory.. if you do a ls sctp* do you see anything? All of these functions are in the sctp_xxx.c files.. all of which, in order to get CVS to even recognize them for patching, I had to do a touch sctp_xxx* The files are: --->cd sys/netinet --->ls sctp* sctp.h sctp_hashdriver.h sctp_sack.h sctp6_usrreq.c sctp_header.h sctp_sha1.c sctp6_var.h sctp_indata.c sctp_sha1.h sctp_asconf.c sctp_indata.h sctp_structs.h sctp_asconf.h sctp_input.c sctp_timer.c sctp_auth.c sctp_input.h sctp_timer.h sctp_auth.h sctp_output.c sctp_uio.h sctp_constants.h sctp_output.h sctp_usrreq.c sctp_crc32.c sctp_pcb.c sctp_var.h sctp_crc32.h sctp_pcb.h sctputil.c sctp_handlesack.c sctp_peeloff.c sctputil.h sctp_hashdriver.c sctp_peeloff.h --->cd ../netinet6 --->ls sctp* sctp6_usrreq.c sctp6_var.h Hmm I am wondering if perhaps if no files are present the patch stuff won't work??? Maybe I should have sent out a tarball of the sctp files and a patch file for all the kernel stuff??? Let me know I am a bit confused by this.. sigh.. R Yann Berthier wrote: > Hello, > > On Fri, 30 Jun 2006, at 12:36, Randall Stewart wrote: > > >>Hi all: >> >>The following link: >> >>http://www.sctp.org/cvs_diff_6_30.bz2 >> >>Will get you a large patch that you can apply to Current that >>will add SCTP. > > > Pilot error ? freshly cvsuped src, patch applied cleanly, > made sysent, and: > > linking kernel.debug > uipc_syscalls.o(.text+0x47c8): In function `sctp_peeloff': > /usr/src/sys/kern/uipc_syscalls.c:2239: undefined reference to > `sctp_can_peel_off' > uipc_syscalls.o(.text+0x49c2):/usr/src/sys/kern/uipc_syscalls.c:2276: > undefined reference to `sctp_do_peeloff' > uipc_syscalls.o(.text+0x4cd7): In function `sctp_generic_sendmsg': > /usr/src/sys/kern/uipc_syscalls.c:2379: undefined reference to > `sctp_lower_sosend' > uipc_syscalls.o(.text+0x506c): In function `sctp_generic_recvmsg': > /usr/src/sys/kern/uipc_syscalls.c:2501: undefined reference to > `sctp_sorecvmsg' > rtsock.o(.text+0x1799): In function `rt_newaddrmsg': > /usr/src/sys/net/rtsock.c:879: undefined reference to `sctp_addr_change' > in_proto.o(.data+0xa8): undefined reference to `sctp_input' > in_proto.o(.data+0xb0): undefined reference to `sctp_ctlinput' > in_proto.o(.data+0xb4): undefined reference to `sctp_ctloutput' > in_proto.o(.data+0xbc): undefined reference to `sctp_init' > in_proto.o(.data+0xc8): undefined reference to `sctp_drain' > [...] > > bummer that, testing sctp seemed like an interesting thing for a > sunny saturday evening :) > > many thanks for your work, > > - yan > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Sun Jul 2 14:31:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB08116A412 for ; Sun, 2 Jul 2006 14:31:09 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB3944403 for ; Sun, 2 Jul 2006 14:31:09 +0000 (GMT) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id C222FBF9224; Sun, 2 Jul 2006 16:31:07 +0200 (CEST) Received: by cc.bashibuzuk.net (Postfix, from userid 1001) id DE140BDA0; Sun, 2 Jul 2006 16:31:26 +0200 (CEST) Date: Sun, 2 Jul 2006 16:31:26 +0200 From: Yann Berthier To: Randall Stewart Message-ID: <20060702143126.GG1788@bashibuzuk.net> References: <44A552FA.2030302@cisco.com> <20060701182815.GD1788@bashibuzuk.net> <44A7AFDF.50303@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A7AFDF.50303@cisco.com> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: 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: Sun, 02 Jul 2006 14:31:09 -0000 On Sun, 02 Jul 2006, at 07:37, Randall Stewart wrote: > Yann: > > Sorry for the delay.. I would have responded quicker > but we have company for this long weekend in the US :-D no problem really > This is definetly a pilot error on my part.. ok never mind: it was a pilot error on my side, but it's all your fault: I had to include INET6 and the build went fine. Please, say me that this is a temporary measure :) thanks, - yan From owner-freebsd-net@FreeBSD.ORG Sun Jul 2 15:47:40 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12B7716A407 for ; Sun, 2 Jul 2006 15:47:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1AF1442F5 for ; Sun, 2 Jul 2006 15:47:39 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 544ED46C16; Sun, 2 Jul 2006 11:47:39 -0400 (EDT) Date: Sun, 2 Jul 2006 16:47:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stefan Bethke In-Reply-To: <7024797F-62A3-43C0-A119-50A3DD34B279@lassitu.de> Message-ID: <20060702164232.G67344@fledge.watson.org> References: <200606271813.29980.mi+mx@aldan.algebra.com> <7024797F-62A3-43C0-A119-50A3DD34B279@lassitu.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rizzo@icir.org, Mikhail Teterin , net@freebsd.org Subject: Re: using ipfw seems to interfere with socket communication 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, 02 Jul 2006 15:47:40 -0000 On Sun, 2 Jul 2006, Stefan Bethke wrote: > Essentially, dummynet delays processing of that "two" line just long enough > to break the code's assumption that TCP over the loopback interface is > instantaneous. If my fading memory of TCP/IP Illustrated Vol 2 serves me > right, that was actually the case at least back then: the sendto system call > would push the data all the way down to lo0, which would immediately pass it > back up until it ended up in the receiving socket buffer. Dummynet will > queue the packet, regardless, so it won't get delivered until the next time > dummynet processes queues. With TCP (and UDP), the ability to immediately deliver has never been guaranteed due to socket buffer and window limits, scheduling priority, etc. TCP over the loopback interface really is TCP -- data is broken up into segments, wrapped in TCP/IP headers, processed by the firewall and dummynet, etc. UNIX domain sockets should be used if it's desirable to avoid this, as that implementation delivers directly to the remote socket buffer. However, due to socket buffer sizing and scheduling, blocking is possible there also. Stream sockets do not guarantee message boundary atomicity or immediate delivery, especially in the presence of SMP. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Jul 2 15:55:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FFA216A40F; Sun, 2 Jul 2006 15:55:02 +0000 (UTC) (envelope-from plk@in.nextra.sk) Received: from fw.nextra.sk (fw.nextra.sk [195.168.29.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6657B442F3; Sun, 2 Jul 2006 15:55:00 +0000 (GMT) (envelope-from plk@in.nextra.sk) Received: from plk.in.nextra.sk (localhost [127.0.0.1]) by fw.nextra.sk (8.13.4/8.13.4) with ESMTP id k5U9VDZv005652; Fri, 30 Jun 2006 11:31:13 +0200 Received: (from plk@localhost) by plk.in.nextra.sk (8.13.4/8.13.4/Submit) id k5U9VC20005651; Fri, 30 Jun 2006 11:31:12 +0200 Date: Fri, 30 Jun 2006 11:31:12 +0200 From: Bohuslav Plucinsky To: freebsd-net@freebsd.org, bugs@freebsd.org Message-ID: <20060630093112.GA24299@gtsnextra.sk> References: <20060609113221.GD25880@gtsnextra.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060609113221.GD25880@gtsnextra.sk> Organization: NEXTRA, Bratislava, SLOVAKIA X-NCC-RegID: sk.nextra User-Agent: Mutt/1.5.11 Cc: mlaier@freebsd.org Subject: Re: Xorp and CARP on FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bohuslav.plucinsky@gtsnextra.sk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 15:55:02 -0000 Hello, here is a reply from one of the XORP developers, Pavlin Radoslavov. What is your opinion to this problem ? Thanks, Bohus ----- Forwarded message from Pavlin Radoslavov ----- > To: bohuslav.plucinsky@gtsnextra.sk > cc: Pavlin Radoslavov , feedback@xorp.org > Subject: Re: [Xorp-feedback] Xorp and CARP on FreeBSD > Date: Thu, 29 Jun 2006 15:54:06 -0700 > From: Pavlin Radoslavov > > > On Fri, Jun 09, 2006 at 09:46:36AM -0700, Pavlin Radoslavov wrote: > > > > I've two FreeBSD 6.1-RELEASE routers (R1, R2) with CARP configured > > > > and it was working OK untill I've installed Xorp and tried to configure > > > > multicast PIM-SM. After that the CARP has stoped working. I've found > > > > out by the tcpdump that after Xorp is started the source IP address > > > > of CARP packets is changed to IP address used as register_vif in Xorp: > > > > > > Do you get the same error if you configure only the "interfaces" > > > section in the XORP config. > > > > No, the problem occures, only when the plumbing section is present. > > > > > Also, is any of the IP address changed (by CARP) while XORP is running? > > > > No. There are the CARP virtual interfaces created befor XORP is started. > > CARP dosn't change any IP address, but XORP changes source IP address > > of multicast CARP packets. When I stop XORP the IP address is retutned > > to original IP address. > > Thank you for the info. > I did some investigation (FreeBSD-6.1) and I was able to see the > the problem: VRRPv2 Advertisement messages with the wrong source > address. > > For the record, this is what I did (on a single machine): > > ===================================== > ifconfig vlan97 create > ifconfig vlan97 inet 192.168.100.2 netmask 255.255.255.0 vlan 97 vlandev xl0 > ifconfig vlan71 create > ifconfig vlan71 inet 10.122.25.66 netmask 255.255.255.224 vlan 71 vlandev xl0 > ifconfig carp97 create > ifconfig carp97 vhid 1 pass foofoo1 192.168.100.1/24 > ifconfig carp71 create > ifconfig carp71 vhid 2 pass foofoo2 10.122.25.64/27 > ===================================== > > Then I started XORP with the configuration file included at the end > of this email. Basically, the important thing in that configuration > file is that inside the MFEA I enabled only the vlan71 interface. > > Indeed, by running tcpdump I was able to see that the VRRPv2 > Advertisement messages sent over vlan97 changed their source address > to be same ass the source address of vlan71: > > ===================================== > root@carp[5] tcpdump -n -i vlan97 proto 112 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vlan97, link-type EN10MB (Ethernet), capture size 96 bytes > 15:38:04.614085 IP 192.168.100.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > 15:38:05.615058 IP 192.168.100.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > ... > 15:38:22.635132 IP 10.122.25.66 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > 15:38:23.636107 IP 10.122.25.66 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > ===================================== > > After some investigation, I was able to trace the problem to the > setsockopt(_mrouter_socket, IPPROTO_IP, MRT_ADD_VIF, ...) system > call. In fact, I was able to reproduce the problem with other > multicast routing implementations: mrouted and pimd which obviously > also use the same setsockopt(). > After some further investigation, it seems to happen only when > running CARP over vlan interfaces, but I haven't investigated this > in greater details. At least, it didn't happen when I enabled in MFEA > the physical xl0 network interface (also running CARP). > > Hence, I belive the problem is in the FreeBSD kernel, and happens > when we have 2+ vlan interfaces configured to run CARP and one of > them is also configured for multicast routing. > > You might want to contact the FreeBSD folks about that, because the > problem is not XORP-specific. > > Please let us know how it goes. > > Thanks, > Pavlin > > > ===================================== > interfaces { > interface vlan97 { > description: "DMZ" > disable: false > default-system-config > } > interface vlan71 { > description: "intranet" > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > plumbing { > mfea4 { > disable: false > interface vlan71 { > vif vlan71 { > disable: false > } > } > /* > interface vlan97 { > vif vlan97 { > disable: false > } > } > */ > /* > interface register_vif { > vif register_vif { > Note: this vif should be always enabled > disable: false > } > } > */ > traceoptions { > flag all { > disable: false > } > } > } > } > ===================================== > > ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Sun Jul 2 18:44:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BD2716A662 for ; Sun, 2 Jul 2006 18:44:39 +0000 (UTC) (envelope-from gcs584@yahoo.com) Received: from web50809.mail.yahoo.com (web50809.mail.yahoo.com [206.190.38.252]) by mx1.FreeBSD.org (Postfix) with SMTP id F33B943D45 for ; Sun, 2 Jul 2006 18:13:52 +0000 (GMT) (envelope-from gcs584@yahoo.com) Received: (qmail 56639 invoked by uid 60001); 2 Jul 2006 18:13:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fYRJ+fxKraudjFXX+rU5uZGZG9jgLf4/Sa6w+IxuNqOYlXJc52BJWu/LdpXy/62f+lW+kyvNMQUNmlfrTBR10AzaJnW+qjlkfe6R/cZg0rK4fJ87gt+7n8a8/RtZwC6He0xZ6bWSXzuBGzrwlB/35NMufNpJ0yzqVf958Kh+2ks= ; Message-ID: <20060702181352.56637.qmail@web50809.mail.yahoo.com> Received: from [62.252.0.5] by web50809.mail.yahoo.com via HTTP; Sun, 02 Jul 2006 19:13:52 BST Date: Sun, 2 Jul 2006 19:13:52 +0100 (BST) From: Gavin Smith To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: ndis with Safecom SWLPT-54108 and FreeBSD 6.1 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, 02 Jul 2006 18:44:39 -0000 Hi, Well, I'm quite new to the *nix/BSD arena, and have been giving it a try lately for a server I'm attempting to host for a University project; so far I've been impressed. I'm trying to setup/install the drivers for a PCI wireless card, but am having little success. The manufacturer of the card is Safecom and the model is SWLPT-54108 (now known as SWLPT-54125). The card uses a TI TNETW1130GVF Chipset. Unfortunately, there are no Linux drivers provided by the company itself. I've been trying to use the ndis wrapper and install the card myself, but I have had little success. Instead of typing out the full procedure of installation, I have already made a post in Safecom's forums here: http://www.adsltech.com/portal/forum/forum_posts.asp?TID=6564&PN=1 The specifications of the PCI card are available here: http://safecom.cn/code/sub/category.asp?prdid=315&subcatid=41 Any guidance/advice would be much appreciated. Regards, Gavin ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 07:48:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8D0E16A4D0; Mon, 3 Jul 2006 07:48:06 +0000 (UTC) (envelope-from lists@yazzy.org) Received: from mx1.yazzy.org (mx1.yazzy.org [84.247.145.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4338B43D48; Mon, 3 Jul 2006 07:48:06 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.witelcom.com ([84.247.144.144] helo=marcin) by mx1.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1FxJA0-0004mX-4i; Mon, 03 Jul 2006 09:48:00 +0200 Date: Mon, 3 Jul 2006 09:48:06 +0200 From: Marcin Jessa To: gnn@freebsd.org Message-ID: <20060703094806.689f33ae@marcin> In-Reply-To: References: <44A552FA.2030302@cisco.com> Organization: YazzY.org X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.19; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: freebsd-net@freebsd.org Subject: Re: 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: Mon, 03 Jul 2006 07:48:06 -0000 On Sat, 01 Jul 2006 17:46:48 +0900 gnn@freebsd.org wrote: > At Fri, 30 Jun 2006 12:36:10 -0400, > randall wrote: > > > > Hi all: > > > > The following link: > > > > http://www.sctp.org/cvs_diff_6_30.bz2 > > > > Will get you a large patch that you can apply to Current that will > > add SCTP. > > > > Its a bzip2 patch file since it is so large :-D > > > > It includes the changes to a few base files.. and mainly its the > > complete files diff'd against this mornings current cvs... > > > > Yes, I know that the build is broken in acpi/acpi_asus but the sctp > > code did compile and build a kernel for me... so once the above is > > fixed.. you should be able to use the patch and check it out :-D > > > > Oh, you will need to add > > > > option SCTP > > > > to your kernel conf... and it might not > > hurt to do a make sysent in sys/kern > > > > I will prepare a seperate file for the overall libsctp.a > > once I figure out where it should go :-D > > > > Happy SCTPing.. and if you have any problems with the patch please > > send me an email :-D > > And please start testing this because many of us want to integrate > this in the near future :-) Any hints on how to test SCTP ? Not much really about any practical implementation of it on http://www.sctp.org/ Marcin. From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 07:49:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A073816A403; Mon, 3 Jul 2006 07:49:14 +0000 (UTC) (envelope-from plk@in.nextra.sk) Received: from fw.nextra.sk (fw.nextra.sk [195.168.29.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E6B43D49; Mon, 3 Jul 2006 07:49:13 +0000 (GMT) (envelope-from plk@in.nextra.sk) Received: from plk.in.nextra.sk (localhost [127.0.0.1]) by fw.nextra.sk (8.13.4/8.13.4) with ESMTP id k637nBcT027368; Mon, 3 Jul 2006 09:49:11 +0200 Received: (from plk@localhost) by plk.in.nextra.sk (8.13.4/8.13.4/Submit) id k637nBQL027367; Mon, 3 Jul 2006 09:49:11 +0200 Date: Mon, 3 Jul 2006 09:49:11 +0200 From: Bohuslav Plucinsky To: freebsd-net@freebsd.org Message-ID: <20060703074911.GB24299@gtsnextra.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: NEXTRA, Bratislava, SLOVAKIA X-NCC-RegID: sk.nextra User-Agent: Mutt/1.5.11 Cc: mlaier@freebsd.org, freebsd-questions@freebsd.org Subject: Re: [Xorp-feedback] Xorp and CARP on FreeBSD] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bohuslav.plucinsky@gtsnextra.sk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 07:49:14 -0000 Hello, here is a reply from one of the XORP developers, Pavlin Radoslavov. What is your opinion to this problem? Thanks, Bohus ----- Forwarded message from Pavlin Radoslavov ----- > To: bohuslav.plucinsky@gtsnextra.sk > Subject: Re: [Xorp-feedback] Xorp and CARP on FreeBSD > Date: Thu, 29 Jun 2006 15:54:06 -0700 > From: Pavlin Radoslavov > > > On Fri, Jun 09, 2006 at 09:46:36AM -0700, Pavlin Radoslavov wrote: > > > > I've two FreeBSD 6.1-RELEASE routers (R1, R2) with CARP configured > > > > and it was working OK untill I've installed Xorp and tried to configure > > > > multicast PIM-SM. After that the CARP has stoped working. I've found > > > > out by the tcpdump that after Xorp is started the source IP address > > > > of CARP packets is changed to IP address used as register_vif in Xorp: > > > > > > Do you get the same error if you configure only the "interfaces" > > > section in the XORP config. > > > > No, the problem occures, only when the plumbing section is present. > > > > > Also, is any of the IP address changed (by CARP) while XORP is running? > > > > No. There are the CARP virtual interfaces created befor XORP is started. > > CARP dosn't change any IP address, but XORP changes source IP address > > of multicast CARP packets. When I stop XORP the IP address is retutned > > to original IP address. > > Thank you for the info. > I did some investigation (FreeBSD-6.1) and I was able to see the > the problem: VRRPv2 Advertisement messages with the wrong source > address. > > For the record, this is what I did (on a single machine): > > ===================================== > ifconfig vlan97 create > ifconfig vlan97 inet 192.168.100.2 netmask 255.255.255.0 vlan 97 vlandev xl0 > ifconfig vlan71 create > ifconfig vlan71 inet 10.122.25.66 netmask 255.255.255.224 vlan 71 vlandev xl0 > ifconfig carp97 create > ifconfig carp97 vhid 1 pass foofoo1 192.168.100.1/24 > ifconfig carp71 create > ifconfig carp71 vhid 2 pass foofoo2 10.122.25.64/27 > ===================================== > > Then I started XORP with the configuration file included at the end > of this email. Basically, the important thing in that configuration > file is that inside the MFEA I enabled only the vlan71 interface. > > Indeed, by running tcpdump I was able to see that the VRRPv2 > Advertisement messages sent over vlan97 changed their source address > to be same ass the source address of vlan71: > > ===================================== > root@carp[5] tcpdump -n -i vlan97 proto 112 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vlan97, link-type EN10MB (Ethernet), capture size 96 bytes > 15:38:04.614085 IP 192.168.100.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > 15:38:05.615058 IP 192.168.100.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > ... > 15:38:22.635132 IP 10.122.25.66 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > 15:38:23.636107 IP 10.122.25.66 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 > ===================================== > > After some investigation, I was able to trace the problem to the > setsockopt(_mrouter_socket, IPPROTO_IP, MRT_ADD_VIF, ...) system > call. In fact, I was able to reproduce the problem with other > multicast routing implementations: mrouted and pimd which obviously > also use the same setsockopt(). > After some further investigation, it seems to happen only when > running CARP over vlan interfaces, but I haven't investigated this > in greater details. At least, it didn't happen when I enabled in MFEA > the physical xl0 network interface (also running CARP). > > Hence, I belive the problem is in the FreeBSD kernel, and happens > when we have 2+ vlan interfaces configured to run CARP and one of > them is also configured for multicast routing. > > You might want to contact the FreeBSD folks about that, because the > problem is not XORP-specific. > > Please let us know how it goes. > > Thanks, > Pavlin > > > ===================================== > interfaces { > interface vlan97 { > description: "DMZ" > disable: false > default-system-config > } > interface vlan71 { > description: "intranet" > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > plumbing { > mfea4 { > disable: false > interface vlan71 { > vif vlan71 { > disable: false > } > } > /* > interface vlan97 { > vif vlan97 { > disable: false > } > } > */ > /* > interface register_vif { > vif register_vif { > Note: this vif should be always enabled > disable: false > } > } > */ > traceoptions { > flag all { > disable: false > } > } > } > } > ===================================== > > ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 08:28:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B64C16A416 for ; Mon, 3 Jul 2006 08:28:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FBF543E2C for ; Mon, 3 Jul 2006 08:27:43 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so397456nzd for ; Mon, 03 Jul 2006 01:27:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=XugUXCFSqWXNBdkMx34JHgk7zK2Lq8v03G+rezf3gdQdmOTOckpm4Vqgo52D7/oI6kNJ5zIL1FjH8EI3OXeKnLK4Db+GKsPhv+iky/M6sIFKpgNTyEbAnXiyRO8f+nQsMAgtXn2EczIKgpQKyevP86YEvx/jHX5dUBVB4oWrH6E= Received: by 10.36.127.4 with SMTP id z4mr1786048nzc; Mon, 03 Jul 2006 01:27:42 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 20sm1840019nzp.2006.07.03.01.27.41; Mon, 03 Jul 2006 01:27:42 -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 k638L4qX065523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jul 2006 17:21:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k638L4ZA065522; Mon, 3 Jul 2006 17:21:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 3 Jul 2006 17:21:04 +0900 From: Pyun YongHyeon To: Nikolas Britton Message-ID: <20060703082104.GB64457@cdnetworks.co.kr> References: <20060630060956.GA51353@cdnetworks.co.kr> <20060701051844.GE54876@cdnetworks.co.kr> <20060701070245.GF54876@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Marvell YukonII Status Update? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 08:28:00 -0000 On Sat, Jul 01, 2006 at 02:54:01AM -0500, Nikolas Britton wrote: > On 7/1/06, Pyun YongHyeon wrote: > >On Sat, Jul 01, 2006 at 01:33:51AM -0500, Nikolas Britton wrote: > > > On 7/1/06, Pyun YongHyeon wrote: > > > >On Fri, Jun 30, 2006 at 11:39:14PM -0500, Nikolas Britton wrote: > > > > > On 6/30/06, Pyun YongHyeon wrote: > > > > > >On Thu, Jun 29, 2006 at 10:53:52PM -0500, Nikolas Britton wrote: > > > > > > > Anyone know what's going on with YukonII support in FreeBSD, > > > > > > > specifically the Marvell chips used in PCI-Express add-on cards? > > > > > > > > > > > > > > Last I checked somebody was developing an experimental driver > > and > > > > > > > Marvell had just released the code to their FreeBSD 5.x/6.x > > driver: > > > > > > > mykbsd60x86-8.12.2.3.tar (bindary kmod package) > > > > > > > mykbsd60x86-8.12.1.3-src.tgz (source code) > > > > > > > > > > > > > > > > > > >I don't know current status of the driver. ATM FreeBSD YukonII > > > > > >driver has stability issues and the driver needs big cleanups > > > > > >if we import the driver into src tree. But I wouldn't do the > > > > > >job and I'll spend my spare time to other thing. > > > > > >I know, from my previous experience(sk(4), stge(4)), how > > > > > >difficult to write a driver without a document and how hard to > > > > > >write a correct driver without knowing hardware internals. I'm > > > > > >sure there are many developers eager to write YukonII driver if > > > > > >they can access the hardware documentation. However I think there > > > > > >is no possibility that Marvell releases their chip documentations. > > > > > > > > > > > > > > > > Marvell will give you the docs if you sign an NDA, I know it's > > stupid > > > > > but I think it's the only way... unless we vote with the wallet... > > Who > > > > > has PCI-Express gigabit NIC cards that meet the following criteria?: > > > > > > > > > > a) Supported by FreeBSD. > > > > > b) Unencumbered documentation. > > > > > c) Checksum offloading. > > > > > > > > > > > > >There are many PCIe GigE hardwares upported by em(4) or bge/bce(4). > > > >AFAIK the only hardware features not supported by em(4)/bge(4) driver > > > >is TSO. And hardwares supported by em(4) also have a capability to > > > >offload IPv6 checksumming too but it's not yet supported by the driver. > > > > > > > > > > Will TCP Segmentation Offloading help if you already use a 9000 byte > > > mtu, and is it going to be supported, someday, with em(4)/bge(4)?... > > > I'm mostly clueless about TSO. > > > > > > >Since not all hardwares support JUMBO frame and the maximum MTU > >for the JUMBO frame varies among vendors/chipsets TSO would be > >better suited for interoperability. > > > >I'm really want to see TSO support in our drivers. See the > >following URL to see TSO effect in NetBSD wm(4) driver. > >http://marc.theaimsgroup.com/?t=111662994600001&r=1&w=2 > > > > I see... A poor mans jumbo frames, but only works with the sender, You may have to get a NIC that supports JUMBO frames on receiver too unless your switch/bridge system fragments the JUMBO frames into standard MTU frames. > correct? If NetBSD supports it can't we more or less just copy and > paste the code to FreeBSD? I know it's never that simple but... > Yes, we may borrow the code from NetBSD implementation but I can't sure we can just copy it. I guess we need careful reexamination the TSO effect on our TCP stack. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 10:49:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AF0216A403 for ; Mon, 3 Jul 2006 10:49:50 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89AED43D4C for ; Mon, 3 Jul 2006 10:49:48 +0000 (GMT) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe (circe.rz.RWTH-Aachen.DE [134.130.3.36]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J1T00E6PQ2R9B@ms-dienst.rz.rwth-aachen.de> for freebsd-net@freebsd.org; Mon, 03 Jul 2006 12:49:40 +0200 (MEST) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Mon, 03 Jul 2006 12:49:39 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.1/8.13.1/1) with ESMTP id k63Anc1s004537; Mon, 03 Jul 2006 12:49:38 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FxLzn-0005RV-49; Mon, 03 Jul 2006 12:49:39 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id D83363F41C; Mon, 03 Jul 2006 12:49:38 +0200 (CEST) Date: Mon, 03 Jul 2006 12:49:38 +0200 From: Christian Brueffer In-reply-to: <20060703082104.GB64457@cdnetworks.co.kr> To: Pyun YongHyeon Message-id: <20060703104938.GA4468@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; boundary=KsGdsel6WgEHnImy; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.11 X-Operating-System: FreeBSD 6.1-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <20060630060956.GA51353@cdnetworks.co.kr> <20060701051844.GE54876@cdnetworks.co.kr> <20060701070245.GF54876@cdnetworks.co.kr> <20060703082104.GB64457@cdnetworks.co.kr> Cc: freebsd-net@freebsd.org, Nikolas Britton Subject: Re: Marvell YukonII Status Update? 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, 03 Jul 2006 10:49:50 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 03, 2006 at 05:21:04PM +0900, Pyun YongHyeon wrote: > On Sat, Jul 01, 2006 at 02:54:01AM -0500, Nikolas Britton wrote: > > On 7/1/06, Pyun YongHyeon wrote: > > >On Sat, Jul 01, 2006 at 01:33:51AM -0500, Nikolas Britton wrote: > > > > On 7/1/06, Pyun YongHyeon wrote: > > > > >On Fri, Jun 30, 2006 at 11:39:14PM -0500, Nikolas Britton wrote: > > > > > > On 6/30/06, Pyun YongHyeon wrote: > > > > > > >On Thu, Jun 29, 2006 at 10:53:52PM -0500, Nikolas Britton wro= te: > > > > > > > > Anyone know what's going on with YukonII support in FreeBS= D, > > > > > > > > specifically the Marvell chips used in PCI-Express add-on = cards? > > > > > > > > > > > > > > > > Last I checked somebody was developing an experimental dri= ver=20 > > > and > > > > > > > > Marvell had just released the code to their FreeBSD 5.x/6.= x=20 > > > driver: > > > > > > > > mykbsd60x86-8.12.2.3.tar (bindary kmod package) > > > > > > > > mykbsd60x86-8.12.1.3-src.tgz (source code) > > > > > > > > > > > > > > > > > > > > > >I don't know current status of the driver. ATM FreeBSD YukonII > > > > > > >driver has stability issues and the driver needs big cleanups > > > > > > >if we import the driver into src tree. But I wouldn't do the > > > > > > >job and I'll spend my spare time to other thing. > > > > > > >I know, from my previous experience(sk(4), stge(4)), how > > > > > > >difficult to write a driver without a document and how hard to > > > > > > >write a correct driver without knowing hardware internals. I'm > > > > > > >sure there are many developers eager to write YukonII driver = if > > > > > > >they can access the hardware documentation. However I think t= here > > > > > > >is no possibility that Marvell releases their chip documentat= ions. > > > > > > > > > > > > > > > > > > > Marvell will give you the docs if you sign an NDA, I know it's= =20 > > > stupid > > > > > > but I think it's the only way... unless we vote with the walle= t...=20 > > > Who > > > > > > has PCI-Express gigabit NIC cards that meet the following crit= eria?: > > > > > > > > > > > > a) Supported by FreeBSD. > > > > > > b) Unencumbered documentation. > > > > > > c) Checksum offloading. > > > > > > > > > > > > > > > >There are many PCIe GigE hardwares upported by em(4) or bge/bce(4= ). > > > > >AFAIK the only hardware features not supported by em(4)/bge(4) dr= iver > > > > >is TSO. And hardwares supported by em(4) also have a capability to > > > > >offload IPv6 checksumming too but it's not yet supported by the d= river. > > > > > > > > > > > > > Will TCP Segmentation Offloading help if you already use a 9000 by= te > > > > mtu, and is it going to be supported, someday, with em(4)/bge(4)?.= =2E. > > > > I'm mostly clueless about TSO. > > > > > > > > > >Since not all hardwares support JUMBO frame and the maximum MTU > > >for the JUMBO frame varies among vendors/chipsets TSO would be > > >better suited for interoperability. > > > > > >I'm really want to see TSO support in our drivers. See the > > >following URL to see TSO effect in NetBSD wm(4) driver. > > >http://marc.theaimsgroup.com/?t=3D111662994600001&r=3D1&w=3D2 > > > > >=20 > > I see... A poor mans jumbo frames, but only works with the sender, >=20 > You may have to get a NIC that supports JUMBO frames on receiver > too unless your switch/bridge system fragments the JUMBO frames > into standard MTU frames. >=20 > > correct? If NetBSD supports it can't we more or less just copy and > > paste the code to FreeBSD? I know it's never that simple but... > >=20 >=20 > Yes, we may borrow the code from NetBSD implementation but I can't > sure we can just copy it. I guess we need careful reexamination > the TSO effect on our TCP stack. >=20 Be sure to discuss this with Andre, according to page 9 of his EuroBSDCon paper he has some plans in this area: http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TC= P%20Stack.pdf - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEqPZCbHYXjKDtmC0RAmXSAKDfYPB1CCW+uoD3x6nT9q9PKjiDmwCfQp0a 4hQenk9NEktcCE9OXIihFzE= =mi78 -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 11:03:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F9D016A5AC for ; Mon, 3 Jul 2006 11:03:06 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA24443D45 for ; Mon, 3 Jul 2006 11:03:05 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k63B35I2069902 for ; Mon, 3 Jul 2006 11:03:05 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k63B349i069892 for freebsd-net@freebsd.org; Mon, 3 Jul 2006 11:03:04 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 3 Jul 2006 11:03:04 GMT Message-Id: <200607031103.k63B349i069892@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 03 Jul 2006 11:03:06 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 13:20:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A93BD16A522 for ; Mon, 3 Jul 2006 13:20:49 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDC8344105 for ; Mon, 3 Jul 2006 13:00:08 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k63Cxj3Q025855; Mon, 3 Jul 2006 05:59:48 -0700 (PDT) Date: Mon, 03 Jul 2006 21:59:37 +0900 Message-ID: From: gnn@freebsd.org To: Marcin Jessa In-Reply-To: <20060703094806.689f33ae@marcin> References: <44A552FA.2030302@cisco.com> <20060703094806.689f33ae@marcin> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: 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: Mon, 03 Jul 2006 13:20:49 -0000 At Mon, 3 Jul 2006 09:48:06 +0200, Marcin Jessa wrote: > > And please start testing this because many of us want to integrate > > this in the near future :-) > > Any hints on how to test SCTP ? > Not much really about any practical implementation of it > on http://www.sctp.org/ One trivial toy to play with is NetPIPE, but that's just a bandwidth tester. It does show socket programming with SCTP, which is relatively the same as TCP, until you get to the advanced features, which NetPIPE doesn't cover. You'll need my updated NetPIPE until the patches are committed to their project: http://www.freebsd.org/~gnn/netpipe.tar.gz I suspect Randall has a better list of things to try. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 15:42:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 131FF16A417 for ; Mon, 3 Jul 2006 15:42:00 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 049DB43D9B for ; Mon, 3 Jul 2006 15:41:41 +0000 (GMT) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.68.98) by 209.67.61.254 with SMTP; 3 Jul 2006 15:41:40 -0000 Date: Mon, 3 Jul 2006 18:41:13 +0300 From: Nikolay Pavlov To: freebsd-net@freebsd.org Message-ID: <20060703154113.GA28598@zone3000.net> Mail-Followup-To: Nikolay Pavlov , freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-RELEASE Subject: tftpd not working when net.inet.udp.blackhole=1 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, 03 Jul 2006 15:42:00 -0000 Hi folks. I have a strange problem with tftpd when using sysctl net.inet.udp.blackhole=1 It's not working with this variable enabled. I use tftp to upload images from my routers. Here is details of the problem: OS FreeBSD 6.0-RELEASE-p6 root@ipstat:~/projects/route_tools# sysctl net.inet.udp.blackhole=1 net.inet.udp.blackhole: 0 -> 1 telnet@fbi8000-Border-NY#copy running-conf tftp XX.XX.48.25 XX.XX.51.194.runcfg.new TFTP session timed out Error - can't upload running-config to TFTP server. root@ipstat:~/projects/route_tools# tail -f /var/log/xferlog Jul 3 11:25:01 ipstat tftpd[31151]: XX.XX.82.18: write request for //XX.XX.51.194.runcfg.new: success Jul 3 11:25:05 ipstat tftpd[31157]: XX.XX.82.18: write request for //XX.XX.51.194.runcfg.new: success Jul 3 11:25:10 ipstat tftpd[31161]: XX.XX.82.18: write request for //XX.XX.51.194.runcfg.new: success Jul 3 11:25:14 ipstat tftpd[31165]: XX.XX.82.18: write request for //XX.XX.51.194.runcfg.new: success But it was not uploded. root@ipstat:~/projects/route_tools# tcpdump -nvvi rl0 port 69 tcpdump: listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 11:23:46.663758 IP (tos 0x0, ttl 56, id 24435, offset 0, flags [DF], proto: UDP (17), length: 62) XX.XX.82.18.1027 > XX.XX.48.25.69: [udp sum ok] 34 WRQ "XX.XX.51.194.runcfg.new" octet 11:23:50.817992 IP (tos 0x0, ttl 56, id 24610, offset 0, flags [DF], proto: UDP (17), length: 62) XX.XX.82.18.1027 > XX.XX.48.25.69: [udp sum ok] 34 WRQ "XX.XX.51.194.runcfg.new" octet 11:23:55.042069 IP (tos 0x0, ttl 56, id 24817, offset 0, flags [DF], proto: UDP (17), length: 62) XX.XX.82.18.1027 > XX.XX.48.25.69: [udp sum ok] 34 WRQ "XX.XX.51.194.runcfg.new" octet 11:23:59.265966 IP (tos 0x0, ttl 56, id 25120, offset 0, flags [DF], proto: UDP (17), length: 62) XX.XX.82.18.1027 > XX.XX.48.25.69: [udp sum ok] 34 WRQ "XX.XX.51.194.runcfg.new" octet Now we disable blackhole: root@ipstat:~/projects/route_tools# sysctl net.inet.udp.blackhole=0 net.inet.udp.blackhole: 1 -> 0 telnet@fbi8000-Border-NY#copy running-conf tftp XX.XX.48.25 XX.XX.51.194.runcfg.new Upload running-config to TFTP server done. root@ipstat:~/projects/route_tools# tail -f /var/log/xferlog Jul 3 11:32:56 ipstat tftpd[31585]: XX.XX.82.18: write request for //XX.XX.51.194.runcfg.new: success root@ipstat:~/projects/route_tools# tcpdump -nvvi rl0 port 69 tcpdump: listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 11:32:55.609803 IP (tos 0x0, ttl 56, id 51742, offset 0, flags [DF], proto: UDP (17), length: 62) XX.XX.82.18.1027 > XX.XX.48.25.69: [udp sum ok] 34 WRQ "XX.XX.51.194.runcfg.new" octet What is the secret of such behaviour? Should i submit a PR? -- ========================================================================= = Best regards, Nikolay Pavlov. <<<------------------------------------ = ========================================================================= From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 16:56:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C15A316A407 for ; Mon, 3 Jul 2006 16:56:03 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 4318C44DD8 for ; Mon, 3 Jul 2006 16:56:03 +0000 (GMT) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.68.98) by 209.67.61.254 with SMTP; 3 Jul 2006 16:56:02 -0000 Date: Mon, 3 Jul 2006 19:55:35 +0300 From: Nikolay Pavlov To: Maxim Konovalov Message-ID: <20060703165535.GB42198@zone3000.net> Mail-Followup-To: Nikolay Pavlov , Maxim Konovalov , freebsd-net@freebsd.org References: <20060703154113.GA28598@zone3000.net> <20060703201300.U57594@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060703201300.U57594@mp2.macomnet.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-RELEASE Cc: freebsd-net@freebsd.org Subject: Re: tftpd not working when net.inet.udp.blackhole=1 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, 03 Jul 2006 16:56:03 -0000 On Monday, 3 July 2006 at 20:25:55 +0400, Maxim Konovalov wrote: > Hello, > > On Mon, 3 Jul 2006, 18:41+0300, Nikolay Pavlov wrote: > > > Hi folks. > > I have a strange problem with tftpd when using sysctl > > net.inet.udp.blackhole=1 It's not working with this variable enabled. > > > > I use tftp to upload images from my routers. Here is details of the > > problem: > > > > OS FreeBSD 6.0-RELEASE-p6 > > > > root@ipstat:~/projects/route_tools# sysctl net.inet.udp.blackhole=1 > > net.inet.udp.blackhole: 0 -> 1 > > > > telnet@fbi8000-Border-NY#copy running-conf tftp XX.XX.48.25 > > XX.XX.51.194.runcfg.new > > TFTP session timed out > > Error - can't upload running-config to TFTP server. > [...] > > Nice question indeed. I spent 20 minutes trying to get wtf is going > on. There are several moments: > > a) I guess you are running stock tftpd from inetd i.e. tftpd -s > /tftproot. In that case tftpd chroots to /tftproot. > > b) tftpd wants to resolve a peer ip address but there is no > /etc/resolv.conf in its new root directory so it asks 127.0.0.1 for > resolve. > > c) net.inet.udp.blackhole=1 forces the kernel just drop tftpd DNS > requests. > > d) From this point several timing issues starts: tftpd still trying to > resolve a client ip address, then gives up but now client gives up. > > I see several solutions: > > a) Don't use chroot. In general this is not good from security point > of view. > > b) Run a named @127.0.0.1. > > c) Put a valid resolv.conf to /tftpboot/etc/. > > d) Don't use net.inet.udp.blackhole=1. > > HTH. > > -- > Maxim Konovalov Hi Maxim. Thanks for quick answer. Named running on local interface fixed this issue. -- ========================================================================= = Best regards, Nikolay Pavlov. <<<------------------------------------ = ========================================================================= From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 17:48:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B40D16A412 for ; Mon, 3 Jul 2006 17:48:09 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7755E4429D for ; Mon, 3 Jul 2006 16:25:56 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.3) with ESMTP id k63GPtLA061019; Mon, 3 Jul 2006 20:25:55 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Mon, 3 Jul 2006 20:25:55 +0400 (MSD) From: Maxim Konovalov To: Nikolay Pavlov In-Reply-To: <20060703154113.GA28598@zone3000.net> Message-ID: <20060703201300.U57594@mp2.macomnet.net> References: <20060703154113.GA28598@zone3000.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: tftpd not working when net.inet.udp.blackhole=1 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, 03 Jul 2006 17:48:09 -0000 Hello, On Mon, 3 Jul 2006, 18:41+0300, Nikolay Pavlov wrote: > Hi folks. > I have a strange problem with tftpd when using sysctl > net.inet.udp.blackhole=1 It's not working with this variable enabled. > > I use tftp to upload images from my routers. Here is details of the > problem: > > OS FreeBSD 6.0-RELEASE-p6 > > root@ipstat:~/projects/route_tools# sysctl net.inet.udp.blackhole=1 > net.inet.udp.blackhole: 0 -> 1 > > telnet@fbi8000-Border-NY#copy running-conf tftp XX.XX.48.25 > XX.XX.51.194.runcfg.new > TFTP session timed out > Error - can't upload running-config to TFTP server. [...] Nice question indeed. I spent 20 minutes trying to get wtf is going on. There are several moments: a) I guess you are running stock tftpd from inetd i.e. tftpd -s /tftproot. In that case tftpd chroots to /tftproot. b) tftpd wants to resolve a peer ip address but there is no /etc/resolv.conf in its new root directory so it asks 127.0.0.1 for resolve. c) net.inet.udp.blackhole=1 forces the kernel just drop tftpd DNS requests. d) From this point several timing issues starts: tftpd still trying to resolve a client ip address, then gives up but now client gives up. I see several solutions: a) Don't use chroot. In general this is not good from security point of view. b) Run a named @127.0.0.1. c) Put a valid resolv.conf to /tftpboot/etc/. d) Don't use net.inet.udp.blackhole=1. HTH. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 20:34:00 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEDBD16A47B; Mon, 3 Jul 2006 20:34:00 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 640A043D53; Mon, 3 Jul 2006 20:34:00 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k63KS40g014269; Mon, 3 Jul 2006 13:28:04 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k63KS39s014268; Mon, 3 Jul 2006 13:28:03 -0700 Date: Mon, 3 Jul 2006 13:28:03 -0700 From: Brooks Davis To: Robert Watson Message-ID: <20060703202803.GA22556@odin.ac.hmc.edu> References: <200606290752.k5T7qU06021639@repoman.freebsd.org> <20060629132354.D73145@mp2.macomnet.net> <20060629131201.GA67682@comp.chem.msu.su> <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20060630115749.G3964@fledge.watson.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: Yar Tikhiy , src-committers@FreeBSD.org, Julian Elischer , FreeBSD Net Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 03 Jul 2006 20:34:01 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2006 at 12:01:23PM +0100, Robert Watson wrote: >=20 > On Thu, 29 Jun 2006, Julian Elischer wrote: >=20 > >>I stress tested gif(4) in the same manner for kicks and got a very=20 > >>similar panic in in_control(). I suppose that my change eliminated a= =20 > >>concurrency problem in vlan(4) and we began to feel the lack of=20 > >>refcounting at ifnet level. Indeed, a thread can keep a pointer to an= =20 > >>ifnet beyond its lifetime and panic the system on access to the dead=20 > >>ifnet. > > > >Unfortunatly, since mbufs point to ifnets it is almost impossible to=20 > >"efficiently" refcount ifnets. Mbufs may persist almost indefinitly in = a=20 > >socket receive buffer, well after the given receive interface has gone= =20 > >away. I submitted patches to full real referenc counting of ifnets in 19= 95=20 > >but it was already too cumbersom then, and since then it has gotten wors= e.=20 > >(due to SMP etc.) >=20 > Partial solutions are possible here -- even if we don't immediately fix t= he=20 > mbuf pointer issue, we can fix other types of ifnet references to be real= ,=20 > such as references from heavier weight administrative structures and=20 > operations, even if mbufs don't get them. It's been suggested that=20 > interfaces become dead and be GC'd after a timeout in order to reduce the= =20 > chances of mbuf related races. I think this is a pretty reasonable=20 > work-around to the general problem here, especially if "dead" is really= =20 > implemented properly. An example of a "bad" implementation of dead would= =20 > have the ifnet continue to be visible and occupy space in the interface= =20 > name space, preventing tun0 from being immediately reallocated after it i= s=20 > destroyed. A better implementation would have all external signs of the= =20 > ifnet disappear, except that the pointer remains minimally valid for a fe= w=20 > seconds. Not ideal, but better than reference counting ifnets from mbufs= . =20 > For gif interfaces, etc, real references are possible and desirable. The goal of the work to remove the ifnet from the softc was that we would end up in a situation where if_free (or if_detach if we remove if_free) would cause the interface to have all it's state set to safe but dead values and remove it from the ifnet list. At that point access by pointer or index would still work, but ifconfig wouldn't see it since it would not be on the ifnet list and syscalls, sysctl, or ioctls that access interfaces by would be modified to detect the dead state and act as though the interface is not there. We could then consider either holding the interface for a configurable or computed length of time or adding some sort of refcounting (probably impractical). In practice ifnet and indexes are pretty cheap so holding on to an interface for up to a couple minutes should be OK in most cases. For some applications (really massive tunnel brokers) it might be beneficial to change if_index from a u_short to an int to increase the available set. I'd been meaning to work on this, but real life has interfered. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqX3SXY6L6fI4GtQRAqy9AKDDQmK7nb+MZayhJ6qSDISpzhPm0gCfYQyq cpTTgo83IAemoaEu2z5mS88= =+pdk -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 3 23:48:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED1C016A52D for ; Mon, 3 Jul 2006 23:48:22 +0000 (UTC) (envelope-from apache@km20932-01.keymachine.de) Received: from km20932-01.keymachine.de (ns.km20932-01.keymachine.de [84.19.184.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5599443D45 for ; Mon, 3 Jul 2006 23:48:21 +0000 (GMT) (envelope-from apache@km20932-01.keymachine.de) Received: from km20932-01.keymachine.de (localhost [127.0.0.1]) by km20932-01.keymachine.de (8.12.11/8.12.11) with ESMTP id k640n7I8005307 for ; Tue, 4 Jul 2006 02:49:07 +0200 Received: (from apache@localhost) by km20932-01.keymachine.de (8.12.11/8.12.11/Submit) id k640n7x0005306; Tue, 4 Jul 2006 02:49:07 +0200 Date: Tue, 4 Jul 2006 02:49:07 +0200 Message-Id: <200607040049.k640n7x0005306@km20932-01.keymachine.de> From: Chase Bank To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Chase Online. Banking Account registration information 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, 03 Jul 2006 23:48:23 -0000 [chaseNew.gif] Chase Bank Online. Department Notice You have received this email because you or someone had used your account from different locations. For security purpose, we are required to open an investigation into this matter. In order to safeguard your account, we require that you confirm your banking details. To help speed up this process, please access the following link so we can complete the verification of your Chase Online. Banking Account registration information : To get started, please click the link below: [1]https://www.chase.com Please Note: If we do no receive the appropriate account verification within 48 hours, then we will assume this Chase Bank account is fraudulent and will be suspended. The purpose of this verification is to ensure that your bank account has not been fraudulently used and to combat the fraud from our community. Regards, Chase Bank - Chase Online. Banking Department _________________________________________________________________ Securities (including mutual funds and variable life insurance), annuities and insurance products are not bank deposits and are not insured by the FDIC or any other agency of the United States, nor are they obligations of, nor insured or guaranteed by, JPMorgan Chase Bank, N.A., CISC, CIA, CMIA or their affiliates. Securities (including mutual funds and variable life insurance) and annuities involve investment risks, including the possible loss of value. References 1. http://cms.ucall.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 15:43:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA7B416A4E5 for ; Tue, 4 Jul 2006 15:43:12 +0000 (UTC) (envelope-from ale@seudns.net) Received: from connectmed.com.br (s200-189-171-55.ipb.diveo.net.br [200.189.171.55]) by mx1.FreeBSD.org (Postfix) with SMTP id 2294943D45 for ; Tue, 4 Jul 2006 15:43:11 +0000 (GMT) (envelope-from ale@seudns.net) Received: (qmail 7601 invoked from network); 4 Jul 2006 15:41:00 -0000 Received: from unknown (HELO ?192.168.3.109?) (192.168.3.109) by donald.connectmed.com.br with SMTP; 4 Jul 2006 15:41:00 -0000 Message-ID: <44AA8C8D.5050700@seudns.net> Date: Tue, 04 Jul 2006 12:43:09 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5 (X11/20060213) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 4.11 + VLAN + IPX 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, 04 Jul 2006 15:43:13 -0000 Hi List, I've a gateway running FreeBSD 4.11-STABLE doing ip filtering, routing and ipx routing among 4 internal networks and 4 external networks. Everything was working perfectly, with the following network adapters: one 3Com 3c905C-TX Fast Etherlink XL, two Intel 82559 Pro/100 Ethernet and one quad D-Link DFE-550TX 10/100BaseTX. I had one network attached to each network interface, the ef module loaded to support multiple novell ethernet frames types, ipxgateway enable and ipxrouted -s running. Due to need of more ip addresses on a new departament of the company, I need to configure a new network on this gateway, then I decided to put an existent network and the new one at a single network interface putting each network on a single vlan. After change the configuration the stations on the vlan networks can't reach the Novell server. The old configuration: fxp0: external network fxp1: external network xl0: external network ste0: internal network 1 ste0f0: internal ipx network Ethernet_II ste0f1: internal ipx network Ethernet_802.3 ste0f2: internal ipx network Ethernet_802.2 ste0f3: internal ipx network Ethernet_802.2/SNAP ste1: internal network 2 ste1f0: internal ipx network Ethernet_II ste1f1: internal ipx network Ethernet_802.3 ste1f2: internal ipx network Ethernet_802.2 ste1f3: internal ipx network Ethernet_802.2/SNAP ste2: internal netowrk 3 ste2f0: internal ipx network Ethernet_II ste2f1: internal ipx network Ethernet_802.3 ste2f2: internal ipx network Ethernet_802.2 ste2f3: internal ipx network Ethernet_802.2/SNAP ste3: internal network 4 ste3f0: internal ipx network Ethernet_II ste3f1: internal ipx network Ethernet_802.3 ste3f2: internal ipx network Ethernet_802.2 ste3f3: internal ipx network Ethernet_802.2/SNAP In the new configuration I added two vlans attached to ste3 then: vlan4: internal network 4 parent ste3 vlan6: internal network 5 parent ste3 The ste3f* interfaces continue configured as before. My doubt is when I created the vlans the system should be created vlan4f* or the ipx should work in the same ste3f* interfaces... The only thing that is not working is ipx access from network 4 to novell server at network 1. Any Ideas ?? Best Regards, Alexandre From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 16:27:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBB9A16A4DD; Tue, 4 Jul 2006 16:27:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22A6A43D68; Tue, 4 Jul 2006 16:27:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k64GPaxe072159; Tue, 4 Jul 2006 10:25:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 04 Jul 2006 10:25:39 -0600 (MDT) Message-Id: <20060704.102539.-494099438.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20060703202803.GA22556@odin.ac.hmc.edu> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: yar@comp.chem.msu.su, src-committers@freebsd.org, rwatson@freebsd.org, julian@elischer.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 04 Jul 2006 16:27:23 -0000 In message: <20060703202803.GA22556@odin.ac.hmc.edu> Brooks Davis writes: : and act as though the interface is not there. We could then consider : either holding the interface for a configurable or computed length : of time or adding some sort of refcounting (probably impractical). Refcounting would be good for the 'macro' things (coming and going) that are infrequent, but we might have mulitple people doing. You are right it likely is too inefficient to do with mbugs. One other option might be to have a configurable time after the last time that it was accessed via the 'safe' routines that were setup. This way we'd tie the removal of the interface to a period of time after it was last used, rather than after it was removed. I don't know if such a difference would matter much in practice. The only other 'issue' that I see with this approach is if I remove a card, and then insert it again before the timeout happens. Does that card get a new interface name? And would people care or not... Warner From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 16:36:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE8C916A4E0; Tue, 4 Jul 2006 16:36:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64C7243D4C; Tue, 4 Jul 2006 16:36:44 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 02D8A46BFC; Tue, 4 Jul 2006 12:36:44 -0400 (EDT) Date: Tue, 4 Jul 2006 17:36:43 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20060704.102539.-494099438.imp@bsdimp.com> Message-ID: <20060704173115.V44010@fledge.watson.org> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: yar@comp.chem.msu.su, src-committers@freebsd.org, julian@elischer.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 04 Jul 2006 16:36:45 -0000 On Tue, 4 Jul 2006, M. Warner Losh wrote: > In message: <20060703202803.GA22556@odin.ac.hmc.edu> > Brooks Davis writes: > : and act as though the interface is not there. We could then consider > : either holding the interface for a configurable or computed length > : of time or adding some sort of refcounting (probably impractical). > > Refcounting would be good for the 'macro' things (coming and going) that are > infrequent, but we might have mulitple people doing. You are right it > likely is too inefficient to do with mbugs. One other option might be to > have a configurable time after the last time that it was accessed via the > 'safe' routines that were setup. This way we'd tie the removal of the > interface to a period of time after it was last used, rather than after it > was removed. I don't know if such a difference would matter much in > practice. > > The only other 'issue' that I see with this approach is if I remove a card, > and then insert it again before the timeout happens. Does that card get a > new interface name? And would people care or not... I think that the name should cease to be "reserved" as soon as the device driver has destroyed the ifnet, because it is up to the device driver to select the index, not the ifnet framework. This means keeping the structure semi-valid but in a state that limits further bad behavior (i.e., repointing its function points at stubs, etc), but removing references to it in global data structures, etc. We're not just quiescing, we're actually taking it 99% of the way to turn down. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 17:47:48 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2435C16A4DA; Tue, 4 Jul 2006 17:47:48 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B77F543D53; Tue, 4 Jul 2006 17:47:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k64Hg8gd007934; Tue, 4 Jul 2006 10:42:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k64Hg8P4007933; Tue, 4 Jul 2006 10:42:08 -0700 Date: Tue, 4 Jul 2006 10:42:08 -0700 From: Brooks Davis To: "M. Warner Losh" Message-ID: <20060704174208.GA1734@odin.ac.hmc.edu> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <20060704.102539.-494099438.imp@bsdimp.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: src-committers@FreeBSD.org, yar@comp.chem.msu.su, rwatson@FreeBSD.org, julian@elischer.org, freebsd-net@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 04 Jul 2006 17:47:48 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: > In message: <20060703202803.GA22556@odin.ac.hmc.edu> > Brooks Davis writes: > : and act as though the interface is not there. We could then consider > : either holding the interface for a configurable or computed length > : of time or adding some sort of refcounting (probably impractical). >=20 > Refcounting would be good for the 'macro' things (coming and going) > that are infrequent, but we might have mulitple people doing. You are > right it likely is too inefficient to do with mbugs. One other option > might be to have a configurable time after the last time that it was > accessed via the 'safe' routines that were setup. This way we'd tie > the removal of the interface to a period of time after it was last > used, rather than after it was removed. I don't know if such a > difference would matter much in practice. We might get some mielage out of last used, but then we'd have to keep that timestamp updated. For normal applications, once we've torn down the sockets and drained their queues, I believe we should not have to wait more than a few seconds unless dummynet or some other mechanism that queues mbufs for a significant period of time is enabled. If dummynet is enabled we need to wait a bit longer, but it isn't outside the relm of possibility for dummynet to be modified to tell us how long it will be until the last mbuf it currenly holds will be released. In practice, 121 seconds is probably a good default number since a 60 second max RTT is assumed in TCP and thus delays longer than that would break everything anyway. > The only other 'issue' that I see with this approach is if I remove a > card, and then insert it again before the timeout happens. Does that > card get a new interface name? And would people care or not... The name is unregistered with the call to if_detach because if_detach removes the interface from the ifnet list. My guess is that we'll either zero the name field or set to something like _zombie. The unit will remain reserved until later. We'll need to add an SNMP index mananaged in userland to satisfy come current if_index consumers. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqqhvXY6L6fI4GtQRAgIJAKCLB1mGVIkKv5nYRED+Dsi33GN9aACeNX9n T4KL4DTb2qW9GJkei79pykM= =4sP+ -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 17:56:17 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BA9C16A4E1; Tue, 4 Jul 2006 17:56:17 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DE5343D45; Tue, 4 Jul 2006 17:56:16 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 19:56:14 +0200 Date: Tue, 4 Jul 2006 19:56:14 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Brooks Davis In-Reply-To: <20060704174208.GA1734@odin.ac.hmc.edu> Message-ID: <20060704195220.K74584@beagle.kn.op.dlr.de> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <20060704174208.GA1734@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 04 Jul 2006 17:56:15.0105 (UTC) FILETIME=[24AE4F10:01C69F93] Cc: src-committers@FreeBSD.org, yar@comp.chem.msu.su, rwatson@FreeBSD.org, julian@elischer.org, freebsd-net@FreeBSD.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2006 17:56:17 -0000 On Tue, 4 Jul 2006, Brooks Davis wrote: BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> BD>> Brooks Davis writes: BD>> : and act as though the interface is not there. We could then consider BD>> : either holding the interface for a configurable or computed length BD>> : of time or adding some sort of refcounting (probably impractical). BD>> BD>> Refcounting would be good for the 'macro' things (coming and going) BD>> that are infrequent, but we might have mulitple people doing. You are BD>> right it likely is too inefficient to do with mbugs. One other option BD>> might be to have a configurable time after the last time that it was BD>> accessed via the 'safe' routines that were setup. This way we'd tie BD>> the removal of the interface to a period of time after it was last BD>> used, rather than after it was removed. I don't know if such a BD>> difference would matter much in practice. BD> BD>We might get some mielage out of last used, but then we'd have to keep BD>that timestamp updated. For normal applications, once we've torn down BD>the sockets and drained their queues, I believe we should not have to BD>wait more than a few seconds unless dummynet or some other mechanism BD>that queues mbufs for a significant period of time is enabled. If BD>dummynet is enabled we need to wait a bit longer, but it isn't outside BD>the relm of possibility for dummynet to be modified to tell us how long BD>it will be until the last mbuf it currenly holds will be released. In BD>practice, 121 seconds is probably a good default number since a 60 BD>second max RTT is assumed in TCP and thus delays longer than that BD>would break everything anyway. BD> BD>> The only other 'issue' that I see with this approach is if I remove a BD>> card, and then insert it again before the timeout happens. Does that BD>> card get a new interface name? And would people care or not... BD> BD>The name is unregistered with the call to if_detach because if_detach BD>removes the interface from the ifnet list. My guess is that BD>we'll either zero the name field or set to something like _zombie. The BD>unit will remain reserved until later. We'll need to add an SNMP index BD>mananaged in userland to satisfy come current if_index consumers. bsnmp does this anyway because of the rules for ifIndex. It has some heuristic to guess whether an interface is a physical one or not and if it is, it uses the same index again. The downside of this is that the interface index you see via SNMP has nothing to do with the interface index you see in the system and this does not work accross reboots and daemon restarts as required by the RFC. harti From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 18:47:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C223016A4DE; Tue, 4 Jul 2006 18:47:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9F7143D7E; Tue, 4 Jul 2006 18:47:52 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.37]) by a50.ironport.com with ESMTP; 04 Jul 2006 11:47:51 -0700 Message-ID: <44AAB7D5.5010609@elischer.org> Date: Tue, 04 Jul 2006 11:47:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> In-Reply-To: <20060704.102539.-494099438.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: yar@comp.chem.msu.su, src-committers@freebsd.org, rwatson@freebsd.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 04 Jul 2006 18:47:59 -0000 M. Warner Losh wrote: >In message: <20060703202803.GA22556@odin.ac.hmc.edu> > Brooks Davis writes: >: and act as though the interface is not there. We could then consider >: either holding the interface for a configurable or computed length >: of time or adding some sort of refcounting (probably impractical). > >Refcounting would be good for the 'macro' things (coming and going) >that are infrequent, but we might have mulitple people doing. You are >right it likely is too inefficient to do with mbugs. One other option >might be to have a configurable time after the last time that it was >accessed via the 'safe' routines that were setup. This way we'd tie >the removal of the interface to a period of time after it was last >used, rather than after it was removed. I don't know if such a >difference would matter much in practice. > >The only other 'issue' that I see with this approach is if I remove a >card, and then insert it again before the timeout happens. Does that >card get a new interface name? And would people care or not... > > As I mentionned earlier, the mbuf references are not always used. They are mainly used for ipfw and friends but are not always used (from memory) on every packet in the receive path. In this case it may be as well to have an indirect reference tha can be checked for validity each time.. e.g. ifnum. it wouldn't be too much to keep the ifnum slots around for a period after the interfaces are destroyed. (and marked invalid), or in tha case of a hash, failure to find it would suggest that is is invalid. >Warner > > From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 18:55:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F76E16A4E7; Tue, 4 Jul 2006 18:55:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04C0A43D76; Tue, 4 Jul 2006 18:55:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.37]) by a50.ironport.com with ESMTP; 04 Jul 2006 11:55:03 -0700 Message-ID: <44AAB986.2070505@elischer.org> Date: Tue, 04 Jul 2006 11:55:02 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harti Brandt References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <20060704174208.GA1734@odin.ac.hmc.edu> <20060704195220.K74584@beagle.kn.op.dlr.de> In-Reply-To: <20060704195220.K74584@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, freebsd-net@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 04 Jul 2006 18:55:16 -0000 Harti Brandt wrote: >On Tue, 4 Jul 2006, Brooks Davis wrote: > >BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: >BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> >BD>> Brooks Davis writes: >BD>> : and act as though the interface is not there. We could then consider >BD>> : either holding the interface for a configurable or computed length >BD>> : of time or adding some sort of refcounting (probably impractical). >BD>> >BD>> Refcounting would be good for the 'macro' things (coming and going) >BD>> that are infrequent, but we might have mulitple people doing. You are >BD>> right it likely is too inefficient to do with mbugs. One other option >BD>> might be to have a configurable time after the last time that it was >BD>> accessed via the 'safe' routines that were setup. This way we'd tie >BD>> the removal of the interface to a period of time after it was last >BD>> used, rather than after it was removed. I don't know if such a >BD>> difference would matter much in practice. >BD> >BD>We might get some mielage out of last used, but then we'd have to keep >BD>that timestamp updated. For normal applications, once we've torn down >BD>the sockets and drained their queues, I believe we should not have to >BD>wait more than a few seconds unless dummynet or some other mechanism >BD>that queues mbufs for a significant period of time is enabled. If >BD>dummynet is enabled we need to wait a bit longer, but it isn't outside >BD>the relm of possibility for dummynet to be modified to tell us how long >BD>it will be until the last mbuf it currenly holds will be released. In >BD>practice, 121 seconds is probably a good default number since a 60 >BD>second max RTT is assumed in TCP and thus delays longer than that >BD>would break everything anyway. >BD> >BD>> The only other 'issue' that I see with this approach is if I remove a >BD>> card, and then insert it again before the timeout happens. Does that >BD>> card get a new interface name? And would people care or not... >BD> >BD>The name is unregistered with the call to if_detach because if_detach >BD>removes the interface from the ifnet list. My guess is that >BD>we'll either zero the name field or set to something like _zombie. The >BD>unit will remain reserved until later. We'll need to add an SNMP index >BD>mananaged in userland to satisfy come current if_index consumers. > >bsnmp does this anyway because of the rules for ifIndex. It has some >heuristic to guess whether an interface is a physical one or not and if it >is, it uses the same index again. The downside of this is that the >interface index you see via SNMP has nothing to do with the interface >index you see in the system and this does not work accross reboots and >daemon restarts as required by the RFC. > > > If we had a way to to this in the system (e.g. kept the mac address with the ifnum in a hash) then we could just keep the ifnum in the mbuf instead of the ifp pointer, as that is only occasionally used, and a ifnum2ipf() macro could check the validity wheheve it is used. >harti > > From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 19:02:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C78DD16A4E1; Tue, 4 Jul 2006 19:02:39 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id B75A443D70; Tue, 4 Jul 2006 19:02:33 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 21:02:32 +0200 Date: Tue, 4 Jul 2006 21:02:32 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Julian Elischer In-Reply-To: <44AAB986.2070505@elischer.org> Message-ID: <20060704205916.X74584@beagle.kn.op.dlr.de> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <20060704174208.GA1734@odin.ac.hmc.edu> <20060704195220.K74584@beagle.kn.op.dlr.de> <44AAB986.2070505@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 04 Jul 2006 19:02:32.0400 (UTC) FILETIME=[67555D00:01C69F9C] Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, freebsd-net@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2006 19:02:40 -0000 On Tue, 4 Jul 2006, Julian Elischer wrote: JE>Harti Brandt wrote: JE> JE>> On Tue, 4 Jul 2006, Brooks Davis wrote: JE>> JE>> BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: JE>> BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> JE>> BD>> Brooks Davis writes: JE>> BD>> : and act as though the interface is not there. We could then JE>> consider JE>> BD>> : either holding the interface for a configurable or computed length JE>> BD>> : of time or adding some sort of refcounting (probably impractical). JE>> BD>> BD>> Refcounting would be good for the 'macro' things (coming and JE>> going) JE>> BD>> that are infrequent, but we might have mulitple people doing. You are JE>> BD>> right it likely is too inefficient to do with mbugs. One other option JE>> BD>> might be to have a configurable time after the last time that it was JE>> BD>> accessed via the 'safe' routines that were setup. This way we'd tie JE>> BD>> the removal of the interface to a period of time after it was last JE>> BD>> used, rather than after it was removed. I don't know if such a JE>> BD>> difference would matter much in practice. JE>> BD> JE>> BD>We might get some mielage out of last used, but then we'd have to keep JE>> BD>that timestamp updated. For normal applications, once we've torn down JE>> BD>the sockets and drained their queues, I believe we should not have to JE>> BD>wait more than a few seconds unless dummynet or some other mechanism JE>> BD>that queues mbufs for a significant period of time is enabled. If JE>> BD>dummynet is enabled we need to wait a bit longer, but it isn't outside JE>> BD>the relm of possibility for dummynet to be modified to tell us how long JE>> BD>it will be until the last mbuf it currenly holds will be released. In JE>> BD>practice, 121 seconds is probably a good default number since a 60 JE>> BD>second max RTT is assumed in TCP and thus delays longer than that JE>> BD>would break everything anyway. JE>> BD> JE>> BD>> The only other 'issue' that I see with this approach is if I remove a JE>> BD>> card, and then insert it again before the timeout happens. Does that JE>> BD>> card get a new interface name? And would people care or not... JE>> BD> JE>> BD>The name is unregistered with the call to if_detach because if_detach JE>> BD>removes the interface from the ifnet list. My guess is that JE>> BD>we'll either zero the name field or set to something like _zombie. The JE>> BD>unit will remain reserved until later. We'll need to add an SNMP index JE>> BD>mananaged in userland to satisfy come current if_index consumers. JE>> JE>> bsnmp does this anyway because of the rules for ifIndex. It has some JE>> heuristic to guess whether an interface is a physical one or not and if it JE>> is, it uses the same index again. The downside of this is that the JE>> interface index you see via SNMP has nothing to do with the interface index JE>> you see in the system and this does not work accross reboots and daemon JE>> restarts as required by the RFC. JE>> JE>> JE> JE>If we had a way to to this in the system (e.g. kept the mac address JE>with the ifnum in a hash) then we could just keep the ifnum in the mbuf JE>instead of the ifp pointer, as that is only occasionally used, and a JE>ifnum2ipf() macro could check the validity wheheve it is used. This would be helpful for the SNMP daemon, because this would also allow to reuse the ifnum if the same interface is plugged in back. However care must be taken that non-physical interfaces get a new ifnum always (iftun for example). harti From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 19:51:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 999FE16A4DD; Tue, 4 Jul 2006 19:51:43 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3499543D46; Tue, 4 Jul 2006 19:51:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k64JkIJl013761; Tue, 4 Jul 2006 12:46:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k64JkIQE013760; Tue, 4 Jul 2006 12:46:18 -0700 Date: Tue, 4 Jul 2006 12:46:18 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20060704194618.GA12928@odin.ac.hmc.edu> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <44AAB7D5.5010609@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <44AAB7D5.5010609@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, freebsd-net@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 04 Jul 2006 19:51:43 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 04, 2006 at 11:47:49AM -0700, Julian Elischer wrote: > M. Warner Losh wrote: >=20 > >In message: <20060703202803.GA22556@odin.ac.hmc.edu> > > Brooks Davis writes: > >: and act as though the interface is not there. We could then consider > >: either holding the interface for a configurable or computed length > >: of time or adding some sort of refcounting (probably impractical). > > > >Refcounting would be good for the 'macro' things (coming and going) > >that are infrequent, but we might have mulitple people doing. You are > >right it likely is too inefficient to do with mbugs. One other option > >might be to have a configurable time after the last time that it was > >accessed via the 'safe' routines that were setup. This way we'd tie > >the removal of the interface to a period of time after it was last > >used, rather than after it was removed. I don't know if such a > >difference would matter much in practice. > > > >The only other 'issue' that I see with this approach is if I remove a > >card, and then insert it again before the timeout happens. Does that > >card get a new interface name? And would people care or not... >=20 > As I mentionned earlier, the mbuf references are not always used. They > are mainly used for ipfw and friends but are not always used (from > memory) on every packet in the receive path. > > In this case it may be as well to have an indirect reference tha can > be checked for validity each time.. e.g. ifnum. it wouldn't be too > much to keep the ifnum slots around for a period after the interfaces > are destroyed. (and marked invalid), or in tha case of a hash, failure > to find it would suggest that is is invalid. As long as the index was once valid, you can check it's existance with (ifnet_byindex() !=3D NULL), but you can't know if if what's there is actually the interface you were looking for unless you also cache and check if_data.if_epoch. Changes to doing more references to interfaces by index are a good idea where they don't have a performance impact, but we need to be careful with overhead since we add a level of indirection with particular care to test the case where we have large numbers of interfaces and thus the array used by ifnet_byindex is large and will have cache effects. It's worth remembering that an ifnet isn't very expensive (and we could make them cheaper still with their own zone) so if keeping them valid a bit instead of checking for validity has a measurable performace impact in the common case we should do it. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqsWJXY6L6fI4GtQRAq81AKCJ+jR6dDrwYN/8WxsueUuTtD2QXgCgrHdc TWHumZ2I4MHxg3ZzY0Q3bZE= =FCpq -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 20:04:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E5C16A4DA; Tue, 4 Jul 2006 20:04:24 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB13F43D55; Tue, 4 Jul 2006 20:04:23 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k64JwwY2014536; Tue, 4 Jul 2006 12:58:58 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k64JwwgK014535; Tue, 4 Jul 2006 12:58:58 -0700 Date: Tue, 4 Jul 2006 12:58:58 -0700 From: Brooks Davis To: Harti Brandt Message-ID: <20060704195858.GB12928@odin.ac.hmc.edu> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <20060704174208.GA1734@odin.ac.hmc.edu> <20060704195220.K74584@beagle.kn.op.dlr.de> <44AAB986.2070505@elischer.org> <20060704205916.X74584@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <20060704205916.X74584@beagle.kn.op.dlr.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, Julian Elischer , freebsd-net@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c 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, 04 Jul 2006 20:04:24 -0000 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 04, 2006 at 09:02:32PM +0200, Harti Brandt wrote: > On Tue, 4 Jul 2006, Julian Elischer wrote: >=20 > JE>Harti Brandt wrote: > JE> > JE>> On Tue, 4 Jul 2006, Brooks Davis wrote: > JE>>=20 > JE>> BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: > JE>> BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> > JE>> BD>> Brooks Davis writes: > JE>> BD>> : and act as though the interface is not there. We could then > JE>> consider > JE>> BD>> : either holding the interface for a configurable or computed l= ength > JE>> BD>> : of time or adding some sort of refcounting (probably impracti= cal). > JE>> BD>> BD>> Refcounting would be good for the 'macro' things (coming a= nd > JE>> going) > JE>> BD>> that are infrequent, but we might have mulitple people doing. = You are > JE>> BD>> right it likely is too inefficient to do with mbugs. One other= option > JE>> BD>> might be to have a configurable time after the last time that i= t was > JE>> BD>> accessed via the 'safe' routines that were setup. This way we'= d tie > JE>> BD>> the removal of the interface to a period of time after it was l= ast > JE>> BD>> used, rather than after it was removed. I don't know if such a > JE>> BD>> difference would matter much in practice. > JE>> BD> > JE>> BD>We might get some mielage out of last used, but then we'd have to= keep > JE>> BD>that timestamp updated. For normal applications, once we've torn= down > JE>> BD>the sockets and drained their queues, I believe we should not hav= e to > JE>> BD>wait more than a few seconds unless dummynet or some other mechan= ism > JE>> BD>that queues mbufs for a significant period of time is enabled. If > JE>> BD>dummynet is enabled we need to wait a bit longer, but it isn't ou= tside > JE>> BD>the relm of possibility for dummynet to be modified to tell us ho= w long > JE>> BD>it will be until the last mbuf it currenly holds will be released= . In > JE>> BD>practice, 121 seconds is probably a good default number since a 60 > JE>> BD>second max RTT is assumed in TCP and thus delays longer than that > JE>> BD>would break everything anyway. > JE>> BD> > JE>> BD>> The only other 'issue' that I see with this approach is if I re= move a > JE>> BD>> card, and then insert it again before the timeout happens. Doe= s that > JE>> BD>> card get a new interface name? And would people care or not... > JE>> BD> > JE>> BD>The name is unregistered with the call to if_detach because if_de= tach > JE>> BD>removes the interface from the ifnet list. My guess is that > JE>> BD>we'll either zero the name field or set to something like _zombie= . The > JE>> BD>unit will remain reserved until later. We'll need to add an SNMP= index > JE>> BD>mananaged in userland to satisfy come current if_index consumers. > JE>>=20 > JE>> bsnmp does this anyway because of the rules for ifIndex. It has some > JE>> heuristic to guess whether an interface is a physical one or not and= if it > JE>> is, it uses the same index again. The downside of this is that the > JE>> interface index you see via SNMP has nothing to do with the interfac= e index > JE>> you see in the system and this does not work accross reboots and dae= mon > JE>> restarts as required by the RFC. > JE> > JE>If we had a way to to this in the system (e.g. kept the mac address=20 > JE>with the ifnum in a hash) then we could just keep the ifnum in the mbu= f=20 > JE>instead of the ifp pointer, as that is only occasionally used, and a= =20 > JE>ifnum2ipf() macro could check the validity wheheve it is used. >=20 > This would be helpful for the SNMP daemon, because this would also allow= =20 > to reuse the ifnum if the same interface is plugged in back. However care= =20 > must be taken that non-physical interfaces get a new ifnum always (iftun= =20 > for example). This belongs in userland. It's too complex to handle in the kernel. We probably need to store the index in the kernel as a rondivues point, but the actual decision on deciding which interfaces are the "same" and which are "different" as defined by the SNMP spec is too difficult and has too many edge cases to try to do in the kernel. I think the right answer is a daemon (or devd triggered script) that sets the SNMP index based on a database containing previous lladdrs and units. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqsiBXY6L6fI4GtQRAk6qAJ9pN6W16KR9Pn9vZfCos4uMweOeRACeNkhz iuOO3BASLA9qW+rBxnNQKu0= =eu1T -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 5 06:47:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43C6E16A4DF; Wed, 5 Jul 2006 06:47:50 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DEC043D49; Wed, 5 Jul 2006 06:47:49 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 08:47:47 +0200 Date: Wed, 5 Jul 2006 08:47:47 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Brooks Davis In-Reply-To: <20060704195858.GB12928@odin.ac.hmc.edu> Message-ID: <20060705084551.V78288@beagle.kn.op.dlr.de> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> <20060704.102539.-494099438.imp@bsdimp.com> <20060704174208.GA1734@odin.ac.hmc.edu> <20060704195220.K74584@beagle.kn.op.dlr.de> <44AAB986.2070505@elischer.org> <20060704205916.X74584@beagle.kn.op.dlr.de> <20060704195858.GB12928@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 05 Jul 2006 06:47:47.0873 (UTC) FILETIME=[ED522110:01C69FFE] Cc: src-committers@freebsd.org, yar@comp.chem.msu.su, rwatson@freebsd.org, Julian Elischer , freebsd-net@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/sys/net if_vlan.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 06:47:50 -0000 On Tue, 4 Jul 2006, Brooks Davis wrote: BD>On Tue, Jul 04, 2006 at 09:02:32PM +0200, Harti Brandt wrote: BD>> On Tue, 4 Jul 2006, Julian Elischer wrote: BD>> BD>> JE>Harti Brandt wrote: BD>> JE> BD>> JE>> On Tue, 4 Jul 2006, Brooks Davis wrote: BD>> JE>> BD>> JE>> BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: BD>> JE>> BD>> In message: <20060703202803.GA22556@odin.ac.hmc.edu> BD>> JE>> BD>> Brooks Davis writes: BD>> JE>> BD>> : and act as though the interface is not there. We could then BD>> JE>> consider BD>> JE>> BD>> : either holding the interface for a configurable or computed length BD>> JE>> BD>> : of time or adding some sort of refcounting (probably impractical). BD>> JE>> BD>> BD>> Refcounting would be good for the 'macro' things (coming and BD>> JE>> going) BD>> JE>> BD>> that are infrequent, but we might have mulitple people doing. You are BD>> JE>> BD>> right it likely is too inefficient to do with mbugs. One other option BD>> JE>> BD>> might be to have a configurable time after the last time that it was BD>> JE>> BD>> accessed via the 'safe' routines that were setup. This way we'd tie BD>> JE>> BD>> the removal of the interface to a period of time after it was last BD>> JE>> BD>> used, rather than after it was removed. I don't know if such a BD>> JE>> BD>> difference would matter much in practice. BD>> JE>> BD> BD>> JE>> BD>We might get some mielage out of last used, but then we'd have to keep BD>> JE>> BD>that timestamp updated. For normal applications, once we've torn down BD>> JE>> BD>the sockets and drained their queues, I believe we should not have to BD>> JE>> BD>wait more than a few seconds unless dummynet or some other mechanism BD>> JE>> BD>that queues mbufs for a significant period of time is enabled. If BD>> JE>> BD>dummynet is enabled we need to wait a bit longer, but it isn't outside BD>> JE>> BD>the relm of possibility for dummynet to be modified to tell us how long BD>> JE>> BD>it will be until the last mbuf it currenly holds will be released. In BD>> JE>> BD>practice, 121 seconds is probably a good default number since a 60 BD>> JE>> BD>second max RTT is assumed in TCP and thus delays longer than that BD>> JE>> BD>would break everything anyway. BD>> JE>> BD> BD>> JE>> BD>> The only other 'issue' that I see with this approach is if I remove a BD>> JE>> BD>> card, and then insert it again before the timeout happens. Does that BD>> JE>> BD>> card get a new interface name? And would people care or not... BD>> JE>> BD> BD>> JE>> BD>The name is unregistered with the call to if_detach because if_detach BD>> JE>> BD>removes the interface from the ifnet list. My guess is that BD>> JE>> BD>we'll either zero the name field or set to something like _zombie. The BD>> JE>> BD>unit will remain reserved until later. We'll need to add an SNMP index BD>> JE>> BD>mananaged in userland to satisfy come current if_index consumers. BD>> JE>> BD>> JE>> bsnmp does this anyway because of the rules for ifIndex. It has some BD>> JE>> heuristic to guess whether an interface is a physical one or not and if it BD>> JE>> is, it uses the same index again. The downside of this is that the BD>> JE>> interface index you see via SNMP has nothing to do with the interface index BD>> JE>> you see in the system and this does not work accross reboots and daemon BD>> JE>> restarts as required by the RFC. BD>> JE> BD>> JE>If we had a way to to this in the system (e.g. kept the mac address BD>> JE>with the ifnum in a hash) then we could just keep the ifnum in the mbuf BD>> JE>instead of the ifp pointer, as that is only occasionally used, and a BD>> JE>ifnum2ipf() macro could check the validity wheheve it is used. BD>> BD>> This would be helpful for the SNMP daemon, because this would also allow BD>> to reuse the ifnum if the same interface is plugged in back. However care BD>> must be taken that non-physical interfaces get a new ifnum always (iftun BD>> for example). BD> BD>This belongs in userland. It's too complex to handle in the kernel. We BD>probably need to store the index in the kernel as a rondivues point, BD>but the actual decision on deciding which interfaces are the "same" and BD>which are "different" as defined by the SNMP spec is too difficult and BD>has too many edge cases to try to do in the kernel. I think the right BD>answer is a daemon (or devd triggered script) that sets the SNMP index BD>based on a database containing previous lladdrs and units. That's probably true and that's what bsnmp is doing, although a hint from the kernel whether the interface is a physical one or not could be very helpful (the driver should know). harti From owner-freebsd-net@FreeBSD.ORG Wed Jul 5 10:09:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2643916A4DE for ; Wed, 5 Jul 2006 10:09:01 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C1A943D53 for ; Wed, 5 Jul 2006 10:08:59 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k65A8oeE025972 for ; Wed, 5 Jul 2006 13:08:50 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 5 Jul 2006 13:08:50 +0300 (EEST) From: Dmitry Pryanishnikov To: freebsd-net@freebsd.org Message-ID: <20060705125957.T30599@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: if_rl VLAN support in RELENG_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, 05 Jul 2006 10:09:01 -0000 Hello! In RELENG_4, RealTek 8129/8139 driver rl(4) doesn't claim VLAN support (when I assign vlandev rl0, my vlan device initially gets mtu 1496). In modern (e.g. RELENG_6) systems if_rl claims native VLAN support. I've tried setting 'ifconfig vlan0 mtu 1500' for rl-based vlan device, and resulting interface Just Works (TM) (1500-byte packets trasmit and receive correctly via such a vlan). So is it safe to use vlan with 'vlandev rl0' and 'mtu 1500' in RELENG_4? Has anyone observed any ill-effects in such a configuration? Would it be simple enough for if_rl in RELENG_4 to just announce native VLAN support to the system? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Jul 5 12:57:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E52016A4DD for ; Wed, 5 Jul 2006 12:57:15 +0000 (UTC) (envelope-from jan@melen.org) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDD5043D45 for ; Wed, 5 Jul 2006 12:57:14 +0000 (GMT) (envelope-from jan@melen.org) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A09D3212C50 for ; Wed, 5 Jul 2006 15:57:11 +0300 (EEST) Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id 6EAF5212C3D for ; Wed, 5 Jul 2006 15:57:11 +0300 (EEST) From: Jan Mikael Melen To: freebsd-net@freebsd.org Date: Wed, 5 Jul 2006 16:05:44 +0300 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200607051605.45014.jan@melen.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Problem with routes when configuring IPv6 addresses 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, 05 Jul 2006 12:57:15 -0000 Hello, I have a problem with routes in 6.1 when configuring IPv6 address using both autoconfigured addresses at the same time with statically configured addresses from different prefixes. If the host is not accepting router advertisements everything seems to work fine: # sysctl -a | grep rtad net.inet6.ip6.accept_rtadv: 0 # ifconfig fxp0 inet6 3ffe:101::1 prefixlen 64 # netstat -rn -f inet6 | grep 3ffe:101 3ffe:101::/64 link#1 UC fxp0 3ffe:101::1 00:12:3f:71:3e:ef UHL lo0 # As you can see I have two routes one for the loopback and one for the prefix as it should GREAT! Now if I'll set the host to accept router advertisements then the route for the 3ffe:101:: prefix will be deleted as the first router advertisement is received. The router advertises prefix 3ffe:14b8:400:101::/64. # sysctl net.inet6.ip6.accept_rtadv=1 net.inet6.ip6.accept_rtadv: 0 -> 1 # rtsol -a # netstat -rn -f inet6 | grep 3ffe:101 3ffe:101::1 00:12:3f:71:3e:ef UHL lo0 # It seems that the route is deleted because in function pfxlist_onlink_check() there is a check that if the state has changed to DETACHED the nd6_prefix_offlink will be called which then removes the route: if ((pr->ndpr_stateflags & NDPRF_DETACHED) != 0 && (pr->ndpr_stateflags & NDPRF_ONLINK) != 0) { if ((e = nd6_prefix_offlink(pr)) != 0) { nd6log((LOG_ERR, "pfxlist_onlink_check: failed to " "make %s/%d offlink, errno=%d\n", ip6_sprintf(&pr->ndpr_prefix.sin6_addr), pr->ndpr_plen, e)); } } This far I digged in to the code but then ran out of steam :-( Obviously the state should not be set to DETACHED for manually configured prefixes but the question is rather where it should be done. Before somebody asks, if I first do the autoconfiguration part and then after I have the autoconfigured address add the manually configured address the result is that there wont be any route for the manually configured prefix (3ffe:101::/64). Regards, Jan From owner-freebsd-net@FreeBSD.ORG Wed Jul 5 15:35:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6054516A4DD; Wed, 5 Jul 2006 15:35:50 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77EF943D55; Wed, 5 Jul 2006 15:35:49 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2006 08:35:50 -0700 X-IronPort-AV: i="4.06,210,1149490800"; d="scan'208"; a="327314318:sNHT33761236" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k65FZmMn008008; Wed, 5 Jul 2006 08:35:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k65FZmke009743; Wed, 5 Jul 2006 08:35:48 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 08:35:48 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Jul 2006 08:35:47 -0700 Message-ID: <44A90031.9010308@cisco.com> Date: Mon, 03 Jul 2006 07:32:01 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <44A552FA.2030302@cisco.com> <20060703094806.689f33ae@marcin> In-Reply-To: <20060703094806.689f33ae@marcin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2006 15:35:47.0622 (UTC) FILETIME=[AFEC3460:01C6A048] DKIM-Signature: a=rsa-sha1; q=dns; l=2624; t=1152113748; x=1152977748; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20SCTP; X=v=3Dcisco.com=3B=20h=3DeFwn8yHouLxYzxwWS0cbAORTlr0=3D; b=KvPneHeu3JRkekJyLnqzLJdoxBZJYCXr70Er1QWk1s0EQ/vG691MR3qWzauspEL+zkt128uO J3Juk+hZB3p9tIBB47Hi2seld5X/Y2Tajm34v9punOU78NznahhhShtA; Authentication-Results: sj-dkim-1.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: gnn@freebsd.org, freebsd-net@freebsd.org Subject: Re: 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: Wed, 05 Jul 2006 15:35:50 -0000 Bascially there are two socket models that can be used by SCTP.. sd = socket(AF_INETX, SOCK_STREAM, IPPROTO_SCTP); or sd = socket(AF_INETX, SOCK_SEQPACKET, IPPROTO_SCTP); The first one will then look JUST like TCP... aka you can take ANY TCP app you have and it will work... only thing you might need to do is convert TCP_MAXSEG and TCP_NODELAY socket option calls to ones with SCTP instead... This is how I quickly converted several fun utilities.. The second model looks like UDP more or less. You still need to do a listen() but other than that you can just send and recv data... Now George also convert his packet pounder program (don't remember the name.. Geroge?)... and if you want I can place a tar-ball of some app programs up that I use for testing.. but of course ..sigh.. there is no documenation .. so it might not be to useful :-0 Let me knof if you want a tarball up on sctp.org of app code :-0 R Marcin Jessa wrote: > On Sat, 01 Jul 2006 17:46:48 +0900 > gnn@freebsd.org wrote: > > >>At Fri, 30 Jun 2006 12:36:10 -0400, >>randall wrote: >> >>>Hi all: >>> >>>The following link: >>> >>>http://www.sctp.org/cvs_diff_6_30.bz2 >>> >>>Will get you a large patch that you can apply to Current that will >>>add SCTP. >>> >>>Its a bzip2 patch file since it is so large :-D >>> >>>It includes the changes to a few base files.. and mainly its the >>>complete files diff'd against this mornings current cvs... >>> >>>Yes, I know that the build is broken in acpi/acpi_asus but the sctp >>>code did compile and build a kernel for me... so once the above is >>>fixed.. you should be able to use the patch and check it out :-D >>> >>>Oh, you will need to add >>> >>>option SCTP >>> >>>to your kernel conf... and it might not >>>hurt to do a make sysent in sys/kern >>> >>>I will prepare a seperate file for the overall libsctp.a >>>once I figure out where it should go :-D >>> >>>Happy SCTPing.. and if you have any problems with the patch please >>>send me an email :-D >> >>And please start testing this because many of us want to integrate >>this in the near future :-) > > > Any hints on how to test SCTP ? > Not much really about any practical implementation of it > on http://www.sctp.org/ > > Marcin. > _______________________________________________ > 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" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Jul 5 17:09:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E120216A4E2 for ; Wed, 5 Jul 2006 17:09:33 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D07543D49 for ; Wed, 5 Jul 2006 17:09:32 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so1636166nfc for ; Wed, 05 Jul 2006 10:09:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EFzV3BxVXnTtbKiUJa0rk7kPkg+Kv/efjYIcA8gNuD82C5uJcKPWOqEGa7QAJNuWrko+6/45lEzCfbjqYiJbACCoScyzPtdq+LAYTF/Cr9fP8EPUgUAInXLBMsxQ/IFR2j8vAeCcKxradpwTRvIL9ZfUFZSN7nA6RMLRHJml26g= Received: by 10.48.243.16 with SMTP id q16mr4076819nfh; Wed, 05 Jul 2006 10:09:31 -0700 (PDT) Received: by 10.48.250.2 with HTTP; Wed, 5 Jul 2006 10:09:31 -0700 (PDT) Message-ID: <79722fad0607051009r4cd6a23bh8923b4aa844c6e40@mail.gmail.com> Date: Wed, 5 Jul 2006 20:09:31 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: bpf seeing non-local traffic on lo0 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, 05 Jul 2006 17:09:34 -0000 I was debugging a dspam->clamav connection and I saw two packets which didn't belong to the loopback interface. The destination IP was assigned to one of the physical interfaces, and the source IP was somewhere on the internet. I've no idea how to reproduce it. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Wed Jul 5 17:13:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A47516A4DF for ; Wed, 5 Jul 2006 17:13:41 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61A5543D45 for ; Wed, 5 Jul 2006 17:13:39 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so1638405nfc for ; Wed, 05 Jul 2006 10:13:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=onaIOCHVfnc9FDX6nVF/fOPwhbIPlcBiwe15BOtmVHo2aZEa4nzwlaD8xL8KrrjJuaOwB3uSOlVOg8bHniPoTWK12JNz0vLduAIAgkn5t5zHdMRMsMI65qQHBQhvM+cxNv27tbL3ej23pTw0tFOZrtkXyXrowkv2VX5yCw0pZpc= Received: by 10.48.47.3 with SMTP id u3mr4079190nfu; Wed, 05 Jul 2006 10:13:39 -0700 (PDT) Received: by 10.48.250.2 with HTTP; Wed, 5 Jul 2006 10:13:39 -0700 (PDT) Message-ID: <79722fad0607051013w38f03fcrd0f9b439dcca2de0@mail.gmail.com> Date: Wed, 5 Jul 2006 20:13:39 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org In-Reply-To: <79722fad0607051009r4cd6a23bh8923b4aa844c6e40@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <79722fad0607051009r4cd6a23bh8923b4aa844c6e40@mail.gmail.com> Subject: Re: bpf seeing non-local traffic on lo0 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, 05 Jul 2006 17:13:41 -0000 On 7/5/06, Vlad GALU wrote: > I was debugging a dspam->clamav connection and I saw two packets > which didn't belong to the loopback interface. The destination IP was > assigned to one of the physical interfaces, and the source IP was > somewhere on the internet. I've no idea how to reproduce it. It looks like a BPF miscompilation, since the filter I set said "tcp port 3310" and the captured packets have, indeed, a source port of 3310. It's perhaps worth saying that the machine is an EM64T running amd64. > > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Thu Jul 6 01:18:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AA1716A4DA for ; Thu, 6 Jul 2006 01:18:42 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D902843D45 for ; Thu, 6 Jul 2006 01:18:41 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k661IOKY006216; Wed, 5 Jul 2006 18:18:24 -0700 (PDT) Date: Thu, 06 Jul 2006 10:18:12 +0900 Message-ID: From: "George V. Neville-Neil" To: Randall Stewart In-Reply-To: <44A90031.9010308@cisco.com> References: <44A552FA.2030302@cisco.com> <20060703094806.689f33ae@marcin> <44A90031.9010308@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, Marcin Jessa Subject: Re: 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: Thu, 06 Jul 2006 01:18:42 -0000 At Mon, 03 Jul 2006 07:32:01 -0400, randall wrote: > > Bascially there are two socket models that > can be used by SCTP.. > > sd = socket(AF_INETX, SOCK_STREAM, IPPROTO_SCTP); > > or > > sd = socket(AF_INETX, SOCK_SEQPACKET, IPPROTO_SCTP); > > The first one will then look JUST like TCP... aka you > can take ANY TCP app you have and it will work... only > thing you might need to do is convert TCP_MAXSEG > and TCP_NODELAY socket option calls to ones with SCTP > instead... > > This is how I quickly converted several fun utilities.. > > The second model looks like UDP more or less. You > still need to do a listen() but other than that > you can just send and recv data... > > Now George also convert his packet pounder program > (don't remember the name.. Geroge?)... and > if you want I can place a tar-ball of some app > programs up that I use for testing.. but of course ..sigh.. there > is no documenation .. so it might not be to useful :-0 > > Let me knof if you want a tarball up on sctp.org of app code :-0 > Even without docs it couldn't hurt. I already sent the pointer to my version of NetPIPE (the pounder you mention) and their new release should have SCTP in it by default. Later, George From owner-freebsd-net@FreeBSD.ORG Thu Jul 6 03:39:33 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 683BE16A4DA for ; Thu, 6 Jul 2006 03:39:33 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BC4743D49 for ; Thu, 6 Jul 2006 03:39:32 +0000 (GMT) (envelope-from brett@lariat.net) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id VAA01072 for ; Wed, 5 Jul 2006 21:39:27 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060705213904.06ab3008@lariat.net> Message-Id: <7.0.1.0.2.20060705115517.05fb6f78@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 05 Jul 2006 21:39:17 -0600 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Strange errors from BIND on FreeBSD 4.x system 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, 06 Jul 2006 03:39:33 -0000 I'm working with a client's FreeBSD system (4.9 with patches) which is having trouble resolving certain domains but not others. When I try to execute the same queries using "dig", I see the error message res_nsend: Protocol not supported Via various search engines, I've seen hints that the problem may have something to do with IPV6 but no instructions as to how to resolve it. Can anyone explain what's wrong and how to fix it? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu Jul 6 12:25:42 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C19616A4DE for ; Thu, 6 Jul 2006 12:25:42 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29FDD43D77 for ; Thu, 6 Jul 2006 12:25:39 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 7865229D4D; Thu, 6 Jul 2006 08:25:38 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 3DF215BCD9; Thu, 6 Jul 2006 08:25:37 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FySvH-0008OB-HP; Thu, 06 Jul 2006 13:25:35 +0100 Date: Thu, 6 Jul 2006 13:25:35 +0100 From: Brian Candler To: Brett Glass Message-ID: <20060706122535.GB32208@uk.tiscali.com> References: <7.0.1.0.2.20060705115517.05fb6f78@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060705115517.05fb6f78@lariat.net> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Strange errors from BIND on FreeBSD 4.x system 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, 06 Jul 2006 12:25:42 -0000 On Wed, Jul 05, 2006 at 09:39:17PM -0600, Brett Glass wrote: > I'm working with a client's FreeBSD system (4.9 with patches) which > is having trouble resolving certain domains but not others. When I > try to execute the same queries using "dig", I see the error message > > res_nsend: Protocol not supported > > Via various search engines, I've seen hints that the problem may > have something to do with IPV6 but no instructions as to how to > resolve it. Can anyone explain what's wrong and how to fix it? The nameserver you're trying to talk to has both IPv6 and IPv4 addresses, dig is trying to use the IPv6 one, but failing because your host doesn't have IPv6 connectivity. Example: ;; ANSWER SECTION: ns-pri.ripe.net. 166057 IN A 193.0.0.195 ns-pri.ripe.net. 72477 IN AAAA 2001:610:240:0:53::3 If you try "dig @ns-pri.ripe.net. ripe.net. soa" I suspect you will get this error. (Of course, this bug only happens because the IPv6 address is tried in preference to IPv4 whenever this case occurs. Life would be much easier if it tried IPv4 in preference to IPv6 - but then the IPv6 stack would never get exercised at all. That would be a good thing IMO :-) Solutions: (1) try rebuilding the kernel with INET6 commented out. Or if it's commented out now, try rebuilding with it back in. I can't remember which way round caused the problem. (2) otherwise, you could upgrade dig to a version from a newer version of BIND, as ISTR this was fixed in the application. So much for the IPv4-IPv6 transition being transparent to applications :-( Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Fri Jul 7 09:49:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C972316A4DE for ; Fri, 7 Jul 2006 09:49:59 +0000 (UTC) (envelope-from mgraneroqtbz@granero.com.br) Received: from host-81-190-206-87.gorzow.mm.pl (host-81-190-206-87.gorzow.mm.pl [81.190.206.87]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BB0743D5D for ; Fri, 7 Jul 2006 09:49:56 +0000 (GMT) (envelope-from mgraneroqtbz@granero.com.br) Received: from mx1.granero.com.br by host-81-190-206-87.gorzow.mm.pl (8.9.3/8.9.3) with ESMTP id 41CYQdGvo6r8 for ; Fri, 7 Jul 2006 05:49:58 -0400 Received: from mfu (226.21.31.38) by mx1.granero.com.br with ESMTP id Kh2xBA8lDTOr for ; Fri, 7 Jul 2006 05:49:58 -0400 From: "Aubrey Wooten" Message-ID: <9818269773.0592515188@granero.com.br> Date: Fri, 7 Jul 2006 05:49:58 -0400 To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: access stimuulate for Penis X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aubrey Wooten List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2006 09:49:59 -0000 Just look at that preview. I do not lies to http://4tsh98avrfa1hmmx9mmf9m44.rejectorhk.com/?eSffiRg-WfQ.eSffiRg,VSd From owner-freebsd-net@FreeBSD.ORG Fri Jul 7 11:40:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CB0D16A4E0 for ; Fri, 7 Jul 2006 11:40:11 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 737B543D46 for ; Fri, 7 Jul 2006 11:40:10 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2006 04:40:10 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k67BeAYb030696; Fri, 7 Jul 2006 04:40:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k67Be8DH011068; Fri, 7 Jul 2006 04:40:09 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 04:40:08 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 04:40:06 -0700 Message-ID: <44AE4814.2020706@cisco.com> Date: Fri, 07 Jul 2006 07:40:04 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "George V. Neville-Neil" References: <44A552FA.2030302@cisco.com> <20060703094806.689f33ae@marcin> <44A90031.9010308@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 11:40:06.0394 (UTC) FILETIME=[17EB8DA0:01C6A1BA] DKIM-Signature: a=rsa-sha1; q=dns; l=3402; t=1152272410; x=1153136410; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20SCTP; X=v=3Dcisco.com=3B=20h=3DeFwn8yHouLxYzxwWS0cbAORTlr0=3D; b=dxWO7n3F/M7r3WC2KWRSP9D2Nc5gWCq83npbL3VnLpvGZCoVv4BQfsmEPAK/bBg15EAPQNVX 8Ab9ZpgoJJw6AmzbrgGZi3BFPSXFxltR79u7OoQLQ+G2Q4b6nA9xZRJr; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, Marcin Jessa Subject: Re: 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, 07 Jul 2006 11:40:11 -0000 George V. Neville-Neil wrote: > > I already sent the pointer to my version of NetPIPE (the pounder you > mention) and their new release should have SCTP in it by default. > > Later, > George > Ok, no doc's just stuff http://www.sctp.org/app.tar.bz2 Un tar into a directory (it creates several) do a gmake and you will have in the apps/FreeBSD subdir: block_test dump_pegs prtcwndlog client_manyconn getcwndlog prtcwndlog_ntohl cmp_client interest_client sctp_test_app cmp_recvfile interest_server server cmp_sendfile m_cmp_client tcp_client cmp_server peel_client tcp_server data_sorter peel_server tsctp bash-stewlap: some ones of interest: cmp_server m_cmp_client cmp_server takes an arg -p port and -s for SCTP and -t for TCP m_cmp_client takes many argumets... -e error -f file -h host -p port -M limit -e error .. is just a text string that goes in the out file.. put -e 0.0 -f file .. is an input list of transfers (see below).. suply your file name -h 10.1.1.1 (host you ran cmp_server on) -p port (port you ran cmp_server on) if you add a -t, you do TCP connections only. If you add a -s you do SCTP connections only.. by default it will try both.. File format is: # Control file needs # sizetos:blksize:snd_buf:recv_buf\n 157000000:157:0:0 158000000:158:0:0 xx yy in the direectory are examples.. First arg is size of transfer second is record size, third and fourth are send/recv buf size changes -- 0 is don't touch. This generates a file... xx.data (xx is the file you input)... this can actually be used with a data_sorter program to plot graphs... sctp_test_app Is a general purpose test app that can do LOTS of things. It gives you a prompt and you can type help to it.. args to it are -m myport -p first-dest-port -h first-dest-host But I will let you type help for fun... and learning .. it does use a readline type syntax. and requires libreadline.so/.a etc.. The rest are migrant test apps we have built over the last 5 years.. some simple.. some complex.. getcwndlog/prtcwndlog is a instrumenting utility that works with the options in kernel config #options SCTP_LOG_MAXBURST #options SCTP_STAT_LOGGING #options SCTP_CWND_LOGGING #options SCTP_CWND_MONITOR #options SCTP_BLK_LOGGING #options SCTP_STR_LOGGING #options SCTP_FR_LOGGING #options SCTP_MAP_LOGGING #options SCTP_SACK_LOGGING #options SCTP_LOCK_LOGGING #options SCTP_RTTVAR_LOGGING #options SCTP_SB_LOGGING #options SCTP_WITH_NO_CSUM #options SCTP_EARLYFR_LOGGING #options SCTP_NAGLE_LOGGING You turn on option SCTP_STAT_LOGGING and then add your favorite type of logging... for example to watch cwnd option SCTP_CWND_LOGGING Now this creates an 80k entry array that the getcwndlog will pull. prtcwndlog will display the log.. I don't recommend this for production kernels.. but it sure is nice for debugging and poking around :-D The rest I will let you explore.. no apologies though for the shape of the hacked together code :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 00:30:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 255C916A4E1; Sat, 8 Jul 2006 00:30:19 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0024943D4C; Sat, 8 Jul 2006 00:30:14 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k680UD52000871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jul 2006 20:30:14 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k680U7MK038308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jul 2006 20:30:08 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: net@freebsd.org Date: Fri, 7 Jul 2006 20:30:01 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607072030.01999.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1589/Fri Jul 7 10:37:51 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: freebsd-security@freebsd.org, imp@freebsd.org Subject: strange limitation on rcmd() 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, 08 Jul 2006 00:30:19 -0000 The manual page says, that rcmd() is only to be used by root's processes. On other OSes (Solaris, AIX), trying to call rcmd() without being root simply fails. FreeBSD, however, tries to be helpful and invokes rcmdsh in this case, which is inefficient and leaves the stderr's filedescriptor (fd2p) unfilled. Why? My understanding is, this is to make it harder for would-be attackers to attack machines with .rhosts-based security. But that is nothing more than a bad band-aid anyway -- attacker's own implementation of rcmd() (without the geteuid() checks) is trivial... So, without providing any meaningful security improvement (who is relying on .rhosts for security anyway?!), we are impeding a very useful functionality. rcmd offers an efficient way to send your data to a command "abroad" and even has a mechanism for getting the remote's stderr -- assuming, your network is secure enough for you to trust .rhosts. Why are we duplicating the misguided efforts of commercial Unixes and limiting it to root only? "Mechanism, not policy", please... -mi From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 10:47:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 398CD16A4DD for ; Sat, 8 Jul 2006 10:47:04 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFD6043D49 for ; Sat, 8 Jul 2006 10:47:03 +0000 (GMT) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id 7D3EBBF8DC7; Sat, 8 Jul 2006 12:47:02 +0200 (CEST) Received: by cc.bashibuzuk.net (Postfix, from userid 1001) id 7F950BDE6; Sat, 8 Jul 2006 12:47:18 +0200 (CEST) Date: Sat, 8 Jul 2006 12:47:18 +0200 From: Yann Berthier To: Randall Stewart Message-ID: <20060708104718.GA1632@bashibuzuk.net> References: <44A552FA.2030302@cisco.com> <20060703094806.689f33ae@marcin> <44A90031.9010308@cisco.com> <44AE4814.2020706@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AE4814.2020706@cisco.com> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: 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, 08 Jul 2006 10:47:04 -0000 Hello, On Fri, 07 Jul 2006, at 07:40, Randall Stewart wrote: > George V. Neville-Neil wrote: > > > > >I already sent the pointer to my version of NetPIPE (the pounder you > >mention) and their new release should have SCTP in it by default. > > > >Later, > >George > > > > > Ok, no doc's just stuff > > http://www.sctp.org/app.tar.bz2 fyi: i've collected netflow records for a couple of days over sctp, from a cisco router to my test machine - i used ntop on the receiver side (the only netflow-related app i found sporting sctp) worked fine - many things i wanted to test i have not - i'll see that after my holidays any patch for netstat and all floating around to display state of sctp sockets ? thanks, - yan From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 13:57:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDA9C16A4DF for ; Sat, 8 Jul 2006 13:57:18 +0000 (UTC) (envelope-from andre.netvision.com.br@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2674D43D46 for ; Sat, 8 Jul 2006 13:57:15 +0000 (GMT) (envelope-from andre.netvision.com.br@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1083771uge for ; Sat, 08 Jul 2006 06:57:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NJ5JSDoVR8dFb8WE5me0XaGoW5T0wybBBsbtjtQq6WNoSj0EBgOGSkevCUZsK7h9z3QtzM8tLgFki2zchBUjao79mT+VjBz8aS2IP+FZ34Xd+anB+helZtMojveMEopvjKucylojCdbBWWxTSqYSjK4T2x4lUA02QWHTi774nTM= Received: by 10.78.122.11 with SMTP id u11mr1107687huc; Sat, 08 Jul 2006 06:57:14 -0700 (PDT) Received: by 10.78.19.10 with HTTP; Sat, 8 Jul 2006 06:57:14 -0700 (PDT) Message-ID: Date: Sat, 8 Jul 2006 10:57:14 -0300 From: "Andre Santos" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Incompatibility between dummynet and PF rdr. 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, 08 Jul 2006 13:57:19 -0000 Are there any known compatibility problems between dummynet and PF rdr rules? When I try to combine both, the packets seem to simply disappear. Here's how to reproduce it on 6.1-RELEASE: Load PF. TCP connections coming in on lnc1 will be redirected to the local SSH server. kldload pf pfctl -e echo "rdr on lnc1 proto tcp -> 127.0.0.1 port 22" \ | pfctl -f - Add dummynet: kldload ipfw; ipfw add 65000 allow ip from any to any kldload dummynet ipfw pipe 1 config mask all ipfw add 1 pipe 1 ip from any to any Up to this point, everything works well, but here's where it breaks. After disabling and re enabling PF, the only packets on this system are SYNs coming in on lnc1, all other interfaces are quiet (lo0, lnc0). pfctl -d pfctl -e PF rules are still in place, dummynet gets the SYN packets, but then they go somewhere where I can't find them. tcpdump on lnc1 shows only the SYN packets coming in, all other interfaces are quiet. Could somebody please help me find these lost packets? Thank you! If you invert the order and load ipfw/dummynet before PF, the disabling and re enabling step is not even necessary. The ftp-proxy in OpenBSD >= 3.9 creates rules that don't need the disabling and re enabling step to fail. Both active and passive data connections don't work. # ipfw show 00001 401 36224 pipe 1 ip from any to any 65000 0 0 allow ip from any to any 65535 0 0 deny ip from any to any # pfctl -vsn [ ... no ALTQ support ... ] rdr on lnc1 inet proto tcp all -> 127.0.0.1 port 22 [ Evaluations: 779 Packets: 85 Bytes: 5013 States: 0 ] On systems that have ethernet interfaces only, I can work around the problem by running: # sysctl -w net.inet.ip.fw.enable=0 # sysctl -w net.link.ether.ipfw=1 From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 14:23:51 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6AEB16A4E0 for ; Sat, 8 Jul 2006 14:23:51 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.FreeBSD.org (Postfix) with SMTP id C1ACC43D45 for ; Sat, 8 Jul 2006 14:23:50 +0000 (GMT) (envelope-from paulo@nlink.com.br) Received: (qmail 87077 invoked from network); 8 Jul 2006 14:23:49 -0000 Received: from j1.nlink.com.br (HELO ?201.12.59.126?) (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 8 Jul 2006 14:23:49 -0000 Message-ID: <44AFBFF0.9050809@nlink.com.br> Date: Sat, 08 Jul 2006 11:23:44 -0300 From: Paulo Fragoso User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: if_bridge problem in hostap (ath)? 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, 08 Jul 2006 14:23:52 -0000 Hi, Are there any problem with if_bridge in hostap mode? We have a FreeBSD 6.1 runnig with 03 atheros cards (all atheros cards are in hostap mode) where 02 cards are bridged: bridge0: flags=8043 mtu 1500 ether ac:de:48:0f:31:2a priority 32768 hellotime 2 fwddelay 15 maxage 20 member: nve0 flags=3 member: ath1 flags=3 member: ath2 flags=3 In this server are happing some crahses like this: ============================================================ kgdb kernel.debug /var/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc05288fd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 #2 0xc0528b94 in panic (fmt=0xc06fa922 "%s") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc06d32f4 in trap_fatal (frame=0xd0fe9ae8, eva=12) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc06d305b in trap_pfault (frame=0xd0fe9ae8, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc06d2cb9 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1017680556, tf_esi = 320, tf_ebp = -788620468, tf_isp = -788620524, tf_ebx = -1017680640, tf_edx = 0, tf_ecx = -1013202928, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068114357, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -788620464}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc06c2b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc055de4b in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:400 #8 0xc05d0d08 in ip_fragment (ip=0xc39bc010, m_frag=0xd0fe9c08, mtu=-1017680640, if_hwassist_flags=0, sw_csum=1) at /usr/src/sys/netinet/ip_output.c:975 #9 0xc05d09af in ip_output (m=0xc399cd00, opt=0xc3449800, ro=0xd0fe9bd4, flags=1, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:804 #10 0xc05cfd98 in ip_forward (m=0xc399cd00, srcrt=0) at /usr/src/sys/netinet/ip_input.c:1907 #11 0xc05ce907 in ip_input (m=0xc399cd00) at /usr/src/sys/netinet/ip_input.c:689 #12 0xc05a5243 in netisr_processqueue (ni=0xc0797458) at /usr/src/sys/net/netisr.c:236 #13 0xc05a53f6 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:343 #14 0xc0513129 in ithread_execute_handlers (p=0xc3329830, ie=0xc338c300) at /usr/src/sys/kern/kern_intr.c:684 #15 0xc0513240 in ithread_loop (arg=0xc330f640) at /usr/src/sys/kern/kern_intr.c:767 #16 0xc0512098 in fork_exit (callout=0xc05131ec , arg=0xc330f640, frame=0xd0fe9d38) at /usr/src/sys/kern/kern_fork.c:805 #17 0xc06c2b7c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 ============================================================ Our /etc/sysctl.conf is: net.link.ether.ipfw=1 kern.maxfiles=32768 net.inet.ip.fw.dyn_max=10240 kern.ipc.nmbclusters=32768 kern.ipc.somaxconn=38400 and /boot/loader.conf: kern.ipc.nmbclusters=32768 kern.ipc.maxpipekva=6553600 if_ath_load="YES" ath_hal_load="YES" ath_rate_load="YES" kern.maxusers=512 debug.mpsafenet=0 and dmesg: Copyright (c) 1992-2006 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 6.1-RELEASE-p2 #0: Thu Jul 6 08:59:27 GMT+3 2006 paulo@***:/usr/obj/usr/src/sys/KERNEL4 WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) Processor 3000+ (1808.81-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20fc0 Stepping = 0 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 268369920 (255 MB) avail memory = 252715008 (241 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0xcf0-0xcf3 on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xf9ffffff at device 0. 0 on pci0 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) nve0: port 0xcc00-0xcc07 mem 0xfd002000- 0xfd002fff irq 20 at device 5.0 on pci0 nve0: Ethernet address 00:0f:ea:ae:d7:44 miibus0: on nve0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:0f:ea:ae:d7:44 nve0: [GIANT-LOCKED] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x 177,0x376,0xf000-0xf00f at device 8.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x 970-0x977,0xb70-0xb73,0xe800-0xe80f,0xec00-0xec7f irq 21 at device 10.0 on pci0 ata2: on atapci1 ata3: on atapci1 pcib1: at device 11.0 on pci0 pci1: on pcib1 pcib2: at device 14.0 on pci0 pci2: on pcib2 ath0: mem 0xfc040000-0xfc04ffff irq 18 at device 6.0 on pci2 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:13:46:93:b6:13 ath0: mac 7.9 phy 4.5 radio 5.6 ath1: mem 0xfc020000-0xfc02ffff irq 19 at device 7.0 on pci2 ath1: [GIANT-LOCKED] ath1: Ethernet address: 00:13:46:93:b8:5b ath1: mac 7.9 phy 4.5 radio 5.6 ath2: mem 0xfc030000-0xfc03ffff irq 16 at device 8.0 on pci2 ath2: [GIANT-LOCKED] ath2: Ethernet address: 00:13:46:93:b6:01 ath2: mac 7.9 phy 4.5 radio 5.6 pci2: at device 9.0 (no driver attached) sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1808812915 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, defau lt to accept, logging unlimited ad0: 38203MB at ata0-master UDMA100 Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted bridge0: Ethernet address: ac:de:48:0f:31:2a Can anyone help us? Thanks, Paulo. From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 17:24:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98D4C16A4DE for ; Sat, 8 Jul 2006 17:24:43 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1C6243D46 for ; Sat, 8 Jul 2006 17:24:42 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1124938uge for ; Sat, 08 Jul 2006 10:24:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QGD4T8OgeJtQ/AcMiSjThVytpp6Jk9PZs4FyEUyDNeQP2m7CiXijLpird4Vk1ec4MKG3LMpj1uMWCFXIu0QvkicQOeNiVFRE20Ml7fmSwkaGApWRS3GtnghpIFuSZTlTBWLwd0MBjnw1Qt4CdOM1wvs1eh3gIHTFl/Iz00YATao= Received: by 10.66.244.10 with SMTP id r10mr3204079ugh; Sat, 08 Jul 2006 10:24:41 -0700 (PDT) Received: by 10.67.105.8 with HTTP; Sat, 8 Jul 2006 10:24:41 -0700 (PDT) Message-ID: Date: Sat, 8 Jul 2006 13:24:41 -0400 From: "Scott Ullrich" To: "Andre Santos" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: Incompatibility between dummynet and PF rdr. 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, 08 Jul 2006 17:24:43 -0000 On 7/8/06, Andre Santos wrote: > Are there any known compatibility problems between dummynet and PF rdr rules? > When I try to combine both, the packets seem to simply disappear. [snip] I can confirm this behavior. Glad someone else noticed as it would happen when we try to use dummynet traffic shaping + pf on pfSense. Never really was a high priority to nail down exactly what combination of dummynet + pf was breaking it. If anyone needs me to test patches, just let me know. Scott From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 17:50:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F6D916A4DA for ; Sat, 8 Jul 2006 17:50:08 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C5C43D45 for ; Sat, 8 Jul 2006 17:50:07 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 606D72D4857; Sat, 8 Jul 2006 17:50:06 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 2B94D1141F; Sat, 8 Jul 2006 19:50:06 +0200 (CEST) Date: Sat, 8 Jul 2006 19:50:05 +0200 From: "Simon L. Nielsen" To: Scott Ullrich Message-ID: <20060708175004.GA1087@zaphod.nitro.dk> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Andre Santos Subject: Re: Incompatibility between dummynet and PF rdr. 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, 08 Jul 2006 17:50:08 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2006.07.08 13:24:41 -0400, Scott Ullrich wrote: > On 7/8/06, Andre Santos wrote: > >Are there any known compatibility problems between dummynet and PF rdr= =20 > >rules? > >When I try to combine both, the packets seem to simply disappear. > [snip] >=20 > I can confirm this behavior. Glad someone else noticed as it would > happen when we try to use dummynet traffic shaping + pf on pfSense. > Never really was a high priority to nail down exactly what combination > of dummynet + pf was breaking it. If anyone needs me to test > patches, just let me know. I also noticed problems when trying to use dummynet/ipfw and pf. I looked a bit at it and it seemed that packets, which got queued in dummynet, were not matched by pf's state engine when re-injected from dummynet. At least I saw a lot of denied packets which shouldn't have been denied on pflog. It wasn't very important for me to get this working, so I haven't looked more at it. --=20 Simon L. Nielsen --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEr/BMh9pcDSc1mlERAj/mAKCiXmpxalcY9HrG7dEguA9TGnPdJwCfaaql y4frc2I09ZAkRY8GicaZmSI= =hdpI -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 18:29:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7393F16A4E0 for ; Sat, 8 Jul 2006 18:29:23 +0000 (UTC) (envelope-from sanford.owings@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D5543D5D for ; Sat, 8 Jul 2006 18:29:22 +0000 (GMT) (envelope-from sanford.owings@gmail.com) Received: by wr-out-0506.google.com with SMTP id i22so1455774wra for ; Sat, 08 Jul 2006 11:29:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=lw0A3WOMN7JF1Av4jDJadeLyUW13oJvYk4q4ef3AfTMAiAIbvWcQ3b3dyMuLyzccV0jiIgOc0eHgKtEn69pnRPc+NQUXQLB0MDVnP7YErBVC9ZAmLjiPGxdTuBI/7N5JP4q0XGplM5+6EddbJR/2dlI5bBp99n1sGUMPlGBjEXY= Received: by 10.54.140.13 with SMTP id n13mr3043442wrd; Sat, 08 Jul 2006 11:29:21 -0700 (PDT) Received: by 10.54.99.17 with HTTP; Sat, 8 Jul 2006 11:29:21 -0700 (PDT) Message-ID: Date: Sat, 8 Jul 2006 11:29:21 -0700 From: "Sanford Owings" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Services on bridging host? 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, 08 Jul 2006 18:29:23 -0000 Hello. I'm looking for some assistance (or at least some more understanding) regarding a connectivity issue with a bridging host. In short, I have a host with two interfaces, using the "options BRIDGE" type of bridging. One interface has an IP assigned, and the other does not (as suggested by the FBSD handbook). Hosts on the "IP enabled" side of the bridging host can connect to that IP (ssh, SMB shares, etc), but not to hosts on the other side of the bridge. In addition, the bridging host itself cannot connect to services on the "non-IP enabled" side of itself. Segment 1: Desktop box .63 Laptop .65 Bridging host .2 Segment 2: Bridging host Firewall/gateway .1 Wireless access point .254 All hosts are in the same (192.168) class C. Hosts on segment 1 (not including the bridging host) can pass *through* the firewall/gateway to the internet, but cannot connect to any services running on the firewall host. Hosts on segment 2 (not including the bridging host, but including hosts connected via wireless) can connect to services on the firewall/gateway, as well as pass through it to the internet. However, no services running on the bridging host can be reached via its IP defined on segment 1. The ethernet address of the firewall host is listed on the segment 1 interface (em0, to differentiate from vr0) of the bridging hosts 'arp -a' output, despite the fact that the firewall is connected on the segment 2 side of the bridge. My sysctl.conf reads: net.link.ether.bridge.enable=1 net.link.ether.bridge.config=em0,vr0 em0 is ifconfiged with an address in rc.conf, while vr0 is not. uname -a: FreeBSD tranquillity.base 6.1-RC FreeBSD 6.1-RC #3: Mon Apr 24 10:56:48 PDT 2006 sowings@tranquillity.base:/usr/src/sys/i386/compile/tranquillity i386 I'd be happy to switch to if_bridge, but I had no luck with that at all in my first attempt. Can anyone offer a hint? If there's additional information needed to help sort this out, please let me know. Sanford -- Sanford Owings sanford.owings@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Jul 8 21:39:40 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8738B16A4DF; Sat, 8 Jul 2006 21:39:40 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C4AD43D45; Sat, 8 Jul 2006 21:39:39 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id EB15729D52; Sat, 8 Jul 2006 17:39:38 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 465D25F5C1; Sat, 8 Jul 2006 17:39:34 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FzKWS-000Aiu-GX; Sat, 08 Jul 2006 22:39:32 +0100 Date: Sat, 8 Jul 2006 22:39:32 +0100 From: Brian Candler To: Mikhail Teterin Message-ID: <20060708213932.GA41178@uk.tiscali.com> References: <200607072030.01999.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607072030.01999.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-security@freebsd.org, imp@freebsd.org, net@freebsd.org Subject: Re: strange limitation on rcmd() 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, 08 Jul 2006 21:39:40 -0000 On Fri, Jul 07, 2006 at 08:30:01PM -0400, Mikhail Teterin wrote: > The manual page says, that rcmd() is only to be used by root's processes. DESCRIPTION The rcmd() function is used by the super-user to execute a command on a remote machine using an authentication scheme based on reserved port num- bers. Note that only root can bind to reserved ports. > On other OSes (Solaris, AIX), trying to call rcmd() without being root simply > fails. > > FreeBSD, however, tries to be helpful and invokes rcmdsh in this case, which > is inefficient and leaves the stderr's filedescriptor (fd2p) unfilled. > > Why? > > My understanding is, this is to make it harder for would-be attackers to > attack machines with .rhosts-based security. But that is nothing more than a > bad band-aid anyway -- attacker's own implementation of rcmd() (without the > geteuid() checks) is trivial... But an attacker who doesn't have root won't be able to use their own implementation of rcmd(). It will just fail. Either the attacker will ask to bind to a privileged port (which will fail at the local host), or they will bind to a non-privileged port (in which case the remote host will reject the request) rsh is a setuid root binary. It is able to bind to privileged ports, whilst performing security checks that the requested access is valid. In the same way, the 'passwd' command lets you change your own password, without letting you change someone else's. > So, without providing any meaningful security improvement (who is relying > on .rhosts for security anyway?!), we are impeding a very useful > functionality. No security improvement is implied. Rather, you just get extra functionality. Instead of a dead failure, certain non-root requests are allowed (i.e. user A on host X can run commands as user A on host Y) > rcmd offers an efficient way to send your data to a command "abroad" and even > has a mechanism for getting the remote's stderr -- assuming, your network is > secure enough for you to trust .rhosts. And the requesting user is running as root, so they can bind to a privileged port. > Why are we duplicating the misguided efforts of commercial Unixes and limiting > it to root only? Because this is exactly how the .rhosts security model works - it accepts requests only from privileged ports, which in turn means that it knows the request only came from root. This mechanism is only valid for trusted hosts, of course. If you allow a random person to put their own PC on the network, they can of course send packets from privileged ports (either by installing Unix with their own root password, or by installing DOS and sending packets which come from privileged ports) HTH, Brian.