From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 02:36:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF40106566B for ; Sun, 26 Sep 2010 02:36:34 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 0279C8FC0A for ; Sun, 26 Sep 2010 02:36:33 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.4) with ESMTP id o8Q2AFli088053; Sat, 25 Sep 2010 20:10:15 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.4/Submit) with ESMTP id o8Q2AFOu088050; Sat, 25 Sep 2010 20:10:15 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 25 Sep 2010 20:10:15 -0600 (MDT) From: Warren Block To: Daniel Feenberg In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (wonkity.com [127.0.0.1]); Sat, 25 Sep 2010 20:10:15 -0600 (MDT) Cc: freebsd-net@freebsd.org, Alex Aminoff Subject: Re: Network booting FreeBSD with gpxelinx almost works 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, 26 Sep 2010 02:36:34 -0000 On Sat, 25 Sep 2010, Daniel Feenberg wrote: > We have been network booting FreeBSD for some time with pxeboot. So I am > confident that we have the dhcpd.conf and the root filesystem sufficient for > diskless booting. But now we would like to have menu of OSs to boot and got > the idea somewhere that gpxelinux could do that for us. We copied gpxelinux.0 > from the syslinux-4.02 distribution and replaced pxeboot with "gpxelinux" in > the dhcpd.conf file. Indeed with a configuration file in pxelinux.cfg like > this: > > default freebsd > label freebsd > PXE pxeboot > > and the root path still specified as a DHCP option, FreeBSD 8.1 does boot. If > I replace the first line with: > > UI menu.c32 > > the client does display the menu and but if one hits return to select the > single item offered the client merely hangs for a minute, then announces > "boot failure". I am guessing that once the UI is interposed, somehow the > root path isn't getting transmitted to pxeboot. 4.01 works, both with menu.c32 and vesamenu.c32. I can't say I've experimented much farther, but used it when writing this: http://www.wonkity.com/~wblock/docs/html/pxe.html > All the other gpxelinux boot kernels seem to expect the information > about the root filesystem to be specified in the pxelinux.cfg file, > rather than in dhcpd.conf. FreeBSD's pxeboot isn't as versatile as others. > Does anyone have experience with this? FreeBSD isn't mentioned > anywhere I can find in the syslinux or gpxelinux documentation, and > the various web posting I have found linking FreeBSD to gpxelinux are > all about do installations of iso files over the net. Yes, that's one of the reasons I wrote the article above. From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 06:45:02 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D024A106564A; Sun, 26 Sep 2010 06:45:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id AC71E8FC0A; Sun, 26 Sep 2010 06:45:02 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8Q6W4as030421; Sat, 25 Sep 2010 23:32:05 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 521AC2D6011; Sat, 25 Sep 2010 23:32:03 -0700 (PDT) Message-ID: <4C9EE905.5090701@freebsd.org> Date: Sat, 25 Sep 2010 23:32:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> In-Reply-To: <4C9DB0C3.5010601@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: FreeBSD Net Subject: Re: mbuf changes 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, 26 Sep 2010 06:45:02 -0000 On 9/25/10 1:20 AM, Andre Oppermann wrote: > On 25.09.2010 09:19, Julian Elischer wrote: >> over the last few years there has been a bit of talk about some >> changes people want to see in mbufs >> for 9.x >> extra fields, changes in the way things are done, etc. >> >> If you are one of these people, pipe up now.. >> >> to get the ball rolling.. >> >> * Add a field for the current FIB.. currently this is 4 bits stolen >> from the flags. >> what would be a good width: 8,12,16,24,32 bits? >> this would allow setfib to use numbers greater than 16 (the current >> max) > > 16 bits for 65535 FIB's should be sufficient. More than that seems > really > excessive. > >> * Preallocating some room for some number of tags before we start >> allocating >> (expensively) new ones. > > Within the mbuf? Or at external and attached mbuf allocation time? > Tags > are variable width and such not really suitable for pre-allocation. yes possibly within.. thre could be for example a reaserver 20 byte field and if it doesn't fit in that we go to expensive tags. I'm just waving my arms here. > >> * dynamically working out what the front padding size should be.. >> per session.. i.e. >> when a packet is sent out and needs to be adjusted to add more >> headers, the originating >> socket should be notified, or maybe the route should have this >> information... >> so that future packets can start out with enough head room. >> (this is not strictly to do with mbufs but might need some added >> field to point to the structure >> that needs to be >> updated. > > We already have "max_linkhdr" that specifies how much space is left > for prepends at the start of each packet. The link protocols set > this and also IPSec adds itself in there if enabled. If you have > other encapsulations you should make them add in there as well. this doesn't take into account tunneling and encapsulation. we could do a lot better than this. especially on a per-route basis. if the first mbuf in a session had a pointer to the relevent rtentry, then as it is processed that could be updated.. just an idea. From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 13:31:41 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94E32106564A for ; Sun, 26 Sep 2010 13:31:41 +0000 (UTC) (envelope-from blade_ly@yahoo.com.cn) Received: from web15008.mail.cnb.yahoo.com (web15008.mail.cnb.yahoo.com [202.165.103.65]) by mx1.freebsd.org (Postfix) with SMTP id AD33F8FC12 for ; Sun, 26 Sep 2010 13:31:40 +0000 (UTC) Received: (qmail 28533 invoked by uid 60001); 26 Sep 2010 13:04:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1285506299; bh=fSvy1qyaALbwU7dvDD56fQnoIV+muV2hig1uqoU04Zw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=gE2KvRjEDbCIjuTxIR8WKh3KWq/fdKJUhwYF4JQp6FYwKgQ+rW1dWxAX5n3t8BR+SKrbyMKcm0fMjr304l6XUJvdMbvsLuKObtJARfgZ9OtVTnVYnTV/FHhHfHE5cz16mPkAfOXy7y/anblALNM1fTLlhH5EXRYsCjw9Gdx66FY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FKxiSazwwa/oGlcg8DvU7QQBQp/0K1q0ZVY6qdEFDMVGVvlajhPFs5/i3EoWtkWt3vQk4bDGfcgF9RJ/cuweHS9jOIgzniH/EIkZlgJBRaYsFLHYcYRJEeU7awmBElbbS0CUeO4m8GiyZlr8qLow4UAVhip2Fa5LTZd+1SzaTV4=; Message-ID: <667141.28043.qm@web15008.mail.cnb.yahoo.com> X-YMail-OSG: SDqzvsIVM1nJbO7xY47A3LA8hXUZF9Yg.p_CpYm43yG9.L0 pX9rT5za0IwSsEF6IRcH28_q5xbqpnyR0mMOZJPl57G.TXUUSeHXlh3ChiPs Pfig9xL6rplZSx8TyKvadzn.ZqcFnyik1gskNkWwc.CP6kXDL.HO1Z9ldEW9 XBp4i4rNQ..oQvOPaFxFTsX1y_j.ZSdCBfBnkCdqJqMcBIH5LLZNTJD44X5S 4nQxvRW7XrHX2pgC6RYZ._WLt.rtkidG3MV39tOQ6bQ-- Received: from [115.197.39.205] by web15008.mail.cnb.yahoo.com via HTTP; Sun, 26 Sep 2010 21:04:59 CST X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.105.279950 Date: Sun, 26 Sep 2010 21:04:59 +0800 (CST) From: =?utf-8?B?572X6ZKw?= To: freebsd-net@freebsd.org In-Reply-To: <20100926120027.889B0106574B@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Help! m_copym panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 13:31:41 -0000 I use=C2=A0a 5.0 freebsd for our company's network device, but one day ther= e is a panic occur: "m_copym, length > size of mbuf chain", and it is can't reproduced. i found maybe this is a old problem, and have not close yet, so can you giv= e me some help? =C2=A0 i must modify this bug for our product, i can't work around this problem. =C2=A0 thanks=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 15:58:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77DFD106566C for ; Sun, 26 Sep 2010 15:58:26 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 090F48FC0C for ; Sun, 26 Sep 2010 15:58:25 +0000 (UTC) Received: by ewy22 with SMTP id 22so1269022ewy.13 for ; Sun, 26 Sep 2010 08:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=JgvzYMWTnFy6Fem3rbNQWF09+8W66CcOQICjIT+PVbA=; b=Lwmhfir5SKyb9Vxb9w5aVZdzk/aAGqTqN39mjuLeYV/rKj0APAjxRlG0ErwWO3a0tX lxlhNQKigHkDoK9nQm7XxyKWQ8dEwgn5ijCh2WAOY05YJZzI2+YIBI+nwYr8+LlcM0tc N6pTVKrDGtXOEstmXEl6qN+/z488KQVArJOHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; b=Skf66xP8UZycpDs4OkCnHWR7lh3OGomTeKW+H1Z2M/Tswds3rSRjvxnRnQAAasO/M9 TOyrmDDenV4Ob0atj8DrP5gnRi2L9NMXykVtZwBLCCEsAL3GlzoBFwJh1m+eBHObZv6m 49x1DVBxI9sIFm1vA65l9kJpjkl1MwLqAONsI= Received: by 10.213.43.80 with SMTP id v16mr2140078ebe.80.1285514994165; Sun, 26 Sep 2010 08:29:54 -0700 (PDT) Received: from localhost (vpn-193-138-133-219.customer.onet.com.ua [193.138.133.219]) by mx.google.com with ESMTPS id u9sm6834401eeh.11.2010.09.26.08.29.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Sep 2010 08:29:53 -0700 (PDT) From: Mikolaj Golub To: freebsd-net@freebsd.org Date: Sun, 26 Sep 2010 18:29:48 +0300 Message-ID: <86zkv4cykz.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Subject: ieee80211_crypto_tkip: panic: not enough data, data_len 2 space 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, 26 Sep 2010 15:58:26 -0000 Hi, Today I had the following panic on 8.1-STABLE #4. panic: not enough data, data_len 2 space 1 (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc04ed9c9 in db_fncall (dummy1=-1064377286, dummy2=0, dummy3=-1, dummy4=0xf808b4c8 "Ü´\bĝ") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04eddff in db_command (last_cmdp=0xc0e2005c, cmd_table=0x0, dopager=0) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04edeb4 in db_command_script (command=0xc0e20f64 "call doadump") at /usr/src/sys/ddb/db_command.c:516 #4 0xc04f2070 in db_script_exec (scriptname=0xf808b5d4 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available. ) at /usr/src/sys/ddb/db_script.c:302 #5 0xc04f2157 in db_script_kdbenter (eventname=0xc0cdbb4a "panic") at /usr/src/sys/ddb/db_script.c:324 #6 0xc04efe38 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228 #7 0xc08ee2b6 in kdb_trap (type=3, code=0, tf=0xf808b710) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xc0c0246b in trap (frame=0xf808b710) at /usr/src/sys/i386/i386/trap.c:690 #9 0xc0be31ec in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #10 0xc08ee43a in kdb_enter (why=0xc0cdbb4a "panic", msg=0xc0cdbb4a "panic") at cpufunc.h:71 #11 0xc08bdb16 in panic (fmt=0xc0cee385 "not enough data, data_len %zu space %u\n") at /usr/src/sys/kern/kern_shutdown.c:573 #12 0xc0994c04 in michael_mic (ctx=Variable "ctx" is not available. ) at /usr/src/sys/net80211/ieee80211_crypto_tkip.c:897 #13 0xc0994e04 in tkip_enmic (k=0xc8d440cc, m=0xc6ba2900, force=0) at /usr/src/sys/net80211/ieee80211_crypto_tkip.c:229 #14 0xc09b6d2d in ieee80211_encap (vap=0xc738e000, ni=0xc8d44000, m=Variable "m" is not available. ) at ieee80211_crypto.h:218 #15 0xc09b7b9e in ieee80211_start (ifp=0xc7ac8800) at /usr/src/sys/net80211/ieee80211_output.c:354 #16 0xc096b252 in if_start (ifp=0xc7ac8800) at /usr/src/sys/net/if.c:3345 #17 0xc096bf1f in if_transmit (ifp=0xc7ac8800, m=0xc8d75700) at /usr/src/sys/net/if.c:3357 #18 0xc0973b10 in ether_output_frame (ifp=0xc7ac8800, m=0xc8d75700) at /usr/src/sys/net/if_ethersubr.c:452 #19 0xc097462e in ether_output (ifp=0xc7ac8800, m=0xc8d75700, dst=0xc8ef71b0, ro=0xf808b9f4) at /usr/src/sys/net/if_ethersubr.c:423 #20 0xc09b7c6d in ieee80211_output (ifp=0xc7ac8800, m=0xc8d75700, dst=0xc8ef71b0, ro=0xf808b9f4) at /usr/src/sys/net80211/ieee80211_output.c:406 #21 0xc09deee9 in ip_output (m=0xc8d75700, opt=0x0, ro=0xf808b9f4, flags=Variable "flags" is not available. ) at /usr/src/sys/netinet/ip_output.c:634 #22 0xc0a43bc0 in tcp_output (tp=0xcae23000) at /usr/src/sys/netinet/tcp_output.c:1190 #23 0xc0a4f8be in tcp_usr_send (so=0xca44bb44, flags=0, m=0xc8aef100, nam=0x0, control=0x0, td=0xcbd8f000) at tcp_offload.h:282 #24 0xc0929fdd in sosend_generic (so=0xca44bb44, addr=0x0, uio=0xf808bc58, top=0xc8aef100, control=0x0, flags=0, td=0xcbd8f000) at /usr/src/sys/kern/uipc_socket.c:1260 #25 0xc092580f in sosend (so=0xca44bb44, addr=0x0, uio=0xf808bc58, top=0x0, control=0x0, flags=0, td=0xcbd8f000) at /usr/src/sys/kern/uipc_socket.c:1304 #26 0xc090b263 in soo_write (fp=0xc9ce80e0, uio=0xf808bc58, active_cred=0xc8f86300, flags=0, td=0xcbd8f000) at /usr/src/sys/kern/sys_socket.c:102 #27 0xc0904015 in dofilewrite (td=0xcbd8f000, fd=11, fp=0xc9ce80e0, auio=0xf808bc58, offset=-1, flags=0) at file.h:239 #28 0xc0905788 in kern_writev (td=0xcbd8f000, fd=11, auio=0xf808bc58) at /usr/src/sys/kern/sys_generic.c:446 #29 0xc090589f in write (td=0xcbd8f000, uap=0xf808bcf8) at /usr/src/sys/kern/sys_generic.c:362 #30 0xc0c01ba0 in syscall (frame=0xf808bd38) at /usr/src/sys/i386/i386/trap.c:1111 #31 0xc0be3281 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:264 #32 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) list 892 /* 893 * Catch degenerate cases like mbuf[4*n+1 bytes] followed by 894 * mbuf[2 bytes]. I don't believe these should happen; if they 895 * do then we'll need more involved logic. 896 */ 897 KASSERT(data_len <= space, 898 ("not enough data, data_len %zu space %u\n", data_len, space)); 899 900 /* Last block and padding (0x5a, 4..7 x 0) */ 901 switch (data_len) { (kgdb) p space $1 = 1 (kgdb) p data_len $2 = 2 (kgdb) p/x m->m_hdr $3 = { mh_next = 0xc8998300, mh_nextpkt = 0x0, mh_data = 0xc8af0818, mh_len = 0xb1, mh_flags = 0x0, mh_type = 0x1, pad = {0xad, 0xde} } (kgdb) p/x m->m_hdr->mh_next->m_hdr $4 = { mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc8998318, mh_len = 0x1, mh_flags = 0x0, mh_type = 0x1, pad = {0xad, 0xde} } So it looks like "degenerate" case happened? I had mbuf[4*44+1 bytes] followed by mbuf[1 byte]. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 20:55:46 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4111065698; Sun, 26 Sep 2010 20:55:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 343178FC68; Sun, 26 Sep 2010 20:55:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8QKtkGS095230; Sun, 26 Sep 2010 20:55:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8QKtkwP095226; Sun, 26 Sep 2010 20:55:46 GMT (envelope-from linimon) Date: Sun, 26 Sep 2010 20:55:46 GMT Message-Id: <201009262055.o8QKtkwP095226@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/150557: [igb] igb0: Watchdog timeout -- resetting 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, 26 Sep 2010 20:55:46 -0000 Synopsis: [igb] igb0: Watchdog timeout -- resetting Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 26 20:55:21 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150557 From owner-freebsd-net@FreeBSD.ORG Sun Sep 26 21:22:34 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C4A106566B; Sun, 26 Sep 2010 21:22:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE828FC14; Sun, 26 Sep 2010 21:22:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8QLMY4h028550; Sun, 26 Sep 2010 21:22:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8QLMYXr028546; Sun, 26 Sep 2010 21:22:34 GMT (envelope-from linimon) Date: Sun, 26 Sep 2010 21:22:34 GMT Message-Id: <201009262122.o8QLMYXr028546@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/150920: [ixgbe][igb] Panic when packets are dropped with header split disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 21:22:34 -0000 Synopsis: [ixgbe][igb] Panic when packets are dropped with header split disabled Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 26 21:21:59 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150920 From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 00:37:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CAA11065672 for ; Mon, 27 Sep 2010 00:37:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C54258FC14 for ; Mon, 27 Sep 2010 00:37:55 +0000 (UTC) Received: by iwn34 with SMTP id 34so5425200iwn.13 for ; Sun, 26 Sep 2010 17:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=m4mGW766mJyJW2ij0YdTO1r/cmf11r4/E1Ecd62k8RA=; b=vUEomxAUxR8hD1Q1eoEO1+xxitqMtKKdor8aSVvsudhD3hf09Re5mNZIBp2UQDsYjE dkwzHp1bPY5WOBzGLDqq/1n8cafU4PSKMB7HnQODoLz4km8tsci3HwpIZH6YfEKIfh29 AWipEPhi1Db7tKZoZSyFBDn/IdMBnDTsdl08o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ph8YP1z0KXo/D8gaoh2K2ljJw27a1IRHFRohRO4AcED97gaF+ClXFZUl1ApnAmaLrw c1M9UaFc/wRezjyJG/7Y78Q4xYEGr0VIdWhC7sE/fmPc8FH56sQsAFpWwmeIIGI9jdS7 FEHim5C0VCl9HcYcovL6biV7WaIGIahbdoHTU= MIME-Version: 1.0 Received: by 10.231.10.135 with SMTP id p7mr7233201ibp.88.1285547874450; Sun, 26 Sep 2010 17:37:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.156.206 with HTTP; Sun, 26 Sep 2010 17:37:54 -0700 (PDT) In-Reply-To: <667141.28043.qm@web15008.mail.cnb.yahoo.com> References: <20100926120027.889B0106574B@hub.freebsd.org> <667141.28043.qm@web15008.mail.cnb.yahoo.com> Date: Mon, 27 Sep 2010 08:37:54 +0800 X-Google-Sender-Auth: rRqf4Soa7E3lwt7U1QVdhuwFxMg Message-ID: From: Adrian Chadd To: =?GB2312?B?wt7u2g==?= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Help! m_copym panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 00:37:56 -0000 The best thing to do here is paste a kernel stack trace so people who may know about the 5.0 network stack can try to understand what condition(s) may lead to that situation. Adrian On 26 September 2010 21:04, =C2=DE=EE=DA wrote: > I use a 5.0 freebsd for our company's network device, but one day there i= s a panic occur: > "m_copym, length > size of mbuf chain", and it is can't reproduced. > i found maybe this is a old problem, and have not close yet, so can you g= ive me some help? > > i must modify this bug for our product, i can't work around this problem. > > thanks > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 08:12:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F73F1065670; Mon, 27 Sep 2010 08:12:20 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 36F5A8FC18; Mon, 27 Sep 2010 08:12:19 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 424591701D; Mon, 27 Sep 2010 12:12:18 +0400 (MSD) Date: Mon, 27 Sep 2010 12:12:18 +0400 From: Maxim Dounin To: Andre Oppermann Message-ID: <20100927081217.GM44164@mdounin.ru> References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100913172453.GG99657@mdounin.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, Igor Sysoev , Lawrence Stewart Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE 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, 27 Sep 2010 08:12:20 -0000 Hello! On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: [...] > Andre, could you please take a look at one more patch as well? > > Igor reported that it still sees 100ms delays with rfc3465 turned > on, and it turns out to be similar issue (setting cwnd to 1*MSS) > for hosts found in hostcache. > > The problem with setting cwnd from hostcache was already reported > here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 > http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html > > As using larger cwnd from hostcache may cause problems on > congested links (see second thread) I changed code to only use > cached cwnd as an upper bound for cwnd (instead of fixing current > code). This is also in-line with what we do on connection > restarts. > > We may later consider re-adding usage of larger cwnd from > hostcache. But I believe it should be done carefully and > probably behind sysctl, off by default. Ping. Maxim Dounin From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 08:53:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 742761065674 for ; Mon, 27 Sep 2010 08:53:25 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 30BE28FC26 for ; Mon, 27 Sep 2010 08:53:24 +0000 (UTC) Received: by qwd6 with SMTP id 6so3196461qwd.13 for ; Mon, 27 Sep 2010 01:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=woao0a14xAhHuEq9LDhc4J5uf7aTvN1h6/46cASbggM=; b=tQpi+nzKboLBxtpK6ErHYUGFxgfxUclc7KsDxRXa6cO4196yfRrydyKGsIHSKhwftv X0s+2Ba06+hD/U/vvjRCFJkrZTuctR41fhFc0zHvzKCZm3DpT0tmfNpohtT10lEE+5CS gcT7uvWEinpAWqT209PQw4wvgz9V4peB+vm0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F/d9IuPIh2zXlOKDy4nalW8umqQIi+ATUkLCiY0D8n0GyOkqWzv77CgF2Ru4usDPFi t8KWJ7Yf2uG8Ecld1uMmZ0XfcVEGQ9w+6phCpMbva6DKftjkVmeosa4kbaQgtBAa4nnO 4ayLQpb61imrAS5OMaJ3JXyUaO/7GfML2WzV4= MIME-Version: 1.0 Received: by 10.224.3.3 with SMTP id 3mr5217173qal.181.1285575980274; Mon, 27 Sep 2010 01:26:20 -0700 (PDT) Received: by 10.229.214.142 with HTTP; Mon, 27 Sep 2010 01:26:20 -0700 (PDT) Date: Mon, 27 Sep 2010 12:26:20 +0400 Message-ID: From: c0re To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: CARP as module 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, 27 Sep 2010 08:53:25 -0000 Hello freebsd-net! It was asked many times, but i'll bump it again. There was patch in 8.0 to allow CARP as module http://lists.freebsd.org/pipermail/freebsd-net/2009-April/021774.html But it was not committed... Any chances to see CARP as module in GENERIC? My interest is to use freebsd-update with CARP enabled systems. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 08:58:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65EF4106566B for ; Mon, 27 Sep 2010 08:58:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id EB5D38FC13 for ; Mon, 27 Sep 2010 08:58:18 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 70D8441C710; Mon, 27 Sep 2010 10:58:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id E6EpVygAK95z; Mon, 27 Sep 2010 10:58:16 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id BA84E41C733; Mon, 27 Sep 2010 10:58:16 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id BA2CE4448F3; Mon, 27 Sep 2010 08:58:08 +0000 (UTC) Date: Mon, 27 Sep 2010 08:58:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: c0re In-Reply-To: Message-ID: <20100927085711.M31898@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: CARP as module 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, 27 Sep 2010 08:58:19 -0000 On Mon, 27 Sep 2010, c0re wrote: Hey, > It was asked many times, but i'll bump it again. > There was patch in 8.0 to allow CARP as module > http://lists.freebsd.org/pipermail/freebsd-net/2009-April/021774.html > But it was not committed... > Any chances to see CARP as module in GENERIC? My interest is to use > freebsd-update with CARP enabled systems. HEAD and imho stable/8 and with that the upcoming 8.2-R and 9.0-R in whatever timeframe will have it. Not sure it made it to stable/7 if it will make it. /bz -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 11:06:59 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956B41065674 for ; Mon, 27 Sep 2010 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8353E8FC1A for ; Mon, 27 Sep 2010 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8RB6xCx023536 for ; Mon, 27 Sep 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8RB6wIk023533 for freebsd-net@FreeBSD.org; Mon, 27 Sep 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Sep 2010 11:06:58 GMT Message-Id: <201009271106.o8RB6wIk023533@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150257 net [msk] watchdog timeout o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149804 net [icmp] [panic] ICMP redirect on causes "panic: rtqkill o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 367 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 11:27:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E3D106566C for ; Mon, 27 Sep 2010 11:27:15 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx1.ukgrid.net (mx1.ukgrid.net [89.107.22.36]) by mx1.freebsd.org (Postfix) with ESMTP id EEBBA8FC13 for ; Mon, 27 Sep 2010 11:27:14 +0000 (UTC) Received: from [89.21.28.38] (port=12443 helo=omicron.ukgrid.net) by mx1.ukgrid.net with esmtp (Exim 4.72; FreeBSD) envelope-from a.smith@ukgrid.net id 1P0BrV-000Ds4-4P; Mon, 27 Sep 2010 12:27:13 +0100 Received: from voip.ukgrid.net (voip.ukgrid.net [89.107.16.9]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Mon, 27 Sep 2010 12:27:13 +0100 Message-ID: <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> Date: Mon, 27 Sep 2010 12:27:13 +0100 From: a.smith@ukgrid.net To: pyunyh@gmail.com References: <20100923154054.21153ulpaucsnocg@webmail2.ukgrid.net> <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> In-Reply-To: <20100924165452.GA19036@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) / FreeBSD-8.0 Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 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, 27 Sep 2010 11:27:15 -0000 Quoting Pyun YongHyeon : > > Order wouldn't be important but you have to apply both patches. > Hi, After successfully applying the patchs I get this error when doing a make: # make Warning: Object directory not changed from original /usr/src/sys/modules/bge @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -h awk -f @/tools/miidevs2h.awk @/dev/mii/miidevs awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/bge/../../dev/bge/if_bge.c /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function 'bge_newbuf_std': /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:954: error: 'struct bge_chain_data' has no member named 'bge_rx_std_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function 'bge_newbuf_jumbo': /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1012: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1013: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1014: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1015: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1029: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1034: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1039: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1044: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function 'bge_rxreuse_std': /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3271: error: 'struct bge_chain_data' has no member named 'bge_rx_std_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function 'bge_rxreuse_jumbo': /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3283: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3284: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3285: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3286: error: 'struct bge_chain_data' has no member named 'bge_rx_jumbo_seglen' *** Error code 1 Stop in /usr/src/sys/modules/bge. As mentioned, this is applying the two patches you provided to the source on my system running 7.3-RELEASE-p1. Any ideas? thanks Andy. From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 12:55:46 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8661065679 for ; Mon, 27 Sep 2010 12:55:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F9238FC0A for ; Mon, 27 Sep 2010 12:55:43 +0000 (UTC) Received: (qmail 81613 invoked from network); 27 Sep 2010 12:48:17 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Sep 2010 12:48:17 -0000 Message-ID: <4CA09451.7010401@freebsd.org> Date: Mon, 27 Sep 2010 14:55:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Luigi Rizzo References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <20100925163010.GA76213@onelab2.iet.unipi.it> In-Reply-To: <20100925163010.GA76213@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 12:55:46 -0000 On 25.09.2010 18:30, Luigi Rizzo wrote: > On Sat, Sep 25, 2010 at 10:20:19AM +0200, Andre Oppermann wrote: >> On 25.09.2010 09:19, Julian Elischer wrote: >>> over the last few years there has been a bit of talk about some changes >>> people want to see in mbufs >>> for 9.x >>> extra fields, changes in the way things are done, etc. >>> >>> If you are one of these people, pipe up now.. >>> >>> to get the ball rolling.. >>> >>> * Add a field for the current FIB.. currently this is 4 bits stolen from >>> the flags. >>> what would be a good width: 8,12,16,24,32 bits? >>> this would allow setfib to use numbers greater than 16 (the current max) >> >> 16 bits for 65535 FIB's should be sufficient. More than that seems really >> excessive. >> >>> * Preallocating some room for some number of tags before we start >>> allocating >>> (expensively) new ones. >> >> Within the mbuf? Or at external and attached mbuf allocation time? Tags >> are variable width and such not really suitable for pre-allocation. > > my idea was to have an extra field in the mbuf to tell how much room > should be reserved/used for metadata (such as mtags) after > the payload area so you don't need to change the allocator, and > possibly can even modify this on an existing mbuf. > Almost always mbufs have spare room (e.g. incoming pkts have all > data in the cluster and mostly empty mdata; outgoing, except > for rare cases, tend to be in a similar situation. > So this approach would allow to take an already allocated > mbuf and put the mtag in the spare area after the data. For incoming data this approach could work as usually 2K mbuf clusters are used and they have trailing space available, or rather the normal mbuf referencing the cluster doesn't have its own data section unused. When trailing space should be used the M_TAILINGSPACE() needs modifications and a full tree audit is required to make sure that all mbuf consumers are correctly using it and not some own version that directly assumes certain mbuf sizes, etc. A lot of work. For locally generated mbufs and socket buffers we try to use the mbufs to their maximal extent. When the socket buffer data is packetized it normally is referenced then we get the normal mbuf with its data portion unused. So that could work. A complication is the m_tag_free() field and function which puts the memory deallocation into the hands of the mtag user. That means all mtag consumers have to made aware of provided storage w/o having to return the memory directly to the memory allocator (malloc/UMA). So the only way I realistically see is to make use of the mbuf's unused data portion when it has external storage to it. This should probably cover about 98% of all cases. The rest has to malloc() the mtag storage as usual. I could whip up a prototype for review in the next weeks. >>> * dynamically working out what the front padding size should be.. per >>> session.. i.e. > ... >> We already have "max_linkhdr" that specifies how much space is left > > the issue is that this is global (kern.ipc.max_linkhdr) > but perhaps it would be good if we could make it per-socket > so either we set it with a setsockopt, or the system can > adjust back the value for specific sockets once it detects > that it needs extra room > (if you make the default too large, the useful room in the mdata > area becomes too small unless perhaps we move to 512-bytes mbufs For most protocols it is only necessary to leave enough space in the mbuf to fit their header. In the case of TCP this is currently 100 bytes. That leaves 156 bytes for the mbuf header and prepend space. TCP can easily be modified to allocate an mbuf cluster when the prepend space is too large. IIRC UDP already get this right. The setsockopt route is suboptimal because it requires the application know about all the encapsulation steps that may happen to its packets. A backcall to update the prepend value is also very difficult because it has to be implemented for every protocol. Taking into consideration that prepending and encapsulation is limited to some reasonable amount (you don't want to have half of your MTU sized packet to be additional encapsulation headers) I'd say the global max_linkhdr is sufficient. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 13:06:49 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 151A61065675; Mon, 27 Sep 2010 13:06:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id CD02E8FC20; Mon, 27 Sep 2010 13:06:48 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6EF97730A1; Mon, 27 Sep 2010 15:18:36 +0200 (CEST) Date: Mon, 27 Sep 2010 15:18:36 +0200 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20100927131836.GA99909@onelab2.iet.unipi.it> References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <20100925163010.GA76213@onelab2.iet.unipi.it> <4CA09451.7010401@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA09451.7010401@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 13:06:49 -0000 On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote: ... > >my idea was to have an extra field in the mbuf to tell how much room > >should be reserved/used for metadata (such as mtags) after > >the payload area so you don't need to change the allocator, and > >possibly can even modify this on an existing mbuf. > >Almost always mbufs have spare room (e.g. incoming pkts have all > >data in the cluster and mostly empty mdata; outgoing, except > >for rare cases, tend to be in a similar situation. > >So this approach would allow to take an already allocated > >mbuf and put the mtag in the spare area after the data. > > For incoming data this approach could work as usually 2K mbuf clusters > are used and they have trailing space available, or rather the normal > mbuf referencing the cluster doesn't have its own data section unused. > > When trailing space should be used the M_TAILINGSPACE() needs modifications > and a full tree audit is required to make sure that all mbuf consumers are > correctly using it and not some own version that directly assumes certain > mbuf sizes, etc. A lot of work. > > For locally generated mbufs and socket buffers we try to use the mbufs to > their maximal extent. When the socket buffer data is packetized it normally > is referenced then we get the normal mbuf with its data portion unused. So > that could work. > > A complication is the m_tag_free() field and function which puts the memory > deallocation into the hands of the mtag user. That means all mtag consumers > have to made aware of provided storage w/o having to return the memory > directly > to the memory allocator (malloc/UMA). > > So the only way I realistically see is to make use of the mbuf's unused > data portion when it has external storage to it. This should probably > cover about 98% of all cases. The rest has to malloc() the mtag storage > as usual. so it wouldn't be bad -- i cannot judge the numbers, but definitely it would work for all incoming traffic, plus all tcp data packets (as the payload is in the cluster), plus all pure acks (which are small), plus all UDP above some 200 bytes... > I could whip up a prototype for review in the next weeks. I seem to remember that jeffr had already something done in Perforce. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 13:09:37 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F9261065672 for ; Mon, 27 Sep 2010 13:09:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 83D8F8FC14 for ; Mon, 27 Sep 2010 13:09:36 +0000 (UTC) Received: (qmail 81732 invoked from network); 27 Sep 2010 13:02:09 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Sep 2010 13:02:09 -0000 Message-ID: <4CA09792.3070307@freebsd.org> Date: Mon, 27 Sep 2010 15:09:38 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Julian Elischer References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <4C9EE905.5090701@freebsd.org> In-Reply-To: <4C9EE905.5090701@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 13:09:37 -0000 On 26.09.2010 08:32, Julian Elischer wrote: > On 9/25/10 1:20 AM, Andre Oppermann wrote: >> On 25.09.2010 09:19, Julian Elischer wrote: >>> over the last few years there has been a bit of talk about some changes people want to see in mbufs >>> for 9.x >>> extra fields, changes in the way things are done, etc. >>> >>> If you are one of these people, pipe up now.. >>> >>> to get the ball rolling.. >>> >>> * Add a field for the current FIB.. currently this is 4 bits stolen from the flags. >>> what would be a good width: 8,12,16,24,32 bits? >>> this would allow setfib to use numbers greater than 16 (the current max) >> >> 16 bits for 65535 FIB's should be sufficient. More than that seems really >> excessive. >> >>> * Preallocating some room for some number of tags before we start allocating >>> (expensively) new ones. >> >> Within the mbuf? Or at external and attached mbuf allocation time? Tags >> are variable width and such not really suitable for pre-allocation. > > yes possibly within.. thre could be for example a reaserver 20 byte field and if it > doesn't fit in that we go to expensive tags. > I'm just waving my arms here. See my reply to Luigi for a detailed view on this. >>> * dynamically working out what the front padding size should be.. per session.. i.e. >>> when a packet is sent out and needs to be adjusted to add more headers, the originating >>> socket should be notified, or maybe the route should have this information... >>> so that future packets can start out with enough head room. >>> (this is not strictly to do with mbufs but might need some added field to point to the structure >>> that needs to be >>> updated. >> >> We already have "max_linkhdr" that specifies how much space is left >> for prepends at the start of each packet. The link protocols set >> this and also IPSec adds itself in there if enabled. If you have >> other encapsulations you should make them add in there as well. > > this doesn't take into account tunneling and encapsulation. It should/could but the tunneling and encapsulation protocols have to add themself to it when active. IPSec does this. > we could do a lot better than this. > especially on a per-route basis. > if the first mbuf in a session had a pointer to the relevent rtentry, > then as it is processed that could be updated.. Please please please don't add a rtentry pointer to the mbuf. Besides that the routing table is a very poor place to do this. We don't have host routes anymore and the locking and refcounting is rather expensive. max_linkhdr should be sufficient (fix small fixes to some protocol mbuf allocators) even for excessive cases of encapsulation: TCP over IPv4 over IPSec(AH+ESP) over UDP over IPv6 over PPPoE over Ethernet = 60 + 20 + (8+24) + 8 + 40 + 8 + 14 = 182 total, of which 102 are prepends. Maybe we need an API for the tunneling and encapsulation protocols to add their overhead to max_linkhdr. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 13:14:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC961065670 for ; Mon, 27 Sep 2010 13:14:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 131578FC14 for ; Mon, 27 Sep 2010 13:14:32 +0000 (UTC) Received: (qmail 81781 invoked from network); 27 Sep 2010 13:07:06 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Sep 2010 13:07:06 -0000 Message-ID: <4CA098BA.2010106@freebsd.org> Date: Mon, 27 Sep 2010 15:14:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Luigi Rizzo References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <20100925163010.GA76213@onelab2.iet.unipi.it> <4CA09451.7010401@freebsd.org> <20100927131836.GA99909@onelab2.iet.unipi.it> In-Reply-To: <20100927131836.GA99909@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 13:14:33 -0000 On 27.09.2010 15:18, Luigi Rizzo wrote: > On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote: > ... >>> my idea was to have an extra field in the mbuf to tell how much room >>> should be reserved/used for metadata (such as mtags) after >>> the payload area so you don't need to change the allocator, and >>> possibly can even modify this on an existing mbuf. >>> Almost always mbufs have spare room (e.g. incoming pkts have all >>> data in the cluster and mostly empty mdata; outgoing, except >>> for rare cases, tend to be in a similar situation. >>> So this approach would allow to take an already allocated >>> mbuf and put the mtag in the spare area after the data. >> >> For incoming data this approach could work as usually 2K mbuf clusters >> are used and they have trailing space available, or rather the normal >> mbuf referencing the cluster doesn't have its own data section unused. >> >> When trailing space should be used the M_TAILINGSPACE() needs modifications >> and a full tree audit is required to make sure that all mbuf consumers are >> correctly using it and not some own version that directly assumes certain >> mbuf sizes, etc. A lot of work. >> >> For locally generated mbufs and socket buffers we try to use the mbufs to >> their maximal extent. When the socket buffer data is packetized it normally >> is referenced then we get the normal mbuf with its data portion unused. So >> that could work. >> >> A complication is the m_tag_free() field and function which puts the memory >> deallocation into the hands of the mtag user. That means all mtag consumers >> have to made aware of provided storage w/o having to return the memory >> directly >> to the memory allocator (malloc/UMA). >> >> So the only way I realistically see is to make use of the mbuf's unused >> data portion when it has external storage to it. This should probably >> cover about 98% of all cases. The rest has to malloc() the mtag storage >> as usual. > > so it wouldn't be bad -- i cannot judge the numbers, but definitely > it would work for all incoming traffic, plus all tcp data packets > (as the payload is in the cluster), plus all pure acks (which are small), > plus all UDP above some 200 bytes... Yes, about that. >> I could whip up a prototype for review in the next weeks. > > I seem to remember that jeffr had already something done in Perforce. That's a more general overhaul of the way mbuf's are structured and allocated with UMA. I'm not sure it provides for the mtag issue. Will check though. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 13:17:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F8BC1065672 for ; Mon, 27 Sep 2010 13:17:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C2AEF8FC1B for ; Mon, 27 Sep 2010 13:17:58 +0000 (UTC) Received: (qmail 81818 invoked from network); 27 Sep 2010 13:10:30 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Sep 2010 13:10:30 -0000 Message-ID: <4CA09987.8020205@freebsd.org> Date: Mon, 27 Sep 2010 15:17:59 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Maxim Dounin References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> In-Reply-To: <20100927081217.GM44164@mdounin.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Igor Sysoev , Lawrence Stewart Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE 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, 27 Sep 2010 13:17:59 -0000 On 27.09.2010 10:12, Maxim Dounin wrote: > Hello! > > On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: > > [...] > >> Andre, could you please take a look at one more patch as well? >> >> Igor reported that it still sees 100ms delays with rfc3465 turned >> on, and it turns out to be similar issue (setting cwnd to 1*MSS) >> for hosts found in hostcache. >> >> The problem with setting cwnd from hostcache was already reported >> here: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 >> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html >> >> As using larger cwnd from hostcache may cause problems on >> congested links (see second thread) I changed code to only use >> cached cwnd as an upper bound for cwnd (instead of fixing current >> code). This is also in-line with what we do on connection >> restarts. >> >> We may later consider re-adding usage of larger cwnd from >> hostcache. But I believe it should be done carefully and >> probably behind sysctl, off by default. > > Ping. Thanks for the reminder. I'll disable priming CWND from hostcache. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 15:48:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E3FC106566B for ; Mon, 27 Sep 2010 15:48:31 +0000 (UTC) (envelope-from apauljoe@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5713A8FC1C for ; Mon, 27 Sep 2010 15:48:31 +0000 (UTC) Received: by qwd6 with SMTP id 6so3419686qwd.13 for ; Mon, 27 Sep 2010 08:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=mY053jZG+Qa4ZJVgNyT53fQtrbINSXmM8E9UUB8wRkM=; b=W05qPtsp3FBUX/rziTFO/H3WvnBfrzYPqhn3viiKBI/y1ljlV9CAdKOryWqg9w7bYH l9EOxK81nHnPFFlHM2G/usqonILNIp5Iw433b+GWxMKCpKPGK49Y1RW/wc+QmSf+cmPW cGMHdIa2FlZj2iMOsHsNncdGGyTuv2f8E7HSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=VMaQwLkFTloqG3voFZqXMfbwAgijAgrWMChY8w+IycfOFkIG1v6KSSDJJZ4I2S5sAB rMQhbyztsPXil3ItCA1qe4nHyaLHkg9vjLVvlMxyVhVIjFz+LiXmvbwqQfpbLT0fGkiA 5vECo18r3PhiX76IAkxd/tjeK/WC3l2U1Xxfw= MIME-Version: 1.0 Received: by 10.224.71.209 with SMTP id i17mr5683354qaj.282.1285600807549; Mon, 27 Sep 2010 08:20:07 -0700 (PDT) Received: by 10.229.26.8 with HTTP; Mon, 27 Sep 2010 08:20:07 -0700 (PDT) Date: Mon, 27 Sep 2010 20:50:07 +0530 Message-ID: From: Paul Joe To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=00c09f8a501e74fc4f04913f434e X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Luigi Rizzo Subject: Extending dummynet/ipfw 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, 27 Sep 2010 15:48:31 -0000 --00c09f8a501e74fc4f04913f434e Content-Type: text/plain; charset=ISO-8859-1 Hi, I have attached a patch which allows to do flow classifications in userland (e.g based on url categories, LDAP users) and do bandwidth control in kernel(dummynet). The patch has a) a setsocketopt, to associate a pipe to the socket. b) an ipfw option(sockarg) to redirect flows to corresponding pipe. Moreover, a member uint32_t is added to struct socket to hold the pipe info. I guess this structure is not part of kernel userland ABI. Please let me know your comments, which I would be glad to incorporate Thanks, Joe. --00c09f8a501e74fc4f04913f434e Content-Type: application/octet-stream; name=ipfwpatch Content-Disposition: attachment; filename=ipfwpatch Content-Transfer-Encoding: base64 X-Attachment-Id: f_gelhemj40 SW5kZXg6IHNiaW4vaXBmdy9pcGZ3Mi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMv c3JjL3NiaW4vaXBmdy9pcGZ3Mi5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE1OQpkaWZmIC1j IC11IC1yMS4xNTkgaXBmdzIuYwotLS0gc2Jpbi9pcGZ3L2lwZncyLmMJMTkgQXByIDIwMTAgMTY6 MzU6NDcgLTAwMDAJMS4xNTkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5jCTI3IFNlcCAyMDEwIDE0OjI1 OjQ3IC0wMDAwCkBAIC0yNjYsNiArMjY2LDcgQEAKIAl7ICJlc3RhYiIsCQlUT0tfRVNUQUIgfSwK IAl7ICJlc3RhYmxpc2hlZCIsCVRPS19FU1RBQiB9LAogCXsgInNldHVwIiwJCVRPS19TRVRVUCB9 LAorCXsgInNvY2thcmciLAkJVE9LX1NPQ0tBUkcgfSwKIAl7ICJ0Y3BkYXRhbGVuIiwJCVRPS19U Q1BEQVRBTEVOIH0sCiAJeyAidGNwZmxhZ3MiLAkJVE9LX1RDUEZMQUdTIH0sCiAJeyAidGNwZmxn cyIsCQlUT0tfVENQRkxBR1MgfSwKQEAgLTEzMzgsNiArMTMzOSw5IEBACiAJCQljYXNlIE9fRklC OgogCQkJCXByaW50ZigiIGZpYiAldSIsIGNtZC0+YXJnMSApOwogCQkJCWJyZWFrOworCQkJY2Fz ZSBPX1NPQ0tBUkc6CisJCQkJcHJpbnRmKCIgc29ja2FyZyIpOworCQkJCWJyZWFrOwogCiAJCQlj YXNlIE9fSU46CiAJCQkJcHJpbnRmKGNtZC0+bGVuICYgRl9OT1QgPyAiIG91dCIgOiAiIGluIik7 CkBAIC0zNTMxLDYgKzM1MzUsOSBAQAogCQkJZmlsbF9jbWQoY21kLCBPX0ZJQiwgMCwgc3RydG91 bCgqYXYsIE5VTEwsIDApKTsKIAkJCWF2Kys7CiAJCQlicmVhazsKKwkJY2FzZSBUT0tfU09DS0FS RzoKKwkJCWZpbGxfY21kKGNtZCwgT19TT0NLQVJHLCAwLCAwKTsKKwkJCWJyZWFrOwogCiAJCWNh c2UgVE9LX0xPT0tVUDogewogCQkJaXBmd19pbnNuX3UzMiAqYyA9IChpcGZ3X2luc25fdTMyICop Y21kOwpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUv bmN2cy9zcmMvc2Jpbi9pcGZ3L2lwZncyLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTMKZGlm ZiAtYyAtdSAtcjEuMTMgaXBmdzIuaAotLS0gc2Jpbi9pcGZ3L2lwZncyLmgJMTkgQXByIDIwMTAg MTU6MTE6NDUgLTAwMDAJMS4xMworKysgc2Jpbi9pcGZ3L2lwZncyLmgJMjcgU2VwIDIwMTAgMTQ6 MjU6NDcgLTAwMDAKQEAgLTE5OSw2ICsxOTksNyBAQAogCVRPS19GSUIsCiAJVE9LX1NFVEZJQiwK IAlUT0tfTE9PS1VQLAorCVRPS19TT0NLQVJHLAogfTsKIC8qCiAgKiB0aGUgZm9sbG93aW5nIG1h Y3JvIHJldHVybnMgYW4gZXJyb3IgbWVzc2FnZSBpZiB3ZSBydW4gb3V0IG9mCkluZGV4OiBzeXMv a2Vybi91aXBjX3NvY2tldC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5 cy9rZXJuL3VpcGNfc29ja2V0LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzUwCmRpZmYgLWMg LXUgLXIxLjM1MCB1aXBjX3NvY2tldC5jCi0tLSBzeXMva2Vybi91aXBjX3NvY2tldC5jCTE4IFNl cCAyMDEwIDExOjE4OjQyIC0wMDAwCTEuMzUwCisrKyBzeXMva2Vybi91aXBjX3NvY2tldC5jCTI3 IFNlcCAyMDEwIDE0OjI1OjUyIC0wMDAwCkBAIC0xMjMsNiArMTIzLDggQEAKICNpbmNsdWRlIDxz eXMvc29ja2V0dmFyLmg+CiAjaW5jbHVkZSA8c3lzL3Jlc291cmNldmFyLmg+CiAjaW5jbHVkZSA8 bmV0L3JvdXRlLmg+CisjaW5jbHVkZSA8bmV0aW5ldC9pbi5oPgorI2luY2x1ZGUgPG5ldGluZXQv aXBfdmFyLmg+CiAjaW5jbHVkZSA8c3lzL3NpZ25hbHZhci5oPgogI2luY2x1ZGUgPHN5cy9zdGF0 Lmg+CiAjaW5jbHVkZSA8c3lzL3N4Lmg+CkBAIC0yNDYxLDYgKzI0NjMsMjUgQEAKIAkJCQlzby0+ c29fZmlibnVtID0gMDsKIAkJCX0KIAkJCWJyZWFrOworCisJCWNhc2UgU09fVVNFUl9DT09LSUU6 CisJCQlpZihpcF9kbl9pb19wdHIgPT0gTlVMTCl7CisJCQkJZXJyb3IgPSBFTk9QUk9UT09QVDsK KwkJCQlnb3RvIGJhZDsKKwkJCX0KKworCQkJZXJyb3IgPSBzb29wdGNvcHlpbihzb3B0LCAmb3B0 dmFsLCBzaXplb2Ygb3B0dmFsLAorCQkJCQkJc2l6ZW9mIG9wdHZhbCk7CisJCQlpZiAob3B0dmFs IDwgMCB8fCBlcnJvciApeworCQkJCWVycm9yPSBFSU5WQUw7IAorCQkJCWdvdG8gYmFkOworCQkJ fQorCQorCQkJaWYoc28tPnNvX3Byb3RvLT5wcl9kb21haW4tPmRvbV9mYW1pbHkgPT0gUEZfSU5F VCkgCisJCQkJc28tPnNvX3VzZXJfY29va2llID0gKHVpbnQzMl90KW9wdHZhbDsKKwkJCQorCQkJ YnJlYWs7CisKIAkJY2FzZSBTT19TTkRCVUY6CiAJCWNhc2UgU09fUkNWQlVGOgogCQljYXNlIFNP X1NORExPV0FUOgpJbmRleDogc3lzL25ldGluZXQvaXBfZncuaAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxl OiAvaG9tZS9uY3ZzL3NyYy9zeXMvbmV0aW5ldC9pcF9mdy5oLHYKcmV0cmlldmluZyByZXZpc2lv biAxLjEzOApkaWZmIC1jIC11IC1yMS4xMzggaXBfZncuaAotLS0gc3lzL25ldGluZXQvaXBfZncu aAkxNSBNYXIgMjAxMCAxNzoxNDoyNyAtMDAwMAkxLjEzOAorKysgc3lzL25ldGluZXQvaXBfZncu aAkyNyBTZXAgMjAxMCAxNDoyNTo1MyAtMDAwMApAQCAtMTkyLDEwICsxOTIsMTMgQEAKIAogCU9f U0VURklCLAkJLyogYXJnMT1GSUIgbnVtYmVyICovCiAJT19GSUIsCQkJLyogYXJnMT1GSUIgZGVz aXJlZCBmaWIgbnVtYmVyICovCisJCisJT19TT0NLQVJHLAkJLyogc29ja2V0IGFyZ3VtZW50ICov CiAKIAlPX0xBU1RfT1BDT0RFCQkvKiBub3QgYW4gb3Bjb2RlIQkJKi8KIH07CiAKKwogLyoKICAq IFRoZSBleHRlbnNpb24gaGVhZGVyIGFyZSBmaWx0ZXJlZCBvbmx5IGZvciBwcmVzZW5jZSB1c2lu ZyBhIGJpdAogICogdmVjdG9yIHdpdGggYSBmbGFnIGZvciBlYWNoIGhlYWRlci4KSW5kZXg6IHN5 cy9uZXRpbmV0L2lwZncvaXBfZncyLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9z cmMvc3lzL25ldGluZXQvaXBmdy9pcF9mdzIuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS40NQpk aWZmIC1jIC11IC1yMS40NSBpcF9mdzIuYwotLS0gc3lzL25ldGluZXQvaXBmdy9pcF9mdzIuYwky NyBKdWwgMjAxMCAxNDoyNjozNCAtMDAwMAkxLjQ1CisrKyBzeXMvbmV0aW5ldC9pcGZ3L2lwX2Z3 Mi5jCTI3IFNlcCAyMDEwIDE0OjI1OjU2IC0wMDAwCkBAIC0xODAxLDYgKzE4MDEsMzkgQEAKIAkJ CQkJbWF0Y2ggPSAxOwogCQkJCWJyZWFrOwogCisJCQljYXNlIE9fU09DS0FSRzoJeworCQkJCXN0 cnVjdCBpbnBjYiAqaW5wID0gYXJncy0+aW5wOworCQkJCXN0cnVjdCBpbnBjYmluZm8gKnBpOwor CQkJCQorCQkJCWlmKGlzX2lwdjYpCisJCQkJCWJyZWFrOworCisJCQkJaWYocHJvdG8gPT0gSVBQ Uk9UT19UQ1ApCisJCQkJCXBpID0gJlZfdGNiaW5mbzsKKwkJCQllbHNlIGlmIChwcm90byA9PSBJ UFBST1RPX1VEUCkKKwkJCQkJcGkgPSAmVl91ZGJpbmZvOworCQkJCWVsc2UKKwkJCQkJYnJlYWs7 CisKKwkJCQkvKiBGb3IgaW5jb21taW5nIHBhY2tldCwgbG9va3VwIHVwIHRoZSAKKwkJCQlpbnBj YiB1c2luZyB0aGUgc3JjL2Rlc3QgaXAvcG9ydCB0dXBsZSAqLworCQkJCWlmKGlucCA9PSBOVUxM KSB7CisJCQkJCUlOUF9JTkZPX1JMT0NLKHBpKTsKKwkJCQkJaW5wID0gaW5fcGNibG9va3VwX2hh c2gocGksIAorCQkJCQkJc3JjX2lwLCBodG9ucyhzcmNfcG9ydCksCisJCQkJCQlkc3RfaXAsIGh0 b25zKGRzdF9wb3J0KSwKKwkJCQkJCTAsIE5VTEwpOworCQkJCQlJTlBfSU5GT19SVU5MT0NLKHBp KTsKKwkJCQl9CisJCQkJCisJCQkJaWYoaW5wICYmIGlucC0+aW5wX3NvY2tldCkgeworCQkJCQl0 YWJsZWFyZyA9IGlucC0+aW5wX3NvY2tldC0+c29fdXNlcl9jb29raWU7CisJCQkJCWlmKHRhYmxl YXJnKQorCQkJCQkJbWF0Y2ggPSAxOworCQkJCX0KKwkJCQlicmVhazsKKwkJCX0KKwogCQkJY2Fz ZSBPX1RBR0dFRDogewogCQkJCXN0cnVjdCBtX3RhZyAqbXRhZzsKIAkJCQl1aW50MzJfdCB0YWcg PSAoY21kLT5hcmcxID09IElQX0ZXX1RBQkxFQVJHKSA/CkluZGV4OiBzeXMvbmV0aW5ldC9pcGZ3 L2lwX2Z3X3NvY2tvcHQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv bmV0aW5ldC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNwpk aWZmIC1jIC11IC1yMS4xNyBpcF9md19zb2Nrb3B0LmMKLS0tIHN5cy9uZXRpbmV0L2lwZncvaXBf Zndfc29ja29wdC5jCTcgQXByIDIwMTAgMDg6MjM6NTggLTAwMDAJMS4xNworKysgc3lzL25ldGlu ZXQvaXBmdy9pcF9md19zb2Nrb3B0LmMJMjcgU2VwIDIwMTAgMTQ6MjU6NTggLTAwMDAKQEAgLTU3 Miw2ICs1NzIsNyBAQAogCQljYXNlIE9fSVBUT1M6CiAJCWNhc2UgT19JUFBSRUNFREVOQ0U6CiAJ CWNhc2UgT19JUFZFUjoKKwkJY2FzZSBPX1NPQ0tBUkc6CiAJCWNhc2UgT19UQ1BXSU46CiAJCWNh c2UgT19UQ1BGTEFHUzoKIAkJY2FzZSBPX1RDUE9QVFM6CkluZGV4OiBzeXMvc3lzL3NvY2tldC5o Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9zeXMvc29ja2V0Lmgsdgpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMTA1CmRpZmYgLWMgLXUgLXIxLjEwNSBzb2NrZXQuaAotLS0g c3lzL3N5cy9zb2NrZXQuaAk5IEphbiAyMDEwIDIzOjI0OjQ5IC0wMDAwCTEuMTA1CisrKyBzeXMv c3lzL3NvY2tldC5oCTI3IFNlcCAyMDEwIDE0OjI1OjU5IC0wMDAwCkBAIC0xMzcsNiArMTM3LDcg QEAKICNkZWZpbmUJU09fTElTVEVOUUxFTgkweDEwMTIJCS8qIHNvY2tldCdzIGNvbXBsZXRlIHF1 ZXVlIGxlbmd0aCAqLwogI2RlZmluZQlTT19MSVNURU5JTkNRTEVOCTB4MTAxMwkvKiBzb2NrZXQn cyBpbmNvbXBsZXRlIHF1ZXVlIGxlbmd0aCAqLwogI2RlZmluZQlTT19TRVRGSUIJMHgxMDE0CQkv KiB1c2UgdGhpcyBGSUIgdG8gcm91dGUgKi8KKyNkZWZpbmUJU09fVVNFUl9DT09LSUUJMHgxMDE1 CQkvKiB1c2UgdGhpcyBwaXBlIHRvIHRocm90dGxlICovCiAjZW5kaWYKIAogLyoKSW5kZXg6IHN5 cy9zeXMvc29ja2V0dmFyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lz L3N5cy9zb2NrZXR2YXIuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNzQKZGlmZiAtYyAtdSAt cjEuMTc0IHNvY2tldHZhci5oCi0tLSBzeXMvc3lzL3NvY2tldHZhci5oCTE4IFNlcCAyMDEwIDEx OjE4OjQyIC0wMDAwCTEuMTc0CisrKyBzeXMvc3lzL3NvY2tldHZhci5oCTI3IFNlcCAyMDEwIDE0 OjI1OjU5IC0wMDAwCkBAIC0xMTgsNiArMTE4LDcgQEAKIAkJY2hhcgkqc29fYWNjZXB0X2ZpbHRl cl9zdHI7CS8qIHNhdmVkIHVzZXIgYXJncyAqLwogCX0gKnNvX2FjY2Y7CiAJaW50IHNvX2ZpYm51 bTsJCS8qIHJvdXRpbmcgZG9tYWluIGZvciB0aGlzIHNvY2tldCAqLworCXVpbnQzMl90IHNvX3Vz ZXJfY29va2llOwogfTsKIAogLyoK --00c09f8a501e74fc4f04913f434e-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 15:55:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5B1B1065697 for ; Mon, 27 Sep 2010 15:55:45 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1temp.jnielsen.net (ns1temp.jnielsen.net [69.55.230.42]) by mx1.freebsd.org (Postfix) with ESMTP id 99AD58FC0A for ; Mon, 27 Sep 2010 15:55:45 +0000 (UTC) Received: from jnielsen.socialserve.com ([12.53.251.10]) (authenticated bits=0) by ns1temp.jnielsen.net (8.14.3/8.14.3) with ESMTP id o8RFth8u093392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Sep 2010 11:55:45 -0400 (EDT) (envelope-from lists@jnielsen.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Nielsen In-Reply-To: Date: Mon, 27 Sep 2010 11:55:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0A10F8F0-5BAB-4782-87CF-91E7661D805E@jnielsen.net> References: To: Paul Joe X-Mailer: Apple Mail (2.1081) X-DCC-x.dcc-servers-Metrics: ns1temp.jnielsen.net; whitelist X-Virus-Scanned: clamav-milter 0.96.3 at ns1temp.jnielsen.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Extending dummynet/ipfw 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, 27 Sep 2010 15:55:45 -0000 On Sep 27, 2010, at 11:20 AM, Paul Joe wrote: > I have attached a patch which allows to do flow classifications in = userland > (e.g based on url categories, LDAP users) > and do bandwidth control in kernel(dummynet). >=20 > The patch has >=20 > a) a setsocketopt, to associate a pipe to the socket. >=20 > b) an ipfw option(sockarg) to redirect flows to corresponding pipe. >=20 > Moreover, a member uint32_t is added to struct socket to hold the pipe = info. >=20 > I guess this structure is not part of kernel userland ABI. >=20 > Please let me know your comments, which I would be glad to incorporate This is something I have wished for in the past so I'm glad to see it. = I'd love to test it but I'm not sure what to do, especially on the = userland side. Could you post a simple ipfw ruleset that uses your patch = along with directions or a simple example program for doing the userland = classification? Thanks! JN From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 16:08:46 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15591065693; Mon, 27 Sep 2010 16:08:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-18.mx.aerioconnect.net [216.240.47.78]) by mx1.freebsd.org (Postfix) with ESMTP id CEAEB8FC16; Mon, 27 Sep 2010 16:08:46 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8RG8iOo028432; Mon, 27 Sep 2010 09:08:45 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C86BD2D6012; Mon, 27 Sep 2010 09:08:43 -0700 (PDT) Message-ID: <4CA0C1B5.2090309@freebsd.org> Date: Mon, 27 Sep 2010 09:09:25 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <20100925163010.GA76213@onelab2.iet.unipi.it> <4CA09451.7010401@freebsd.org> <20100927131836.GA99909@onelab2.iet.unipi.it> <4CA098BA.2010106@freebsd.org> In-Reply-To: <4CA098BA.2010106@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Jeff Roberson , Luigi Rizzo , FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 16:08:47 -0000 On 9/27/10 6:14 AM, Andre Oppermann wrote: > On 27.09.2010 15:18, Luigi Rizzo wrote: >> On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote: >> ... >>>> my idea was to have an extra field in the mbuf to tell how much room >>>> should be reserved/used for metadata (such as mtags) after >>>> the payload area so you don't need to change the allocator, and >>>> possibly can even modify this on an existing mbuf. >>>> Almost always mbufs have spare room (e.g. incoming pkts have all >>>> data in the cluster and mostly empty mdata; outgoing, except >>>> for rare cases, tend to be in a similar situation. >>>> So this approach would allow to take an already allocated >>>> mbuf and put the mtag in the spare area after the data. >>> >>> For incoming data this approach could work as usually 2K mbuf >>> clusters >>> are used and they have trailing space available, or rather the normal >>> mbuf referencing the cluster doesn't have its own data section >>> unused. >>> >>> When trailing space should be used the M_TAILINGSPACE() needs >>> modifications >>> and a full tree audit is required to make sure that all mbuf >>> consumers are >>> correctly using it and not some own version that directly assumes >>> certain >>> mbuf sizes, etc. A lot of work. >>> >>> For locally generated mbufs and socket buffers we try to use the >>> mbufs to >>> their maximal extent. When the socket buffer data is packetized >>> it normally >>> is referenced then we get the normal mbuf with its data portion >>> unused. So >>> that could work. >>> >>> A complication is the m_tag_free() field and function which puts >>> the memory >>> deallocation into the hands of the mtag user. That means all mtag >>> consumers >>> have to made aware of provided storage w/o having to return the >>> memory >>> directly >>> to the memory allocator (malloc/UMA). >>> >>> So the only way I realistically see is to make use of the mbuf's >>> unused >>> data portion when it has external storage to it. This should >>> probably >>> cover about 98% of all cases. The rest has to malloc() the mtag >>> storage >>> as usual. >> >> so it wouldn't be bad -- i cannot judge the numbers, but definitely >> it would work for all incoming traffic, plus all tcp data packets >> (as the payload is in the cluster), plus all pure acks (which are >> small), >> plus all UDP above some 200 bytes... > > Yes, about that. > >>> I could whip up a prototype for review in the next weeks. >> >> I seem to remember that jeffr had already something done in Perforce. > > That's a more general overhaul of the way mbuf's are structured and > allocated with UMA. I'm not sure it provides for the mtag issue. Will > check though. I'd like to see if we can go over his stuff and any other suggested changes before 9.0 and see if we can agree on a change for 9.0 Jeff, we discussed this a year ago.. do you still have your suggested changes? From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 16:12:44 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC3F106564A; Mon, 27 Sep 2010 16:12:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-18.mx.aerioconnect.net [216.240.47.78]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFD78FC08; Mon, 27 Sep 2010 16:12:44 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8RGChCQ029208; Mon, 27 Sep 2010 09:12:43 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 6B6122D6018; Mon, 27 Sep 2010 09:12:42 -0700 (PDT) Message-ID: <4CA0C2A3.7000508@freebsd.org> Date: Mon, 27 Sep 2010 09:13:23 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <4C9EE905.5090701@freebsd.org> <4CA09792.3070307@freebsd.org> In-Reply-To: <4CA09792.3070307@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 16:12:44 -0000 On 9/27/10 6:09 AM, Andre Oppermann wrote: > On 26.09.2010 08:32, Julian Elischer wrote: >> On 9/25/10 1:20 AM, Andre Oppermann wrote: >>> On 25.09.2010 09:19, Julian Elischer wrote: >>>> over the last few years there has been a bit of talk about some >>>> changes people want to see in mbufs >>>> for 9.x >>>> extra fields, changes in the way things are done, etc. >>>> >>>> If you are one of these people, pipe up now.. >>>> >>>> to get the ball rolling.. >>>> >>>> * Add a field for the current FIB.. currently this is 4 bits >>>> stolen from the flags. >>>> what would be a good width: 8,12,16,24,32 bits? >>>> this would allow setfib to use numbers greater than 16 (the >>>> current max) >>> >>> 16 bits for 65535 FIB's should be sufficient. More than that seems >>> really >>> excessive. >>> >>>> * Preallocating some room for some number of tags before we start >>>> allocating >>>> (expensively) new ones. >>> >>> Within the mbuf? Or at external and attached mbuf allocation time? >>> Tags >>> are variable width and such not really suitable for pre-allocation. >> >> yes possibly within.. thre could be for example a reaserver 20 byte >> field and if it >> doesn't fit in that we go to expensive tags. >> I'm just waving my arms here. > > See my reply to Luigi for a detailed view on this. > >>>> * dynamically working out what the front padding size should be.. >>>> per session.. i.e. >>>> when a packet is sent out and needs to be adjusted to add more >>>> headers, the originating >>>> socket should be notified, or maybe the route should have this >>>> information... >>>> so that future packets can start out with enough head room. >>>> (this is not strictly to do with mbufs but might need some added >>>> field to point to the structure >>>> that needs to be >>>> updated. >>> >>> We already have "max_linkhdr" that specifies how much space is left >>> for prepends at the start of each packet. The link protocols set >>> this and also IPSec adds itself in there if enabled. If you have >>> other encapsulations you should make them add in there as well. >> >> this doesn't take into account tunneling and encapsulation. > > It should/could but the tunneling and encapsulation protocols have to > add themself to it when active. IPSec does this. yes bit the troubel is that every packet is then given a worst -case reserved area at the front > >> we could do a lot better than this. >> especially on a per-route basis. >> if the first mbuf in a session had a pointer to the relevent rtentry, >> then as it is processed that could be updated.. > > Please please please don't add a rtentry pointer to the mbuf. Besides > that the routing table is a very poor place to do this. We don't have > host routes anymore and the locking and refcounting is rather > expensive. yes but we do have a route cache (and we probably should still have some form of host routes but that's a different issue not to be argued here.) > > max_linkhdr should be sufficient (fix small fixes to some protocol mbuf > allocators) even for excessive cases of encapsulation: max-linkhdr is way too big for 99% of all packets. > > TCP over IPv4 over IPSec(AH+ESP) over UDP over IPv6 over PPPoE over > Ethernet = > 60 + 20 + (8+24) + 8 + 40 + 8 + 14 = 182 total, of which 102 are > prepends. > > Maybe we need an API for the tunneling and encapsulation protocols to > add their overhead to max_linkhdr. > From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 16:52:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91CBF106564A for ; Mon, 27 Sep 2010 16:52:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E33D8FC18 for ; Mon, 27 Sep 2010 16:52:27 +0000 (UTC) Received: by pvc21 with SMTP id 21so1658284pvc.13 for ; Mon, 27 Sep 2010 09:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=EZzqLPg7K8fqOLsoIZWJ4yHnJjjsRhDmmfRjtI+lGk0=; b=i3Xe2fn8LhhHuZoKZTDTH8ewlID+yJoIVRa0Cuo7OsdStV0OMLG5MKNrsmnz4mfMtg gNHdchpIRdnWlEnLUcgt91xF6xjSJ3LMVvIZpkvxxETpl8wmBOpQZSIut9p4wyWAe5uP 5Qb+o2cDq5KzXuoVSgx+KT3meOIy/ADJ/4LDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=JPL5uwLst8kNaLU1LCD+jIsGkuiIDGEHbiheRNBDUaHkuiqKLrgIXIFKlbzPnmTebt emu6Fi+emmCXYMu1VtWDQ+hC5NhXN/nso1R9NeZE45KC6HkZekSDdm5P+gz6Abc/MdEp Y5ZegjR7WIa1SKnFwUb7r3OkvO+UdrmDV91SI= Received: by 10.142.106.9 with SMTP id e9mr6727378wfc.96.1285606346751; Mon, 27 Sep 2010 09:52:26 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v6sm7644081wfg.3.2010.09.27.09.52.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 09:52:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 27 Sep 2010 09:51:29 -0700 From: Pyun YongHyeon Date: Mon, 27 Sep 2010 09:51:29 -0700 To: a.smith@ukgrid.net Message-ID: <20100927165129.GA1435@michelle.cdnetworks.com> References: <20100923154054.21153ulpaucsnocg@webmail2.ukgrid.net> <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 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, 27 Sep 2010 16:52:27 -0000 On Mon, Sep 27, 2010 at 12:27:13PM +0100, a.smith@ukgrid.net wrote: > Quoting Pyun YongHyeon : > > > > >Order wouldn't be important but you have to apply both patches. > > > > Hi, > > After successfully applying the patchs I get this error when doing a make: > Oops, sorry. I forgot one more chunk. You need to apply this one in addition to two patches. http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/bge/if_bgereg.h?r1=202861&r2=208995&view=patch > # make > Warning: Object directory not changed from original /usr/src/sys/modules/bge > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -h > awk -f @/tools/miidevs2h.awk @/dev/mii/miidevs > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function > 'bge_newbuf_std': > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:954: error: 'struct > bge_chain_data' has no member named 'bge_rx_std_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function > 'bge_newbuf_jumbo': > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1012: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1013: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1014: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1015: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1029: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1034: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1039: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:1044: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function > 'bge_rxreuse_std': > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3271: error: 'struct > bge_chain_data' has no member named 'bge_rx_std_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c: In function > 'bge_rxreuse_jumbo': > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3283: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3284: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3285: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:3286: error: 'struct > bge_chain_data' has no member named 'bge_rx_jumbo_seglen' > *** Error code 1 > > Stop in /usr/src/sys/modules/bge. > > As mentioned, this is applying the two patches you provided to the > source on my system running 7.3-RELEASE-p1. > Any ideas? > > thanks Andy. > > > > From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 17:12:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5FC106564A for ; Mon, 27 Sep 2010 17:12:30 +0000 (UTC) (envelope-from apauljoe@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A3CF08FC15 for ; Mon, 27 Sep 2010 17:12:30 +0000 (UTC) Received: by gxk8 with SMTP id 8so1970830gxk.13 for ; Mon, 27 Sep 2010 10:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/2dP+qnuWMit9RfpQ/A7tF315cfqrRYnTw/nVrLYd2g=; b=mFpglaRBcqztJpEvaOTZM4Ebockv5wDpo2xgX5v0NBZ88NzLzAqKh/d8akjlGV2pr8 s/pvF2c0hAYHqctwNOK4adT/K1KxGz1Gt3c/tfV8KLUnu7+mqn4thQw8n36G4y9qatpd 0aOsrd5L8GkaJ3gkmJoUuHtr71jU1dsnO+pu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uBannAsyMHDyug7ZB2HdRkj6an+yZ915sIB1tvUmuqI2Jdjwoxu4N54QZeNd2stWhI cl2t84jBeDZv1g3Z2lhlZJtW4rGbcxg5QZqlEkrYP/qUM45nxjLGQl5o2BmVTC3ClxqW FCzp9hHI3MukUVRr+5H502gjHWf6o4K8IieVM= MIME-Version: 1.0 Received: by 10.150.161.9 with SMTP id j9mr9305200ybe.201.1285607549560; Mon, 27 Sep 2010 10:12:29 -0700 (PDT) Received: by 10.151.156.21 with HTTP; Mon, 27 Sep 2010 10:12:29 -0700 (PDT) In-Reply-To: <0A10F8F0-5BAB-4782-87CF-91E7661D805E@jnielsen.net> References: <0A10F8F0-5BAB-4782-87CF-91E7661D805E@jnielsen.net> Date: Mon, 27 Sep 2010 22:42:29 +0530 Message-ID: From: Paul Joe To: John Nielsen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Extending dummynet/ipfw 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, 27 Sep 2010 17:12:31 -0000 On Mon, Sep 27, 2010 at 9:25 PM, John Nielsen wrote: > On Sep 27, 2010, at 11:20 AM, Paul Joe wrote: > > > I have attached a patch which allows to do flow classifications in > userland > > (e.g based on url categories, LDAP users) > > and do bandwidth control in kernel(dummynet). > > > > The patch has > > > > a) a setsocketopt, to associate a pipe to the socket. > > > > b) an ipfw option(sockarg) to redirect flows to corresponding pipe. > > > > Moreover, a member uint32_t is added to struct socket to hold the pipe > info. > > > > I guess this structure is not part of kernel userland ABI. > > > > Please let me know your comments, which I would be glad to incorporate > > This is something I have wished for in the past so I'm glad to see it. I'd > love to test it but I'm not sure what to do, especially on the userland > side. Could you post a simple ipfw ruleset that uses your patch along with > directions or a simple example program for doing the userland > classification? > 1) Create some pipes using ipfw pipe command or directly using dummynet socket option. ipfw pipe 2 config bw 100KB/sec 2) Add the generic sockarg option to redirect the traffic to pipe associated with the socket. ipfw add 100 pipe tablearg ip from any to any sockarg out 3) A sample python program could be import socket client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # Make the traffic flow through pipe 2. You can use any userspace logic to select any pipe you created. # you can use SO_USER_COOKIE for 0x1015 after the patch is checked in rest = client_socket.setsockopt(socket.SOL_SOCKET, 0x1015, 2); client_socket.connect(("www.google.com",80)) s = "GET\r\n" print client_socket.send(s); r = client_socket.recv(512); print r Let me know if you face any issues in testing it. Thanks, Joe > Thanks! > > JN > > From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 17:22:28 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E36E1065674 for ; Mon, 27 Sep 2010 17:22:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 625318FC1C for ; Mon, 27 Sep 2010 17:22:27 +0000 (UTC) Received: (qmail 83555 invoked from network); 27 Sep 2010 17:14:58 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Sep 2010 17:14:58 -0000 Message-ID: <4CA0D2D5.6070801@freebsd.org> Date: Mon, 27 Sep 2010 19:22:29 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Julian Elischer References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <20100925163010.GA76213@onelab2.iet.unipi.it> <4CA09451.7010401@freebsd.org> <20100927131836.GA99909@onelab2.iet.unipi.it> <4CA098BA.2010106@freebsd.org> <4CA0C1B5.2090309@freebsd.org> In-Reply-To: <4CA0C1B5.2090309@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Luigi Rizzo , FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 17:22:28 -0000 On 27.09.2010 18:09, Julian Elischer wrote: > On 9/27/10 6:14 AM, Andre Oppermann wrote: >> On 27.09.2010 15:18, Luigi Rizzo wrote: >>> On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote: >>> ... >>>>> my idea was to have an extra field in the mbuf to tell how much room >>>>> should be reserved/used for metadata (such as mtags) after >>>>> the payload area so you don't need to change the allocator, and >>>>> possibly can even modify this on an existing mbuf. >>>>> Almost always mbufs have spare room (e.g. incoming pkts have all >>>>> data in the cluster and mostly empty mdata; outgoing, except >>>>> for rare cases, tend to be in a similar situation. >>>>> So this approach would allow to take an already allocated >>>>> mbuf and put the mtag in the spare area after the data. >>>> >>>> For incoming data this approach could work as usually 2K mbuf clusters >>>> are used and they have trailing space available, or rather the normal >>>> mbuf referencing the cluster doesn't have its own data section unused. >>>> >>>> When trailing space should be used the M_TAILINGSPACE() needs modifications >>>> and a full tree audit is required to make sure that all mbuf consumers are >>>> correctly using it and not some own version that directly assumes certain >>>> mbuf sizes, etc. A lot of work. >>>> >>>> For locally generated mbufs and socket buffers we try to use the mbufs to >>>> their maximal extent. When the socket buffer data is packetized it normally >>>> is referenced then we get the normal mbuf with its data portion unused. So >>>> that could work. >>>> >>>> A complication is the m_tag_free() field and function which puts the memory >>>> deallocation into the hands of the mtag user. That means all mtag consumers >>>> have to made aware of provided storage w/o having to return the memory >>>> directly >>>> to the memory allocator (malloc/UMA). >>>> >>>> So the only way I realistically see is to make use of the mbuf's unused >>>> data portion when it has external storage to it. This should probably >>>> cover about 98% of all cases. The rest has to malloc() the mtag storage >>>> as usual. >>> >>> so it wouldn't be bad -- i cannot judge the numbers, but definitely >>> it would work for all incoming traffic, plus all tcp data packets >>> (as the payload is in the cluster), plus all pure acks (which are small), >>> plus all UDP above some 200 bytes... >> >> Yes, about that. >> >>>> I could whip up a prototype for review in the next weeks. >>> >>> I seem to remember that jeffr had already something done in Perforce. >> >> That's a more general overhaul of the way mbuf's are structured and >> allocated with UMA. I'm not sure it provides for the mtag issue. Will >> check though. > > I'd like to see if we can go over his stuff and any other suggested changes before 9.0 > and see if we can agree on a change for 9.0 > > Jeff, we discussed this a year ago.. do you still have your suggested changes? In other recent communication Jeff indicated to revisit the mbuf/UMA situation at around end of this year. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 18:33:36 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C47201065670 for ; Mon, 27 Sep 2010 18:33:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC1B8FC1F for ; Mon, 27 Sep 2010 18:33:35 +0000 (UTC) Received: (qmail 84025 invoked from network); 27 Sep 2010 18:26:06 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Sep 2010 18:26:06 -0000 Message-ID: <4CA0E382.90101@freebsd.org> Date: Mon, 27 Sep 2010 20:33:38 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Julian Elischer References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> <4C9EE905.5090701@freebsd.org> <4CA09792.3070307@freebsd.org> <4CA0C2A3.7000508@freebsd.org> In-Reply-To: <4CA0C2A3.7000508@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: mbuf changes 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, 27 Sep 2010 18:33:36 -0000 On 27.09.2010 18:13, Julian Elischer wrote: > On 9/27/10 6:09 AM, Andre Oppermann wrote: >> On 26.09.2010 08:32, Julian Elischer wrote: >>> On 9/25/10 1:20 AM, Andre Oppermann wrote: >>>> On 25.09.2010 09:19, Julian Elischer wrote: >>>>> * dynamically working out what the front padding size should be.. per session.. i.e. >>>>> when a packet is sent out and needs to be adjusted to add more headers, the originating >>>>> socket should be notified, or maybe the route should have this information... >>>>> so that future packets can start out with enough head room. >>>>> (this is not strictly to do with mbufs but might need some added field to point to the structure >>>>> that needs to be >>>>> updated. >>>> >>>> We already have "max_linkhdr" that specifies how much space is left >>>> for prepends at the start of each packet. The link protocols set >>>> this and also IPSec adds itself in there if enabled. If you have >>>> other encapsulations you should make them add in there as well. >>> >>> this doesn't take into account tunneling and encapsulation. >> >> It should/could but the tunneling and encapsulation protocols have to >> add themself to it when active. IPSec does this. > > yes bit the troubel is that every packet is then given a worst -case reserved area at the front Yes, but so what? We've got the space in the mbuf anyway. Right now it lays unused at the end. See below for more detailed explanation. <----------mbuf----------> ppdddddddddd............ now pppppppppdddddddddd..... with large prepend area p = prepend d = data >>> we could do a lot better than this. >>> especially on a per-route basis. >>> if the first mbuf in a session had a pointer to the relevent rtentry, >>> then as it is processed that could be updated.. >> >> Please please please don't add a rtentry pointer to the mbuf. Besides >> that the routing table is a very poor place to do this. We don't have >> host routes anymore and the locking and refcounting is rather expensive. > > yes but we do have a route cache > (and we probably should still have some form of host routes but that's a > different issue not to be argued here.) We have the hostcache (which needs some revisiting). >> max_linkhdr should be sufficient (fix small fixes to some protocol mbuf >> allocators) even for excessive cases of encapsulation: > > max-linkhdr is way too big for 99% of all packets. That doesn't matter in practice. We have a very binary distribution for the packets and the space in the mbuf is there anyway. Today it's simply not used. We tend to have small packets (TCP ACK for example) and large packets at around MTU (bulk data transfer). For normal mbuf's (256 bytes) the header and lots of encapsulation fit. For mbuf clusters (2Kbytes) there is plenty of space too. For packets in between that currently may have fit into a normal mbuf we may have to switch to allocating a cluster earlier. That's no biggy though and doesn't happen too often, is not much overhead and only with excessive encapsulation. Unless you can demonstrate a realistic case where the encapsulation overhead with a large max_linkhdr is actually causing a measurable pessimization I'd say the complexity of adding a mechanism you propose is not justified. >> TCP over IPv4 over IPSec(AH+ESP) over UDP over IPv6 over PPPoE over Ethernet = >> 60 + 20 + (8+24) + 8 + 40 + 8 + 14 = 182 total, of which 102 are prepends. I forgot MPLS, add another 4 bytes. ;-) For 32bit machines (60 bytes mbuf headers) this fits just fine. For 64bit machines (84 bytes mbuf headers) it fits for TCP ACK just fine. >> Maybe we need an API for the tunneling and encapsulation protocols to >> add their overhead to max_linkhdr. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 19:30:11 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E630610656B4 for ; Mon, 27 Sep 2010 19:30:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BAB4E8FC13 for ; Mon, 27 Sep 2010 19:30:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8RJUBpO046784 for ; Mon, 27 Sep 2010 19:30:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8RJUBFP046776; Mon, 27 Sep 2010 19:30:11 GMT (envelope-from gnats) Date: Mon, 27 Sep 2010 19:30:11 GMT Message-Id: <201009271930.o8RJUBFP046776@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/149804: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 19:30:12 -0000 The following reply was made to PR kern/149804; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/149804: commit references a PR Date: Mon, 27 Sep 2010 19:27:05 +0000 (UTC) Author: delphij Date: Mon Sep 27 19:26:56 2010 New Revision: 213225 URL: http://svn.freebsd.org/changeset/base/213225 Log: Add a bandaid for a long-standing race condition during route entry un-expiring. The previous version of code have no locking when testing rt_refcnt. The result of the lack of locking may result in a condition where a routing entry have a reference count but at the same time have RTPRF_OURS bit set and an expiration timer. These would eventually lead to a panic: panic: rtqkill route really not free When the system have ICMP redirects accepted from local gateway in a moderate frequency, for instance. Commit this workaround for now until we have some better solution. PR: kern/149804 Reviewed by: bz Tested by: Zhao Xin, Pete French MFC after: 2 weeks Modified: head/sys/netinet/in_rmx.c head/sys/netinet6/in6_rmx.c Modified: head/sys/netinet/in_rmx.c ============================================================================== --- head/sys/netinet/in_rmx.c Mon Sep 27 19:03:18 2010 (r213224) +++ head/sys/netinet/in_rmx.c Mon Sep 27 19:26:56 2010 (r213225) @@ -121,12 +121,13 @@ in_matroute(void *v_arg, struct radix_no struct radix_node *rn = rn_match(v_arg, head); struct rtentry *rt = (struct rtentry *)rn; - /*XXX locking? */ - if (rt && rt->rt_refcnt == 0) { /* this is first reference */ + if (rt) { + RT_LOCK(rt); if (rt->rt_flags & RTPRF_OURS) { rt->rt_flags &= ~RTPRF_OURS; rt->rt_rmx.rmx_expire = 0; } + RT_UNLOCK(rt); } return rn; } Modified: head/sys/netinet6/in6_rmx.c ============================================================================== --- head/sys/netinet6/in6_rmx.c Mon Sep 27 19:03:18 2010 (r213224) +++ head/sys/netinet6/in6_rmx.c Mon Sep 27 19:26:56 2010 (r213225) @@ -193,11 +193,13 @@ in6_matroute(void *v_arg, struct radix_n struct radix_node *rn = rn_match(v_arg, head); struct rtentry *rt = (struct rtentry *)rn; - if (rt && rt->rt_refcnt == 0) { /* this is first reference */ + if (rt) { + RT_LOCK(rt); if (rt->rt_flags & RTPRF_OURS) { rt->rt_flags &= ~RTPRF_OURS; rt->rt_rmx.rmx_expire = 0; } + RT_UNLOCK(rt); } return rn; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 19:46:47 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62CB106564A for ; Mon, 27 Sep 2010 19:46:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-21.mx.aerioconnect.net [216.240.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id AB73B8FC18 for ; Mon, 27 Sep 2010 19:46:47 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8RJkkmL007766 for ; Mon, 27 Sep 2010 12:46:46 -0700 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 513322D6013 for ; Mon, 27 Sep 2010 12:46:45 -0700 (PDT) Message-ID: <4CA0F4CE.7020905@freebsd.org> Date: Mon, 27 Sep 2010 12:47:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: Fwd: Re: VIMAGE + NDIS 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, 27 Sep 2010 19:46:47 -0000 anyone here have NDIS experience? On 9/27/10 10:51 AM, Nikos Vassiliadis wrote: > Julian Elischer wrote: >>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at >>> /usr/src/sys/net/rtsock.c:1374 >>> 1374 if (V_loif) >>> (kgdb) list >>> 1369 } >>> 1370 *(unsigned short *)(tag + 1) = sa->sa_family; >>> 1371 m_tag_prepend(m, tag); >>> 1372 } >>> 1373 #ifdef VIMAGE >>> 1374 if (V_loif) >>> 1375 m->m_pkthdr.rcvif = V_loif; >>> 1376 else { >>> 1377 m_freem(m); >>> 1378 return; >>> (kgdb) >>> >> >> ok so probably there is a code-path to this point that does not first >> set up the current-vnet pointer before doing this. >> what you need to do is to produce a stack-trace so we can see how >> it got here, >> and then we can figure out where on that path we should set the >> pointer. > > Here it is: > (kgdb) #0 doadump () at pcpu.h:231 > #1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808, > dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0, > dopager=1) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04d4e0a in db_command_loop () at > /usr/src/sys/ddb/db_command.c:498 > #4 0xc04d6d0d in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:229 > #5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948) > at /usr/src/sys/kern/subr_kdb.c:535 > #6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24) > at /usr/src/sys/i386/i386/trap.c:929 > #7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24) > at /usr/src/sys/i386/i386/trap.c:851 > #8 0xc0c0bad5 in trap (frame=0xeef1d948) at > /usr/src/sys/i386/i386/trap.c:533 > #9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) > at /usr/src/sys/net/rtsock.c:1374 > #11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at > /usr/src/sys/net/rtsock.c:1168 > #12 0xc76704a1 in ?? () > #13 0xc6c3d400 in ?? () > #14 0xeef1daa8 in ?? () > #15 0xeef1daf4 in ?? () > #16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200) > at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105 > #17 0xc766d8a1 in ?? () > #18 0xc76b9200 in ?? () > #19 0xc76c0000 in ?? () > #20 0xc76f1000 in ?? () > #21 0xeef1dacc in ?? () > #22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #23 0x006c0000 in ?? () > #24 0xeef1dbb4 in ?? () > #25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #26 0xc76c0000 in ?? () > #27 0xc76c0000 in ?? () > #28 0xc7340800 in ?? () > #29 0xc086adcc in hardclock_cpu (usermode=7077888) > at /usr/src/sys/kern/kern_clock.c:447 whoa! hardclock interrupted itself? > #30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #31 0x006c0000 in ?? () > #32 0xeef1dbb4 in ?? () > #33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #34 0xc76c0000 in ?? () > #35 0xc76c0000 in ?? () > #36 0xc7340800 in ?? () hmmm maybe we need to get ndis to put in a wrapper at this point that is called form hardclock and sets the value before going further I'd have to look at the code to see what happens here.. *wonders who has their fingers in this code*.. > #37 0xc086adcc in hardclock_cpu (usermode=-949223424) > at /usr/src/sys/kern/kern_clock.c:447 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > and the panic, in case it helps: > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x18 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0978200 > stack pointer = 0x28:0xeef1d988 > frame pointer = 0x28:0xeef1d9a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1404 (Windows Workitem 3) > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > Physical memory: 2916 MB > Dumping 113 MB: 98 82 66 50 34 18 2 > > Thanks, Nikos > _______________________________________________ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 10:25:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC755106566C for ; Tue, 28 Sep 2010 10:25:21 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 84B388FC1C for ; Tue, 28 Sep 2010 10:25:21 +0000 (UTC) Received: by qyk7 with SMTP id 7so6339873qyk.13 for ; Tue, 28 Sep 2010 03:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=L66YIIqig/B7JDJ0tzW4rI7HjAOkXdNoeWK/PgPqaK8=; b=IwEJt3a9R9JRtGLxVFItVLn6BRk3uyJmv9Cq9ln9zwyZDzfECODl5bh9UPzuriNMZ1 yQSWuOsvZl0M1BguY4lHXmzBVHiPrCFfSAiev7S+p0+d3Dm91n3gm+ZU44PrId7JRN9N GU4d5J8Nx+Tv3cAx2jwbAm2UI2SIgN1Ypyofc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dT35C/pUt9xINICUmpve0NJyVH6qKqLoKewkwwVcZ5Lec9RAu6hQUGUfHkxxSjCKjz oSgnMh0Rii2cdM2PSG0WD0BL/UzYDyC8ccYtUrOOc3M0tvisYJaisyCR/SQ8zmpqadzo QlE/2+PxH3mvwTcVOI4bK7nA3m77/85pgCAuc= MIME-Version: 1.0 Received: by 10.220.157.139 with SMTP id b11mr2761840vcx.11.1285667933455; Tue, 28 Sep 2010 02:58:53 -0700 (PDT) Received: by 10.220.202.136 with HTTP; Tue, 28 Sep 2010 02:58:53 -0700 (PDT) Date: Tue, 28 Sep 2010 17:58:53 +0800 Message-ID: From: dave jones To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: UDP socket disconnect problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 10:25:21 -0000 Hello, In Linux, I can disconnect the socket using: sa.sin_family = AF_UNSPEC; val = connect(sockfd, (struct sockaddr *)&sa, sizeof(sa)); the return value of val is 0; on freebsd, the return value of connect() is -1. According to Linux's connect(2) man page: Connectionless sockets may dissolve the association by connecting to an address with the sa_family member of sockaddr set to AF_UNSPEC but FreeBSD's connect says: Datagram sockets may dissolve the association by connecting to an invalid address, such as a null address. I try to convert above code to memset(&sa, 0, sizeof(sa)); sa.sin_addr.s_addr = htonl(INADDR_ANY); val = connect(sockfd, (struct sockaddr *)&sa, sizeof(sa)); the return value of val still -1. Any idea? Thanks. Regards, Dave. From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 11:39:08 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE0F106564A; Tue, 28 Sep 2010 11:39:08 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB388FC14; Tue, 28 Sep 2010 11:39:08 +0000 (UTC) Received: by gxk8 with SMTP id 8so2323993gxk.13 for ; Tue, 28 Sep 2010 04:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KL/SgpmReN+lc0Gu+QU69tBFAIBG0VeaeQJzRXwLNfg=; b=PP9VAykFqLQrkdtjwXP0vranLNzOyCZPflyp3iBRx4hrgk3AUVe+HrjY45WluTUBHD TevpnIxYkz8MqtoC4bnMIv+vZ1xPwTKey9zc7772dNjBxlE9RaCC5oYda+bo/Qi541oO jdfhS5kuFwG73MwcGes3X8jLW7fgLYnFKHFzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K7rOVYfdGYY7pt5gE4n3DcdnN9hLj0GCo/2ziO5g82saijhBg7KJlRuagwHj3NDDDj ih9KQQMj819sQd54k7nYExXy+NLSs3KsXob2NUyjb6SsJon0RUbmRAu0IiQAiJOcD4Tz pjs4r2slhg4RaytQcSocc+FjK+in8GlZcSDw4= MIME-Version: 1.0 Received: by 10.151.83.5 with SMTP id k5mr10905062ybl.42.1285672203324; Tue, 28 Sep 2010 04:10:03 -0700 (PDT) Received: by 10.220.200.1 with HTTP; Tue, 28 Sep 2010 04:10:03 -0700 (PDT) In-Reply-To: <4CA0F4CE.7020905@freebsd.org> References: <4CA0F4CE.7020905@freebsd.org> Date: Tue, 28 Sep 2010 11:10:03 +0000 Message-ID: From: Paul B Mahol To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Re: Re: VIMAGE + NDIS 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, 28 Sep 2010 11:39:09 -0000 On 9/27/10, Julian Elischer wrote: > anyone here have NDIS experience? > > On 9/27/10 10:51 AM, Nikos Vassiliadis wrote: >> Julian Elischer wrote: >>>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at >>>> /usr/src/sys/net/rtsock.c:1374 >>>> 1374 if (V_loif) >>>> (kgdb) list >>>> 1369 } >>>> 1370 *(unsigned short *)(tag + 1) = sa->sa_family; >>>> 1371 m_tag_prepend(m, tag); >>>> 1372 } >>>> 1373 #ifdef VIMAGE >>>> 1374 if (V_loif) >>>> 1375 m->m_pkthdr.rcvif = V_loif; >>>> 1376 else { >>>> 1377 m_freem(m); >>>> 1378 return; >>>> (kgdb) >>>> >>> >>> ok so probably there is a code-path to this point that does not first >>> set up the current-vnet pointer before doing this. >>> what you need to do is to produce a stack-trace so we can see how >>> it got here, >>> and then we can figure out where on that path we should set the >>> pointer. >> >> Here it is: >> (kgdb) #0 doadump () at pcpu.h:231 >> #1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808, >> dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548 >> #2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0, >> dopager=1) >> at /usr/src/sys/ddb/db_command.c:445 >> #3 0xc04d4e0a in db_command_loop () at >> /usr/src/sys/ddb/db_command.c:498 >> #4 0xc04d6d0d in db_trap (type=12, code=0) at >> /usr/src/sys/ddb/db_main.c:229 >> #5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948) >> at /usr/src/sys/kern/subr_kdb.c:535 >> #6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24) >> at /usr/src/sys/i386/i386/trap.c:929 >> #7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24) >> at /usr/src/sys/i386/i386/trap.c:851 >> #8 0xc0c0bad5 in trap (frame=0xeef1d948) at >> /usr/src/sys/i386/i386/trap.c:533 >> #9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166 >> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) >> at /usr/src/sys/net/rtsock.c:1374 >> #11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at >> /usr/src/sys/net/rtsock.c:1168 >> #12 0xc76704a1 in ?? () >> #13 0xc6c3d400 in ?? () >> #14 0xeef1daa8 in ?? () >> #15 0xeef1daf4 in ?? () >> #16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200) >> at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105 >> #17 0xc766d8a1 in ?? () >> #18 0xc76b9200 in ?? () >> #19 0xc76c0000 in ?? () >> #20 0xc76f1000 in ?? () >> #21 0xeef1dacc in ?? () >> #22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () >> from /boot/modules/bcmwl5_sys.ko >> #23 0x006c0000 in ?? () >> #24 0xeef1dbb4 in ?? () >> #25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () >> from /boot/modules/bcmwl5_sys.ko >> #26 0xc76c0000 in ?? () >> #27 0xc76c0000 in ?? () >> #28 0xc7340800 in ?? () >> #29 0xc086adcc in hardclock_cpu (usermode=7077888) >> at /usr/src/sys/kern/kern_clock.c:447 > > > whoa! > hardclock interrupted itself? > >> #30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () >> from /boot/modules/bcmwl5_sys.ko >> #31 0x006c0000 in ?? () >> #32 0xeef1dbb4 in ?? () >> #33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () >> from /boot/modules/bcmwl5_sys.ko >> #34 0xc76c0000 in ?? () >> #35 0xc76c0000 in ?? () >> #36 0xc7340800 in ?? () > > hmmm maybe we need to get ndis to put in a wrapper at this point that > is called form hardclock and sets the value before going further > > I'd have to look at the code to see what happens here.. > > *wonders who has their fingers in this code*.. > >> #37 0xc086adcc in hardclock_cpu (usermode=-949223424) >> at /usr/src/sys/kern/kern_clock.c:447 >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> >> >> and the panic, in case it helps: >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x18 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0978200 >> stack pointer = 0x28:0xeef1d988 >> frame pointer = 0x28:0xeef1d9a0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 1404 (Windows Workitem 3) >> panic: from debugger >> cpuid = 1 >> KDB: stack backtrace: >> Physical memory: 2916 MB >> Dumping 113 MB: 98 82 66 50 34 18 2 >> >> Thanks, Nikos >> Please give more background information of this case. Personally I never tested VIMAGE. Note that, for unknown reason (must be bug from old days) if_ndis.c calls rt_ifmsg() on its own via NdisMIndicateStatusComplete(), and I see no point to do that. From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 12:24:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 540EA106564A for ; Tue, 28 Sep 2010 12:24:47 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx1.ukgrid.net (mx1.ukgrid.net [89.107.22.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1912F8FC13 for ; Tue, 28 Sep 2010 12:24:46 +0000 (UTC) Received: from [89.21.28.38] (port=11797 helo=omicron.ukgrid.net) by mx1.ukgrid.net with esmtp (Exim 4.72; FreeBSD) envelope-from a.smith@ukgrid.net id 1P0ZEj-0000ID-4W; Tue, 28 Sep 2010 13:24:45 +0100 Received: from voip.ukgrid.net (voip.ukgrid.net [89.107.16.9]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Tue, 28 Sep 2010 13:24:45 +0100 Message-ID: <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> Date: Tue, 28 Sep 2010 13:24:45 +0100 From: a.smith@ukgrid.net To: pyunyh@gmail.com References: <20100923154054.21153ulpaucsnocg@webmail2.ukgrid.net> <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> In-Reply-To: <20100927165129.GA1435@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) / FreeBSD-8.0 Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 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, 28 Sep 2010 12:24:47 -0000 Quoting Pyun YongHyeon : > Oops, sorry. I forgot one more chunk. You need to apply this one in > addition to two patches. > http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/bge/if_bgereg.h?r1=202861&r2=208995&view=patch > Hi, Ok I have installed the patches, and rebuilt the kernel. Unfortunately the errors persist, Sep 28 12:27:58 vcomm kernel: bge0: watchdog timeout -- resetting Sep 28 12:27:58 vcomm kernel: bge0: link state changed to DOWN Sep 28 12:28:00 vcomm kernel: bge0: link state changed to UP Although prior to the installation of the patch I tried to copy some backup files off the server via scp. Copying a large file ~2GB caused the network connection to drop and the copy to fail. Testing after applying the patch shows that this is now improved, I have ran a few copies without any problems... Where does that leave things? thanks Andy. From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 18:08:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54111106564A for ; Tue, 28 Sep 2010 18:08:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE7A8FC1D for ; Tue, 28 Sep 2010 18:08:26 +0000 (UTC) Received: by gxk8 with SMTP id 8so2492696gxk.13 for ; Tue, 28 Sep 2010 11:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qmCwzUz5VAUR1sJJQ97Ri01gFuQw2DPjHlEMtM5xj70=; b=fT/COwpUYT42UsH+aQ+1QQTSNbz/62TVRPsWmOFIP2kkw64Z5TFDMWp453ptXntxhb V6hrZdHJtZ5UTDI+9I/IRloN3w9BEk60RZuMJB+vq0hmhwnWzoWCqJ+UsvLsN6OCvLzm vYOcA1GAs2H+IHjeD0OhmD4ydBCZJAmgw6EbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=mQGkv7qlsnkKUHgGKa/FN0szwZYcwo0KbQt+2/vvWQ6SYGkEWHMwHuhQJYDzmfoQIM Bmkam+H2pw1rg7G/OkLyrXxbIpef43b8jMu2oX9NzddfulZBz5InqOVkVU58//tvuYpm Ed0YZuhTvTplRvwfIG9ukni3snGLWn2+6fIdw= MIME-Version: 1.0 Received: by 10.150.52.11 with SMTP id z11mr508444ybz.149.1285695583833; Tue, 28 Sep 2010 10:39:43 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.150.158.20 with HTTP; Tue, 28 Sep 2010 10:39:43 -0700 (PDT) Date: Tue, 28 Sep 2010 19:39:43 +0200 X-Google-Sender-Auth: 50houPhnTXGyhYeLaLPt8apOQf4 Message-ID: From: Attilio Rao To: freebsd-net@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 Cc: Ryan Stone , Ed Maste Subject: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 18:08:27 -0000 In the last weeks I worked for porting the netdump infrastructure to FreeBSD-CURRENT on the behalf of Sandvine Incorporated. Netdump is a framework that aims for handling kernel coredumps over the TCP/IP suite in order to dump to a separate machine than the running one. That may be used on an interesting number of cases involving disk-less workstations, disk driver debugging or embedded devices. GENERAL FRAMEWORK ARCHITECTURE Netdump is composed, right now, by an userland "server" and a kernel "client". The former is run on the target machine (where the dump will phisically happen) and it is responsible for receiving the packets containing coredumps frame and for correctly writing them on-disk. The latter is part of the kernel installed on the source machine (where the dump is initiated) and is responsible for building correctly UDP packets containing the coredump frames, pushing through the network interface and routing them appropriately. While the server may appear as, pretty much, a simple userland deamon dealing with UDP packets, the client imposes interesting problems as long as its activity is linked to handling kernel core dumping. More precisely, as long as the client is part of the dumping mechanism and the kernel may be in general panic conditions, netdump must ensure "robustness" of operations. That is partially achieved by reworking (and someway replicating) locally some UDP, ARP and IP operations, hardsetting some values (like the default gateway, the destination and the client address) and reducing further interactions with the kernel just to the network interface acitivities. More specifically, it implements a very basic UDP / IPv4 / ARP stack separate from the standard stack (since that may not be in a consistent state). It can dump to a server on the same LAN or via a router (correctly specifying the connection gateway). In order to receive packet on critical conditions, netdump polls the interface. Every network driver can implement hooks to be used by netdump independently by DEVICE_POLLING option, even if it is probabilly a good idea to share some code among them. The reference set of hooks is contained into "struct netdump_methods". And if_lem/if_em driver modifies may be set as reference for netdump hooks implementation. In order to work into an "up and running" system (meant as with all the devices in place) the netdump handler hooks as a pre-sync handler (differently from other dumping routines). It however suffers some problems typical of other dumping mechanism. For example, on DDB entering unlocked version of polling handler is used, in order to reduce the risk of deadlocks during inspections*. That reflects, among the netdump methods, the existence of 2 versions of polling hooks, where the "unlocked" is meant as reducing locking as much as possible. PATCH AND FURTHER WORK The patch is not totally complete and it is not intended to be committed in SVN yet. What I'm looking for now is more testing and review (in particular in terms of architecture) coverage by community. The server should be in realtively "committable" state, though, but I encourage its stress-testing. A manpage is provided along that should be very easy to understand how to use it. Things that can be further improved, as it is now, in the client, are: - Deciding if hardcoding of the kernel parameter is done properly. I personally don't like the sysctl usage and I would prefer an userland small utility used to testing and maybe add some tunables for enabling netdump early in the boot. You may have several opinions on this though. - VIMAGE and IPv6 support. - More drivers support. Right now only if_em (and if_lem) are converted to use netdump and can be used as a draft for other device drivers. if_ixgb should came along in the final, committing, version too. In general I think that all drivers supporting device polling could easilly support also netdump - Ideally dumpsys() in FreeBSD is too much disk-activity oriented. It should be made, instead, more neutral and more flexible to cope better with different interfaces. It is a quite a bit of work, however, and beyond the scope of netdump introduction (even if it could be beneficial for it) Netdump has been developed on a FreeBSD project branch located here: svn://svn.freebsd.org/base/projects/sv/ which could also forsee further informations about every single change. However, for your convenience, also a patch has been made public which is located here (against FreeBSD-CURRENT@213246): http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_0.diff In order to enable the client it is enough to add at your kernel config: options NETDUMP_CLIENT NETDUMP_CLIENT_DEBUG can be specified too in order to have further debuggin traces but I'd encourage to use them just for developing Netdump itself. TYPICAL USAGE This is a set of the available sysctls for netdump: # sysctl -d net.dump net.dump: netdump net.dump.enable: enable network dump net.dump.retries: times to retransmit lost packets net.dump.polls: times to poll NIC per retry net.dump.nic: NIC to dump on net.dump.gateway: dump default gateway net.dump.client: dump client And when compiled with the NETDUMP_CLIENT_DEBUG option: net.dump.serve# sysctl -d debug.netdump debug.netdump: Netdump debugging debug.netdump.crash: force crashingr: dump server A tipycal setup for netdump can be the following: Run the server on the receiving interface: # ifconfig em2 em2: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:28:b2:7a inet 10.135.14.118 netmask 0xfffffffc broadcast 10.135.14.119 media: Ethernet autoselect (1000baseT ) status: active # netdumpsrv -a 10.135.14.118 Listening on IP 10.135.14.118 Default: dumping on /var/crash/ While on the client: # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 10.128.0.0/10 10.135.12.113 UGS 18 149 em2 10.135.12.112/30 link#3 U 0 0 em2 127.0.0.1 link#5 UH 0 118 lo0 ... # ifconfig em2 em2: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:28:9f:b2 inet6 fe80::230:48ff:fe28:9fb2%em2 prefixlen 64 scopeid 0x3 inet 10.135.12.114 netmask 0xfffffffc broadcast 10.135.12.115 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active # sysctl net.dump.server=10.135.14.118 net.dump.server: 0.0.0.0 -> 10.135.14.118 # sysctl net.dump.client=10.135.12.114 net.dump.client: 0.0.0.0 -> 10.135.12.114 # sysctl net.dump.gateway=10.135.12.113 net.dump.gateway: 0.0.0.0 -> 10.135.12.113 # sysctl net.dump.nic=em2 net.dump.nic: none -> em2 # sysctl net.dump.enable=1 net.dump.enable: 0 -> 1 and at next dumping operation on client, it must netdump. Thanks, Attilio [* The dumping infrastructure in FreeBSD has several weaknesses that needs to be discussed and treacted separately] -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 18:30:46 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E9A10656A7 for ; Tue, 28 Sep 2010 18:30:46 +0000 (UTC) (envelope-from lasse@bitmand.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A21D48FC14 for ; Tue, 28 Sep 2010 18:30:45 +0000 (UTC) Received: by eyx24 with SMTP id 24so2249671eyx.13 for ; Tue, 28 Sep 2010 11:30:44 -0700 (PDT) Received: by 10.213.15.140 with SMTP id k12mr24642eba.15.1285698644375; Tue, 28 Sep 2010 11:30:44 -0700 (PDT) Received: from [10.13.37.105] (1905ds1-taa.0.fullrate.dk [90.184.133.165]) by mx.google.com with ESMTPS id z55sm10876036eeh.15.2010.09.28.11.30.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Sep 2010 11:30:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lasse Brandt In-Reply-To: <4264F18E-9A17-4272-90CD-C96F818EB2B2@nokia.com> Date: Tue, 28 Sep 2010 20:30:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A88C70B-E752-498A-853E-8F2D06C08381@bitmand.com> References: <6BE964C4-0838-4DA6-9278-12C620CA1EE1@bitmand.com> <20100924.004332.121072178.hrs@allbsd.org> <20100923160300.S31898@maildrop.int.zabbadoz.net> <4264F18E-9A17-4272-90CD-C96F818EB2B2@nokia.com> To: Lars Eggert X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: Default gateway on different net 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, 28 Sep 2010 18:30:46 -0000 Sorry for the late reply, On 24. Sep 2010, at 12:56 , Lars Eggert wrote: > This seems very complex. Have you simply tried: >=20 > ipv6_defaultrouter=3D"2a01:xxxx:xxxx:3180::1" > ipv6_ifconfig_re0=3D"2a01:xxxx:xxxx:3183::1 prefixlen 64" Yes - but you can't add a defaultroute to an ip not on the same subnet. If I had ie. 2a01:xxxx:xxxx:3180::2 on my interface re0, it would work = (I tried) - but the hosting provided wasn't very happy with me just = picking a $random ip from their subnet ;) Best regards, Lasse Brandt= From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 21:45:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E9DD106566C for ; Tue, 28 Sep 2010 21:45:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2AAAB8FC1E for ; Tue, 28 Sep 2010 21:45:37 +0000 (UTC) Received: by iwn34 with SMTP id 34so189968iwn.13 for ; Tue, 28 Sep 2010 14:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=bnlLyQdghBK1/wW3JMOr5SS68uVYVJTNPOMnz/8fxJQ=; b=qgiXPt8O9oPwbR+6EooqVykU/24saTPl2Ijh5BMbdD68weg+x6OEJH799mrazeHsQT LpBQYXJtIkKBnhV6HLfLiowe4c877EJ0EGDP1IdmQsC0HeC4C1JFYYiVrTM92Vlyx6Os efSkdLG2q51dpQ3XJoVOqGaSlBmNBVSQB41SE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=IdYd5drBT30eXBblz79mHcrRAqdLzBvRDM0IH4IVzaWFR2rX0vupyjY+G/1htym2AS dNH01Yxb674EPHJAfTs2KPlEruIMm5/t970zZNfZBhPc6l1lswjf0RlyRuoKZWTka6X2 6qRTS5icLphHl5TxVaRI3HS04a6p8Gmxte6sc= Received: by 10.231.35.135 with SMTP id p7mr628638ibd.73.1285710337375; Tue, 28 Sep 2010 14:45:37 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r3sm8045939ibk.19.2010.09.28.14.45.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Sep 2010 14:45:33 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 28 Sep 2010 14:44:38 -0700 From: Pyun YongHyeon Date: Tue, 28 Sep 2010 14:44:38 -0700 To: a.smith@ukgrid.net Message-ID: <20100928214438.GC1252@michelle.cdnetworks.com> References: <20100923154054.21153ulpaucsnocg@webmail2.ukgrid.net> <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 21:45:38 -0000 On Tue, Sep 28, 2010 at 01:24:45PM +0100, a.smith@ukgrid.net wrote: > Quoting Pyun YongHyeon : > > >Oops, sorry. I forgot one more chunk. You need to apply this one in > >addition to two patches. > >http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/bge/if_bgereg.h?r1=202861&r2=208995&view=patch > > > > Hi, > > Ok I have installed the patches, and rebuilt the kernel. > Unfortunately the errors persist, > > > Sep 28 12:27:58 vcomm kernel: bge0: watchdog timeout -- resetting > Sep 28 12:27:58 vcomm kernel: bge0: link state changed to DOWN > Sep 28 12:28:00 vcomm kernel: bge0: link state changed to UP > > Although prior to the installation of the patch I tried to copy some > backup files off the server via scp. Copying a large file ~2GB caused > the network connection to drop and the copy to fail. Testing after > applying the patch shows that this is now improved, I have ran a few > copies without any problems... > > Where does that leave things? > Ok thanks for testing. It seems you have another issue which is not correctly handled in bge(4). I'm not sure you're actually seeing an errata of controller but could you try patch at the following URL? http://freefall.freebsd.org/~yongari/bge/bge.7.3R.post.diff The patch includes all patches I suggested so please back out previous patches before applying it. The patch was written to get better RX performance under high network load and it also includes a fix for a known hardware errata. But it's highly experimental and it's not for non-MSI bge(4) controllers because the patch may trigger other locking issues due to highly increased RX BD updates ratio in firmware for controllers that use shared interrupt. It seems your controller uses MSI so you don't have to worry about the issue. However don't apply the patch to production box. From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 22:08:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC2D1106566C for ; Tue, 28 Sep 2010 22:08:25 +0000 (UTC) (envelope-from a.smith@ukgrid.net) Received: from mx1.ukgrid.net (mx1.ukgrid.net [89.107.22.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7DEA58FC0C for ; Tue, 28 Sep 2010 22:08:25 +0000 (UTC) Received: from [89.21.28.38] (port=27031 helo=omicron.ukgrid.net) by mx1.ukgrid.net with esmtp (Exim 4.72; FreeBSD) envelope-from a.smith@ukgrid.net id 1P0iLY-000KB1-4r; Tue, 28 Sep 2010 23:08:24 +0100 Received: from voip.ukgrid.net (voip.ukgrid.net [89.107.16.9]) by webmail2.ukgrid.net (Horde Framework) with HTTP; Tue, 28 Sep 2010 23:08:24 +0100 Message-ID: <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> Date: Tue, 28 Sep 2010 23:08:24 +0100 From: a.smith@ukgrid.net To: pyunyh@gmail.com References: <20100923154054.21153ulpaucsnocg@webmail2.ukgrid.net> <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> In-Reply-To: <20100928214438.GC1252@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) / FreeBSD-8.0 Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 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, 28 Sep 2010 22:08:25 -0000 Quoting Pyun YongHyeon : > However don't apply the patch to production box. > Hi, actually the only server of this type is a production box, it was originally running FreeBSD 7.2 without issue but was upgraded when 7.2 went EOL. What would you recommend? I guess I can wait for this to be tested by someone else as it doesnt seem to be causing and severe issues. The server in question is running wordpress-mu and I havent had any complaints from end users about this, thanks Andy. From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 22:26:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D6B1065693 for ; Tue, 28 Sep 2010 22:26:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id EE0348FC19 for ; Tue, 28 Sep 2010 22:26:28 +0000 (UTC) Received: by pxi17 with SMTP id 17so47247pxi.13 for ; Tue, 28 Sep 2010 15:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=GO1AouX8HYrYzwrl2sCSbf5Kd46GhrrNae1wmzM6+eI=; b=T5SMz0TRjnIbSeXTf3dxxm35acZWUh9JOG6Y4aWVovEZtAqVRQW20nzPaibq5X41xS 4Cv6NcLlhNT8cGSbw0V+t3L6Tsov0nALXKksHHdViIb+fZVaWuOXBroY2DYK9yojPeNe 2A6LU7Z4ACMMaoZYuIE8iP+39MPwQ7o4JhbcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=NIkiZdeTp/DNjshUiNuynzd9Y129mLvN7DXLDhU6QZSenIONUITl/Q/rNhCgxTvKc7 w/MfkjHjtIYsqngDu0nrFbEsmicDVc9UQjzKCLBmoBIb01PmQCUQvWvDeFp6OA9yZ4SD JeeFRCuGWHWdOSOOZuMlaTayQdANlghK9wMLA= Received: by 10.114.131.6 with SMTP id e6mr867435wad.20.1285712788456; Tue, 28 Sep 2010 15:26:28 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r37sm13303476wak.23.2010.09.28.15.26.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Sep 2010 15:26:26 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 28 Sep 2010 15:25:32 -0700 From: Pyun YongHyeon Date: Tue, 28 Sep 2010 15:25:32 -0700 To: a.smith@ukgrid.net Message-ID: <20100928222532.GD1252@michelle.cdnetworks.com> References: <20100923154054.21153ulpaucsnocg@webmail2.ukgrid.net> <20100924021115.GI15014@michelle.cdnetworks.com> <20100924123938.80702gxrzyfpury0@webmail2.ukgrid.net> <20100924165452.GA19036@michelle.cdnetworks.com> <20100927122713.12822br1odth4sro@webmail2.ukgrid.net> <20100927165129.GA1435@michelle.cdnetworks.com> <20100928132445.72052m5iw9f41ns4@webmail2.ukgrid.net> <20100928214438.GC1252@michelle.cdnetworks.com> <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100928230824.10533d7gmmba360w@webmail2.ukgrid.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge watchdog timeout errors FreeBSD 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 22:26:29 -0000 On Tue, Sep 28, 2010 at 11:08:24PM +0100, a.smith@ukgrid.net wrote: > Quoting Pyun YongHyeon : > > > However don't apply the patch to production box. > > > > Hi, > > actually the only server of this type is a production box, it was > originally running FreeBSD 7.2 without issue but was upgraded when 7.2 > went EOL. > What would you recommend? I guess I can wait for this to be tested by I don't think it would cause severe problem with the patch but it was not heavily tested under various network load so this is the main reason why I took precaution against applying it on production box. If you're prepared to go back to old working kernel and it's tolerable for small down time you may go that route. > someone else as it doesnt seem to be causing and severe issues. The As I said, the patch requires another patch that handles shared interrupt with tagged status. I also have initial patch for that but it needs more polishing and cleanups. Lack of controller that has this issue also makes it hard to write patch. Your controller has no such issue so I wanted to know whether you're seeing known hardware errata or not. > server in question is running wordpress-mu and I havent had any > complaints from end users about this, > > thanks Andy. > > > > From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 22:27:01 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADDE61065696 for ; Tue, 28 Sep 2010 22:27:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 542258FC1D for ; Tue, 28 Sep 2010 22:27:00 +0000 (UTC) Received: (qmail 16908 invoked by uid 399); 28 Sep 2010 22:27:00 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 28 Sep 2010 22:27:00 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA26BB7.2090907@FreeBSD.org> Date: Tue, 28 Sep 2010 15:27:03 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20100923.053236.231630719.hrs@allbsd.org> In-Reply-To: <20100923.053236.231630719.hrs@allbsd.org> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(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: Tue, 28 Sep 2010 22:27:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 9/22/2010 1:32 PM, Hiroki Sato wrote: | Hello, | | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? Well I don't want to be "Mr. Negativity," but I'd like to suggest that adding this support is the wrong way to go. STF and teredo are transition mechanisms, and we're currently knee-deep (well maybe ankle-deep) in the deployment of IPv6. This is only going to pick up steam in the next few years given the impending run-out of the free /8s in the IANA pool. In my opinion we'd be much better off focusing on making our native IPv6 stack more robust rather than adding more transition protocols that will (with any kind of luck) be obsolete within the useful life of the 9.x branch. For example I seem to recall you identifying a performance penalty with the IPv6 loopback device vs. the IPv4 version. Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) iQEcBAEBCAAGBQJMomu3AAoJEFzGhvEaGryE1hsH/iWx2smE8VC3akxNM8K8aCo5 ikGeSdpxRUVeu7Uz+fZ8RAIDkSPiD7qIIpGDFNJfur7KjojLJWS4twLCsXqmAQ62 kY4FsyWzogfYv+CnX1X7dmmYt7g1fNS3tzwq8cGS7HaQ74lP42W5dZBuqU8o9V2C 9Oq77LsmDNNnGYvpa9v/NgGxen6sm/ENC6Xb6cQ/5APd9inZqlJFjPwVQLvEFhf5 oI6GrP/jCprmhx7hDrnJ/OKvKp8+hxkzjRczRJ93ZYWWHvTSIhjkOaeCnTSwGmEa aFmdOVX+h3Y2rziNvrBhhzaDproGZXiyGUiZ/Lak/lypgbdpB7N3FO05p3hSaT8= =UjVm -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 05:56:12 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C6E41065679; Wed, 29 Sep 2010 05:56:12 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 01EFB8FC16; Wed, 29 Sep 2010 05:56:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8T5uBSt029532; Wed, 29 Sep 2010 05:56:11 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8T5uBht029528; Wed, 29 Sep 2010 05:56:11 GMT (envelope-from delphij) Date: Wed, 29 Sep 2010 05:56:11 GMT Message-Id: <201009290556.o8T5uBht029528@freefall.freebsd.org> To: petefrench@ticketswitch.com, delphij@FreeBSD.org, freebsd-net@FreeBSD.org, delphij@FreeBSD.org From: delphij@FreeBSD.org Cc: Subject: Re: kern/149804: [icmp] [panic] ICMP redirect on causes "panic: rtqkill route really not free" 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, 29 Sep 2010 05:56:12 -0000 Synopsis: [icmp] [panic] ICMP redirect on causes "panic: rtqkill route really not free" State-Changed-From-To: open->patched State-Changed-By: delphij State-Changed-When: Wed Sep 29 05:55:38 UTC 2010 State-Changed-Why: A bandaid have been committed against -HEAD. Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Wed Sep 29 05:55:38 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=149804 From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 08:50:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DE861065695 for ; Wed, 29 Sep 2010 08:50:58 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2595A8FC27 for ; Wed, 29 Sep 2010 08:50:57 +0000 (UTC) Received: by qyk7 with SMTP id 7so948236qyk.13 for ; Wed, 29 Sep 2010 01:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=r0mq1Ep7QBUjnbRTStJF8pxeksUC1tELp2UOBIhCu80=; b=wkzEfEeotMzuXC3Y4dyts3eTk3w2hgxrZ+1f7D/6S+WOlj+lE4lCygowpxCHaJR3yO lt9FGqd6ke116276CKfMMIm4cU944QzRDqFNcAKEYdgwRbeV4JO2Ll0WXJWOX4/AddcI jDMpjQTbUTUKlafiqa60hdYHOlbnkvAKswow4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xXOAxu0dRSZw7zinGg5cPY6yQOApCxmYIhg2SQfnA5Jk0DSiGGyc1TZRD4e78hBrPR HiRsvgEnC6K7d6x4jDadQ0/RWhbYfc/CXd7UB1i1d9bHWV3HkE6stdAOsjm2935WEVaY GeMkz+vO4IGUOrT7pTeTgRr+JcPeLnz+rVEvM= MIME-Version: 1.0 Received: by 10.229.224.137 with SMTP id io9mr941125qcb.206.1285748924152; Wed, 29 Sep 2010 01:28:44 -0700 (PDT) Received: by 10.229.50.8 with HTTP; Wed, 29 Sep 2010 01:28:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Sep 2010 12:28:44 +0400 Message-ID: From: Sergey Kandaurov To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ryan Stone , FreeBSD Current , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 08:50:58 -0000 [just don't know what namely need to test, so] All made according to your instructions. The only way I could trigger netdump was to run its ddb command by hand. Neither debug.kdb.enter nor debug.kdb.panic don't do it. Some numbers and output (bit verbose but again don't know what need to show here) Entered through debug.kdb.panic, thus Panicstring. db> netdump ----------------------------------- netdump in progress. searching for server.. dumping to xx.xxx.xx.xx (00:1a:64:d3:4f:20) ----------------------------------- Physical memory: 2026 MB Dumping 1154 MB: 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Dump complete netdump finished. cancelling normal dump # ls -hl /home/fooserv/crash/ total 1182930 -rw-r--r-- 1 root wheel 404B Sep 29 12:05 info.fooserv.0 -rw-r--r-- 1 root wheel 1.1G Sep 29 12:05 vmcore.fooserv.0 Dump from fooserv [xx.xxx.xx.xx] Architecture: amd64 Architecture version: 2 Dump length: 1210687488B (1154 MB) blocksize: 8192 Dumptime: Wed Sep 29 11:55:30 2010 Hostname: fooserv Versionstring: FreeBSD 9.0-CURRENT #51: Wed Sep 29 07:18:24 UTC 2010 root@fooserv:/usr/obj/usr/src/sys/GENERIC Panicstring: kdb_sysctl_panic Header parity check: Pass Dump complete I tried to netdump a bit later again, but it couldn't find server, which runs though, and client traffic was seen on server-side (w/o reply). db> netdump ----------------------------------- netdump in progress. searching for server.. . . . . . . . . . . . Failed to contact netdump server As for netdumpserv, it misses #include before __FBSDID(); I happily tested it on 7.3-amd64. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Sep 29 16:10:44 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41E06106566B; Wed, 29 Sep 2010 16:10:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1DA08FC18; Wed, 29 Sep 2010 16:10:43 +0000 (UTC) Received: by qyk7 with SMTP id 7so1468345qyk.13 for ; Wed, 29 Sep 2010 09:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3496qKG/dXXyNKRIqEuf4rn7YmzRGPQhs8KSIUhGStA=; b=gON4Vl7FR6FKHkur+QGKEnO26BUPRcouUV3Q06KZ9Rvt7eFHhwYhz983JxEwY4KT/1 P83p5/aEWzuDX6+8WQc6Il8uIxc5hyGQX3La7NAnoT8998rgfjnpTzL1T9sny+t7AUjw 0zy1nC1SGn6919KWCBaFYWwM4BYfGv1tMls6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Uyvke3WWKIl13F1XuVCbOcMfLGdBQLw4mNCcN/I2kRS0O5h/uPF96T92upxnjnpepJ SzlDhb7D9FWSZV/8azxt4PWKsB3bt64xiO+DDN5juH+r2VmBK/LMLXXygEqZ3aQN7WOe zibZ47/tXvvBSdYKfnGc6w4Bf69W5n7P8ihLg= MIME-Version: 1.0 Received: by 10.224.19.147 with SMTP id a19mr1294648qab.235.1285776642662; Wed, 29 Sep 2010 09:10:42 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Wed, 29 Sep 2010 09:10:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Sep 2010 18:10:42 +0200 X-Google-Sender-Auth: ZRQ-w5G8dl0FAnwibK5pfCpw6qc Message-ID: From: Attilio Rao To: Sergey Kandaurov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Ryan Stone , FreeBSD Current , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 16:10:44 -0000 2010/9/29 Sergey Kandaurov : > [just don't know what namely need to test, so] > > All made according to your instructions. > The only way I could trigger netdump was > to run its ddb command by hand. Neither > debug.kdb.enter nor debug.kdb.panic don't do it. You probabilly need to use KDB_UNATTENDED. > Some numbers and output (bit verbose > but again don't know what need to show here) > Entered through debug.kdb.panic, thus Panicstring. > db> netdump > > ----------------------------------- > netdump in progress. searching for server.. dumping to xx.xxx.xx.xx > (00:1a:64:d3:4f:20) > ----------------------------------- > Physical memory: 2026 MB > Dumping 1154 MB: 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 > 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 > 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 > 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 > 147 131 115 99 83 67 51 35 19 3 > Dump complete > > netdump finished. > cancelling normal dump > > # ls -hl /home/fooserv/crash/ > total 1182930 > -rw-r--r-- =C2=A01 root =C2=A0wheel =C2=A0 404B Sep 29 12:05 info.fooserv= .0 > -rw-r--r-- =C2=A01 root =C2=A0wheel =C2=A0 1.1G Sep 29 12:05 vmcore.foose= rv.0 > > Dump from fooserv [xx.xxx.xx.xx] > =C2=A0Architecture: amd64 > =C2=A0Architecture version: 2 > =C2=A0Dump length: 1210687488B (1154 MB) > =C2=A0blocksize: 8192 > =C2=A0Dumptime: Wed Sep 29 11:55:30 2010 > =C2=A0Hostname: fooserv > =C2=A0Versionstring: FreeBSD 9.0-CURRENT #51: Wed Sep 29 07:18:24 UTC 201= 0 > =C2=A0 =C2=A0root@fooserv:/usr/obj/usr/src/sys/GENERIC > =C2=A0Panicstring: kdb_sysctl_panic > =C2=A0Header parity check: Pass > Dump complete > > I tried to netdump a bit later again, but it couldn't find server, which > runs though, and client traffic was seen on server-side (w/o reply). > db> netdump > > ----------------------------------- > netdump in progress. searching for server.. . . . . . . . . . . . > Failed to contact netdump server Could you compile the kernel with NETDUMP_CLIENT_DEBUG and retry? (Warning: the log may be huge, so you may be needing to log with serial lin= e) I will try to reproduce locally, if anything. Thanks, Attilio > > As for netdumpserv, > it misses #include before __FBSDID(); > I happily tested it on 7.3-amd64. Yes, there are also other small style(9) nits that needs to be addressed in the netdumpserver as well. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 18:19:43 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0D51065679; Thu, 30 Sep 2010 18:19:43 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 080288FC1A; Thu, 30 Sep 2010 18:19:42 +0000 (UTC) Received: by eyx24 with SMTP id 24so1164995eyx.13 for ; Thu, 30 Sep 2010 11:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=yR9xoLjK+p1pppy/iIP8pFK07cwBb/KnNwuq6WhvxHc=; b=GAMYtb4kKIwqTWlriimpTLK+RWNCF8QqWLItQXq80QtBfgsMGktykGFpPgixvbNPPF csg4uLDkFBlZKgFEu+20gnmlYzWq+rrb/vluyKQbt7GDM4ne+5d5PYxnsaCnQBcKi9Vh UhkFbAhWyWlR3870Ig17QRAgs6ymPPiok2fbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QNZhtojQnZAeUwcmQRWjQN7H8jvl/EBBTTJKKYms6C8OEGkTR6+H08WbfFC6BbccMN o61S4TFbjEQU62B4u39OWjwIP+DqCB2zvf8t2Ynwpg3R/I8PoYPKxDod5xLqHg5SRLCn AjDDbfi6NhmFUsAm+Gd1l1YeLIuJTPBWd291o= MIME-Version: 1.0 Received: by 10.213.2.136 with SMTP id 8mr4605800ebj.18.1285868951172; Thu, 30 Sep 2010 10:49:11 -0700 (PDT) Received: by 10.213.105.208 with HTTP; Thu, 30 Sep 2010 10:49:11 -0700 (PDT) In-Reply-To: <4C9DA26D.7000309@freebsd.org> References: <4C9DA26D.7000309@freebsd.org> Date: Thu, 30 Sep 2010 13:49:11 -0400 Message-ID: From: Ryan Stone To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Re: mbuf changes 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, 30 Sep 2010 18:19:43 -0000 It's not a big thing but it would be nice to replace the m_next and m_nextpkt fields with queue.h macros. From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 18:36:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080BC106567A; Thu, 30 Sep 2010 18:36:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 88C548FC1A; Thu, 30 Sep 2010 18:36:36 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 84185A6ACA1; Fri, 1 Oct 2010 02:36:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id JJeg2mpPYFRf; Fri, 1 Oct 2010 02:36:28 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id EA989A6AC9F; Fri, 1 Oct 2010 02:36:26 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=n2oCghm/7n+SSPO/Edk3qudEDKy2Nj9ZTZ8RX5IOi7rkaoSRaZ9XQl2n9b99G+IBx I6Ug0WpEoTzL/SsYxmxxw== Message-ID: <4CA4D8A7.80802@delphij.net> Date: Thu, 30 Sep 2010 11:36:23 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20100920 Thunderbird/3.0.8 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: Jack Vogel References: <4C93A762.40305@delphij.net> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jfv@freebsd.org, "freebsd-net@freebsd.org" , d@delphij.net Subject: Re: em(4): discard frame w/o packet header (82547L on Supermicro X7SPA-H) on stable/8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 18:36:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Jack, On 2010/09/17 10:42, Jack Vogel wrote: > Put DDB/KDB into the kernel and get me the stack trace when this > problem happens. Tell me exactly what the hardware is (pciconf). Just wanted to let you know that after putting DDB/KDB into the kernel, the problem vanished mysteriously and I can not provoke the problem any more. I have traversed the changes since the build date to 09/18/2010 (when I built the new kernel) but have no clue what exactly fixed the problem. I have placed pciconf -lv, devinfo -rv, dmesg.boot and acpidump -dt information as well as sysctl dev.em output on the system just in case you will be interested in them: https://neptune.delphij.net/acpi/ Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMpNinAAoJEATO+BI/yjfBf8UH/1M84qigDwbwx2/aNZFurG+k cgpDaBnPwMndMI2w391S5jWOYTqBjcvEBLcNLSpTa/P2DHxSqCH5dFIqyTbDA+X6 k4AjOW0ClUKkT8wxZS/26XHRnqvjAM3p7rPgSQHlWVOubX0OpHZGlv87LIbaiLmj UywPwqOnIYSFPiBX8xhwjM4MSPQatFCuF2nNgmWEFGOokPfPNuKABXyJhwK/A4/X uQ9lLIX1+BmvfzBBLIqJhQWb4FEJsXVV6WyjTkpS7rYqySDcfdPORU+C4oiF87RU udu1BqwO4b7FeyoqBJ2dUUvF85mtsaRBXF5tO8V8QJxvFrHqwnNgMVlC954qu8c= =1zLX -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 19:13:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7381D1065674 for ; Thu, 30 Sep 2010 19:13:58 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4CDA18FC0C for ; Thu, 30 Sep 2010 19:13:58 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 77EBE11B860; Thu, 30 Sep 2010 14:13:57 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id ZP7P1N1NUXTV; Thu, 30 Sep 2010 14:13:57 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4CA26BB7.2090907@FreeBSD.org> Date: Thu, 30 Sep 2010 20:13:54 +0100 Content-Transfer-Encoding: 7bit Message-Id: <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> To: Doug Barton , Hiroki Sato X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(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: Thu, 30 Sep 2010 19:13:58 -0000 On 28 Sep 2010, at 23:27, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 9/22/2010 1:32 PM, Hiroki Sato wrote: > | Hello, > | > | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? > > Well I don't want to be "Mr. Negativity," but I'd like to suggest that > adding this support is the wrong way to go. STF and teredo are > transition mechanisms, and we're currently knee-deep (well maybe > ankle-deep) in the deployment of IPv6. This is only going to pick up > steam in the next few years given the impending run-out of the free /8s > in the IANA pool. I disagree with you and I want to see this going in. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 19:16:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A74106566B for ; Thu, 30 Sep 2010 19:16:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA688FC0A for ; Thu, 30 Sep 2010 19:16:51 +0000 (UTC) Received: (qmail 32407 invoked by uid 399); 30 Sep 2010 19:16:50 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Sep 2010 19:16:50 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA4E221.4060107@FreeBSD.org> Date: Thu, 30 Sep 2010 12:16:49 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> In-Reply-To: <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(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: Thu, 30 Sep 2010 19:16:51 -0000 On 9/30/2010 12:13 PM, Rui Paulo wrote: > On 28 Sep 2010, at 23:27, Doug Barton wrote: > >> On 9/22/2010 1:32 PM, Hiroki Sato wrote: >> | Hello, >> | >> | Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)? >> >> Well I don't want to be "Mr. Negativity," but I'd like to suggest that >> adding this support is the wrong way to go. STF and teredo are >> transition mechanisms, and we're currently knee-deep (well maybe >> ankle-deep) in the deployment of IPv6. This is only going to pick up >> steam in the next few years given the impending run-out of the free /8s >> in the IANA pool. > > I disagree with you and I want to see this going in. Perhaps you could provide a little more information about the basis for your opinion, as I attempted to do for mine? If for no other reason than to help educate me on why I'm wrong? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 20:03:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7AA2106566C for ; Thu, 30 Sep 2010 20:03:57 +0000 (UTC) (envelope-from apauljoe@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 22DD98FC0C for ; Thu, 30 Sep 2010 20:03:55 +0000 (UTC) Received: by qyk7 with SMTP id 7so2536762qyk.13 for ; Thu, 30 Sep 2010 13:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=XNabErH4P+CNCqTMYB8I6tYb01gMBdmprOCXLoDYa3Q=; b=pyzOOFK/LzXTN96q2fRHqS6ukgxq03vrkAHapaWGm1hzf5q4JJhN3jC9kifl9IcAlS IIDqaQ8pvfaSNC5CIzbFp5Pm4N6glJ9EuQHZXtBh7vSAbeBtg6t8qSEm62iEsd0HJ78T VwkM1PFRkVKiBtsm7gPiFaYBscA30zYICRmQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DmfpN5CoEsjf7ch/oAK7zTQJbeyt6Jp/HEnx2EhNx5R0z1Fd5tvgsVt8XrmHBbLVSF vhUg3V65ssGvOyV7xKyAVv9/r/XKN0SSQ6euqzV+NE6mejzzmRmQrq7wUF5ttv5jmMK0 ATjaeOob4hLEzDGCWEDKsI/RPnN9PMv/enpCI= MIME-Version: 1.0 Received: by 10.229.223.198 with SMTP id il6mr3034666qcb.50.1285877034617; Thu, 30 Sep 2010 13:03:54 -0700 (PDT) Received: by 10.229.26.8 with HTTP; Thu, 30 Sep 2010 13:03:54 -0700 (PDT) Date: Fri, 1 Oct 2010 01:33:54 +0530 Message-ID: From: Paul Joe To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=00163630eb25df9caa04917f93e0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw tablearg support for setfib 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, 30 Sep 2010 20:03:57 -0000 --00163630eb25df9caa04917f93e0 Content-Type: text/plain; charset=ISO-8859-1 Hi, The attached patch supports tablearg options to setfib. With the patch, you can add rules like ipfw add 100 setfib tablearg ip from 'table(1)' to any It help in policy based routing as discussed in this thread. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=124951+0+archive/2009/freebsd-net/20090426.freebsd-net Let me know your comments.. Thanks, Joe --00163630eb25df9caa04917f93e0 Content-Type: text/plain; charset=US-ASCII; name="setfib.txt" Content-Disposition: attachment; filename="setfib.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_geq1x4bv0 SW5kZXg6IHNyYy9zYmluL2lwZncvaXBmdzIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9u Y3ZzL3NyYy9zYmluL2lwZncvaXBmdzIuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNTkKZGlm ZiAtYyAtdSAtcjEuMTU5IGlwZncyLmMKLS0tIHNyYy9zYmluL2lwZncvaXBmdzIuYwkxOSBBcHIg MjAxMCAxNjozNTo0NyAtMDAwMAkxLjE1OQorKysgc3JjL3NiaW4vaXBmdy9pcGZ3Mi5jCTMwIFNl cCAyMDEwIDE4OjUyOjQxIC0wMDAwCkBAIC0yODMzLDExICsyODMzLDE3IEBACiAKIAkJYWN0aW9u LT5vcGNvZGUgPSBPX1NFVEZJQjsKICAJCU5FRUQxKCJtaXNzaW5nIGZpYiBudW1iZXIiKTsKLSAJ ICAgICAgICBhY3Rpb24tPmFyZzEgPSBzdHJ0b3VsKCphdiwgTlVMTCwgMTApOwotCQlpZiAoc3lz Y3RsYnluYW1lKCJuZXQuZmlicyIsICZudW1maWJzLCAmaW50c2l6ZSwgTlVMTCwgMCkgPT0gLTEp Ci0JCQllcnJ4KEVYX0RBVEFFUlIsICJmaWJzIG5vdCBzdXBvcnRlZC5cbiIpOwotCQlpZiAoYWN0 aW9uLT5hcmcxID49IG51bWZpYnMpICAvKiBUZW1wb3JhcnkgKi8KLQkJCWVycngoRVhfREFUQUVS UiwgImZpYiB0b28gbGFyZ2UuXG4iKTsKKwkJaWYoaXNkaWdpdCgqKmF2KSkgeworCQkJYWN0aW9u LT5hcmcxID0gc3RydG91bCgqYXYsIE5VTEwsIDEwKTsKKwkJCWlmIChzeXNjdGxieW5hbWUoIm5l dC5maWJzIiwgJm51bWZpYnMsICZpbnRzaXplLAorCQkJICAgIE5VTEwsIDApID09IC0xKQorCQkJ CWVycngoRVhfREFUQUVSUiwgImZpYnMgbm90IHN1cG9ydGVkLlxuIik7CisJCQlpZiAoYWN0aW9u LT5hcmcxID49IG51bWZpYnMpICAvKiBUZW1wb3JhcnkgKi8KKwkJCQllcnJ4KEVYX0RBVEFFUlIs ICJmaWIgdG9vIGxhcmdlLlxuIik7CisJCX0gZWxzZSBpZiAoX3N1YnN0cmNtcCgqYXYsICJ0YWJs ZWFyZyIpID09IDApCisJCQlhY3Rpb24tPmFyZzEgPSBJUF9GV19UQUJMRUFSRzsKKwkJZWxzZQor CQkJZXJyeChFWF9EQVRBRVJSLCAiaWxsZWdhbCBhcmd1bWVudCBmb3IgJXMiLCAqKGF2IC0gMSkp OwogIAkJYXYrKzsKICAJCWJyZWFrOwogCSAgICB9CkluZGV4OiBzcmMvc3lzL25ldGluZXQvaXBm dy9pcF9mdzIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvbmV0aW5l dC9pcGZ3L2lwX2Z3Mi5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjQ1CmRpZmYgLWMgLXUgLXIx LjQ1IGlwX2Z3Mi5jCi0tLSBzcmMvc3lzL25ldGluZXQvaXBmdy9pcF9mdzIuYwkyNyBKdWwgMjAx MCAxNDoyNjozNCAtMDAwMAkxLjQ1CisrKyBzcmMvc3lzL25ldGluZXQvaXBmdy9pcF9mdzIuYwkz MCBTZXAgMjAxMCAxODo1Mjo0MyAtMDAwMApAQCAtMjA5MiwxMiArMjA5MiwxNSBAQAogCQkJCWRv bmUgPSAxOyAgICAgICAvKiBleGl0IG91dGVyIGxvb3AgKi8KIAkJCQlicmVhazsKIAotCQkJY2Fz ZSBPX1NFVEZJQjoKKwkJCWNhc2UgT19TRVRGSUI6IHsKKwkJCQl1aW50MzJfdCBmaWJudW07CiAJ CQkJZi0+cGNudCsrOwkvKiB1cGRhdGUgc3RhdHMgKi8KIAkJCQlmLT5iY250ICs9IHBrdGxlbjsK IAkJCQlmLT50aW1lc3RhbXAgPSB0aW1lX3VwdGltZTsKLQkJCQlNX1NFVEZJQihtLCBjbWQtPmFy ZzEpOwotCQkJCWFyZ3MtPmZfaWQuZmliID0gY21kLT5hcmcxOworCQkJCWZpYm51bSA9IChjbWQt PmFyZzEgPT0gSVBfRldfVEFCTEVBUkcpPworCQkJCQkgdGFibGVhcmcgOiBjbWQtPmFyZzE7CisJ CQkJTV9TRVRGSUIobSwgZmlibnVtKTsKKwkJCQlhcmdzLT5mX2lkLmZpYiA9IGZpYm51bTsKIAkJ CQlsID0gMDsJCS8qIGV4aXQgaW5uZXIgbG9vcCAqLwogCQkJCWJyZWFrOwogCkluZGV4OiBzcmMv c3lzL25ldGluZXQvaXBmdy9pcF9md19zb2Nrb3B0LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hv bWUvbmN2cy9zcmMvc3lzL25ldGluZXQvaXBmdy9pcF9md19zb2Nrb3B0LmMsdgpyZXRyaWV2aW5n IHJldmlzaW9uIDEuMTcKZGlmZiAtYyAtdSAtcjEuMTcgaXBfZndfc29ja29wdC5jCi0tLSBzcmMv c3lzL25ldGluZXQvaXBmdy9pcF9md19zb2Nrb3B0LmMJNyBBcHIgMjAxMCAwODoyMzo1OCAtMDAw MAkxLjE3CisrKyBzcmMvc3lzL25ldGluZXQvaXBmdy9pcF9md19zb2Nrb3B0LmMJMzAgU2VwIDIw MTAgMTg6NTI6NDQgLTAwMDAKQEAgLTYwNSw3ICs2MDUsOCBAQAogCQljYXNlIE9fU0VURklCOgog CQkJaWYgKGNtZGxlbiAhPSBGX0lOU05fU0laRShpcGZ3X2luc24pKQogCQkJCWdvdG8gYmFkX3Np emU7Ci0JCQlpZiAoY21kLT5hcmcxID49IHJ0X251bWZpYnMpIHsKKwkJCWlmIChjbWQtPmFyZzEg Pj0gcnRfbnVtZmlicyAmJgorCQkJICAgICBjbWQtPmFyZzEgIT0gSVBfRldfVEFCTEVBUkcpIHsK IAkJCQlwcmludGYoImlwZnc6IGludmFsaWQgZmliIG51bWJlciAlZFxuIiwKIAkJCQkJY21kLT5h cmcxKTsKIAkJCQlyZXR1cm4gRUlOVkFMOwo= --00163630eb25df9caa04917f93e0-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 21:46:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD259106566C; Thu, 30 Sep 2010 21:46:15 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 64FAF8FC0C; Thu, 30 Sep 2010 21:46:15 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id B49F211B8A5; Thu, 30 Sep 2010 16:46:14 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id 3DZNHM73BL4T; Thu, 30 Sep 2010 16:46:14 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4CA4E221.4060107@FreeBSD.org> Date: Thu, 30 Sep 2010 22:46:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> <4CA4E221.4060107@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(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: Thu, 30 Sep 2010 21:46:15 -0000 On 30 Sep 2010, at 20:16, Doug Barton wrote: > On 9/30/2010 12:13 PM, Rui Paulo wrote: >> On 28 Sep 2010, at 23:27, Doug Barton wrote: >>=20 >>> On 9/22/2010 1:32 PM, Hiroki Sato wrote: >>> | Hello, >>> | >>> | Can anyone try a patch for adding 6rd (RFC 5569) support to = stf(4)? >>>=20 >>> Well I don't want to be "Mr. Negativity," but I'd like to suggest = that >>> adding this support is the wrong way to go. STF and teredo are >>> transition mechanisms, and we're currently knee-deep (well maybe >>> ankle-deep) in the deployment of IPv6. This is only going to pick up >>> steam in the next few years given the impending run-out of the free = /8s >>> in the IANA pool. >>=20 >> I disagree with you and I want to see this going in. >=20 > Perhaps you could provide a little more information about the basis = for your opinion, as I attempted to do for mine? If for no other reason = than to help educate me on why I'm wrong? I really don't feel like discussion this ad nauseum as your last IPv6 = thread, but 6rd is useful and your argument about the timeline for = FreeBSD 9.0 doesn't make sense: we can have this on FreeBSD 8-STABLE in = a week after this is committed to HEAD. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 22:32:29 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F065106564A for ; Thu, 30 Sep 2010 22:32:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-30.mx.aerioconnect.net [216.240.47.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2455C8FC0A for ; Thu, 30 Sep 2010 22:32:28 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8UMWSBi020195; Thu, 30 Sep 2010 15:32:28 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id F1E772D6011; Thu, 30 Sep 2010 15:32:26 -0700 (PDT) Message-ID: <4CA51024.8020307@freebsd.org> Date: Thu, 30 Sep 2010 15:33:08 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Ryan Stone References: <4C9DA26D.7000309@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: FreeBSD Net Subject: Re: mbuf changes 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, 30 Sep 2010 22:32:29 -0000 On 9/30/10 10:49 AM, Ryan Stone wrote: > It's not a big thing but it would be nice to replace the m_next and > m_nextpkt fields with queue.h macros. > funny, I've never even thought of that.. From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 22:55:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7460D1065672 for ; Thu, 30 Sep 2010 22:55:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1665E8FC1C for ; Thu, 30 Sep 2010 22:55:02 +0000 (UTC) Received: (qmail 27569 invoked by uid 399); 30 Sep 2010 22:55:02 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Sep 2010 22:55:02 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA51544.9080103@FreeBSD.org> Date: Thu, 30 Sep 2010 15:55:00 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Rui Paulo References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> In-Reply-To: <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(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: Thu, 30 Sep 2010 22:55:03 -0000 On 9/30/2010 2:46 PM, Rui Paulo wrote: > > I really don't feel like discussion this ad nauseum as your last IPv6 > thread, but 6rd is useful and your argument about the timeline for > FreeBSD 9.0 doesn't make sense: we can have this on FreeBSD 8-STABLE > in a week after this is committed to HEAD. Well I was actually trying to make a new start here and avoid discussing the history. In any case I didn't say that 6rd was not useful at all. What I tried to make the case for is that its utility is limited, both in the absolute sense and in the temporal sense; and that because of these limitations the benefits that adding the code bring are outweighed by the costs of maintaining it past what will likely be its useful lifetime. My point about FreeBSD 9 is that if we add the 6rd code today, then release 9.0 in about a year, then support the RELENG_9 branch for 4-6 years that we will still be maintaining code that no one has any use for. Sorry if I wasn't clear. In contrast, the bit of my post that you snipped suggested that a better course of action would be to focus on the areas of our v6 stack that will be used for the lifetime of the protocol, like the performance penalty that currently exists for the v6 loopback device. But that's really all I have to say, and I'd hate to ad nauseate you. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Thu Sep 30 23:40:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7668D106566C; Thu, 30 Sep 2010 23:40:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id ED29D8FC13; Thu, 30 Sep 2010 23:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 46CA641C650; Fri, 1 Oct 2010 01:40:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id W3r9utFPbQz7; Fri, 1 Oct 2010 01:40:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B326A41C64C; Fri, 1 Oct 2010 01:40:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 965024448F3; Thu, 30 Sep 2010 23:38:18 +0000 (UTC) Date: Thu, 30 Sep 2010 23:38:17 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Doug Barton In-Reply-To: <4CA51544.9080103@FreeBSD.org> Message-ID: <20100930231715.D95502@maildrop.int.zabbadoz.net> References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(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: Thu, 30 Sep 2010 23:40:08 -0000 On Thu, 30 Sep 2010, Doug Barton wrote: Hey, > In any case I didn't say that 6rd was not useful at all. What I tried to make > the case for is that its utility is limited, both in the absolute sense and > in the temporal sense; and that because of these limitations the benefits > that adding the code bring are outweighed by the costs of maintaining it past > what will likely be its useful lifetime. The maintainance costs are effectively pretty low, especially as it's coming with stf; it's a single line in a kernel config and not many more files but it will have great value to a lot of people the next years. > My point about FreeBSD 9 is that if we add the 6rd code today, then release > 9.0 in about a year, then support the RELENG_9 branch for 4-6 years that we > will still be maintaining code that no one has any use for. Sorry if I wasn't > clear. While I would like to live in that kind of world that by mid 10s all the tunneling, transition, .. technologies would be gone, ideally along with legacy IP, I guess you are massively underestimating this from the early adopters point of view; while for some of us things have happened and we are waiting for the world to catch up, for other folks things might not start within the another product lifecycle. I am sure we'll see a lot of different scenarios for quite some time. I would expect that we'll still be shipping that code in at least 12.x. Though completely taken out of context, Dave Ward's words the minute on from there: http://www.youtube.com/watch?v=mXMMBrWRnvc#t=49m54s summarizes some things quite nicely. > In contrast, the bit of my post that you snipped suggested that a better > course of action would be to focus on the areas of our v6 stack that will be > used for the lifetime of the protocol, like the performance penalty that > currently exists for the v6 loopback device. I think that noone questions that this will need time as well and so do another 15 things on the IPv6 side but maybe someone is already working on it .. /bz -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 03:25:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46CBF1065670 for ; Fri, 1 Oct 2010 03:25:38 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1DDB58FC15 for ; Fri, 1 Oct 2010 03:25:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id AE79C509A5 for ; Fri, 1 Oct 2010 04:06:43 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY9Bl5xjXBzO for ; Fri, 1 Oct 2010 04:06:43 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 750E5509A3 for ; Fri, 1 Oct 2010 04:06:43 +0100 (BST) Message-ID: <4CA55041.7040001@langille.org> Date: Thu, 30 Sep 2010 23:06:41 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 03:25:38 -0000 Hi folks, I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But not from within the LAN. I have: Routed /48: 2001:470:8a86::/48 Routed /64: 2001:470:1f07:b80::/64 On the gateway, I have this: # cat /etc/rtadvd.conf fxp1:\ :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an IP address. (you should be able to ping6 that). Starting rtadvd I get: # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 rtadvd[33958]: fxp1 isn't defined in the configuration file or the configuration file doesn't exist. Treat it as default So why that message? And is it the cause of the 'no route to host' message below? rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]:
set timer to 15:998571. waiting for inputs or timeout rtadvd[33958]:
set timer to 0:4276. waiting for inputs or timeout rtadvd[33958]: RA timer on fxp1 is expired rtadvd[33958]: send RA on fxp1, # of waitings = 0 rtadvd[33958]: RA timer on fxp1 is set to 16:0 rtadvd[33958]:
set timer to 16:0. waiting for inputs or timeout rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[33958]:
set timer to 15:994315. waiting for inputs or timeout From a client on the LAN, I try this: $ ping6 ipv6.google.com ping6: UDP connect: No route to host From the same client (where em0 is the nic) $ netstat -nr -f inet6 | grep em0 fe80::%em0/64 link#1 U em0 fe80::21b:21ff:fe51:ab2d%em0 link#1 UHS lo0 ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 ff02::%em0/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 Can you see something I'm doing wrong? -- Dan Langille - http://langille.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 03:36:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9220A106566B for ; Fri, 1 Oct 2010 03:36:08 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 632178FC13 for ; Fri, 1 Oct 2010 03:36:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 9D167509A5 for ; Fri, 1 Oct 2010 04:36:07 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBrsCXXFAuUU for ; Fri, 1 Oct 2010 04:36:07 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 5D9C9509A3 for ; Fri, 1 Oct 2010 04:36:07 +0100 (BST) Message-ID: <4CA55725.10007@langille.org> Date: Thu, 30 Sep 2010 23:36:05 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CA55041.7040001@langille.org> In-Reply-To: <4CA55041.7040001@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 03:36:08 -0000 On 9/30/2010 11:06 PM, Dan Langille wrote: > Hi folks, > > I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But > not from within the LAN. > > I have: > > Routed /48: 2001:470:8a86::/48 > Routed /64: 2001:470:1f07:b80::/64 > > On the gateway, I have this: > > # cat /etc/rtadvd.conf > fxp1:\ > :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: > > Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an > IP address. (you should be able to ping6 that). > > Starting rtadvd I get: > > # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 > rtadvd[33958]: fxp1 isn't defined in the configuration file > or the configuration file doesn't exist. Treat it as default > > So why that message? And is it the cause of the 'no route to host' > message below? > > rtadvd[33958]: RA timer on fxp1 is set to 16:0 > rtadvd[33958]:
set timer to 15:998571. waiting for inputs or timeout > rtadvd[33958]:
set timer to 0:4276. waiting for inputs or timeout > rtadvd[33958]: RA timer on fxp1 is expired > rtadvd[33958]: send RA on fxp1, # of waitings = 0 > rtadvd[33958]: RA timer on fxp1 is set to 16:0 > rtadvd[33958]:
set timer to 16:0. waiting for inputs or timeout > rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 > rtadvd[33958]:
set timer to 15:994315. waiting for inputs or timeout > > From a client on the LAN, I try this: > > $ ping6 ipv6.google.com > ping6: UDP connect: No route to host > > From the same client (where em0 is the nic) > > $ netstat -nr -f inet6 | grep em0 > fe80::%em0/64 link#1 U em0 > fe80::21b:21ff:fe51:ab2d%em0 link#1 UHS lo0 > ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 > ff02::%em0/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 > > Can you see something I'm doing wrong? I am now convinced the problem is rtadvd. Gateway and internal box are both FreeBSd 8.1-stable. After I issued this command on the server: # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 add net 2001:470:1f07:b80::/64: gateway fxp1 And this one on the internal box: $ sudo route add -inet6 default 2001:470:1f07:b80::1 Password: add net default: gateway 2001:470:1f07:b80::1 ... things started working: $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2001:470:1f07:b80::2 --> 2001:4860:800f::63 16 bytes from 2001:4860:800f::63, icmp_seq=0 hlim=57 time=23.466 ms 16 bytes from 2001:4860:800f::63, icmp_seq=1 hlim=57 time=23.221 ms ^C --- ipv6.l.google.com ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 23.221/23.343/23.466/0.123 ms Would you agree that rtadvd may be the issue? -- Dan Langille - http://langille.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 04:18:46 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAE7B106566B for ; Fri, 1 Oct 2010 04:18:46 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id AB63D8FC13 for ; Fri, 1 Oct 2010 04:18:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id A6AAA509A5 for ; Fri, 1 Oct 2010 05:18:45 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yGtingZRnkJ for ; Fri, 1 Oct 2010 05:18:45 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 5E287509A3 for ; Fri, 1 Oct 2010 05:18:45 +0100 (BST) Message-ID: <4CA56123.2030304@langille.org> Date: Fri, 01 Oct 2010 00:18:43 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CA55041.7040001@langille.org> <4CA55725.10007@langille.org> In-Reply-To: <4CA55725.10007@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 04:18:47 -0000 On 9/30/2010 11:36 PM, Dan Langille wrote: > On 9/30/2010 11:06 PM, Dan Langille wrote: >> Hi folks, >> >> I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But >> not from within the LAN. >> >> I have: >> >> Routed /48: 2001:470:8a86::/48 >> Routed /64: 2001:470:1f07:b80::/64 >> >> On the gateway, I have this: >> >> # cat /etc/rtadvd.conf >> fxp1:\ >> :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: >> >> Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an >> IP address. (you should be able to ping6 that). >> >> Starting rtadvd I get: >> >> # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 >> rtadvd[33958]: fxp1 isn't defined in the configuration file >> or the configuration file doesn't exist. Treat it as default >> >> So why that message? And is it the cause of the 'no route to host' >> message below? >> >> rtadvd[33958]: RA timer on fxp1 is set to 16:0 >> rtadvd[33958]:
set timer to 15:998571. waiting for inputs or >> timeout >> rtadvd[33958]:
set timer to 0:4276. waiting for inputs or timeout >> rtadvd[33958]: RA timer on fxp1 is expired >> rtadvd[33958]: send RA on fxp1, # of waitings = 0 >> rtadvd[33958]: RA timer on fxp1 is set to 16:0 >> rtadvd[33958]:
set timer to 16:0. waiting for inputs or timeout >> rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 >> rtadvd[33958]:
set timer to 15:994315. waiting for inputs or >> timeout >> >> From a client on the LAN, I try this: >> >> $ ping6 ipv6.google.com >> ping6: UDP connect: No route to host >> >> From the same client (where em0 is the nic) >> >> $ netstat -nr -f inet6 | grep em0 >> fe80::%em0/64 link#1 U em0 >> fe80::21b:21ff:fe51:ab2d%em0 link#1 UHS lo0 >> ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 >> ff02::%em0/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 >> >> Can you see something I'm doing wrong? > > I am now convinced the problem is rtadvd. Gateway and internal box are > both FreeBSd 8.1-stable. > > After I issued this command on the server: > > # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 > add net 2001:470:1f07:b80::/64: gateway fxp1 > > And this one on the internal box: > > $ sudo route add -inet6 default 2001:470:1f07:b80::1 > Password: > add net default: gateway 2001:470:1f07:b80::1 > > ... things started working: > > $ ping6 ipv6.google.com > PING6(56=40+8+8 bytes) 2001:470:1f07:b80::2 --> 2001:4860:800f::63 > 16 bytes from 2001:4860:800f::63, icmp_seq=0 hlim=57 time=23.466 ms > 16 bytes from 2001:4860:800f::63, icmp_seq=1 hlim=57 time=23.221 ms > ^C > --- ipv6.l.google.com ping6 statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 23.221/23.343/23.466/0.123 ms > > Would you agree that rtadvd may be the issue? changing the conf file to this helps with the startup messages: # cat /etc/rtadvd.conf fxp1:\ :addr="2001:470:1f07:b80::":prefixlen#64: In this regard, the handbook may require updating. However, clients on my LAN are unable to get any IPv6 routing information despite having ipv6_enable="YES" in /etc/rc.conf. Running rtsol on the client doesn't get it an IPv6 address. However, we can see that rtadvd is processing the requests; # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 rtadvd[40477]: RA timer on fxp1 is set to 16:0 rtadvd[40477]:
set timer to 15:998900. waiting for inputs or timeout rtadvd[40477]:
set timer to 0:4953. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 0 rtadvd[40477]: RA timer on fxp1 is set to 16:0 rtadvd[40477]:
set timer to 16:0. waiting for inputs or timeout rtadvd[40477]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[40477]:
set timer to 15:994797. waiting for inputs or timeout rtadvd[40477]:
set timer to 0:4517. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 0 rtadvd[40477]: RA timer on fxp1 is set to 16:0 rtadvd[40477]:
set timer to 16:0. waiting for inputs or timeout rtadvd[40477]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[40477]:
set timer to 15:994119. waiting for inputs or timeout rtadvd[40477]: RS received from fe80::21b:21ff:fe51:ab2d on fxp1 rtadvd[40477]:
set timer to 0:490712. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 1 rtadvd[40477]: RA timer on fxp1 is set to 518:0 rtadvd[40477]:
set timer to 518:0. waiting for inputs or timeout rtadvd[40477]: RA received from 2001:470:1f07:b80::1 on fxp1 rtadvd[40477]:
set timer to 517:994623. waiting for inputs or timeout rtadvd[40477]: RS received from fe80::21b:21ff:fe51:ab2d on fxp1 rtadvd[40477]:
set timer to 0:426786. waiting for inputs or timeout rtadvd[40477]: RA timer on fxp1 is expired rtadvd[40477]: send RA on fxp1, # of waitings = 1 rtadvd[40477]: RA timer on fxp1 is set to 239:0 -- Dan Langille - http://langille.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 04:21:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BB8106566C for ; Fri, 1 Oct 2010 04:21:04 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 682C78FC0A for ; Fri, 1 Oct 2010 04:21:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 18BCA509A5 for ; Fri, 1 Oct 2010 05:21:04 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA48+wLU+2T4 for ; Fri, 1 Oct 2010 05:21:03 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id CA4C9509A3 for ; Fri, 1 Oct 2010 05:21:03 +0100 (BST) Message-ID: <4CA561AD.9020509@langille.org> Date: Fri, 01 Oct 2010 00:21:01 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CA55041.7040001@langille.org> <4CA55725.10007@langille.org> In-Reply-To: <4CA55725.10007@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 04:21:04 -0000 On 9/30/2010 11:36 PM, Dan Langille wrote: > On 9/30/2010 11:06 PM, Dan Langille wrote: >> Hi folks, >> >> I'm setting up IPv6 at home. On the gateway, I can ping6 just fine. But >> not from within the LAN. >> >> I have: >> >> Routed /48: 2001:470:8a86::/48 >> Routed /64: 2001:470:1f07:b80::/64 >> >> On the gateway, I have this: >> >> # cat /etc/rtadvd.conf >> fxp1:\ >> :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: >> >> Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an >> IP address. (you should be able to ping6 that). >> >> Starting rtadvd I get: >> >> # /usr/sbin/rtadvd -dDf -c /etc/rtadvd.conf fxp1 >> rtadvd[33958]: fxp1 isn't defined in the configuration file >> or the configuration file doesn't exist. Treat it as default >> >> So why that message? And is it the cause of the 'no route to host' >> message below? >> >> rtadvd[33958]: RA timer on fxp1 is set to 16:0 >> rtadvd[33958]:
set timer to 15:998571. waiting for inputs or >> timeout >> rtadvd[33958]:
set timer to 0:4276. waiting for inputs or timeout >> rtadvd[33958]: RA timer on fxp1 is expired >> rtadvd[33958]: send RA on fxp1, # of waitings = 0 >> rtadvd[33958]: RA timer on fxp1 is set to 16:0 >> rtadvd[33958]:
set timer to 16:0. waiting for inputs or timeout >> rtadvd[33958]: RA received from 2001:470:1f07:b80::1 on fxp1 >> rtadvd[33958]:
set timer to 15:994315. waiting for inputs or >> timeout >> >> From a client on the LAN, I try this: >> >> $ ping6 ipv6.google.com >> ping6: UDP connect: No route to host >> >> From the same client (where em0 is the nic) >> >> $ netstat -nr -f inet6 | grep em0 >> fe80::%em0/64 link#1 U em0 >> fe80::21b:21ff:fe51:ab2d%em0 link#1 UHS lo0 >> ff01:1::/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 >> ff02::%em0/32 fe80::21b:21ff:fe51:ab2d%em0 U em0 >> >> Can you see something I'm doing wrong? > > I am now convinced the problem is rtadvd. Gateway and internal box are > both FreeBSd 8.1-stable. > > After I issued this command on the server: > > # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 > add net 2001:470:1f07:b80::/64: gateway fxp1 > > And this one on the internal box: > > $ sudo route add -inet6 default 2001:470:1f07:b80::1 > Password: > add net default: gateway 2001:470:1f07:b80::1 > I also did this on the client: ifconfig em0 inet6 2001:470:1f07:b80::2/64 add > ... things started working: > > $ ping6 ipv6.google.com > PING6(56=40+8+8 bytes) 2001:470:1f07:b80::2 --> 2001:4860:800f::63 > 16 bytes from 2001:4860:800f::63, icmp_seq=0 hlim=57 time=23.466 ms > 16 bytes from 2001:4860:800f::63, icmp_seq=1 hlim=57 time=23.221 ms > ^C > --- ipv6.l.google.com ping6 statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 23.221/23.343/23.466/0.123 ms > > Would you agree that rtadvd may be the issue? > -- Dan Langille - http://langille.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 04:51:50 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8335E106566C; Fri, 1 Oct 2010 04:51:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4CA8FC0C; Fri, 1 Oct 2010 04:51:49 +0000 (UTC) Received: by iwn34 with SMTP id 34so4120598iwn.13 for ; Thu, 30 Sep 2010 21:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=37ltffGWcfLrDr2SoQoF/VO7u5wqetlmKMmDJF3wEEs=; b=QmhNRPeHqNJ6Wj93JyO+fbE3uyIQ5OSrfW2IMAY2PHsjlY0upXqK+ewISQMphAmyHv q/sHhWlQMkgMUlTM1mZYI2spwFUX1yLOCDPDu92c390uqWsmFOQq27wt8M76Zf/MYTHO z/WZL4Fc7fJ+8i7fnVOMb5ZykjESTtcTz6wO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=FDmkr21Rphx6PtlpZFjLvZnDGpATxw2mZ247haKIXX/6yqYJsuoxACjcpGZQRxW5u+ uN8+08shS/kkLVMoArrUEFVAb426ToJcZMM9P8nuBJ1VRtwRWOQMY6sxDi/pSirOC0t/ SCzDY6HaC2sQRnno2Ykp3ch2zHnkwUkLPdV4o= MIME-Version: 1.0 Received: by 10.231.190.203 with SMTP id dj11mr4890951ibb.93.1285908709446; Thu, 30 Sep 2010 21:51:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.171.203 with HTTP; Thu, 30 Sep 2010 21:51:49 -0700 (PDT) In-Reply-To: <4CA51544.9080103@FreeBSD.org> References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@FreeBSD.org> Date: Fri, 1 Oct 2010 12:51:49 +0800 X-Google-Sender-Auth: wwox3tS25FhLxP4IWHgpq6LFJ1A Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Rui Paulo Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 04:51:50 -0000 On 1 October 2010 06:55, Doug Barton wrote: > In any case I didn't say that 6rd was not useful at all. What I tried to > make the case for is that its utility is limited, both in the absolute sense > and in the temporal sense; and that because of these limitations the > benefits that adding the code bring are outweighed by the costs of > maintaining it past what will likely be its useful lifetime. People are going to be using IPv4 for a number of years. More than IPv6 proponents want or believe. I don't see the harm of doing both this work and improving our IPv6 stack support in general. It's all about choice, right? Adrian From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 07:44:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9455E1065693 for ; Fri, 1 Oct 2010 07:44:09 +0000 (UTC) (envelope-from lars.eggert@nokia.com) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3F38FC1D for ; Fri, 1 Oct 2010 07:44:08 +0000 (UTC) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o917i7vw006040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 10:44:07 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-112-521670312; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4CA51544.9080103@FreeBSD.org> Date: Fri, 1 Oct 2010 10:43:51 +0300 Message-Id: <750AF539-C163-428C-B930-25E08EC565FB@nokia.com> References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 01 Oct 2010 10:43:57 +0300 (EEST) X-Spam-Status: No, score=-101.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_SUBJECT,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on fit.nokia.com X-Nokia-AV: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Rui Paulo Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 07:44:09 -0000 --Apple-Mail-112-521670312 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2010-10-1, at 1:55, Doug Barton wrote: > My point about FreeBSD 9 is that if we add the 6rd code today, then > release 9.0 in about a year, then support the RELENG_9 branch for 4-6 > years that we will still be maintaining code that no one has any use > for. Sorry if I wasn't clear. You're seriously underestimating the transition time needed for IPv6. Lars --Apple-Mail-112-521670312-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 09:10:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A54A2106566B; Fri, 1 Oct 2010 09:10:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id EA93A8FC12; Fri, 1 Oct 2010 09:10:00 +0000 (UTC) Received: from alph.d.allbsd.org (p2176-ipbf406funabasi.chiba.ocn.ne.jp [124.86.72.176]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id o9199bM4026791; Fri, 1 Oct 2010 18:09:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o9199aVn038900; Fri, 1 Oct 2010 18:09:37 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 01 Oct 2010 18:09:21 +0900 (JST) Message-Id: <20101001.180921.203815983.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4CA51544.9080103@FreeBSD.org> References: <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Oct__1_18_09_21_2010_045)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Fri, 01 Oct 2010 18:09:51 +0900 (JST) X-Spam-Status: No, score=-99.1 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org, rpaulo@FreeBSD.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 09:10:01 -0000 ----Security_Multipart(Fri_Oct__1_18_09_21_2010_045)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4CA51544.9080103@FreeBSD.org>: do> In any case I didn't say that 6rd was not useful at all. What I tried do> to make the case for is that its utility is limited, both in the do> absolute sense and in the temporal sense; and that because of these do> limitations the benefits that adding the code bring are outweighed by do> the costs of maintaining it past what will likely be its useful do> lifetime. do> do> My point about FreeBSD 9 is that if we add the 6rd code today, then do> release 9.0 in about a year, then support the RELENG_9 branch for 4-6 do> years that we will still be maintaining code that no one has any use do> for. Sorry if I wasn't clear. In my understanding the transition period from IPv4 to IPv6 will take a very very long time, not a year or two even if it happens eventually. Migration techniques like 6rd which are applicable to subscriber access in large-scale ISPs are discussed and being adopted as their service just around these few years. Some may have some different ideas about the transition, but at least there is a fact that many ISPs think some kind of automatic IPv4-IPv6 tunneling is useful for their IPv6 deployment and investigating its implementability. I am not sure how much useful the 6rd will be in the near future in reality. However, I believe it is something worth implementing because I am sure that market of v4/v6 dual-stack CPE is rapidly growing, it is possible 6rd becomes one of its key techniques, and the market is where embedded FreeBSD systems can be visible. So, if we fail implementing ones that people want in a timely manner, we will lose our seat as a good networking OS vendor. I agree that introducing additional complexity is not a good thing, but most of the techniques including 6rd can be implemented by using the existing code with small changes because after all they are ones to solve operational/administrative issues by some specific combinations of the basic IPv6 functionality. This is my thought in general. If you have specific comments on the implementation which may lead to unacceptable maintenance cost or something bad, please let me know. do> In contrast, the bit of my post that you snipped suggested that a do> better course of action would be to focus on the areas of our v6 stack do> that will be used for the lifetime of the protocol, like the do> performance penalty that currently exists for the v6 loopback device. There is no trade-off between improving robustness/performance of the basic functionality and adding a new protocol in this case. The negative impact of adding 6rd is quite small if any, and we have nothing to lose even if 6rd will be useless some day. -- Hiroki ----Security_Multipart(Fri_Oct__1_18_09_21_2010_045)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkylpUEACgkQTyzT2CeTzy0oXQCg3byCzm1NIR0ceFUaBcWr+/QZ ZJoAn0NLEPta3+ipOoq+Awoa70BfYJqS =dxZE -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct__1_18_09_21_2010_045)---- From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 09:38:52 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C1F3106566B for ; Fri, 1 Oct 2010 09:38:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8330C8FC13 for ; Fri, 1 Oct 2010 09:38:51 +0000 (UTC) Received: from alph.d.allbsd.org (p2176-ipbf406funabasi.chiba.ocn.ne.jp [124.86.72.176]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id o919cX3F027405; Fri, 1 Oct 2010 18:38:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o919cWEF039079; Fri, 1 Oct 2010 18:38:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 01 Oct 2010 18:38:05 +0900 (JST) Message-Id: <20101001.183805.53791271.hrs@allbsd.org> To: dan@langille.org From: Hiroki Sato In-Reply-To: <4CA55041.7040001@langille.org> <4CA55725.10007@langille.org> <4CA56123.2030304@langille.org> References: <4CA55041.7040001@langille.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Oct__1_18_38_05_2010_567)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Fri, 01 Oct 2010 18:38:46 +0900 (JST) X-Spam-Status: No, score=-99.2 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 09:38:52 -0000 ----Security_Multipart(Fri_Oct__1_18_38_05_2010_567)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan Langille wrote in <4CA55041.7040001@langille.org>: da> # cat /etc/rtadvd.conf da> fxp1:\ da> :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: In this case, you do not need rtadvd.conf. The command line "rtadvd fxp1" should work fine. da> Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an da> IP address. (you should be able to ping6 that). Can you show the results of "ifconfig fxp1"? Dan Langille wrote in <4CA55725.10007@langille.org>: da> After I issued this command on the server: da> da> # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 da> add net 2001:470:1f07:b80::/64: gateway fxp1 I do not think this is needed if you did "ifconfig fxp1 inet6 2001:470:1f07:b80::1/64". Dan Langille wrote in <4CA56123.2030304@langille.org>: da> However, clients on my LAN are unable to get any IPv6 routing da> information despite having ipv6_enable="YES" in /etc/rc.conf. What is displayed when entering the following commands? # ifconfig em0 # sysctl net.inet6.ip6.accept_rtadv -- Hiroki ----Security_Multipart(Fri_Oct__1_18_38_05_2010_567)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkylq/0ACgkQTyzT2CeTzy0e7wCdEVfr9P1ru1r699oe7PmDaVC0 ok4AnifHbgrI9Kvo/4CZO6eCN8Cmi5FW =Ws6L -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct__1_18_38_05_2010_567)---- From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 10:26:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69953106564A for ; Fri, 1 Oct 2010 10:26:22 +0000 (UTC) (envelope-from gsriram@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3D08FC14 for ; Fri, 1 Oct 2010 10:26:21 +0000 (UTC) Received: by qyk8 with SMTP id 8so1435119qyk.13 for ; Fri, 01 Oct 2010 03:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=HCtOFGt/ty4WLm5PqEwL/H/YdHrpSwNN3v6aFaoXOww=; b=Da5SrSR7YFLcPoT/B0CdNAzd0piiLqLNm7xHG/jqdOYOXoDs2ncnJo3Z2wW1uDPQwt gAIVX4ud5jJtx+j8NM1oWNex9cFdXSuByh7sY2x7yPQh9BUzhQEMk0VLhsywddhc1LNh rJ1+WmJtCvKkrtbtehxmqxNEaA7Me+9+wYb84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=q/MD2oGg4a8LkabriynCEBFWBNjwHe4GeOUIXJxAAj6aYc+bynvyK0W83JYyPtJiVK du+TXDvh8csQEkxCDETZDHpwg/MzIpM1JQjFf+1Y7W3X/6NLaOfMZww8i6uwvVvjybRz MLCrRkvjDG4zNBM/XWKwUD3doQTlEBm5ppk5w= MIME-Version: 1.0 Received: by 10.224.29.3 with SMTP id o3mr3580581qac.178.1285927289266; Fri, 01 Oct 2010 03:01:29 -0700 (PDT) Received: by 10.229.236.66 with HTTP; Fri, 1 Oct 2010 03:01:29 -0700 (PDT) Date: Fri, 1 Oct 2010 15:31:29 +0530 Message-ID: From: Sriram Gorti To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Question on TCP reassembly counter 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, 01 Oct 2010 10:26:22 -0000 Hi, In the following is an observation when testing our XLR/XLS network driver with 16 concurrent instances of netperf on FreeBSD-CURRENT. Based on this observation, I have a question on which I hope to get some understanding from here. When running 16 concurrent netperf instances (each for about 20 seconds), it was found that after some number of runs performance degraded badly (almost by a factor of 5). All subsequent runs remained so. Started debugging this from TCP-side as other driver tests were doing fine for comparably long durations on same board+s/w. netstat indicated the following: $ netstat -s -f inet -p tcp | grep discarded 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 7318 discarded due to memory problems Then, traced the "discarded due to memory problems" to the following counter: $ sysctl -a net.inet.tcp.reass net.inet.tcp.reass.overflows: 7318 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 1594 <--- // corresponds to V_tcp_reass_qsize variable net.inet.tcp.reass.maxsegments: 1600 Our guess for the need for reassembly (in this low-packet-loss test setup) was the lack of per-flow classification in the driver, causing it to spew incoming packets across the 16 h/w cpus instead of packets of a flow being sent to the same cpu. While we are working on addressing this driver limitation, debugged further to see how/why the V_tcp_reass_qsize grew (assuming that out-of-order segments should have dropped to zero at the end of the run). It was seen that this counter was actually growing up from the initial runs but only when it reached near to maxsgements, perf degradation was seen. Then, started looking at vmstat also to see how many of the reassembly segments were lost. But, there were no segments lost. We could not reconcile "no lost segments" with "growth of this counter across test runs". $ sysctl net.inet.tcp.reass ; vmstat -z | egrep "FREE|mbuf|tcpre" net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 147 net.inet.tcp.reass.maxsegments: 1600 ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP mbuf_packet: 256, 0, 4096, 3200, 5653833, 0, 0 mbuf: 256, 0, 1, 2048, 4766910, 0, 0 mbuf_cluster: 2048, 25600, 7296, 6, 7297, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 tcpreass: 20, 1690, 0, 845, 1757074, 0, 0 In view of these observations, my question is: is it possible for the V_tcp_reass_qsize variable to be unsafely updated on SMP ? (The particular flavor of XLS that was used in the test had 4 cores with 4 h/w threads/core). I see that the tcp_reass function assumes some lock is taken but not sure if it is the per-socket or the global tcp lock. Any inputs on what I missed are most welcome. Thanks, Sriram Gorti Netlogic Microsystems From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 12:13:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F5441065673 for ; Fri, 1 Oct 2010 12:13:24 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 416428FC18 for ; Fri, 1 Oct 2010 12:13:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 8D2C6509A5; Fri, 1 Oct 2010 13:13:23 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDptX19Pq+iy; Fri, 1 Oct 2010 13:13:23 +0100 (BST) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id A4284509A3; Fri, 1 Oct 2010 13:13:22 +0100 (BST) Received: from 68.64.144.221 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Fri, 1 Oct 2010 08:13:23 -0400 Message-ID: <0a85d5595ffdc548668406d3e87621c2.squirrel@nyi.unixathome.org> In-Reply-To: <20101001.183805.53791271.hrs@allbsd.org> References: <4CA55041.7040001@langille.org> <20101001.183805.53791271.hrs@allbsd.org> Date: Fri, 1 Oct 2010 08:13:23 -0400 From: "Dan Langille" To: "Hiroki Sato" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org, dan@langille.org Subject: Re: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 12:13:24 -0000 On Fri, October 1, 2010 5:38 am, Hiroki Sato wrote: > Dan Langille wrote > in <4CA55041.7040001@langille.org>: > > da> # cat /etc/rtadvd.conf > da> fxp1:\ > da> :addrs#1:addr="2001:470:1f07:b80::":prefixlen#64:tc=ether: > > In this case, you do not need rtadvd.conf. The command line "rtadvd > fxp1" should work fine. I have removed the .conf and restarted rtadvd > da> Where: fxp1 is on my internal LAN which has 2001:470:1f07:b80::1 as an > da> IP address. (you should be able to ping6 that). > > Can you show the results of "ifconfig fxp1"? # ifconfig fxp1 fxp1: flags=8843 metric 0 mtu 1500 options=9 ether 00:04:ac:d3:70:12 inet 10.55.0.1 netmask 0xffffff00 broadcast 10.55.0.255 inet6 2001:470:1f07:b80::1 prefixlen 64 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active > > Dan Langille wrote > in <4CA55725.10007@langille.org>: > > da> After I issued this command on the server: > da> > da> # route -n add -inet6 2001:470:1f07:b80::/64 -interface fxp1 > da> add net 2001:470:1f07:b80::/64: gateway fxp1 > > I do not think this is needed if you did "ifconfig fxp1 inet6 > 2001:470:1f07:b80::1/64". > > Dan Langille wrote > in <4CA56123.2030304@langille.org>: > > da> However, clients on my LAN are unable to get any IPv6 routing > da> information despite having ipv6_enable="YES" in /etc/rc.conf. > > What is displayed when entering the following commands? > > # ifconfig em0 > # sysctl net.inet6.ip6.accept_rtadv # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:1b:21:51:ab:2d inet 10.55.0.44 netmask 0xffffff00 broadcast 10.55.0.255 inet6 fe80::21b:21ff:fe51:ab2d%em0 prefixlen 64 scopeid 0x1 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active # sysctl net.inet6.ip6.accept_rtadv net.inet6.ip6.accept_rtadv: 1 This is after running netsol em0 -- Dan Langille -- http://langille.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 12:20:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B22B106566B for ; Fri, 1 Oct 2010 12:20:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1A68FC14 for ; Fri, 1 Oct 2010 12:20:01 +0000 (UTC) Received: (qmail 29853 invoked from network); 1 Oct 2010 12:11:50 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Oct 2010 12:11:50 -0000 Message-ID: <4CA5D1F0.3000307@freebsd.org> Date: Fri, 01 Oct 2010 14:20:00 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Sriram Gorti References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Question on TCP reassembly counter 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, 01 Oct 2010 12:20:02 -0000 On 01.10.2010 12:01, Sriram Gorti wrote: > Hi, > > In the following is an observation when testing our XLR/XLS network > driver with 16 concurrent instances of netperf on FreeBSD-CURRENT. > Based on this observation, I have a question on which I hope to get > some understanding from here. > > When running 16 concurrent netperf instances (each for about 20 > seconds), it was found that after some number of runs performance > degraded badly (almost by a factor of 5). All subsequent runs remained > so. Started debugging this from TCP-side as other driver tests were > doing fine for comparably long durations on same board+s/w. > > netstat indicated the following: > > $ netstat -s -f inet -p tcp | grep discarded > 0 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 7318 discarded due to memory problems > > Then, traced the "discarded due to memory problems" to the following counter: > > $ sysctl -a net.inet.tcp.reass > net.inet.tcp.reass.overflows: 7318 > net.inet.tcp.reass.maxqlen: 48 > net.inet.tcp.reass.cursegments: 1594<--- // corresponds to > V_tcp_reass_qsize variable > net.inet.tcp.reass.maxsegments: 1600 > > Our guess for the need for reassembly (in this low-packet-loss test > setup) was the lack of per-flow classification in the driver, causing > it to spew incoming packets across the 16 h/w cpus instead of packets > of a flow being sent to the same cpu. While we are working on > addressing this driver limitation, debugged further to see how/why the > V_tcp_reass_qsize grew (assuming that out-of-order segments should > have dropped to zero at the end of the run). It was seen that this > counter was actually growing up from the initial runs but only when it > reached near to maxsgements, perf degradation was seen. Then, started > looking at vmstat also to see how many of the reassembly segments were > lost. But, there were no segments lost. We could not reconcile "no > lost segments" with "growth of this counter across test runs". A patch is in the works to properly autoscale the reassembly queue and should be comitted shortly. > $ sysctl net.inet.tcp.reass ; vmstat -z | egrep "FREE|mbuf|tcpre" > net.inet.tcp.reass.overflows: 0 > net.inet.tcp.reass.maxqlen: 48 > net.inet.tcp.reass.cursegments: 147 > net.inet.tcp.reass.maxsegments: 1600 > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > mbuf_packet: 256, 0, 4096, 3200, 5653833, 0, 0 > mbuf: 256, 0, 1, 2048, 4766910, 0, 0 > mbuf_cluster: 2048, 25600, 7296, 6, 7297, 0, 0 > mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0, 0 > mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 > tcpreass: 20, 1690, 0, 845, 1757074, 0, 0 > > In view of these observations, my question is: is it possible for the > V_tcp_reass_qsize variable to be unsafely updated on SMP ? (The > particular flavor of XLS that was used in the test had 4 cores with 4 > h/w threads/core). I see that the tcp_reass function assumes some lock > is taken but not sure if it is the per-socket or the global tcp lock. The updating of the global counter is indeed unsafe and becomes obsolete with the autotuning patch. The patch is reviewed by me and ready for commit. However lstewart@ is currently writing his thesis and has only very little spare time. I'll send you the patch in private email so you can continue your testing. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 12:31:44 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9335F106566C for ; Fri, 1 Oct 2010 12:31:44 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB6278FC0C for ; Fri, 1 Oct 2010 12:31:43 +0000 (UTC) Received: from alph.d.allbsd.org (p2176-ipbf406funabasi.chiba.ocn.ne.jp [124.86.72.176]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id o91CVLLb030819; Fri, 1 Oct 2010 21:31:31 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o91CVJjw056479; Fri, 1 Oct 2010 21:31:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 01 Oct 2010 21:31:07 +0900 (JST) Message-Id: <20101001.213107.204806220.hrs@allbsd.org> To: dan@langille.org From: Hiroki Sato In-Reply-To: <0a85d5595ffdc548668406d3e87621c2.squirrel@nyi.unixathome.org> References: <4CA55041.7040001@langille.org> <20101001.183805.53791271.hrs@allbsd.org> <0a85d5595ffdc548668406d3e87621c2.squirrel@nyi.unixathome.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Oct__1_21_31_07_2010_698)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Fri, 01 Oct 2010 21:31:36 +0900 (JST) X-Spam-Status: No, score=-99.1 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, QENCPTR1,RCVD_IN_CHINA,RCVD_IN_CHINA_KR,RCVD_IN_PBL,RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 12:31:44 -0000 ----Security_Multipart(Fri_Oct__1_21_31_07_2010_698)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Dan Langille" wrote in <0a85d5595ffdc548668406d3e87621c2.squirrel@nyi.unixathome.org>: da> > Can you show the results of "ifconfig fxp1"? da> da> # ifconfig fxp1 da> fxp1: flags=8843 metric 0 mtu 1500 da> options=9 da> ether 00:04:ac:d3:70:12 da> inet 10.55.0.1 netmask 0xffffff00 broadcast 10.55.0.255 da> inet6 2001:470:1f07:b80::1 prefixlen 64 da> nd6 options=3 da> media: Ethernet autoselect (100baseTX ) da> status: active The fxp1 should have "inet6 fe80::0204:acff:fed3:7012%fxp1 prefixlen 64" here. Do you set ipv6_enable="YES" in rc.conf on the router box? If not, the fe80:: address is not automatically added, and probably you will have trouble in IPv6 configuration in various ways. -- Hiroki ----Security_Multipart(Fri_Oct__1_21_31_07_2010_698)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkyl1IsACgkQTyzT2CeTzy3htwCePQxyYk7F3UknFjnS7r2btjSo rwoAn28kIpyrJfyy++ToANN7Sq3voIbR =1tOf -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct__1_21_31_07_2010_698)---- From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 12:47:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E709210656A7; Fri, 1 Oct 2010 12:47:08 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF2D8FC08; Fri, 1 Oct 2010 12:47:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 1CD5C509A5; Fri, 1 Oct 2010 13:47:08 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI14hTFyOd2V; Fri, 1 Oct 2010 13:47:07 +0100 (BST) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 33A5A509A3; Fri, 1 Oct 2010 13:47:07 +0100 (BST) Received: from 68.64.144.221 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Fri, 1 Oct 2010 08:47:07 -0400 Message-ID: <568354c2dd7591fe54cb183ec92c55b1.squirrel@nyi.unixathome.org> In-Reply-To: <20101001.213107.204806220.hrs@allbsd.org> References: <4CA55041.7040001@langille.org> <20101001.183805.53791271.hrs@allbsd.org> <0a85d5595ffdc548668406d3e87621c2.squirrel@nyi.unixathome.org> <20101001.213107.204806220.hrs@allbsd.org> Date: Fri, 1 Oct 2010 08:47:07 -0400 From: "Dan Langille" To: "Hiroki Sato" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org Subject: Re: ipv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 12:47:09 -0000 On Fri, October 1, 2010 8:31 am, Hiroki Sato wrote: > "Dan Langille" wrote > in <0a85d5595ffdc548668406d3e87621c2.squirrel@nyi.unixathome.org>: > > da> > Can you show the results of "ifconfig fxp1"? > da> > da> # ifconfig fxp1 > da> fxp1: flags=8843 metric 0 mtu > 1500 > da> options=9 > da> ether 00:04:ac:d3:70:12 > da> inet 10.55.0.1 netmask 0xffffff00 broadcast 10.55.0.255 > da> inet6 2001:470:1f07:b80::1 prefixlen 64 > da> nd6 options=3 > da> media: Ethernet autoselect (100baseTX ) > da> status: active > > The fxp1 should have "inet6 fe80::0204:acff:fed3:7012%fxp1 prefixlen > 64" here. [root@bast:~] # ifconfig fxp1 inet6 fe80::0204:acff:fed3:7012%fxp1 prefixlen 64 [root@bast:~] # ifconfig fxp1 fxp1: flags=8843 metric 0 mtu 1500 options=9 ether 00:04:ac:d3:70:12 inet 10.55.0.1 netmask 0xffffff00 broadcast 10.55.0.255 inet6 2001:470:1f07:b80::1 prefixlen 64 inet6 fe80::204:acff:fed3:7012%fxp1 prefixlen 64 scopeid 0x2 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active > Do you set ipv6_enable="YES" in rc.conf on the router box? If not, > the fe80:: address is not automatically added, and probably you will > have trouble in IPv6 configuration in various ways. Yes, it is there. I suspect the address was removed when I was working on this late Thursday night. # grep ipv6_enable /etc/rc.conf ipv6_enable="YES" Ahhh! [root@bast:~] # /etc/rc.d/rtadvd restart Stopping rtadvd. Waiting for PIDS: 98221. Starting rtadvd. [root@bast:~] # ifconfig fxp1 fxp1: flags=8843 metric 0 mtu 1500 options=9 ether 00:04:ac:d3:70:12 inet 10.55.0.1 netmask 0xffffff00 broadcast 10.55.0.255 inet6 2001:470:1f07:b80::1 prefixlen 64 inet6 fe80::204:acff:fed3:7012%fxp1 prefixlen 64 scopeid 0x2 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active [root@bast:~] # [root@kraken ~]# rtsol em0 [root@kraken ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:1b:21:51:ab:2d inet 10.55.0.44 netmask 0xffffff00 broadcast 10.55.0.255 inet6 fe80::21b:21ff:fe51:ab2d%em0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f07:b80:21b:21ff:fe51:ab2d prefixlen 64 autoconf nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active [root@kraken ~]# $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2001:470:1f07:b80:21b:21ff:fe51:ab2d --> 2001:4860:800f::63 16 bytes from 2001:4860:800f::63, icmp_seq=0 hlim=57 time=23.122 ms 16 bytes from 2001:4860:800f::63, icmp_seq=1 hlim=57 time=22.188 ms 16 bytes from 2001:4860:800f::63, icmp_seq=2 hlim=57 time=20.816 ms ^C --- ipv6.l.google.com ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 20.816/22.042/23.122/0.947 ms Thank you for your help. I appreciate it. :) -- Dan Langille -- http://langille.org/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 20:25:28 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E24A106566C for ; Fri, 1 Oct 2010 20:25:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id E9C308FC15 for ; Fri, 1 Oct 2010 20:25:27 +0000 (UTC) Received: (qmail 4060 invoked by uid 399); 1 Oct 2010 20:25:25 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Oct 2010 20:25:25 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CA643B4.90109@FreeBSD.org> Date: Fri, 01 Oct 2010 13:25:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@FreeBSD.org> <20100930231715.D95502@maildrop.int.zabbadoz.net> In-Reply-To: <20100930231715.D95502@maildrop.int.zabbadoz.net> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:25:28 -0000 I'm going to combine all of my responses into one message since it will be my last on the topic. It's pretty clear to me at this point that the code is going in, so I will make one last attempt to clarify my points in the hope that they are beneficial to anyone who is actually interested in learning. On 9/30/2010 4:38 PM, Bjoern A. Zeeb wrote: > On Thu, 30 Sep 2010, Doug Barton wrote: > > Hey, > >> In any case I didn't say that 6rd was not useful at all. What I tried >> to make the case for is that its utility is limited, both in the >> absolute sense and in the temporal sense; and that because of these >> limitations the benefits that adding the code bring are outweighed by >> the costs of maintaining it past what will likely be its useful lifetime. > > The maintainance costs are effectively pretty low, especially as it's > coming > with stf; it's a single line in a kernel config and not many more files but > it will have great value to a lot of people the next years. From your statement above it's not clear to me that you have actually reviewed the diff. However your last statement is assuming the point that we're trying to discuss. You're basically saying "it's good because it's good" which isn't particularly helpful. >> My point about FreeBSD 9 is that if we add the 6rd code today, then >> release 9.0 in about a year, then support the RELENG_9 branch for 4-6 >> years that we will still be maintaining code that no one has any use >> for. Sorry if I wasn't clear. > > While I would like to live in that kind of world that by mid 10s all > the tunneling, transition, .. technologies would be gone, ideally > along with legacy IP, I guess you are massively underestimating this > from the early adopters point of view; while for some of us things > have happened and we are waiting for the world to catch up, for other > folks things might not start within the another product lifecycle. > I am sure we'll see a lot of different scenarios for quite some time. > I would expect that we'll still be shipping that code in at least 12.x. I am not saying, nor have I ever said that the complete IPv4 -> IPv6 transition will be complete in the next 5 years. What I am saying is that 6rd, as one particular transition mechanism, will have very limited value, and that the value of it is vastly exceeded by the short term instability and long term support issues that adding it will create. >> In contrast, the bit of my post that you snipped suggested that a >> better course of action would be to focus on the areas of our v6 stack >> that will be used for the lifetime of the protocol, like the >> performance penalty that currently exists for the v6 loopback device. > > I think that noone questions that this will need time as well and so > do another 15 things on the IPv6 side but maybe someone is already > working on it .. Hope is not a plan. :) On 10/1/2010 12:43 AM, Lars Eggert wrote: > > You're seriously underestimating the transition time needed for IPv6. Actually I think based on my extensive experience in this area I'm in a very good position to forecast what's going to happen, but as I've said several times now the overall time that the total v4->v6 transition will take is not relevant to my argument about this code. On 10/1/2010 2:09 AM, Hiroki Sato wrote: > There is no trade-off between improving robustness/performance of the > basic functionality and adding a new protocol in this case. The > negative impact of adding 6rd is quite small if any, and we have > nothing to lose even if 6rd will be useless some day. http://en.wikipedia.org/wiki/Opportunity_cost (seriously, you're part of the project leadership you really should develop an understanding of this topic). Short version, every second you spend doing something that has less overall utility for the project is a second that you cannot spend doing something that has more utility. You and gnn identified the performance penalty on the loopback interface months ago, and told me that it was a massive problem that prevented us from being able to make preferring IPv6 the default. Given that no matter what happens in IPv6 transition land we're always going to need the loopback address, would you not agree that solving that problem is more important than adding new flavors of STF? Doug From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 21:40:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECC24106564A for ; Fri, 1 Oct 2010 21:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C215A8FC17 for ; Fri, 1 Oct 2010 21:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o91Le49J022681 for ; Fri, 1 Oct 2010 21:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o91Le4GV022680; Fri, 1 Oct 2010 21:40:04 GMT (envelope-from gnats) Date: Fri, 1 Oct 2010 21:40:04 GMT Message-Id: <201010012140.o91Le4GV022680@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Nicola Tiling Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nicola Tiling List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:40:05 -0000 The following reply was made to PR kern/146792; it has been noted by GNATS. From: Nicola Tiling To: bug-followup@FreeBSD.org, niko@gtelecom.ru Cc: Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load Date: Fri, 1 Oct 2010 23:19:17 +0200 --Apple-Mail-3-570601307 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Today I recognize also 100 % CPU load by flowcleaner. Machine is a fresh installed 8.1 stable with *no* router functionality = but with opennms - a netmanagement application - installed.=20 Nicola= --Apple-Mail-3-570601307 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOdDCCBoow ggVyoAMCAQICAwE4+DANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEwMDQyNjE2MTY1NloXDTExMDQyODAzMzEwMlowgYkxIDAeBgNVBA0TFzE4NjUxNS0xZTZL UFU4bVFTS05jaFQ2MR4wHAYDVQQKExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxKTAnBgNVBAMTIFN0 YXJ0Q29tIEZyZWUgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYJKoZIhvcNAQkBFgtudGlAdzR3Lm5l dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOuNCGJ/TSCscEZjBvLH+umUC4cUbFJQ I8BT27bygDWugqz8885U281Tso92HCfToo81WySIBITQPsO3rr62DPCilK/hQVoSYVsujaw7UFo2 sfmun/zvYhPKXu1EjN1AcD1rQ4wrh+yVSf6/ICENIuKz7B7G0i2OWLXHp08GuM9a2liPGU1NNw/5 TYPacCX1yI8LNiTQs+pVunV1F6ApFaHgZMNUOrfAOXULzF4Kwak2XFt3k5OJtWvAFQA/WBLgFAyC hWUN4kpJJwA2QrOiiAABNu28bubOQyXwzm4W2snq8Q5vFLWxjbCovpTo++63slzD9H5vcinu5yti epsHzHUCAwEAAaOCAvQwggLwMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUfOopkXLofBSTotwRG9r7vMzUtRswHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwFgYDVR0RBA8wDYELbnRpQHc0dy5uZXQwggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20v aW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGR TGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhl IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBABrEhQYXIthY 8q8cwfqklVtGdZvQsnmpOa1N51ZflXbJY5JuojJc2JDRMUi7MaDp0UpTmnl8F43uFtHwc0N0kCPw VzkzWs+61r1tYbwMh4x8NxwQ7U1zFGteD4RqvUoPlLzPpFsuW00YArGWXljdFhBPmRU5HFghs0ZO kzVdwqL9z/DhDPgdRIojz8qBV4BF2xyma0JIR46i2FDLUrDHkynk0LbvdH5Z8mUGjhXeBY8HgTao DxzjdNPNTfB2g2DhucvVeruGyIbGGdLLST+I5UKag2Va1Ig/pc1brFmrl55gcU8RlxV6W70ie6uM rUo5x+LxRdAOBdvxTWKS7HmpxfgwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0wNzEwMjQyMTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4T q5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYz oVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQ eGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/X e2AC/Y7zeEsnR7FOp+uXAgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcw yjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8w LQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBX MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEE AYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBk ZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIB ARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9u cyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQD AgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b /B3GLDAgoLeTJv3xArbNESi/Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEA OmQ+t+b/xLOMa0m18zoRqW4k6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUk NzTC7IVpmYVsKuNOnxE1jJFZNNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8v rOvD0g5g7dA4pkOAU2Ed4pSCowBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJa LMAmu6GZs5Xgsbzn0wUJvbD9h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6 J4uqNAxzoa5RxkBA5a/3qlbgF9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85 OJEnCx/quShWA6w318LDnba3M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26os Mg64CbZsDVrEDr7uSMV40ieBJTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1 pbyFWKvyYmdungJtySWUMw+R5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMBOPgwCQYFKw4DAhoFAKCCAa8wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMDAxMjExOTE3WjAjBgkq hkiG9w0BCQQxFgQUnWq9qDRDuUn6fu/LFj1AKHZBUXYwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMBOPgwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwE4+DANBgkqhkiG9w0BAQEFAASCAQAaYytsXIzlJuEA D39UwkpUn0Ulr1ifwKsIU/AczZv2r44zQ8jxIt7C1Z0JZSWRIXmxmZidfsqothinkfr3UoGN6uf0 3SqDsBCT3u6CRjxp6d7Y99HnhcRt2/vJ39Y0owg8YpsC/wKoA6v3+ckasfkdq9GCogXbXu6orRtb WVZ/sDwAc+NEh7qTEytQJc3D5U/MUmkChqPxQ5h4ajh3ASD5qeQRHGB12MH8PsYaO439Zw/4pJWk kVhaEzge1OJ7x8+CeACxs22ausv/2mLAUPqVmrz4+20hNMe1HIGgtMppR9/VcVUqKYuemDQUc6aW PSenCBdNv/k8gbFIEHNNN7KfAAAAAAAA --Apple-Mail-3-570601307-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 10:00:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17AA71065670 for ; Sat, 2 Oct 2010 10:00:25 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from gwgy.x.rootbsd.net (gwgy.x.rootbsd.net [204.109.59.162]) by mx1.freebsd.org (Postfix) with ESMTP id E56FA8FC19 for ; Sat, 2 Oct 2010 10:00:24 +0000 (UTC) Received: from c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se (c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se [213.113.54.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by unicornio.localdomain (Postfix) with ESMTPSA id DDA8986510 for ; Sat, 2 Oct 2010 11:47:08 +0200 (CEST) Message-ID: <4CA6FF9A.9090502@minibofh.org> Date: Sat, 02 Oct 2010 11:47:06 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: TCP 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, 02 Oct 2010 10:00:25 -0000 Hi all, I've read this interesting article: http://www.packetstan.com/2010/09/openbsd-timestamps.html The question is simple żIs there some way in FreeBSD to randomize the TCP timestamps as OpenBSD does by default? I guess some sysctl statement should do it, but I don't know. Thanks. -- I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 10:00:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1950D106566B for ; Sat, 2 Oct 2010 10:00:25 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from gwgy.x.rootbsd.net (gwgy.x.rootbsd.net [204.109.59.162]) by mx1.freebsd.org (Postfix) with ESMTP id E57608FC1A for ; Sat, 2 Oct 2010 10:00:24 +0000 (UTC) Received: from c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se (c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se [213.113.54.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gwgy.x.rootbsd.net (Postfix) with ESMTPSA id 77526865D7 for ; Sat, 2 Oct 2010 11:52:28 +0200 (CEST) Message-ID: <4CA700DB.1090001@minibofh.org> Date: Sat, 02 Oct 2010 11:52:27 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: TCP 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, 02 Oct 2010 10:00:25 -0000 Hi all, I've read this interesting article: http://www.packetstan.com/2010/09/openbsd-timestamps.html The question is simple żIs there some way in FreeBSD to randomize the TCP timestamps as OpenBSD does by default? I guess some sysctl statement should do it, but I don't know. Thanks. -- I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 10:05:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B5F106564A for ; Sat, 2 Oct 2010 10:05:25 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from gwgy.x.rootbsd.net (gwgy.x.rootbsd.net [204.109.59.162]) by mx1.freebsd.org (Postfix) with ESMTP id E4EAC8FC13 for ; Sat, 2 Oct 2010 10:05:24 +0000 (UTC) Received: from c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se (c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se [213.113.54.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by minibofh.org (Postfix) with ESMTPSA id B39548621F for ; Sat, 2 Oct 2010 11:49:50 +0200 (CEST) Message-ID: <4CA7003D.4000509@minibofh.org> Date: Sat, 02 Oct 2010 11:49:49 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: TCP 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, 02 Oct 2010 10:05:25 -0000 Hi all, I've read this interesting article: http://www.packetstan.com/2010/09/openbsd-timestamps.html The question is simple żIs there some way in FreeBSD to randomize the TCP timestamps as OpenBSD does by default? I guess some sysctl statement should do it, but I don't know. Thanks. -- I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 10:05:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F4A1065672 for ; Sat, 2 Oct 2010 10:05:25 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from gwgy.x.rootbsd.net (gwgy.x.rootbsd.net [204.109.59.162]) by mx1.freebsd.org (Postfix) with ESMTP id E4E088FC12 for ; Sat, 2 Oct 2010 10:05:24 +0000 (UTC) Received: from c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se (c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se [213.113.54.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gwgy.x.rootbsd.net (Postfix) with ESMTPSA id 5054E864F8 for ; Sat, 2 Oct 2010 11:57:09 +0200 (CEST) Message-ID: <4CA701F4.2030400@minibofh.org> Date: Sat, 02 Oct 2010 11:57:08 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: TCP 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, 02 Oct 2010 10:05:25 -0000 Hi all, I've read this interesting article: http://www.packetstan.com/2010/09/openbsd-timestamps.html The question is simple żIs there some way in FreeBSD to randomize the TCP timestamps as OpenBSD does by default? I guess some sysctl statement should do it, but I don't know. Thanks. -- I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 10:05:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1872F1065673 for ; Sat, 2 Oct 2010 10:05:25 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from gwgy.x.rootbsd.net (gwgy.x.rootbsd.net [204.109.59.162]) by mx1.freebsd.org (Postfix) with ESMTP id E83E48FC14 for ; Sat, 2 Oct 2010 10:05:24 +0000 (UTC) Received: from c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se (c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se [213.113.54.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gwgy.x.rootbsd.net (Postfix) with ESMTPSA id 9CB8B865D8 for ; Sat, 2 Oct 2010 11:55:53 +0200 (CEST) Message-ID: <4CA701A8.2080809@minibofh.org> Date: Sat, 02 Oct 2010 11:55:52 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: TCP 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, 02 Oct 2010 10:05:25 -0000 Hi all, I've read this interesting article: http://www.packetstan.com/2010/09/openbsd-timestamps.html The question is simple żIs there some way in FreeBSD to randomize the TCP timestamps as OpenBSD does by default? I guess some sysctl statement should do it, but I don't know. Thanks. -- I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 10:07:36 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06317106566B for ; Sat, 2 Oct 2010 10:07:36 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from gwgy.x.rootbsd.net (gwgy.x.rootbsd.net [204.109.59.162]) by mx1.freebsd.org (Postfix) with ESMTP id D2BE78FC15 for ; Sat, 2 Oct 2010 10:07:35 +0000 (UTC) Received: from c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se (c-043671d5.01-140-73746f22.cust.bredbandsbolaget.se [213.113.54.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gwgy.x.rootbsd.net (Postfix) with ESMTPSA id 31ACE8621F for ; Sat, 2 Oct 2010 12:07:35 +0200 (CEST) Message-ID: <4CA70465.9090202@minibofh.org> Date: Sat, 02 Oct 2010 12:07:33 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CA701A8.2080809@minibofh.org> In-Reply-To: <4CA701A8.2080809@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: TCP 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, 02 Oct 2010 10:07:36 -0000 It seems my server is missconfigured and I see this message several times. Sorry for that, of course. Admins, feel free to delete all the same messages but one. ;) -- I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 15:29:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B1AB1065672; Sat, 2 Oct 2010 15:29:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 67B9A8FC12; Sat, 2 Oct 2010 15:29:33 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D4BDA46B49; Sat, 2 Oct 2010 11:29:32 -0400 (EDT) Date: Sat, 2 Oct 2010 16:29:32 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4CA51024.8020307@freebsd.org> Message-ID: References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ryan Stone , FreeBSD Net Subject: Re: mbuf changes 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, 02 Oct 2010 15:29:33 -0000 On Thu, 30 Sep 2010, Julian Elischer wrote: > On 9/30/10 10:49 AM, Ryan Stone wrote: >> It's not a big thing but it would be nice to replace the m_next and >> m_nextpkt fields with queue.h macros. >> > funny, I've never even thought of that.. I have, and it's a massive change touching code all over the kernel in vast quantities. While in principle it's a good idea (consistently avoid hand-crafted linked lists), it's something I'd discourage on the basis that it probably won't significant reduce the kernel bug count, but will make it even harder for vendors with large local changes to the network stack to keep up. (We might consider revisiting the proposal for 10.0, perhaps? I'd rather we burnt the cycles on fleshing out network stack virtualization more thoroughly for 9.x though.) Robert From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 19:33:14 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4188106564A for ; Sat, 2 Oct 2010 19:33:14 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1528FC15 for ; Sat, 2 Oct 2010 19:33:14 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 6FE2C11B8A7; Sat, 2 Oct 2010 14:07:05 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id HHAO5LPYS6DV; Sat, 02 Oct 2010 14:07:05 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sat, 2 Oct 2010 20:07:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> To: Robert Watson X-Mailer: Apple Mail (2.1081) Cc: Ryan Stone , FreeBSD Net Subject: Re: mbuf changes 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, 02 Oct 2010 19:33:14 -0000 On 2 Oct 2010, at 16:29, Robert Watson wrote: > On Thu, 30 Sep 2010, Julian Elischer wrote: >=20 >> On 9/30/10 10:49 AM, Ryan Stone wrote: >>> It's not a big thing but it would be nice to replace the m_next and = m_nextpkt fields with queue.h macros. >> funny, I've never even thought of that.. >=20 > I have, and it's a massive change touching code all over the kernel in = vast quantities. While in principle it's a good idea (consistently = avoid hand-crafted linked lists), it's something I'd discourage on the = basis that it probably won't significant reduce the kernel bug count, = but will make it even harder for vendors with large local changes to the = network stack to keep up. I think it could also increase the kernel bug count. Unfortunately, we = can't do this incrementally. > (We might consider revisiting the proposal for 10.0, perhaps? I'd = rather we burnt the cycles on fleshing out network stack virtualization = more thoroughly for 9.x though.) I agree that this doesn't bring us a great improvement for the amount of = work that's required. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 21:01:33 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCFDA106566C; Sat, 2 Oct 2010 21:01:33 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 75F198FC0A; Sat, 2 Oct 2010 21:01:33 +0000 (UTC) Received: by qwd6 with SMTP id 6so2701882qwd.13 for ; Sat, 02 Oct 2010 14:01:32 -0700 (PDT) Received: by 10.224.45.135 with SMTP id e7mr5228880qaf.390.1286051777838; Sat, 02 Oct 2010 13:36:17 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.229.239.72 with HTTP; Sat, 2 Oct 2010 13:35:57 -0700 (PDT) In-Reply-To: <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> From: Juli Mallett Date: Sat, 2 Oct 2010 13:35:57 -0700 X-Google-Sender-Auth: 7LqkUdxHoM_harpPhI0FxuvSfMk Message-ID: To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ryan Stone , Robert Watson , FreeBSD Net Subject: Re: mbuf changes 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, 02 Oct 2010 21:01:33 -0000 On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote: > On 2 Oct 2010, at 16:29, Robert Watson wrote: >> On Thu, 30 Sep 2010, Julian Elischer wrote: >>> On 9/30/10 10:49 AM, Ryan Stone wrote: >>>> It's not a big thing but it would be nice to replace the m_next and m_= nextpkt fields with queue.h macros. >>> funny, I've never even thought of that.. >> >> I have, and it's a massive change touching code all over the kernel in v= ast quantities. =A0While in principle it's a good idea (consistently avoid = hand-crafted linked lists), it's something I'd discourage on the basis that= it probably won't significant reduce the kernel bug count, but will make i= t even harder for vendors with large local changes to the network stack to = keep up. > > I think it could also increase the kernel bug count. Unfortunately, we ca= n't do this incrementally. Can't we? What about a union, so that we can gradually convert things but keep ABI and API compatibility? I mean, as long as we use the right queue.h type, anyway, it should be consistent? STAILQ, presumably. From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 21:15:49 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F3531065670 for ; Sat, 2 Oct 2010 21:15:49 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F89E8FC0C for ; Sat, 2 Oct 2010 21:15:48 +0000 (UTC) Received: (qmail 47362 invoked from network); 2 Oct 2010 21:07:21 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Oct 2010 21:07:21 -0000 Message-ID: <4CA7A103.3050000@freebsd.org> Date: Sat, 02 Oct 2010 23:15:47 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Jordi Espasa Clofent References: <4CA6FF9A.9090502@minibofh.org> In-Reply-To: <4CA6FF9A.9090502@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: TCP 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, 02 Oct 2010 21:15:49 -0000 On 02.10.2010 11:47, Jordi Espasa Clofent wrote: > Hi all, > > I've read this interesting article: > http://www.packetstan.com/2010/09/openbsd-timestamps.html > > The question is simple > > żIs there some way in FreeBSD to randomize the TCP timestamps as OpenBSD does by default? I guess > some sysctl statement should do it, but I don't know. The timestamps on FreeBSD for passive open are randomized as long as you use SYN cookies (enabled by default). For passive open they are not (yet) randomized. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 23:29:25 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5333106566C; Sat, 2 Oct 2010 23:29:25 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 63A538FC1B; Sat, 2 Oct 2010 23:29:25 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id A033811B887; Sat, 2 Oct 2010 18:29:24 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id 7HXEFN76VTP1; Sat, 02 Oct 2010 18:29:24 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sun, 3 Oct 2010 00:29:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> To: Juli Mallett X-Mailer: Apple Mail (2.1081) Cc: Ryan Stone , Robert Watson , FreeBSD Net Subject: Re: mbuf changes 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, 02 Oct 2010 23:29:25 -0000 On 2 Oct 2010, at 21:35, Juli Mallett wrote: > On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote: >> On 2 Oct 2010, at 16:29, Robert Watson wrote: >>> On Thu, 30 Sep 2010, Julian Elischer wrote: >>>> On 9/30/10 10:49 AM, Ryan Stone wrote: >>>>> It's not a big thing but it would be nice to replace the m_next = and m_nextpkt fields with queue.h macros. >>>> funny, I've never even thought of that.. >>>=20 >>> I have, and it's a massive change touching code all over the kernel = in vast quantities. While in principle it's a good idea (consistently = avoid hand-crafted linked lists), it's something I'd discourage on the = basis that it probably won't significant reduce the kernel bug count, = but will make it even harder for vendors with large local changes to the = network stack to keep up. >>=20 >> I think it could also increase the kernel bug count. Unfortunately, = we can't do this incrementally. >=20 > Can't we? What about a union, so that we can gradually convert things > but keep ABI and API compatibility? I mean, as long as we use the > right queue.h type, anyway, it should be consistent? STAILQ, > presumably. Well, I don't have the layout of the mbuf struct offhand, but it's an = idea worth investigating. Regards, -- Rui Paulo