From owner-freebsd-net@FreeBSD.ORG Sun Jun 22 08:43:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C5B106568C for ; Sun, 22 Jun 2008 08:43:17 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id A4E1C8FC19 for ; Sun, 22 Jun 2008 08:43:15 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 11756 invoked by uid 98); 22 Jun 2008 08:43:14 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.038991 secs); 22 Jun 2008 08:43:14 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.038991 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 22 Jun 2008 08:43:13 -0000 Message-ID: <485E109C.9060705@zirakzigil.org> Date: Sun, 22 Jun 2008 10:43:08 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: Primeroz lists References: <4859877A.3020300@zirakzigil.org> <4859A3A1.6070105@pce-net.com> <485A28ED.9020103@zirakzigil.org> <55b8c6fe0806190330p225ec6d1g65f8424efeab9b41@mail.gmail.com> <485A3DC6.2030500@zirakzigil.org> <55b8c6fe0806190417r440045e6ncf6e99945c453f10@mail.gmail.com> In-Reply-To: <55b8c6fe0806190417r440045e6ncf6e99945c453f10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Han Hwei Woo Subject: Re: Problems with vlan + carp + alias X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jun 2008 08:43:17 -0000 Primeroz lists wrote: > What is tcpdump showing for ping on 192.168.10.11 > ? can you see echo reply exiting vlan10 > interface ? > > what if you try from your server to "ping -S 192.168.10.11 > 192.168.10.254 " ? > > > First of all I'm sorry for the late reply. Yesterday I could do some more in-depth test to analyze this strange behavior of my firewall. The 192.168.10.0/24 range I used in the previous example isn't the real one, I just used it for simplicity´s sake. The true range, the one which has been assigned by the ISP to my customer is: x.y.z.128/27. (x.y.z corresponds to a true public IP address) I've deactivated the firewall, so we have one less thing to worry about: /etc/rc.d/pf stop This is a pure network configuration issue. Here is the relevant part in /etc/rc.conf: --------------------------------------------------- ... ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" ... cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 carp30 carp40 carp128" ... ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 vlandev bce0" ... ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255" ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255" ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255" ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255" ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255" ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255" ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255" ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255" ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255" ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255" ... defaultrouter="x.y.z.129" --------------------------------------------------- On my managed switch I've set 2 ports: 1) the one where the bce0 interface is plugged in : mode trunk with all the vlans above 2) the one where the ISP internet is plugged in : mode access with vlan 128 I've also set the ip interface of my switch to x.y.z.155 vlan 128 Here is the relevant part of netstat -rn on my machine --------------------------------------------------- default x.y.z.129 UGS 0 13966 vlan12 x.y.z/27 link#11 UC 0 0 vlan12 x.y.z.132 x.y.z.132 UH 0 0 carp12 x.y.z.133 x.y.z.133 UH 0 0 carp12 x.y.z.134 x.y.z.134 UH 0 0 carp12 x.y.z.135 x.y.z135 UH 0 0 carp12 x.y.z.136 x.y.z.136 UH 0 0 carp12 x.y.z.137 x.y.z.137 UH 0 0 carp12 x.y.z.138 x.y.z.138 UH 0 0 carp12 x.y.z.139 x.y.z.139 UH 0 0 carp12 x.y.z.140 x.y.z.140 UH 0 0 carp12 x.y.z.141 x.y.z.141 UH 0 0 carp12 x.y.z.155 00:1e:c9:90:4a:c0 UHLW 1 8 vlan12 1183 --------------------------------------------------- Here come the tests. 1) From the firewall : basic I can ping both the default gateway (x.y.z.129) and the switch interface (x.y.z.155) I can ping a generic internet address (a.b.c.d) With tcpdump I can see the packets leaving as x.y.z.157 and coming with the same address 2) from the switch : basic I can ping the firewall's vlan address (x.y.z.157) I can ping _ALL_ the carp interfaces, base and alias: ping x.y.z.157 -> OK ping x.y.z.132 -> OK ping x.y.z.133 -> OK ... ping x.y.z.141 -> OK 3) from the internet : basic From an external internet address I can ping the vlan address: ping x.y.z.157 -> OK 4) from the firewall : advanced From the firewall I can ping the switch address from one of the carp base and aliased address: ping -S x.y.z.132 x.y.z.155 -> OK ping -S x.y.z.133 x.y.z.155 -> OK I _cannot_ ping the default router from one of the carp addresses: ping -S x.y.z.132 x.y.z.129 -> NOT OK ping -S x.y.z.133 x.y.z.129 -> NOT OK By using tcpdump on the vlan128 interface I can see the packets _BOTH_ leaving and coming from the carp addresses. It just seems that the carp interfaces can't process the packets properly. 5) from the internet : advanced From an external internet address I _cannot_ ping the carp addresses (x.y.z.132 and up) As above, I can see the incoming packets with tcpdump -i vlan128 -n icmp Ok, that was long. I hope someone can help to shed light into this, to see whether this is a bug or not. I stress again that the _same_ configuration works as it should on a physical (non-vlan) interface. From owner-freebsd-net@FreeBSD.ORG Sun Jun 22 14:42:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2423A1065686; Sun, 22 Jun 2008 14:42:02 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 911148FC13; Sun, 22 Jun 2008 14:42:01 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from crab.unsane.co.uk (crab.unsane.co.uk [10.0.0.111]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m5MEfxQu067679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 15:42:00 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <485E647D.1030301@unsane.co.uk> Date: Sun, 22 Jun 2008 15:41:01 +0100 From: Vince Hoffman User-Agent: Thunderbird 2.0.0.14 (X11/20080507) MIME-Version: 1.0 To: martes@mgwigglesworth.com References: <1213691523.22762.16.camel@localhost> <20080618172216.GA76058@citylink.fud.org.nz> <1213846763.14151.1.camel@localhost> In-Reply-To: <1213846763.14151.1.camel@localhost> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Andrew Thompson Subject: Re: Use lagg(4) or Use Layer-4 Load Balancing? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jun 2008 14:42:02 -0000 Martes G Wigglesworth wrote: > I was attempting to find good information on how to achieve a type of > bonding using advanced routing on FreeBSD, such as with layer-4 routers, > that can bond multiple sources into a single overall larger source for > logical backbone creation for networks. > You could have a look at ng_one2many(4) I've never used it but it sounds like it could be what you are after according to the manpage. Vince > > On Wed, 2008-06-18 at 13:22 -0400, Andrew Thompson wrote: >> On Tue, Jun 17, 2008 at 04:32:03AM -0400, Martes G Wigglesworth wrote: >>> Greetings all. >>> >>> I have been attempting to research what I have been informed is >>> actually accomplished with layer-4 load balancing. I have seen many >>> articles and reviews that indicate that lagg(4) will accomplish the >>> teaming of multiple internet access sorces into a single logical pipe, >>> however, I have tried this using a dumb switch two nic interfaces and >>> this simply is not the case. >>> >>> I am new and may not have enough cool equipment around, however, aside >>> from using the fail-over mode for redundancy, and lacp on a supported >>> switch, then if lagg(4) could really combine multiple sources into one >>> for use as a larger overall backbone, then I should be able to get >>> doulbed bandwidth using two separate ports on an unmanaged switch using >>> some option on the lagg(4) driver, which is not the cast.(if this is >>> wrong I would be happy to get the correct information, however I have a >>> few network engineer references that say that you cannot do anything >>> more than layer-2 lacp with appropriate equipment to create an >>> isp-supported trunk) Even in the on-lamp interview the 7.0 developer >>> implies that you can do what I am attempting to research however, it is >>> not possible at layer 2 without an end-point. >> How are you testing this? You need to have multiple IP flows in order to >> fully utilise the multiple links. See this snippet from the handbook >> (i'll put it in the man page too). >> >> "Since frame ordering is mandatory on Ethernet links then any traffic >> between two stations always flows over the same physical link limiting >> the maximum speed to that of one interface. The transmit algorithm >> attempts to use as much information as it can to distinguish different >> traffic flows and balance across the available interfaces." >> >> >> Does that answer your question, you will not get more speed on a single >> download. >> >> >> Andrew >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jun 22 22:16:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ACAB10656AE for ; Sun, 22 Jun 2008 22:16:08 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id F408A8FC1A for ; Sun, 22 Jun 2008 22:16:07 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-76-203-175-234.dsl.pltn13.sbcglobal.net [76.203.175.234]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id m5MMG5HQ060571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 15:16:07 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <485ECF20.6000607@monkeybrains.net> Date: Sun, 22 Jun 2008 15:16:00 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.12 (X11/20080310) MIME-Version: 1.0 To: Jack Vogel References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> <485C41C5.4090706@monkeybrains.net> <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> <485D5B9E.8020908@monkeybrains.net> In-Reply-To: <485D5B9E.8020908@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on pita.monkeybrains.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Seeking help understanding my "emX: watchdog timeout" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jun 2008 22:16:08 -0000 Reading if_em.h 77 * EM_TIDV - Transmit Interrupt Delay Value 78 * Valid Range: 0-65535 (0=off) 79 * Default Value: 64 80 * This value delays the generation of transmit interrupts in units of 81 * 1.024 microseconds. Transmit interrupt reduction can improve CPU 82 * efficiency if properly tuned for specific network traffic. If the 83 * system is reporting dropped transmits, this value may be set too high 84 * causing the driver to run out of available transmit descriptors. seems to indicate that 'dropped transmits' may be due to the 'tx_int_delay' being too high. So, I lowered the Transmit Interrupt Delay Values 33 useconds. I will report if this helps. Does anyone have experience using tuning these values? dev.em.2.tx_int_delay: 33 dev.em.2.tx_abs_int_delay: 33 The Intel docs explain the tx_int_delay vs the tx_abs_int_delay: "In [high traffic] situations, the absolute timer is the source of most device interrupts. Under light loads or brief bursts of traffic, the packet timers are the primary source of interrupts. In these situations, the packet timers determine the latency suffered by most packets. The packet timers also determine the minimum traffic rate required to trigger the absolute timer interrupts. For example, if the traffic rate is high enough to prevent the packet timer from ever expiring, then the GbE controller does not interrupt until the absolute timer has expired." That is why I picked a tx_abs_int_delay == tx_int_delay. The source code references running out of available transmit descriptors... Is there a way to bump up the number of available transmit descriptors or to change the packet buffer size? here is the dev.em.2.debug info: kernel: em2: Adapter hardware address = 0xc4d91224 kernel: em2: CTRL = 0x400c0241 RCTL = 0x8002 kernel: em2: Packet buffer = Tx=16k Rx=32k kernel: em2: Flow control watermarks high = 30720 low = 29220 kernel: em2: tx_int_delay = 32, tx_abs_int_delay = 32 kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 66 kernel: em2: fifo workaround = 0, fifo_reset_count = 0 kernel: em2: hw tdh = 41, hw tdt = 41 kernel: em2: hw rdh = 130, hw rdt = 129 kernel: em2: Num Tx descriptors avail = 254 (Can I increase?) kernel: em2: Tx Descriptors not avail1 = 15 (Why not available?) kernel: em2: Tx Descriptors not avail2 = 0 kernel: em2: Std mbuf failed = 0 kernel: em2: Std mbuf cluster failed = 0 kernel: em2: Driver dropped packets = 0 kernel: em2: Driver tx dma failure in encap = 0 (not sure why tx_int_delay is 32 when I set it to 33... starts counting at 0?) Rudy Reference for if_em.h: http://fxr.watson.org/fxr/source/dev/em/if_em.h?v=FREEBSD7 Referenve for Absolute vs Packet timer: http://www.intel.com/design/network/applnots/ap450.pdf (page 12) From owner-freebsd-net@FreeBSD.ORG Sun Jun 22 22:26:48 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5488F106567E; Sun, 22 Jun 2008 22:26:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7FC8FC1E; Sun, 22 Jun 2008 22:26:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (mav@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5MMQmV5092730; Sun, 22 Jun 2008 22:26:48 GMT (envelope-from mav@freefall.freebsd.org) Received: (from mav@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5MMQl0I092726; Sun, 22 Jun 2008 22:26:47 GMT (envelope-from mav) Date: Sun, 22 Jun 2008 22:26:47 GMT Message-Id: <200806222226.m5MMQl0I092726@freefall.freebsd.org> To: mimielliot@gmail.com, mav@FreeBSD.org, freebsd-net@FreeBSD.org From: mav@FreeBSD.org Cc: Subject: Re: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Jun 2008 22:26:48 -0000 Synopsis: [netgraph] [panic] kernel panic due to netgraph mpd State-Changed-From-To: patched->closed State-Changed-By: mav State-Changed-When: Sun Jun 22 22:26:06 UTC 2008 State-Changed-Why: Patches merged, no more feedback received. http://www.freebsd.org/cgi/query-pr.cgi?pr=123741 From owner-freebsd-net@FreeBSD.ORG Mon Jun 23 11:06:58 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE4031065673 for ; Mon, 23 Jun 2008 11:06:58 +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 9C0418FC37 for ; Mon, 23 Jun 2008 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5NB6wC0065038 for ; Mon, 23 Jun 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5NB6wK0065034 for freebsd-net@FreeBSD.org; Mon, 23 Jun 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jun 2008 11:06:58 GMT Message-Id: <200806231106.m5NB6wK0065034@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, 23 Jun 2008 11:06:58 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124540 net [tcp] RTM_MISS with the transit packets o kern/124753 net net80211 discards power-save queue packets early 90 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd p kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 54 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 23 11:35:06 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 599F9106566C for ; Mon, 23 Jun 2008 11:35:06 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id A185C8FC27 for ; Mon, 23 Jun 2008 11:35:04 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 22443 invoked from network); 23 Jun 2008 13:35:03 +0200 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jun 2008 13:35:03 +0200 Date: Mon, 23 Jun 2008 13:35:03 +0200 (CEST) From: Ingo Flaschberger To: freebsd-net@FreeBSD.ORG In-Reply-To: Message-ID: References: <200806191435.m5JEZ4xs083455@lurza.secnetix.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: CARP + multiple addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2008 11:35:06 -0000 Patch was removed by mailinglist, use this link instead: http://xip.at/~transfer/ucarp-1.5_if.tar.bz2 Kind regards, ingo flaschberger geschaeftsleitung --------------------------- netstorage-crossip-flat:fee powered by crossip communications gmbh --------------------------- sebastian kneipp gasse 1 a-1020 wien fix: +43-1-726 15 22-217 fax: +43-1-726 15 22-111 --------------------------- On Thu, 19 Jun 2008, Ingo Flaschberger wrote: > Hi, > > problems with carp: > *) freebsd only allows 1 route > -> with a routing-protocol at the ucarp-machine > carp can not add the 2nd own route > *) carp can/could not use more than 1 subnet > *) carp can/could not bind to an interface > *) in a router environment carp fails to add routes > ... > > I decided to use ucarp but needed to modify it. see attached patch / scripts. > > I use ucarp now since 3 months in production. > > Kind regards, > ingo flaschberger > > geschaeftsleitung > --------------------------- > netstorage-crossip-flat:fee > powered by > crossip communications gmbh > --------------------------- > sebastian kneipp gasse 1 > a-1020 wien > fix: +43-1-726 15 22-217 > fax: +43-1-726 15 22-111 > --------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Jun 23 19:59:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5CF71065671 for ; Mon, 23 Jun 2008 19:59:58 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 865718FC24 for ; Mon, 23 Jun 2008 19:59:56 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 25556 invoked by uid 98); 23 Jun 2008 19:59:54 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.040082 secs); 23 Jun 2008 19:59:54 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.040082 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 23 Jun 2008 19:59:54 -0000 Message-ID: <486000B5.9090703@zirakzigil.org> Date: Mon, 23 Jun 2008 21:59:49 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Problem clarification (was: Problems with vlan + carp + alias) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jun 2008 19:59:59 -0000 After some more tests I've finally realized that the problem is with vlan and alias. I've taken carp out of the picture. (Please read my previous message on the topic to understand the scenario, I've reported it below) Here is what matters in /etc/rc.conf: ----------------------------------------------------------- ... ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" ... ifconfig_vlan128="inet x.y.z.132 netmask 255.255.255.224 vlan 128 vlandev bce0" ifconfig_vlan128_alias0="x.y.z.133 netmask 255.255.255.255" ifconfig_vlan128_alias1="x.y.z.134 netmask 255.255.255.255" ifconfig_vlan128_alias2="x.y.z.135 netmask 255.255.255.255" ifconfig_vlan128_alias3="x.y.z.136 netmask 255.255.255.255" ifconfig_vlan128_alias4="x.y.z.137 netmask 255.255.255.255" ifconfig_vlan128_alias5="x.y.z.138 netmask 255.255.255.255" ifconfig_vlan128_alias6="x.y.z.139 netmask 255.255.255.255" ifconfig_vlan128_alias7="x.y.z.140 netmask 255.255.255.255" ifconfig_vlan128_alias8="x.y.z.141 netmask 255.255.255.255" ... defaultrouter="x.y.z.129" ----------------------------------------------------------- netstat -rn ----------------------------------------------------------- default x.y.z.129 UGS 0 9869 vlan12 x.y.z.128/27 link#11 UC 0 0 vlan12 x.y.z.129 00:00:0c:07:ac:0a UHLW 2 52 vlan12 1107 x.y.z.130 00:d0:03:8a:9b:fc UHLW 1 0 vlan12 1147 x.y.z.131 00:d0:03:8a:9b:fd UHLW 1 0 vlan12 1144 x.y.z.133/32 link#11 UC 0 0 vlan12 x.y.z.134/32 link#11 UC 0 0 vlan12 x.y.z.135/32 link#11 UC 0 0 vlan12 x.y.z.136/32 link#11 UC 0 0 vlan12 x.y.z.137/32 link#11 UC 0 0 vlan12 x.y.z.138/32 link#11 UC 0 0 vlan12 x.y.z.139/32 link#11 UC 0 0 vlan12 x.y.z.140/32 link#11 UC 0 0 vlan12 x.y.z.141/32 link#11 UC 0 0 vlan12 ----------------------------------------------------------- ifconfig vlan128 ----------------------------------------------------------- vlan128: flags=8843 metric 0 mtu 1500 options=3 ether 00:1e:c9:ad:fa:c9 inet x.y.z.132 netmask 0xffffffe0 broadcast x.y.z.159 inet x.y.z.133 netmask 0xffffffff broadcast x.y.z.133 inet x.y.z.134 netmask 0xffffffff broadcast x.y.z.134 inet x.y.z.135 netmask 0xffffffff broadcast x.y.z.135 inet x.y.z.136 netmask 0xffffffff broadcast x.y.z.136 inet x.y.z.137 netmask 0xffffffff broadcast x.y.z.137 inet x.y.z.138 netmask 0xffffffff broadcast x.y.z.138 inet x.y.z.139 netmask 0xffffffff broadcast x.y.z.139 inet x.y.z.140 netmask 0xffffffff broadcast x.y.z.140 inet x.y.z.141 netmask 0xffffffff broadcast x.y.z.141 media: Ethernet autoselect (1000baseTX ) status: active vlan: 128 parent interface: bce0 ----------------------------------------------------------- Tests: No problem when I try to ping the default gateway from my fw No problem when I ping my fw from an external internet address Problems: - I cannot ping the router from one of the aliased address: ping -S x.y.z.133 x.y.z.129 - I cannot ping the aliased addresses from an external internet address Note : I can see the packets with tcpdump travelling from and to the aliased address. It seems the interface won't process them for some reason. This seems suspiciously like a bug to me... -------------------------------------------------------------------------------------- (previous message on vlan + carp +alias) -------------------------------------------------------------------------------------- Primeroz lists wrote: > What is tcpdump showing for ping on 192.168.10.11 > ? can you see echo reply exiting vlan10 > interface ? > > what if you try from your server to "ping -S 192.168.10.11 > 192.168.10.254 " ? > > > First of all I'm sorry for the late reply. Yesterday I could do some more in-depth test to analyze this strange behavior of my firewall. The 192.168.10.0/24 range I used in the previous example isn't the real one, I just used it for simplicity´s sake. The true range, the one which has been assigned by the ISP to my customer is: x.y.z.128/27. (x.y.z corresponds to a true public IP address) I've deactivated the firewall, so we have one less thing to worry about: /etc/rc.d/pf stop This is a pure network configuration issue. Here is the relevant part in /etc/rc.conf: --------------------------------------------------- ... ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" ... cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 carp30 carp40 carp128" ... ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 vlandev bce0" ... ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255" ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255" ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255" ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255" ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255" ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255" ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255" ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255" ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255" ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255" ... defaultrouter="x.y.z.129" --------------------------------------------------- On my managed switch I've set 2 ports: 1) the one where the bce0 interface is plugged in : mode trunk with all the vlans above 2) the one where the ISP internet is plugged in : mode access with vlan 128 I've also set the ip interface of my switch to x.y.z.155 vlan 128 Here is the relevant part of netstat -rn on my machine --------------------------------------------------- default x.y.z.129 UGS 0 13966 vlan12 x.y.z/27 link#11 UC 0 0 vlan12 x.y.z.132 x.y.z.132 UH 0 0 carp12 x.y.z.133 x.y.z.133 UH 0 0 carp12 x.y.z.134 x.y.z.134 UH 0 0 carp12 x.y.z.135 x.y.z135 UH 0 0 carp12 x.y.z.136 x.y.z.136 UH 0 0 carp12 x.y.z.137 x.y.z.137 UH 0 0 carp12 x.y.z.138 x.y.z.138 UH 0 0 carp12 x.y.z.139 x.y.z.139 UH 0 0 carp12 x.y.z.140 x.y.z.140 UH 0 0 carp12 x.y.z.141 x.y.z.141 UH 0 0 carp12 x.y.z.155 00:1e:c9:90:4a:c0 UHLW 1 8 vlan12 1183 --------------------------------------------------- Here come the tests. 1) From the firewall : basic I can ping both the default gateway (x.y.z.129) and the switch interface (x.y.z.155) I can ping a generic internet address (a.b.c.d) With tcpdump I can see the packets leaving as x.y.z.157 and coming with the same address 2) from the switch : basic I can ping the firewall's vlan address (x.y.z.157) I can ping _ALL_ the carp interfaces, base and alias: ping x.y.z.157 -> OK ping x.y.z.132 -> OK ping x.y.z.133 -> OK ... ping x.y.z.141 -> OK 3) from the internet : basic From an external internet address I can ping the vlan address: ping x.y.z.157 -> OK 4) from the firewall : advanced From the firewall I can ping the switch address from one of the carp base and aliased address: ping -S x.y.z.132 x.y.z.155 -> OK ping -S x.y.z.133 x.y.z.155 -> OK I _cannot_ ping the default router from one of the carp addresses: ping -S x.y.z.132 x.y.z.129 -> NOT OK ping -S x.y.z.133 x.y.z.129 -> NOT OK By using tcpdump on the vlan128 interface I can see the packets _BOTH_ leaving and coming from the carp addresses. It just seems that the carp interfaces can't process the packets properly. 5) from the internet : advanced From an external internet address I _cannot_ ping the carp addresses (x.y.z.132 and up) As above, I can see the incoming packets with tcpdump -i vlan128 -n icmp Ok, that was long. I hope someone can help to shed light into this, to see whether this is a bug or not. I stress again that the _same_ configuration works as it should on a physical (non-vlan) interface. From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 04:01:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E698F106567F for ; Tue, 24 Jun 2008 04:01:06 +0000 (UTC) (envelope-from snb@moduli.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id AD8138FC0C for ; Tue, 24 Jun 2008 04:01:06 +0000 (UTC) (envelope-from snb@moduli.net) Received: by rv-out-0506.google.com with SMTP id b25so9845683rvf.43 for ; Mon, 23 Jun 2008 21:01:06 -0700 (PDT) Received: by 10.140.161.11 with SMTP id j11mr13945649rve.134.1214278396976; Mon, 23 Jun 2008 20:33:16 -0700 (PDT) Received: by 10.141.176.12 with HTTP; Mon, 23 Jun 2008 20:33:16 -0700 (PDT) Message-ID: Date: Mon, 23 Jun 2008 20:33:16 -0700 From: "Nick Barkas" Sender: snb@moduli.net To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: c7b2ccf017aefe5a Subject: reference count bug in sys/netinet/in.c on 6.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, 24 Jun 2008 04:01:07 -0000 There was a bug in sys/netinet/in.c that was fixed in the RELENG_6 branch, in revision 1.85.2.10 (see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=1.85.2.9;r2=1.85.2.10). But, this fix hasn't yet made it into RELENG_6_3. I had a machine panic on this bug, so I have patched the kernels on all of my 6.3 machines, but I am wondering if this fix might eventually get merged into RELENG_6_3 and perhaps get an errata update. There was talk about this on freebsd-stable a couple months ago: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-04/msg00158.html I have quite a few machines running 6.3 and they will likely continue to do so until it hits end of life. Most use GENERIC or SMP kernels, so I'd like to be able to install any future updates to their kernels using freebsd-update. I imagine I'm not the only one who wants to do this. So, any chance on this fix being applied to RELENG_6_3 so it is possible to apply it in the future with freebsd-update? Nick From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 08:14:49 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC301065670; Tue, 24 Jun 2008 08:14:49 +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 10C328FC15; Tue, 24 Jun 2008 08:14:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5O8Em5w025073; Tue, 24 Jun 2008 08:14:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5O8Emu4025069; Tue, 24 Jun 2008 08:14:48 GMT (envelope-from linimon) Date: Tue, 24 Jun 2008 08:14:48 GMT Message-Id: <200806240814.m5O8Emu4025069@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/124904: [fxp] EEPROM corruption with Compaq NC3163 NIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jun 2008 08:14:49 -0000 Old Synopsis: EEPROM corruption with Compaq NC3163 NIC New Synopsis: [fxp] EEPROM corruption with Compaq NC3163 NIC Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 24 08:14:04 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=124904 From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 12:58:34 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB6751065675 for ; Tue, 24 Jun 2008 12:58:34 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 97CB78FC16 for ; Tue, 24 Jun 2008 12:58:34 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 4E1CF1B10EE8; Tue, 24 Jun 2008 14:58:33 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id BD34F1B10EF2 for ; Tue, 24 Jun 2008 14:58:30 +0200 (CEST) Message-ID: <4860EF76.1050807@moneybookers.com> Date: Tue, 24 Jun 2008 15:58:30 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Cc: Subject: jboss4 on freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2008 12:58:34 -0000 Greetings, I'm experimenting with jboss4 cluster under freebsd 7 (amd64). In my configuration I have 2 jboss instances which are in cluster and they communicate via separate network (used only for shared data) When I create some load on the application sometimes I see this error: 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed sending message to 10.50.1.1:57680 (59800 bytes) java.io.IOException: No buffer space available It looks very much, that jboss can't handle properly such error as on linux there is no such thing as no network buffers ;) - http://wiki.freebsd.org/AvoidingLinuxisms But what really bothers me is that I see "No buffer space available" on very low network IO - input (em2) output packets errs bytes packets errs bytes colls 144 0 2203390 292 0 2072771 0 1568 0 2329764 63 0 9099 0 76 0 231562 34 0 148306 0 563 0 1152531 1009 0 1768748 0 1625 0 2601502 104 0 229728 0 65 0 467296 85 0 441566 0 464 0 680082 973 0 1439442 0 357 0 1940361 55 0 222484 0 1651 0 2827932 145 0 450265 0 E.g. traffic between 1-3MB/s. I'm using: em2: flags=8843 metric 0 mtu 9000 options=19b ether 00:15:17:60:04:c8 inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 media: Ethernet autoselect (1000baseTX ) status: active em2: port 0x2020-0x203f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 em2: Using MSI interrupt em2: [FILTER] and my sysctl.conf is: kern.maxfiles=65000 kern.ipc.shmmax=67108864 kern.fallback_elf_brand=3 kern.threads.max_threads_per_proc=6000 kern.ipc.somaxconn=512 #jboss extra net.inet.udp.maxdgram=73728 kern.ipc.maxsockbuf=1048576 net.inet.udp.recvspace=147456 kern.ipc.maxsockets=49312 Any ideas how I can improve things? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 13:16:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C84B106567A for ; Tue, 24 Jun 2008 13:16:11 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 8357D8FC14 for ; Tue, 24 Jun 2008 13:16:10 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 5F2D11B10EF4; Tue, 24 Jun 2008 15:16:09 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, J_CHICKENPOX_48 autolearn=no version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 7B4071B10CB6; Tue, 24 Jun 2008 15:16:06 +0200 (CEST) Message-ID: <4860F395.1010000@moneybookers.com> Date: Tue, 24 Jun 2008 16:16:05 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Paul References: <4860EF76.1050807@moneybookers.com> <4860F0FA.1010707@gtcomm.net> In-Reply-To: <4860F0FA.1010707@gtcomm.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Cc: "freebsd-net@freebsd.org" Subject: Re: jboss4 on freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2008 13:16:11 -0000 Paul wrote: > kern.ipc.nmbclusters=128000 changed - no effect > > Check output from netstat -m, this shows network buffers. 770/8200/8970 mbufs in use (current/cache/total) 768/5426/6194/128000 mbuf clusters in use (current/cache/total/max) 768/5248 mbuf+clusters out of packet secondary zone in use (current/cache) 0/677/677/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 1728K/15610K/17338K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 73 requests for I/O initiated by sendfile 0 calls to protocol drain routines This output is in the same second as I see no buffer space available .. isn't this weird? > > > Stefan Lambrev wrote: >> Greetings, >> >> I'm experimenting with jboss4 cluster under freebsd 7 (amd64). >> In my configuration I have 2 jboss instances which are in cluster and >> they communicate via separate network (used only for shared data) >> When I create some load on the application sometimes I see this error: >> >> 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed >> sending message to 10.50.1.1:57680 (59800 bytes) >> java.io.IOException: No buffer space available >> >> It looks very much, that jboss can't handle properly such error as on >> linux there is no such thing as no network buffers ;) - >> http://wiki.freebsd.org/AvoidingLinuxisms >> >> But what really bothers me is that I see "No buffer space available" >> on very low network IO - >> >> input (em2) output >> packets errs bytes packets errs bytes colls >> 144 0 2203390 292 0 2072771 0 >> 1568 0 2329764 63 0 9099 0 >> 76 0 231562 34 0 148306 0 >> 563 0 1152531 1009 0 1768748 0 >> 1625 0 2601502 104 0 229728 0 >> 65 0 467296 85 0 441566 0 >> 464 0 680082 973 0 1439442 0 >> 357 0 1940361 55 0 222484 0 >> 1651 0 2827932 145 0 450265 0 >> >> E.g. traffic between 1-3MB/s. >> >> I'm using: >> em2: flags=8843 metric 0 mtu >> 9000 >> >> options=19b >> ether 00:15:17:60:04:c8 >> inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 >> media: Ethernet autoselect (1000baseTX ) >> status: active >> >> em2: port 0x2020-0x203f >> mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 >> on pci5 >> em2: Using MSI interrupt >> em2: [FILTER] >> >> and my sysctl.conf is: >> kern.maxfiles=65000 >> kern.ipc.shmmax=67108864 >> kern.fallback_elf_brand=3 >> kern.threads.max_threads_per_proc=6000 >> kern.ipc.somaxconn=512 >> #jboss extra >> net.inet.udp.maxdgram=73728 >> kern.ipc.maxsockbuf=1048576 >> net.inet.udp.recvspace=147456 >> kern.ipc.maxsockets=49312 >> >> Any ideas how I can improve things? >> > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 15:08:38 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D7F106566B for ; Tue, 24 Jun 2008 15:08:38 +0000 (UTC) (envelope-from _pppp@mail.ru) Received: from mx45.mail.ru (mx45.mail.ru [194.67.23.236]) by mx1.freebsd.org (Postfix) with ESMTP id E81318FC1D for ; Tue, 24 Jun 2008 15:08:37 +0000 (UTC) (envelope-from _pppp@mail.ru) Received: from f7.mail.ru (f7.mail.ru [194.67.57.37]) by mx45.mail.ru (mPOP.Fallback_MX) with ESMTP id 2DD8EE0046D0 for ; Tue, 24 Jun 2008 18:46:39 +0400 (MSD) Received: from mail by f7.mail.ru with local id 1KB9n2-0002X3-00; Tue, 24 Jun 2008 18:46:36 +0400 Received: from [213.180.219.187] by koi.mail.ru with HTTP; Tue, 24 Jun 2008 18:46:36 +0400 From: Dmitriy <_pppp@mail.ru> To: Stefan Lambrev Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [213.180.219.187] Date: Tue, 24 Jun 2008 18:46:36 +0400 In-Reply-To: <4860EF76.1050807@moneybookers.com> References: <4860EF76.1050807@moneybookers.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected Cc: freebsd-net@FreeBSD.org Subject: Re: jboss4 on freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitriy <_pppp@mail.ru> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2008 15:08:38 -0000 -----Original Message----- From: Stefan Lambrev To: freebsd-net@FreeBSD.org Date: Tue, 24 Jun 2008 15:58:30 +0300 Subject: jboss4 on freebsd > > Greetings, > > I'm experimenting with jboss4 cluster under freebsd 7 (amd64). > In my configuration I have 2 jboss instances which are in cluster and > they communicate via separate network (used only for shared data) > When I create some load on the application sometimes I see this error: > > 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed sending > message to 10.50.1.1:57680 (59800 bytes) > java.io.IOException: No buffer space available > > It looks very much, that jboss can't handle properly such error as on > linux there is no such thing as no network buffers ;) - > http://wiki.freebsd.org/AvoidingLinuxisms > > But what really bothers me is that I see "No buffer space available" on > very low network IO - > > input (em2) output > packets errs bytes packets errs bytes colls > 144 0 2203390 292 0 2072771 0 > 1568 0 2329764 63 0 9099 0 > 76 0 231562 34 0 148306 0 > 563 0 1152531 1009 0 1768748 0 > 1625 0 2601502 104 0 229728 0 > 65 0 467296 85 0 441566 0 > 464 0 680082 973 0 1439442 0 > 357 0 1940361 55 0 222484 0 > 1651 0 2827932 145 0 450265 0 > > E.g. traffic between 1-3MB/s. > > I'm using: > em2: flags=8843 metric 0 mtu 9000 > options=19b > ether 00:15:17:60:04:c8 > inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > em2: port 0x2020-0x203f mem > 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 > em2: Using MSI interrupt > em2: [FILTER] > > and my sysctl.conf is: > kern.maxfiles=65000 > kern.ipc.shmmax=67108864 > kern.fallback_elf_brand=3 > kern.threads.max_threads_per_proc=6000 > kern.ipc.somaxconn=512 > #jboss extra > net.inet.udp.maxdgram=73728 > kern.ipc.maxsockbuf=1048576 > net.inet.udp.recvspace=147456 > kern.ipc.maxsockets=49312 > > Any ideas how I can improve things? > I guess you get the error from the NIC driver. There 2 conditions which can trigger it: 1. if( adapter->num_tx_desc_avail < EM_TX_OP_THRESHOLD ) 2. if( nsegs > ( adapter->num_tx_desc_avail - 2 ) ) I have 2 suggestions how to fix your error: 1. try to disable TXCSUM ( #ifconfig em2 -txcsum ) 2. increase the number of transfer descriptors available if your hardware supports it: [man em(4) excerpt] Tunables can be set at the loader(8) prompt before booting the kernel or stored in loader.conf(5). hw.em.txd Number of transmit descriptors allocated by the driver. The default value is 256. The 82542 and 82543-based adapters can handle up to 256 descriptors, while others can have up to 4096. hw.em.tx_int_delay This value delays the generation of transmit interrupts in units of 1.024 microseconds. The default value is 64. hw.em.tx_abs_int_delay If hw.em.tx_int_delay is non-zero, this tunable limits the maxi- mum delay in which a transmit interrupt is generated. [/man] Regards, Dmitriy. From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 15:24:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B62CF106566B; Tue, 24 Jun 2008 15:24:41 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from atlas.gtcomm.net (atlas.gtcomm.net [67.215.15.242]) by mx1.freebsd.org (Postfix) with ESMTP id 84D498FC13; Tue, 24 Jun 2008 15:24:41 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from c-76-108-179-28.hsd1.fl.comcast.net ([76.108.179.28] helo=[192.168.1.6]) by atlas.gtcomm.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KBAL2-0001Iy-Tc; Tue, 24 Jun 2008 11:21:45 -0400 Message-ID: <48611231.6000603@gtcomm.net> Date: Tue, 24 Jun 2008 11:26:41 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4852E23E.2040505@gtcomm.net> <4854EBF1.7020708@FreeBSD.org> In-Reply-To: <4854EBF1.7020708@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Route messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jun 2008 15:24:41 -0000 2574 output packets discarded due to no route 2904 output datagrams fragmented 5808 fragments created not incrementing.. route monitor....: got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default I don't get it.. :/ I do have a default route.. grr. :P Must be something to do with GRE but I can't recreate it on -RELEASE, only -STABLE and I don't see any differences in -STABLE that might cause it except maybe the EM driver? But I don't see how that would do it.. The only difference in route.c from RELEASE to STABLE is : - * $FreeBSD: src/sys/net/route.c,v 1.120.2.1.2.1 2008/01/09 15:23:36 mux Exp $ + * $FreeBSD: src/sys/net/route.c,v 1.120.2.3 2008/03/05 20:33:46 jhb Exp $ */ #include "opt_inet.h" @@ -396,7 +396,7 @@ error = EHOSTUNREACH; done: if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); out: if (error) rtstat.rts_badredirect++; Hrm.. what's a good way to disable the RT_MISS messages .. I guess ill have to add a check to see if msgtype=RTM_MISS and bypass the reporting... Is there a way to make it report what the source ip address it is trying to find a route for? Thanks Paul Bruce M. Simpson wrote: > Paul wrote: >> Get these with GRE tunnel on >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT >> 2008 :/usr/obj/usr/src/sys/ROUTER amd64 >> But do not get them with 7.0-RELEASE >> >> Any ideas what changed? :) Wish there was some sort of changelog.. >> # of messages per second seems consistent with packets per second on >> GRE interface.. >> No impact in routing, but definitely impact in cpu usage for all >> processes monitoring the route messages. > > RTM_MISS is actually fairly common when you don't have a default route. > > Messages which get enqueued don't necessarily get delivered -- and > very few processes actually listen to the routing socket actively like > this, so I wouldn't worry about it. > > If it's a real concern for you then you could try hacking in a sysctl > to tell the radix trie code not to issue RTM_MISS messages on the > routing socket. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 17:46:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCFAD1065670 for ; Tue, 24 Jun 2008 17:46:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id CE3208FC0A for ; Tue, 24 Jun 2008 17:46:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7DC522482; Tue, 24 Jun 2008 10:46:32 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 4AEA22D6150; Tue, 24 Jun 2008 10:46:32 -0700 (PDT) Message-ID: <48613304.7090204@elischer.org> Date: Tue, 24 Jun 2008 10:46:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Stefan Lambrev References: <4860EF76.1050807@moneybookers.com> <4860F0FA.1010707@gtcomm.net> <4860F395.1010000@moneybookers.com> In-Reply-To: <4860F395.1010000@moneybookers.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Paul Subject: Re: jboss4 on freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2008 17:46:32 -0000 Stefan Lambrev wrote: > > > Paul wrote: >> kern.ipc.nmbclusters=128000 > changed - no effect >> if this is udp or some datagram traffic then it is telling you that the interface queue has filled up.. >> Check output from netstat -m, this shows network buffers. > 770/8200/8970 mbufs in use (current/cache/total) > 768/5426/6194/128000 mbuf clusters in use (current/cache/total/max) > 768/5248 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/677/677/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 1728K/15610K/17338K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 73 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > This output is in the same second as I see no buffer space available .. > isn't this weird? >> >> >> Stefan Lambrev wrote: >>> Greetings, >>> >>> I'm experimenting with jboss4 cluster under freebsd 7 (amd64). >>> In my configuration I have 2 jboss instances which are in cluster and >>> they communicate via separate network (used only for shared data) >>> When I create some load on the application sometimes I see this error: >>> >>> 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed >>> sending message to 10.50.1.1:57680 (59800 bytes) >>> java.io.IOException: No buffer space available >>> >>> It looks very much, that jboss can't handle properly such error as on >>> linux there is no such thing as no network buffers ;) - >>> http://wiki.freebsd.org/AvoidingLinuxisms >>> >>> But what really bothers me is that I see "No buffer space available" >>> on very low network IO - >>> >>> input (em2) output >>> packets errs bytes packets errs bytes colls >>> 144 0 2203390 292 0 2072771 0 >>> 1568 0 2329764 63 0 9099 0 >>> 76 0 231562 34 0 148306 0 >>> 563 0 1152531 1009 0 1768748 0 >>> 1625 0 2601502 104 0 229728 0 >>> 65 0 467296 85 0 441566 0 >>> 464 0 680082 973 0 1439442 0 >>> 357 0 1940361 55 0 222484 0 >>> 1651 0 2827932 145 0 450265 0 >>> >>> E.g. traffic between 1-3MB/s. >>> >>> I'm using: >>> em2: flags=8843 metric 0 mtu >>> 9000 >>> >>> options=19b >>> ether 00:15:17:60:04:c8 >>> inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 >>> media: Ethernet autoselect (1000baseTX ) >>> status: active >>> >>> em2: port 0x2020-0x203f >>> mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 >>> on pci5 >>> em2: Using MSI interrupt >>> em2: [FILTER] >>> >>> and my sysctl.conf is: >>> kern.maxfiles=65000 >>> kern.ipc.shmmax=67108864 >>> kern.fallback_elf_brand=3 >>> kern.threads.max_threads_per_proc=6000 >>> kern.ipc.somaxconn=512 >>> #jboss extra >>> net.inet.udp.maxdgram=73728 >>> kern.ipc.maxsockbuf=1048576 >>> net.inet.udp.recvspace=147456 >>> kern.ipc.maxsockets=49312 >>> >>> Any ideas how I can improve things? >>> >> > From owner-freebsd-net@FreeBSD.ORG Tue Jun 24 21:42:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73726106566B for ; Tue, 24 Jun 2008 21:42:09 +0000 (UTC) (envelope-from erik@cepheid.org) Received: from mail.cepheid.org (aleph.cepheid.org [72.232.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id 67B2F8FC22 for ; Tue, 24 Jun 2008 21:42:09 +0000 (UTC) (envelope-from erik@cepheid.org) Received: by mail.cepheid.org (Postfix, from userid 1006) id 062009B4011; Tue, 24 Jun 2008 16:26:40 -0500 (CDT) Date: Tue, 24 Jun 2008 16:26:39 -0500 From: Erik Osterholm To: freebsd-net@freebsd.org Message-ID: <20080624212639.GA41755@aleph.cepheid.org> Mail-Followup-To: Erik Osterholm , freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Why isn't ALTQ in GENERIC? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Jun 2008 21:42:09 -0000 Hi all, Can anyone tell me if there are good reasons for explicitly leaving ALTQ out of the kernel? More specific to my circumstances, if I'm building kernels to be installed on every machine we deploy, is it worth building a separate kernel for ALTQ for those few boxes which will require it? Are there performance issues? Stability issues? Ultimately, I'm just surprised that it's not available in GENERIC if there isn't a good reason, but I can't find any documentation for that reason. If you can answer the same question for IPSEC, that would be nice, too! Erik From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 01:28:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 877BD1065671 for ; Wed, 25 Jun 2008 01:28:46 +0000 (UTC) (envelope-from SRS0=UD3h=XH=tm.uka.de=max.laier@srs.kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 28E2F8FC1E for ; Wed, 25 Jun 2008 01:28:45 +0000 (UTC) (envelope-from SRS0=UD3h=XH=tm.uka.de=max.laier@srs.kundenserver.de) Received: from vampire.homelinux.org (dslb-088-064-178-179.pools.arcor-ip.net [88.64.178.179]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1KBJcI0o0l-0004JP; Wed, 25 Jun 2008 03:16:10 +0200 Received: (qmail 2951 invoked by uid 80); 25 Jun 2008 01:13:54 -0000 Received: from 2001:6f8:12c8:1:31b7:808e:a19e:8e6e (SquirrelMail authenticated user mlaier) by router with HTTP; Wed, 25 Jun 2008 03:13:54 +0200 (CEST) Message-ID: <4c5bca29cfc1cdd3efa81ffb2f815675.squirrel@router> In-Reply-To: <20080624212639.GA41755@aleph.cepheid.org> References: <20080624212639.GA41755@aleph.cepheid.org> Date: Wed, 25 Jun 2008 03:13:54 +0200 (CEST) From: "Max Laier" To: "Erik Osterholm" , freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V01U2FsdGVkX19zBsVozVcFl8auT/5Lu3k6R4K2kEWRZF10SMR JlsNKNHzX/YRl3Yw9QJOsIsLdhoD7OUsoXPpvUVTcauSuyWYtl 96y1V+6rcpHTFd2Sn0emw== Cc: Subject: Re: Why isn't ALTQ in GENERIC? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 01:28:46 -0000 Hi Erik, Am Di, 24.06.2008, 23:26, schrieb Erik Osterholm: > Can anyone tell me if there are good reasons for explicitly leaving > ALTQ out of the kernel? More specific to my circumstances, if I'm > building kernels to be installed on every machine we deploy, is it > worth building a separate kernel for ALTQ for those few boxes which > will require it? > > Are there performance issues? Stability issues? Ultimately, I'm just > surprised that it's not available in GENERIC if there isn't a good > reason, but I can't find any documentation for that reason. Short answer: Historical reasons. Whole stroy: When ALTQ was added there were both performance and stability concerns. For a long time we had a big #ifdef ALTQ in if_var.h to avoid one additional check for if_queue enqueue opperations. These are now gone and I personally don't see any issues that would prevent ALTQ from being in GENERIC. However, it's unclear which disceplines to turn on by default. I'd like to see ALTQ in GERNERIC, but I've been reluctant to make the change on my own. If we can get a quorum here, I'll reconsider it. > If you can answer the same question for IPSEC, that would be nice, > too! Size? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 03:27:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80C14106567A for ; Wed, 25 Jun 2008 03:27:55 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 603B98FC0A for ; Wed, 25 Jun 2008 03:27:55 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id B36B379E307 for ; Tue, 24 Jun 2008 22:01:52 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 82257-07 for ; Wed, 25 Jun 2008 03:01:51 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 2197C79E2FD for ; Tue, 24 Jun 2008 22:01:47 -0500 (CDT) Received: from hole.shrew.net (localhost [127.0.0.1]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m5P31kIr040593 for ; Tue, 24 Jun 2008 22:01:46 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: (from www@localhost) by hole.shrew.net (8.14.2/8.14.2/Submit) id m5P31kOW040592; Tue, 24 Jun 2008 22:01:46 -0500 (CDT) (envelope-from mgrooms@shrew.net) X-Authentication-Warning: hole.shrew.net: www set sender to mgrooms@shrew.net using -f To: freebsd-net@freebsd.org MIME-Version: 1.0 Date: Tue, 24 Jun 2008 22:01:46 -0500 From: mgrooms Organization: Shrew Soft Inc Message-ID: <0efb44e3c6c6603e69207eb15fec2718@localhost> X-Sender: mgrooms@shrew.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mgrooms@shrew.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2008 03:27:55 -0000 All, Is anyone currently looking at the IPsec NAT-T patches? I posted a similar question several months ago around the FAST_IPSEC + IPv6 integration time frame. Maybe now that things have settled a bit, this work can be reviewed and possibly committed? Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 04:21:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5D98106567A for ; Wed, 25 Jun 2008 04:21:21 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id A39768FC1B for ; Wed, 25 Jun 2008 04:21:21 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 29281 invoked from network); 24 Jun 2008 22:54:41 -0500 Received: from 124-170-79-158.dyn.iinet.net.au (HELO ayiin) (124.170.79.158) by sigma.octantis.com.au with (DHE-RSA-AES128-SHA encrypted) SMTP; 24 Jun 2008 22:54:41 -0500 Date: Wed, 25 Jun 2008 13:54:37 +1000 From: Norberto Meijome To: freebsd-net@freebsd.org Message-ID: <20080625135437.32e7a1f9@ayiin> In-Reply-To: <0efb44e3c6c6603e69207eb15fec2718@localhost> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mgrooms@shrew.net Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 04:21:22 -0000 On Tue, 24 Jun 2008 22:01:46 -0500 mgrooms wrote: > Is anyone currently looking at the IPsec NAT-T patches? I posted a similar > question several months ago around the FAST_IPSEC + IPv6 integration time > frame. Maybe now that things have settled a bit, this work can be reviewed > and possibly committed? +1 _________________________ {Beto|Norberto|Numard} Meijome "Truth has no special time of its own. Its hour is now -- always." Albert Schweitzer I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 08:20:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31E401065670 for ; Wed, 25 Jun 2008 08:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABC78FC1D for ; Wed, 25 Jun 2008 08:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5P8K3uY010557 for ; Wed, 25 Jun 2008 08:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5P8K30M010556; Wed, 25 Jun 2008 08:20:03 GMT (envelope-from gnats) Date: Wed, 25 Jun 2008 08:20:03 GMT Message-Id: <200806250820.m5P8K30M010556@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Manuel Kasper" Cc: Subject: Re: kern/122295: [bge] bge Ierr rate increase (since 6.0R) [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manuel Kasper List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2008 08:20:04 -0000 The following reply was made to PR kern/122295; it has been noted by GNATS. From: "Manuel Kasper" To: Cc: Subject: Re: kern/122295: [bge] bge Ierr rate increase (since 6.0R) [regression] Date: Wed, 25 Jun 2008 09:48:29 +0200 We've been experiencing the same issue with BCM5704 B0 in HP ProLiant DL360 G4 servers. The Ierrs are correlated with packet loss (which is why we noticed the problem in the first place); however for us, the patch in completely fixes the problem and doesn't seem to introduce any problems with link state detection (cable disconnect/reconnect, changing link speed on remote end etc. all work fine). Also, OpenBSD already has essentially the same fix (with some dubious style changes) in its repository: The problem appears in both FreeBSD 6.3-RELEASE and 7.0-RELEASE. This is how things look without the fix (regardless of what link speed is used): ---- Router#ping 192.168.4.1 repeat 1000 size 1500 Type escape sequence to abort. Sending 1000, 1500-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 98 percent (983/1000), round-trip min/avg/max =3D 1/1/4 = ms ---- -> Pings from Cisco routers are especially likely to show the issue, as apparently mii_tick() and the pings from the Cisco occur synchronously for a while. TCP throughput isn't affected very much. Related dmesg output: bge0: mem 0xfdd70000-0xfdd7ffff irq 25 at device 2.0 on pci2 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:18:71:e4:xx:xx pciconf -lv: bge0@pci2:2:0: class=3D0x020000 card=3D0x00d00e11 chip=3D0x164814e4 = rev=3D0x10 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM5704 NetXtreme Dual Gigabit Adapter' class =3D network subclass =3D ethernet From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 15:15:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4985F106566C for ; Wed, 25 Jun 2008 15:15:29 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by mx1.freebsd.org (Postfix) with ESMTP id D45958FC1D for ; Wed, 25 Jun 2008 15:15:28 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by gv-out-0910.google.com with SMTP id n8so519548gve.39 for ; Wed, 25 Jun 2008 08:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lj8YE1InJObH42hMyVdx6XKS/PKCNiMtQrsdwe2YYcU=; b=hiYsjGCaP+0PR36ICoJd1BgTPlyHCiaiBoQxR48PKvpCGcxd9gKECsYZ99YPbhfbFR hiTqIzFhQM47znCU84kh3E0nIqo3YolXnarsqcnzTzfpd4uGNf7FG+tUSMK5mlTlq4QV DmfbnythUUY9VAzxZkUn+9UvpJzGQtZPhA1wI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bpXLEa62iS30AE8V3sTK5dZ0/NEuCqfz7kaV1GNcakWzvVlxPPHUZV+QAIyFbKY5TY tGW43H+1jjM8sb0RSBIn8rSYLnf5veUz1eASj2YsgRJPvotqckKOFDmWIP8zCZfL+cza ZP91JTCK8EmhkZSgPie18VW5GACPvuXdf1MbA= Received: by 10.78.161.4 with SMTP id j4mr2559278hue.74.1214406927301; Wed, 25 Jun 2008 08:15:27 -0700 (PDT) Received: by 10.78.161.6 with HTTP; Wed, 25 Jun 2008 08:15:27 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2008 11:15:27 -0400 From: "Scott Ullrich" To: "Norberto Meijome" In-Reply-To: <20080625135437.32e7a1f9@ayiin> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> Cc: freebsd-net@freebsd.org, mgrooms@shrew.net Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 15:15:29 -0000 On Tue, Jun 24, 2008 at 11:54 PM, Norberto Meijome wrote: > On Tue, 24 Jun 2008 22:01:46 -0500 > mgrooms wrote: > >> Is anyone currently looking at the IPsec NAT-T patches? I posted a similar >> question several months ago around the FAST_IPSEC + IPv6 integration time >> frame. Maybe now that things have settled a bit, this work can be reviewed >> and possibly committed? > > +1 Both m0n0wall and pfSense also use NAT-T. It sure would be nice to have it in FreeBSD so we can discontinue our patching every time we move to a newer FreeBSD revision. Scott From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 18:01:13 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0005106564A for ; Wed, 25 Jun 2008 18:01:13 +0000 (UTC) (envelope-from freebsd-net@transip.nl) Received: from relay0.transip.nl (relay0.transip.nl [80.69.67.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2148FC15 for ; Wed, 25 Jun 2008 18:01:13 +0000 (UTC) (envelope-from freebsd-net@transip.nl) Received: from [192.168.0.3] (ip86-50-212-87.adsl2.static.versatel.nl [87.212.50.86]) by relay0.transip.nl (Postfix) with ESMTP id 2BCC910530B for ; Wed, 25 Jun 2008 19:43:24 +0200 (CEST) Message-ID: <486283B0.3060805@transip.nl> Date: Wed, 25 Jun 2008 19:43:12 +0200 From: Ali Niknam Organization: Transip BV User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 18:01:13 -0000 Dear All, Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to FreeBSD 7.0 amd64. After upgrading I noticed a weird error/bug. It seems that after several thousand TCP connections some seem to hang in 'CLOSED' state. netstat -n gives: ... tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED ... These never go away; they gradually increase and increase until the application starts giving errors (probably because some socket or filedescriptor limit is reached). When the application is killed these entries disappear. The application in question is a self written DNS server, multithreaded, and running fine for years without any troubles on both BSD 5.x as well as 6.x. Also 32bits as well as 64bits on 6.x. Ofcourse that doesn't mean that the application is error free, however, after doing extensive testing I really can not find anything wrong with the application itself, so I'm thinking maybe there's a change somewhere that causes this? I know that tcp/network has been completely redone... What basically happens in the application is this: - one main tcp thread runs an infinite while loop waiting for new connections to arrive - as soon as one arrives a new thread is spawned that handles the newly created stream - it reads some bytes, writes some bytes, then closes it - thread exits What appears to happen is this: after the new thread is spawned it tries to read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and therefore closes the sockets and calls pthread_exit. However in netstat that same stream oftenly appears to have bytes 'stuck' in the in queue... I really can't see how this can cause hanging sockets in 'CLOSED' state. Even if the incoming queue isnt read entirely a call to close should close it. Also I really can't find any documentation in netstat, or elsewhere, about the 'CLOSED' state... Any help would greatly be appreciated! Kind Regards, Ali Niknam From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 18:36:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88284106567D for ; Wed, 25 Jun 2008 18:36:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 74B978FC17 for ; Wed, 25 Jun 2008 18:36:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B46D2247A; Wed, 25 Jun 2008 11:36:05 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A7ADE2D600F; Wed, 25 Jun 2008 11:36:03 -0700 (PDT) Message-ID: <48629020.8000207@elischer.org> Date: Wed, 25 Jun 2008 11:36:16 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Scott Ullrich References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, Norberto Meijome Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 18:36:04 -0000 Scott Ullrich wrote: > On Tue, Jun 24, 2008 at 11:54 PM, Norberto Meijome wrote: >> On Tue, 24 Jun 2008 22:01:46 -0500 >> mgrooms wrote: >> >>> Is anyone currently looking at the IPsec NAT-T patches? I posted a similar >>> question several months ago around the FAST_IPSEC + IPv6 integration time >>> frame. Maybe now that things have settled a bit, this work can be reviewed >>> and possibly committed? >> +1 > > Both m0n0wall and pfSense also use NAT-T. It sure would be nice to > have it in FreeBSD so we can discontinue our patching every time we > move to a newer FreeBSD revision. > > Scott > _______________________________________________ > 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" where is the patch? From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 18:44:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B98A6106566B for ; Wed, 25 Jun 2008 18:44:39 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4885A8FC0A for ; Wed, 25 Jun 2008 18:44:39 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by gv-out-0910.google.com with SMTP id n8so543262gve.39 for ; Wed, 25 Jun 2008 11:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=y0Jjb9G6Gu0IefSMc+69hXbEkB41XJiDAZaJjCm7J+o=; b=LrziilkF/OCLvttXo1ttOpeQP5zRHuCBl20KFqx5kfGGv++mNZ2UaZo3z187h1LhwZ 7UBWzmhBI5TgJH5Ha/x56AItPRyubPla+XsJ9Jtrrtiwtk6BtCRCe2Xe3WjUTaofceNb s1NcNHyUp1glKzwOO8cdwf7amuxMfH6084o/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=H87zScdw1C3nIhu6DaJjWwtwOd9lCmqK8YzFBJJyqUPkkcT4T5YW1onvR7hUKFPPHI OsRlggS6pUgb7k7eI57Lsz2zFX/jELJpYdpznIF2di7wWsGaz+jrV80fGl4xZzCtBB7x SLqs/N1XaAjIZdkWeY7/3+qrb2QsR9Gp5jDSI= Received: by 10.78.141.12 with SMTP id o12mr3873738hud.47.1214419477454; Wed, 25 Jun 2008 11:44:37 -0700 (PDT) Received: by 10.78.161.6 with HTTP; Wed, 25 Jun 2008 11:44:37 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2008 14:44:37 -0400 From: "Scott Ullrich" To: "Julian Elischer" In-Reply-To: <48629020.8000207@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, Norberto Meijome Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 18:44:39 -0000 On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer wrote: > > > where is the patch? > > The version that we use in RELENG_7_0 is located here: http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain Thanks Julian! Scott From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 18:46:12 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77391106567A for ; Wed, 25 Jun 2008 18:46:12 +0000 (UTC) (envelope-from ali@transip.nl) Received: from relay0.transip.nl (relay0.transip.nl [80.69.67.21]) by mx1.freebsd.org (Postfix) with ESMTP id 428258FC1D for ; Wed, 25 Jun 2008 18:46:12 +0000 (UTC) (envelope-from ali@transip.nl) Received: from [192.168.0.3] (ip86-50-212-87.adsl2.static.versatel.nl [87.212.50.86]) by relay0.transip.nl (Postfix) with ESMTP id 511281032DA; Wed, 25 Jun 2008 20:27:43 +0200 (CEST) Message-ID: <48628E13.40207@transip.nl> Date: Wed, 25 Jun 2008 20:27:31 +0200 From: Ali Niknam Organization: Transip BV User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vlad GALU References: <486283B0.3060805@transip.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 18:46:12 -0000 > This looks like an issue we used to have at work, where a streaming > application suddenly started getting kevents for sockets that had been > already closed. While that was happening, a netstat output looked just > like yours. We never tracked it down, as we moved to other projects :( > > Was that BSD 7.0 also? -- Transip BV | http://www.transip.nl/ We never let you down. From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 18:46:46 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C72CC1065672 for ; Wed, 25 Jun 2008 18:46:46 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 35BB78FC16 for ; Wed, 25 Jun 2008 18:46:45 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id k31so3401840fkk.11 for ; Wed, 25 Jun 2008 11:46:44 -0700 (PDT) Received: by 10.82.185.3 with SMTP id i3mr662100buf.27.1214417846331; Wed, 25 Jun 2008 11:17:26 -0700 (PDT) Received: by 10.82.185.13 with HTTP; Wed, 25 Jun 2008 11:17:26 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2008 21:17:26 +0300 From: "Vlad GALU" To: "Ali Niknam" In-Reply-To: <486283B0.3060805@transip.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <486283B0.3060805@transip.nl> Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 18:46:46 -0000 On 6/25/08, Ali Niknam wrote: > Dear All, > > Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to > FreeBSD 7.0 amd64. > > After upgrading I noticed a weird error/bug. It seems that after several > thousand TCP connections some seem to hang in 'CLOSED' state. > > netstat -n gives: > ... > tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED > tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED > tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED > tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED > ... > > These never go away; they gradually increase and increase until the > application starts giving errors (probably because some socket or > filedescriptor limit is reached). When the application is killed these > entries disappear. > > The application in question is a self written DNS server, multithreaded, > and running fine for years without any troubles on both BSD 5.x as well as > 6.x. Also 32bits as well as 64bits on 6.x. > > Ofcourse that doesn't mean that the application is error free, however, > after doing extensive testing I really can not find anything wrong with the > application itself, so I'm thinking maybe there's a change somewhere that > causes this? I know that tcp/network has been completely redone... > > What basically happens in the application is this: > - one main tcp thread runs an infinite while loop waiting for new > connections to arrive > - as soon as one arrives a new thread is spawned that handles the newly > created stream > - it reads some bytes, writes some bytes, then closes it > - thread exits > > What appears to happen is this: after the new thread is spawned it tries to > read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and > therefore closes the sockets and calls pthread_exit. However in netstat that > same stream oftenly appears to have bytes 'stuck' in the in queue... > > I really can't see how this can cause hanging sockets in 'CLOSED' state. > Even if the incoming queue isnt read entirely a call to close should close > it. Also I really can't find any documentation in netstat, or elsewhere, > about the 'CLOSED' state... > > > Any help would greatly be appreciated! > > > Kind Regards, > > > Ali Niknam > _______________________________________________ This looks like an issue we used to have at work, where a streaming application suddenly started getting kevents for sockets that had been already closed. While that was happening, a netstat output looked just like yours. We never tracked it down, as we moved to other projects :( -- ~/.signature: no such file or directory From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 18:55:43 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10697106564A for ; Wed, 25 Jun 2008 18:55:43 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id A56278FC24 for ; Wed, 25 Jun 2008 18:55:42 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id k31so3405196fkk.11 for ; Wed, 25 Jun 2008 11:55:41 -0700 (PDT) Received: by 10.82.146.10 with SMTP id t10mr661837bud.51.1214420141273; Wed, 25 Jun 2008 11:55:41 -0700 (PDT) Received: by 10.82.185.13 with HTTP; Wed, 25 Jun 2008 11:55:41 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2008 21:55:41 +0300 From: "Vlad GALU" To: "Ali Niknam" In-Reply-To: <48628E13.40207@transip.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <486283B0.3060805@transip.nl> <48628E13.40207@transip.nl> Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 18:55:43 -0000 On 6/25/08, Ali Niknam wrote: > > This looks like an issue we used to have at work, where a streaming > > application suddenly started getting kevents for sockets that had been > > already closed. While that was happening, a netstat output looked just > > like yours. We never tracked it down, as we moved to other projects :( > > > > > > > > Was that BSD 7.0 also? Yes. > > -- > Transip BV | http://www.transip.nl/ > We never let you down. > -- ~/.signature: no such file or directory From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 19:34:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77325106566B for ; Wed, 25 Jun 2008 19:34:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 628A68FC19 for ; Wed, 25 Jun 2008 19:34:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 91FCE240A; Wed, 25 Jun 2008 12:34:43 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id CEC722D60AC; Wed, 25 Jun 2008 12:34:42 -0700 (PDT) Message-ID: <48629DE0.5000407@elischer.org> Date: Wed, 25 Jun 2008 12:34:56 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Scott Ullrich References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, Norberto Meijome Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 19:34:43 -0000 Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer wrote: >> >> where is the patch? >> >> > > The version that we use in RELENG_7_0 is located here: > http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain > > Thanks Julian! I don't have time to do a lot of work on it, but if you can get me a patch that applies cleanly on -current and that you have tested, along with testing other cases (e.g. not compiled in) then I can give it a look over and if it looks ok I can commit it to -current and then MFC it back to 7 in a week's time or so. is it ABI compatible? > > Scott From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 19:35:32 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 025A31065679 for ; Wed, 25 Jun 2008 19:35:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 31D988FC22 for ; Wed, 25 Jun 2008 19:35:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AD14E46B99; Wed, 25 Jun 2008 15:35:30 -0400 (EDT) Date: Wed, 25 Jun 2008 20:35:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ali Niknam In-Reply-To: <486283B0.3060805@transip.nl> Message-ID: <20080625195523.N29013@fledge.watson.org> References: <486283B0.3060805@transip.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 19:35:32 -0000 On Wed, 25 Jun 2008, Ali Niknam wrote: > Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to > FreeBSD 7.0 amd64. > > After upgrading I noticed a weird error/bug. It seems that after several > thousand TCP connections some seem to hang in 'CLOSED' state. Sounds like there's a bug somewhere. Before we start trying to track it down, I'll tell you a little more about how this works so that we can interpret the output you're seeing. In FreeBSD, as with all UNIX/Berkeley sockets systems, each socket is actually represented by a set of data structures representing different layers of abstraction. At the top level of struct file, representing a file descriptor. Next down is struct socket, representing a socket. Then the protocol code has struct inpcb, representing a generic IP connection, and struct tcpcb (or struct tcptw once we enter TIMEWAIT), representing a TCP connection. Confusingly, these data structures don't always exist all at once. For example, if you close the file descriptor, freeing struct file, the socket and protocol state may persist for some time until the TCP connection closes (all data has been sent, or various other close modes). One important difference between FreeBSD 6.x and FreeBSD 7.x is that, in FreeBSD 7.x, we've reduced the degree to which these data structures exist in isolation. If you look at the mailing list threads discussing the change, you'll see it described as "strengthening invariants". The most important part of the change was making it an invariant that so->so_pcb, the pointer from the socket to the protocol layer state, always remains stable and valid. This had a number of benefits: because the pointer is always stable, it no longer requires locks to following, lowering overhead and improving parallelism. It also simplifies the code by removing lots of error handling, and improved code stability by avoiding the inevitable bugs associated with complex error handling. If you look at bug reports over the years, we've had quite a few panics reported (and fixed) in which the disappearance of protocol layer state, such as when a connection is reset while still in use by a process, and these are now all believed to be eliminated. So the code is faster, cleaner, and more stable. But there are a few interesting side effects. One is that we retain state at the TCP layer for longer than we used to. Specifically, if a TCP connection closes, the inpcb remains allocated until the file descriptor is closed (i.e., the application notices the connection has closed and invokes close() on the file descriptor). This has a few impacts: one is that TCP connections now appear in netstat in the CLOSED state for longer than before, and another is that open sockets that are associated with CLOSED TCP connections now count against the global resource limit on the number of simultaneous TCP connections. I say "longer than before", but I should be clear that, in practice, assuming all is working properly, there's no measurable behavioral change *except* for improved performance, cleanliness, and stability. This is because applications generally open a socket, run a protocol, and when the protocol wraps up, they then close() the file descriptor in order to close the connection. So, with that introduction, we're interested in resolving: (1) Is this an application bug (leaking file descriptors) that only manifests in 7.x due to changes in kernel state management, leading to the sockets being visible in netstat and counting against the resource limit? (2) Is this a *new* bug in TCP in 7.x, perhaps a result of the state-related changes I've described? (3) Is this an *old* bug in TCP that is only now manifesting because of the changes in kernel state management? The first is the easiest to resolve, as all we need to do is see whether the number of file descriptors for the application goes upwards in an improbable manner. You can use fstat, procstat, sockstat, or various other tools (such as lsof) to see whether the process is leaking file descriptors. You can also instrument your application to keep track of the file descriptor numbers being returned to see whether, perhaps, that number only goes up over time, and gets really big. If it turns out that your application *is* properly closing sockets, then we need to decide if perhaps we're looking at a race in close and state management. In particular, I'll need the output of "netstat -na", "vmstat -z", and "vmstat -m" from the machine once it's in its rather wedged-up state. It would be most helpful if you could actually shut down to single-user mode, killing all user processes, then waiting ten minutes, and capturing the output of those above commands to files that you can then e-mail to me. Without accusing you of having buggy code, I should say that I think there's a reasonable chance that what you're seeing is an interaction between an existing leak of resources in the application and the way the kernel state management has changed. The output from netstat pretty precisely matches that what you'd expect: lots of TCP connections in the CLOSED state reflecting a series of connections built by an application but then not properly discarded. Likewise, when the application is killed, all of the connections go away -- most likely because the file descriptors are all closed, allowing them to be garbage collected and connection state freed. If it is this sort of bug, then most likely you're missing a call to close() in a work loop somewhere, and in some exceptional case, you fall out of the loop without calling close(). If it turns out that you can get to single-user, wait ten minutes to make sure all the connections wind down, and there are still connections visible in netstat, then we may indeed be looking at a kernel bug, and the debugging information using netstat and vmstat will allow us to start to investigate. Robert N M Watson Computer Laboratory University of Cambridge > > netstat -n gives: > ... > tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED > tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED > tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED > tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED > ... > > These never go away; they gradually increase and increase until the > application starts giving errors (probably because some socket or > filedescriptor limit is reached). When the application is killed these > entries disappear. > > The application in question is a self written DNS server, multithreaded, and > running fine for years without any troubles on both BSD 5.x as well as 6.x. > Also 32bits as well as 64bits on 6.x. > > Ofcourse that doesn't mean that the application is error free, however, after > doing extensive testing I really can not find anything wrong with the > application itself, so I'm thinking maybe there's a change somewhere that > causes this? I know that tcp/network has been completely redone... > > What basically happens in the application is this: > - one main tcp thread runs an infinite while loop waiting for new > connections to arrive > - as soon as one arrives a new thread is spawned that handles the newly > created stream > - it reads some bytes, writes some bytes, then closes it > - thread exits > > What appears to happen is this: after the new thread is spawned it tries to > read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and > therefore closes the sockets and calls pthread_exit. However in netstat that > same stream oftenly appears to have bytes 'stuck' in the in queue... > > I really can't see how this can cause hanging sockets in 'CLOSED' state. Even > if the incoming queue isnt read entirely a call to close should close it. > Also I really can't find any documentation in netstat, or elsewhere, about > the 'CLOSED' state... > > > Any help would greatly be appreciated! > > > Kind Regards, > > > Ali Niknam > _______________________________________________ > 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 Wed Jun 25 19:50:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A70C9106566C for ; Wed, 25 Jun 2008 19:50:28 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 36F098FC31 for ; Wed, 25 Jun 2008 19:50:27 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so3424824fkk.11 for ; Wed, 25 Jun 2008 12:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Z5Jxig8N+zgDRJzT1xjHHZbOsi6+nIBHGsLuilhFdRc=; b=Dz8QPtyylIXJodczv+cZJEtwmyuhNnHCSUapiT+xIpmbsOAmIEcECGbvDRaJQWHxI/ RocknTjtb/9pPJgfR+fss+UEAfcImRUFAzSoo1N6tqXSTAlUw+/4Xov4Scim/GqYi8se 8MbyBjTs+XGT/YR+gppXH4QVzpKtby8iJ7/YU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=i5TSuK5Q+urd3AnisLyGad1pna3MTc0jqz/XYA1cNb0aXMwlOjjJA5pB8b6kFGpCay WfyK/vaZB+F5LtZLFs3SRbidpMvhRWENLweKLRd8ecxLNSrcf0YzdDpePD2sppl0aHDz nY381m5Jiz6iDVLDPvvznglYFJLRUrUk+IVdQ= Received: by 10.78.106.3 with SMTP id e3mr3892273huc.73.1214423425918; Wed, 25 Jun 2008 12:50:25 -0700 (PDT) Received: by 10.78.161.6 with HTTP; Wed, 25 Jun 2008 12:50:25 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2008 15:50:25 -0400 From: "Scott Ullrich" To: "Yuri Lukin" In-Reply-To: <20080625193208.M92670@swaggi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 19:50:28 -0000 On Wed, Jun 25, 2008 at 3:33 PM, Yuri Lukin wrote: > I believe the original author of the patch has one that should work with current: > > http://vanhu.free.fr/FreeBSD/ Even better. Looks like http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff might be semi up to date. Thanks a million for assisting Julian, this is going to make a lot of folks happy! :) Scott From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 19:53:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C79E41065672 for ; Wed, 25 Jun 2008 19:53:10 +0000 (UTC) (envelope-from emss@free.fr) Received: from mallaury.nerim.net (mallaury.ipv6.nerim.net [IPv6:2001:7a8:1:5::82]) by mx1.freebsd.org (Postfix) with ESMTP id 829728FC1B for ; Wed, 25 Jun 2008 19:53:10 +0000 (UTC) (envelope-from emss@free.fr) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id D030F4FD3F; Wed, 25 Jun 2008 21:52:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id F0A9F170BA; Wed, 25 Jun 2008 21:53:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omj8i9FptVJT; Wed, 25 Jun 2008 21:53:07 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id C659C170E7; Wed, 25 Jun 2008 21:53:07 +0200 (CEST) To: Julian Elischer From: Eric Masson In-Reply-To: <48629020.8000207@elischer.org> (Julian Elischer's message of "Wed, 25 Jun 2008 11:36:16 -0700") References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> X-Operating-System: FreeBSD 6.3-RELEASE-p1 i386 Date: Wed, 25 Jun 2008 21:53:07 +0200 Message-ID: <867icdfg0s.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, vanhu@free.fr, mgrooms@shrew.net, Norberto Meijome , Scott Ullrich Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 19:53:10 -0000 Julian Elischer writes: Hi, > where is the patch? It seems that the last patch to -current is available here : http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff Maybe Yvan has a more recent patch available (CCed) -- Ce ne sont que des propositions. Je ne veux pas les faire passer en force. Je pense que si mes idées doivent être reprises, elles ne doivent pas passer au vote, pour plusieurs raison : -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 19:55:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 560EE1065677 for ; Wed, 25 Jun 2008 19:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1070D8FC2C for ; Wed, 25 Jun 2008 19:55:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7E7D141C7B5; Wed, 25 Jun 2008 21:55:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id IemsN4wz1d9Z; Wed, 25 Jun 2008 21:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 32C6D41C7B4; Wed, 25 Jun 2008 21:55: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 50BF144487F; Wed, 25 Jun 2008 19:53:27 +0000 (UTC) Date: Wed, 25 Jun 2008 19:53:27 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <48629DE0.5000407@elischer.org> Message-ID: <20080625195246.N83875@maildrop.int.zabbadoz.net> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, Norberto Meijome , Scott Ullrich Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 19:55:07 -0000 On Wed, 25 Jun 2008, Julian Elischer wrote: Hi Julian, > I don't have time to do a lot of work on it, but if you can get me a patch > that applies cleanly on -current > and that you have tested, along with testing other cases (e.g. not compiled > in) > then I can give it a look over and if it looks ok I can commit it > to -current and then MFC it back to 7 in a week's time or so. if it would be that easy, it would have happened 2 years ago. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 19:56:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F11C1065671 for ; Wed, 25 Jun 2008 19:56:19 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8D47F8FC0A for ; Wed, 25 Jun 2008 19:56:18 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so3426890fkk.11 for ; Wed, 25 Jun 2008 12:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7ZqHNlBIAEQG4aVfblwXMjlEWlGo4Bd5wfR9b30MM/8=; b=vFDCoGxdVnbCu99D9PyNMNFlUdUBLq+nj5TYdekDgQvzwFw/x7UmYErdBWsPUVcpvp RS2JI63yLFSjzBnswa5NQ6Ix6Fa2qIxLhAGJnXPLTZBTDoZDYI93r/aG9XNJ5+m/L8ye HMhj51Mce5BbC6J9MpT1bU7bDinOwgCpy131I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=I5TXqJ+yWevTgoauwdEkByd5cTQqXmPcwQxU2451JdKquCwAzbOcjeIiXxOPTci116 AaBcHJNMcC5BsXKqKigyQEKF7ujnXhQ+AdjzH6k0w5IYEqO5xTws2A6HUhg06duYAtDu GVg/lTcQe6wy2wgT5HcoRPbYWEImGuDJeiluI= Received: by 10.78.97.7 with SMTP id u7mr3898857hub.28.1214423777044; Wed, 25 Jun 2008 12:56:17 -0700 (PDT) Received: by 10.78.161.6 with HTTP; Wed, 25 Jun 2008 12:56:16 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2008 15:56:16 -0400 From: "Scott Ullrich" To: "Bjoern A. Zeeb" In-Reply-To: <20080625195246.N83875@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625195246.N83875@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, Julian Elischer , Norberto Meijome Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 19:56:19 -0000 On Wed, Jun 25, 2008 at 3:53 PM, Bjoern A. Zeeb wrote: > if it would be that easy, it would have happened 2 years ago. What can we as a community do to assist in making this easier and doable? Scott From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 20:09:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4141065674 for ; Wed, 25 Jun 2008 20:09:40 +0000 (UTC) (envelope-from lists@swaggi.com) Received: from rusty.swaggy.net (rusty.swaggy.net [204.14.85.196]) by mx1.freebsd.org (Postfix) with ESMTP id A71BA8FC0C for ; Wed, 25 Jun 2008 20:09:40 +0000 (UTC) (envelope-from lists@swaggi.com) Received: from localhost ([127.0.0.1] helo=swaggi.com) by rusty.swaggy.net with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBaju-0000Vt-46; Wed, 25 Jun 2008 15:33:11 -0400 From: "Yuri Lukin" To: Julian Elischer ,Scott Ullrich Date: Wed, 25 Jun 2008 15:33:10 -0400 Message-Id: <20080625193208.M92670@swaggi.com> In-Reply-To: <48629DE0.5000407@elischer.org> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> X-Mailer: swaggi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 20:09:40 -0000 On Wed, 25 Jun 2008 12:34:56 -0700, Julian Elischer wrote > Scott Ullrich wrote: > > On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer wrote: > >> > >> where is the patch? > >> > >> > > > > The version that we use in RELENG_7_0 is located here: > > http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain > > > > Thanks Julian! > > I don't have time to do a lot of work on it, but if you can get me a > patch that applies cleanly on -current > and that you have tested, along with testing other cases (e.g. not > compiled in) > then I can give it a look over and if it looks ok I can commit it > to -current and then MFC it back to 7 in a week's time or so. > is it ABI compatible? > > > > > Scott > I believe the original author of the patch has one that should work with current: http://vanhu.free.fr/FreeBSD/ From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 20:24:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAED91065670 for ; Wed, 25 Jun 2008 20:24:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 94CF68FC0A for ; Wed, 25 Jun 2008 20:24:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id DAC6B2478; Wed, 25 Jun 2008 13:24:40 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BBE5A2D6004; Wed, 25 Jun 2008 13:24:40 -0700 (PDT) Message-ID: <4862A995.3090109@elischer.org> Date: Wed, 25 Jun 2008 13:24:53 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Scott Ullrich References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 20:24:41 -0000 Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 3:33 PM, Yuri Lukin wrote: >> I believe the original author of the patch has one that should work with current: >> >> http://vanhu.free.fr/FreeBSD/ > > Even better. > > Looks like http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff > might be semi up to date. > > Thanks a million for assisting Julian, this is going to make a lot of > folks happy! :) do you have the ability to test this? > > Scott From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 20:30:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F24031065677 for ; Wed, 25 Jun 2008 20:30:38 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7D83B8FC21 for ; Wed, 25 Jun 2008 20:30:38 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so3438986fkk.11 for ; Wed, 25 Jun 2008 13:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=h+N5kR9WsaeMsnvt9oq033p03C0riq2w4hhJgcKPMY8=; b=UMn7lMacEkNyNr/mpJ6nuI8npU25FJNUSJlPaN4Sf56d6o820ixmM5hAzVDvA2xpbU NOAj/B/h9J6WOhbYiH7sy4hooMpWO9Jqp1UJIe7tGBaCIcIpht8hDR+lbKrdz5MFGqk0 rIFiTC1tcq2bQ2BjftoVlHOQsKuv5xVJxN5EI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hu6TxVMiJDOIqX9NWMpK/LTG8NJy0vnnf0ERkJVI2btejeMgaTXLtauJ2SmcFhd4Re i52wr8v8z1h/m5L76m+HUpFpTaJUXpmEp5kWy62vtz8zgQZ0lTXjVw+jV4rdDVPpanF5 kxg4fEvJPMkBDSyBVmuPKT1Cqlu9UUGTccMzM= Received: by 10.78.200.17 with SMTP id x17mr3911220huf.57.1214425836989; Wed, 25 Jun 2008 13:30:36 -0700 (PDT) Received: by 10.78.161.6 with HTTP; Wed, 25 Jun 2008 13:30:36 -0700 (PDT) Message-ID: Date: Wed, 25 Jun 2008 16:30:36 -0400 From: "Scott Ullrich" To: "Julian Elischer" In-Reply-To: <4862A995.3090109@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> <4862A995.3090109@elischer.org> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 20:30:39 -0000 On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer wrote: > do you have the ability to test this? Absolutely. Is this the only thing from preventing it being merged into HEAD? Scott From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 20:44:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8A801065674 for ; Wed, 25 Jun 2008 20:44:59 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 37B1C8FC13 for ; Wed, 25 Jun 2008 20:44:58 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m5PKjQjE047881; Wed, 25 Jun 2008 15:45:26 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m5PKjQJe047880; Wed, 25 Jun 2008 15:45:26 -0500 (CDT) (envelope-from brooks) Date: Wed, 25 Jun 2008 15:45:26 -0500 From: Brooks Davis To: Scott Ullrich Message-ID: <20080625204526.GA47809@lor.one-eyed-alien.net> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> <4862A995.3090109@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 25 Jun 2008 15:45:26 -0500 (CDT) Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 20:45:00 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer wr= ote: > > do you have the ability to test this? >=20 > Absolutely. Is this the only thing from preventing it being merged into= HEAD? No. It's a large and complex patch an a subsystem (ipsec) that must not be broken. We're a bit shorthanded in this area, but people have been working on this for quite some time and IIRC aren't fully comfortable with the patch yet. -- Brooks --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIYq5lXY6L6fI4GtQRApu2AKC3WPUkNu7k3+7SYv9VpoLgBS3xQQCfUGi5 pnOFo/vFif8KRISeZoawYKQ= =7GOt -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 25 21:03:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A230106566B for ; Wed, 25 Jun 2008 21:03:52 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 57C708FC1B for ; Wed, 25 Jun 2008 21:03:50 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 49795 invoked by uid 98); 25 Jun 2008 21:03:48 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.040336 secs); 25 Jun 2008 21:03:48 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.040336 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 25 Jun 2008 21:03:48 -0000 Message-ID: <4862B2AF.70202@zirakzigil.org> Date: Wed, 25 Jun 2008 23:03:43 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <486000B5.9090703@zirakzigil.org> In-Reply-To: <486000B5.9090703@zirakzigil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 21:03:52 -0000 I finally got the problem, and it had nothing to do either with vlans or with carp. The firewall I was setting up was meant to replace an existing freebsd firewall which didn't use vlans (it had a lot of nics). The problem was that the network port where our ISP brings the internet connection still had the old aliased mac addresses in its arp cache. For some reason when I plugged in the new firewall, only the base non-aliased address was updated in the ISP switch arp cache (if someone can throw a guess at why, I'm eager to listen). The ISP router was still looking for the aliased addresses with the old macs, so it didn't find them. Moreover, I inadvertently put the vlan internet interface in promiscuous mode, so with tcpdump I also picked up those packets with wrong mac address which weren't meant for me. To make the story short, I called the technical customer care of the ISP and I requested them to reset the arp cache of the port. Done that, everything worked without a glitch. The new firewall is now up and running in production with vlan + carp. Everything seems fine. Thanks to everybody who answered my plea... :-) Giulio Ferro wrote: > After some more tests I've finally realized that the problem is with > vlan and alias. I've taken carp out of the picture. > > > (Please read my previous message on the topic to understand the scenario, > I've reported it below) > > Here is what matters in /etc/rc.conf: > > ----------------------------------------------------------- > ... > ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" > ... > ifconfig_vlan128="inet x.y.z.132 netmask 255.255.255.224 vlan 128 > vlandev bce0" > ifconfig_vlan128_alias0="x.y.z.133 netmask 255.255.255.255" > ifconfig_vlan128_alias1="x.y.z.134 netmask 255.255.255.255" > ifconfig_vlan128_alias2="x.y.z.135 netmask 255.255.255.255" > ifconfig_vlan128_alias3="x.y.z.136 netmask 255.255.255.255" > ifconfig_vlan128_alias4="x.y.z.137 netmask 255.255.255.255" > ifconfig_vlan128_alias5="x.y.z.138 netmask 255.255.255.255" > ifconfig_vlan128_alias6="x.y.z.139 netmask 255.255.255.255" > ifconfig_vlan128_alias7="x.y.z.140 netmask 255.255.255.255" > ifconfig_vlan128_alias8="x.y.z.141 netmask 255.255.255.255" > ... > defaultrouter="x.y.z.129" > ----------------------------------------------------------- > > netstat -rn > ----------------------------------------------------------- > default x.y.z.129 UGS 0 9869 vlan12 > x.y.z.128/27 link#11 UC 0 0 vlan12 > x.y.z.129 00:00:0c:07:ac:0a UHLW 2 52 vlan12 1107 > x.y.z.130 00:d0:03:8a:9b:fc UHLW 1 0 vlan12 1147 > x.y.z.131 00:d0:03:8a:9b:fd UHLW 1 0 vlan12 1144 > x.y.z.133/32 link#11 UC 0 0 vlan12 > x.y.z.134/32 link#11 UC 0 0 vlan12 > x.y.z.135/32 link#11 UC 0 0 vlan12 > x.y.z.136/32 link#11 UC 0 0 vlan12 > x.y.z.137/32 link#11 UC 0 0 vlan12 > x.y.z.138/32 link#11 UC 0 0 vlan12 > x.y.z.139/32 link#11 UC 0 0 vlan12 > x.y.z.140/32 link#11 UC 0 0 vlan12 > x.y.z.141/32 link#11 UC 0 0 vlan12 > ----------------------------------------------------------- > > ifconfig vlan128 > ----------------------------------------------------------- > vlan128: flags=8843 metric 0 > mtu 1500 > options=3 > ether 00:1e:c9:ad:fa:c9 > inet x.y.z.132 netmask 0xffffffe0 broadcast x.y.z.159 > inet x.y.z.133 netmask 0xffffffff broadcast x.y.z.133 > inet x.y.z.134 netmask 0xffffffff broadcast x.y.z.134 > inet x.y.z.135 netmask 0xffffffff broadcast x.y.z.135 > inet x.y.z.136 netmask 0xffffffff broadcast x.y.z.136 > inet x.y.z.137 netmask 0xffffffff broadcast x.y.z.137 > inet x.y.z.138 netmask 0xffffffff broadcast x.y.z.138 > inet x.y.z.139 netmask 0xffffffff broadcast x.y.z.139 > inet x.y.z.140 netmask 0xffffffff broadcast x.y.z.140 > inet x.y.z.141 netmask 0xffffffff broadcast x.y.z.141 > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 128 parent interface: bce0 > ----------------------------------------------------------- > > Tests: > No problem when I try to ping the default gateway from my fw > No problem when I ping my fw from an external internet address > > Problems: > - I cannot ping the router from one of the aliased address: > ping -S x.y.z.133 x.y.z.129 > - I cannot ping the aliased addresses from an external internet address > > Note : I can see the packets with tcpdump travelling from and to the > aliased > address. It seems the interface won't process them for some reason. > > This seems suspiciously like a bug to me... > > > -------------------------------------------------------------------------------------- > > (previous message on vlan + carp +alias) > -------------------------------------------------------------------------------------- > > > > Primeroz lists wrote: >> What is tcpdump showing for ping on 192.168.10.11 >> ? can you see echo reply exiting vlan10 >> interface ? >> >> what if you try from your server to "ping -S 192.168.10.11 >> 192.168.10.254 " ? >> >> >> > First of all I'm sorry for the late reply. Yesterday I could do some more > in-depth test to analyze this strange behavior of my firewall. > > The 192.168.10.0/24 range I used in the previous example isn't the real > one, I just used it for simplicity´s sake. > The true range, the one which has been assigned by the ISP to my customer > is: x.y.z.128/27. (x.y.z corresponds to a true public IP address) > > I've deactivated the firewall, so we have one less thing to worry about: > /etc/rc.d/pf stop > This is a pure network configuration issue. > > Here is the relevant part in /etc/rc.conf: > --------------------------------------------------- > ... > ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" > ... > cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 > carp30 carp40 carp128" > ... > ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 > vlandev bce0" > ... > ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255" > ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255" > ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255" > ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255" > ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255" > ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255" > ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255" > ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255" > ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255" > ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255" > ... > defaultrouter="x.y.z.129" > --------------------------------------------------- > > On my managed switch I've set 2 ports: > 1) the one where the bce0 interface is plugged in : mode trunk with > all the vlans above > 2) the one where the ISP internet is plugged in : mode access with > vlan 128 > > I've also set the ip interface of my switch to x.y.z.155 vlan 128 > > > Here is the relevant part of netstat -rn on my machine > --------------------------------------------------- > default x.y.z.129 UGS 0 13966 vlan12 > x.y.z/27 link#11 UC 0 0 vlan12 > x.y.z.132 x.y.z.132 UH 0 0 carp12 > x.y.z.133 x.y.z.133 UH 0 0 carp12 > x.y.z.134 x.y.z.134 UH 0 0 carp12 > x.y.z.135 x.y.z135 UH 0 0 carp12 > x.y.z.136 x.y.z.136 UH 0 0 carp12 > x.y.z.137 x.y.z.137 UH 0 0 carp12 > x.y.z.138 x.y.z.138 UH 0 0 carp12 > x.y.z.139 x.y.z.139 UH 0 0 carp12 > x.y.z.140 x.y.z.140 UH 0 0 carp12 > x.y.z.141 x.y.z.141 UH 0 0 carp12 > x.y.z.155 00:1e:c9:90:4a:c0 UHLW 1 8 vlan12 1183 > > --------------------------------------------------- > > > > Here come the tests. > 1) From the firewall : basic > I can ping both the default gateway (x.y.z.129) and the switch > interface (x.y.z.155) > I can ping a generic internet address (a.b.c.d) > With tcpdump I can see the packets leaving as x.y.z.157 and coming > with the same > address > > 2) from the switch : basic > I can ping the firewall's vlan address (x.y.z.157) > I can ping _ALL_ the carp interfaces, base and alias: > ping x.y.z.157 -> OK > ping x.y.z.132 -> OK > ping x.y.z.133 -> OK > ... > ping x.y.z.141 -> OK > > 3) from the internet : basic > From an external internet address I can ping the vlan address: > ping x.y.z.157 -> OK > > 4) from the firewall : advanced > From the firewall I can ping the switch address from one of the carp > base and aliased address: > ping -S x.y.z.132 x.y.z.155 -> OK > ping -S x.y.z.133 x.y.z.155 -> OK > > I _cannot_ ping the default router from one of the carp addresses: > ping -S x.y.z.132 x.y.z.129 -> NOT OK > ping -S x.y.z.133 x.y.z.129 -> NOT OK > By using tcpdump on the vlan128 interface I can see the packets > _BOTH_ leaving and coming from the carp addresses. It just seems > that the carp interfaces can't process the packets properly. > > 5) from the internet : advanced > From an external internet address I _cannot_ ping the carp addresses > (x.y.z.132 and up) > As above, I can see the incoming packets with > tcpdump -i vlan128 -n icmp > > > Ok, that was long. I hope someone can help to shed light into this, to > see > whether this is a bug or not. > I stress again that the _same_ configuration works as it should on a > physical > (non-vlan) interface. > _______________________________________________ > 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 Wed Jun 25 21:47:53 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 902E0106567B for ; Wed, 25 Jun 2008 21:47:53 +0000 (UTC) (envelope-from freebsd-net@transip.nl) Received: from relay0.transip.nl (relay0.transip.nl [80.69.67.21]) by mx1.freebsd.org (Postfix) with ESMTP id 42C988FC1E for ; Wed, 25 Jun 2008 21:47:53 +0000 (UTC) (envelope-from freebsd-net@transip.nl) Received: from [192.168.0.3] (ip86-50-212-87.adsl2.static.versatel.nl [87.212.50.86]) by relay0.transip.nl (Postfix) with ESMTP id 54BDE1036BA; Wed, 25 Jun 2008 23:47:49 +0200 (CEST) Message-ID: <4862BCF5.4070900@transip.nl> Date: Wed, 25 Jun 2008 23:47:33 +0200 From: Ali Niknam Organization: Transip BV User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Robert Watson References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> In-Reply-To: <20080625195523.N29013@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Jun 2008 21:47:53 -0000 Hi Robert, > Sounds like there's a bug somewhere. Before we start trying to track it [...] > So, with that introduction, we're interested in resolving: > Quite comprehensive indeed; thank you for all that information. I was not aware that there was a decoupling between the various parts of the abstractions, but now that I think of it, it's more or less logical I guess. > The first is the easiest to resolve, as all we need to do is see whether [...] > the file descriptor numbers being returned to see whether, perhaps, that > number only goes up over time, and gets really big. > My personal feeling is that it's a race condition; no idea why, but it feels that way. Maybe because it's such a small number as compared to the big amount of connections that takes place. I do not leak file descriptors as far as I can see, I can send you the information you ask for (netstat, sockstat, fstat, etc.) offlist if you like, or if you prefer, I can give you access to the machine, please let me know whichever you like. I'd like to reiterate that at this moment i'm not sure at all if it's my code, or kernel code. However I've seen, for my feeling, sufficient information to reasonably suspect that it _might_ be something outside my code :). > wedged-up state. It would be most helpful if you could actually shut > down to single-user mode, killing all user processes, then waiting ten > minutes, and capturing the output of those above commands to files that > you can then e-mail to me. > Because it's a live machine that would be very difficult. Maybe, if you really really need it that way and we can't find another way I can announce maintainance and do it in the middle of the night :). > Without accusing you of having buggy code, I should say that I think > there's a reasonable chance that what you're seeing is an interaction > between an existing leak of resources in the application and the way the > kernel state management has changed. The output from netstat pretty Yes that was the first thing I though of as well, however, especially one of the two applications is so simple that I would be ashamed to death if I still had a bug in there :). If it turns out that way: sssstttt ;). > precisely matches that what you'd expect: lots of TCP connections in the > CLOSED state reflecting a series of connections built by an application > but then not properly discarded. Likewise, when the application is > killed, all of the connections go away -- most likely because the file > descriptors are all closed, allowing them to be garbage collected and > connection state freed. If it is this sort of bug, then most likely > you're missing a call to close() in a work loop somewhere, and in some > exceptional case, you fall out of the loop without calling close(). > I will double check this once more, but honestly, i strongly doubt it... Also one other thing that I've noticed, is that it's always the input buffer that has bytes left; never the output buffer... Moreover, i've seen that close() reports EBADF, but due to the insane amount of connections I can not say for certain that that's when the connection goes into CLOSED state. The ip's do match, but it's very common for the same ip's to make numerous connections too. Kind Regards, Ali -- Transip BV | http://www.transip.nl/ We never let you down. From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 00:03:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5ED106564A for ; Thu, 26 Jun 2008 00:03:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id E84838FC26 for ; Thu, 26 Jun 2008 00:03:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A41462448; Wed, 25 Jun 2008 17:03:58 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 75FBB2D600F; Wed, 25 Jun 2008 17:03:58 -0700 (PDT) Message-ID: <4862DCFB.1050203@elischer.org> Date: Wed, 25 Jun 2008 17:04:11 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625195246.N83875@maildrop.int.zabbadoz.net> In-Reply-To: <20080625195246.N83875@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, Norberto Meijome , Scott Ullrich Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 00:03:59 -0000 Bjoern A. Zeeb wrote: > On Wed, 25 Jun 2008, Julian Elischer wrote: > > Hi Julian, > >> I don't have time to do a lot of work on it, but if you can get me a >> patch that applies cleanly on -current >> and that you have tested, along with testing other cases (e.g. not >> compiled in) >> then I can give it a look over and if it looks ok I can commit it >> to -current and then MFC it back to 7 in a week's time or so. > > if it would be that easy, it would have happened 2 years ago. > I don't see anything in there that would stop a commit. Please be more specific? From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 00:14:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31FA106564A for ; Thu, 26 Jun 2008 00:14:02 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id C3F3E8FC19 for ; Thu, 26 Jun 2008 00:14:02 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 96E5879E2CA; Wed, 25 Jun 2008 19:14:02 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 83815-09; Thu, 26 Jun 2008 00:14:02 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 2CC4A79E26A; Wed, 25 Jun 2008 19:14:02 -0500 (CDT) Received: from hole.shrew.net (localhost [127.0.0.1]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m5Q0DxCP048521; Wed, 25 Jun 2008 19:13:59 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: (from www@localhost) by hole.shrew.net (8.14.2/8.14.2/Submit) id m5Q0DxQR048520; Wed, 25 Jun 2008 19:13:59 -0500 (CDT) (envelope-from mgrooms@shrew.net) X-Authentication-Warning: hole.shrew.net: www set sender to mgrooms@shrew.net using -f To: Julian Elischer MIME-Version: 1.0 Date: Wed, 25 Jun 2008 19:13:59 -0500 From: mgrooms Organization: Shrew Soft Inc In-Reply-To: <48629DE0.5000407@elischer.org> References: <48629DE0.5000407@elischer.org> Message-ID: <7ec5b81263bb9dc933d392a8efb26136@localhost> X-Sender: mgrooms@shrew.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Norberto Meijome , Scott Ullrich Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mgrooms@shrew.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 00:14:03 -0000 On Wed, 25 Jun 2008 12:34:56 -0700, Julian Elischer wrote: > Scott Ullrich wrote: >> On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer > wrote: >>> >>> where is the patch? >>> >>> >> >> The version that we use in RELENG_7_0 is located here: >> > http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain >> >> Thanks Julian! > > I don't have time to do a lot of work on it, but if you can get me a > patch that applies cleanly on -current > and that you have tested, along with testing other cases (e.g. not > compiled in) > then I can give it a look over and if it looks ok I can commit it > to -current and then MFC it back to 7 in a week's time or so. > is it ABI compatible? > Julian, To my knowledge, here are the latest patch sets ... http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 00:22:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 870921065671 for ; Thu, 26 Jun 2008 00:22:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF458FC1A for ; Thu, 26 Jun 2008 00:22:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 2F65F248C; Wed, 25 Jun 2008 17:22:31 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BCA202D600F; Wed, 25 Jun 2008 17:22:30 -0700 (PDT) Message-ID: <4862E154.1000907@elischer.org> Date: Wed, 25 Jun 2008 17:22:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Scott Ullrich References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625195246.N83875@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , mgrooms@shrew.net, Norberto Meijome , freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 00:22:31 -0000 Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 3:53 PM, Bjoern A. Zeeb > wrote: >> if it would be that easy, it would have happened 2 years ago. > > What can we as a community do to assist in making this easier and doable? that is the question.. NAT-T is a very useful feature, and not having it s a strike agains FreeBSD in a lot of eyes.. (It's needed for example to talk to ASA firewalls for VPN stuff I believe). Anyhow I looked at the patch briefly and haven't seen anything horrendously terrible in it.. I'll look a bit more later but it doesn't seem to interfere with unrelated code that I can see. > > Scott > _______________________________________________ > 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 Thu Jun 26 01:38:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C497E1065676 for ; Thu, 26 Jun 2008 01:38:02 +0000 (UTC) (envelope-from erik@cepheid.org) Received: from mail.cepheid.org (aleph.cepheid.org [72.232.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id A69868FC18 for ; Thu, 26 Jun 2008 01:38:02 +0000 (UTC) (envelope-from erik@cepheid.org) Received: by mail.cepheid.org (Postfix, from userid 1006) id B06AB9B4002; Wed, 25 Jun 2008 20:38:01 -0500 (CDT) Date: Wed, 25 Jun 2008 20:38:01 -0500 From: Erik Osterholm To: Max Laier Message-ID: <20080626013801.GA83308@aleph.cepheid.org> Mail-Followup-To: Erik Osterholm , Max Laier , freebsd-net@freebsd.org References: <20080624212639.GA41755@aleph.cepheid.org> <4c5bca29cfc1cdd3efa81ffb2f815675.squirrel@router> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c5bca29cfc1cdd3efa81ffb2f815675.squirrel@router> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Why isn't ALTQ in GENERIC? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 01:38:02 -0000 On Wed, Jun 25, 2008 at 03:13:54AM +0200, Max Laier wrote: > Hi Erik, > > Am Di, 24.06.2008, 23:26, schrieb Erik Osterholm: > > Can anyone tell me if there are good reasons for explicitly leaving > > ALTQ out of the kernel? More specific to my circumstances, if I'm > > building kernels to be installed on every machine we deploy, is it > > worth building a separate kernel for ALTQ for those few boxes which > > will require it? > > > > Are there performance issues? Stability issues? Ultimately, I'm just > > surprised that it's not available in GENERIC if there isn't a good > > reason, but I can't find any documentation for that reason. > > Short answer: Historical reasons. > > Whole stroy: When ALTQ was added there were both performance and stability > concerns. For a long time we had a big #ifdef ALTQ in if_var.h to avoid > one additional check for if_queue enqueue opperations. These are now gone > and I personally don't see any issues that would prevent ALTQ from being > in GENERIC. However, it's unclear which disceplines to turn on by > default. I'd like to see ALTQ in GERNERIC, but I've been reluctant to > make the change on my own. If we can get a quorum here, I'll reconsider > it. Thanks for the explanation. I think that it would be nice to have in GENERIC, but my immediate concerns were for with the performance and stability. Thanks! Erik From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 02:31:35 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8932106566C; Thu, 26 Jun 2008 02:31:35 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from outbound.icp-qv1-irony-out1.iinet.net.au (outbound.icp-qv1-irony-out1.iinet.net.au [203.59.1.108]) by mx1.freebsd.org (Postfix) with ESMTP id 1FEC98FC1D; Thu, 26 Jun 2008 02:31:34 +0000 (UTC) (envelope-from lstewart@room52.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOuZYkh8qAaW/2dsb2JhbACycw X-IronPort-AV: E=Sophos;i="4.27,706,1204470000"; d="scan'208";a="347714656" Received: from unknown (HELO lawrence1.loshell.home) ([124.168.6.150]) by outbound.icp-qv1-irony-out1.iinet.net.au with ESMTP; 26 Jun 2008 10:19:28 +0800 Message-ID: <4862FCBD.3090906@room52.net> Date: Thu, 26 Jun 2008 12:19:41 +1000 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.14 (X11/20080530) MIME-Version: 1.0 To: Ali Niknam References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> In-Reply-To: <4862BCF5.4070900@transip.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 02:31:35 -0000 Ali Niknam wrote: > Hi Robert, [snip] > > I will double check this once more, but honestly, i strongly doubt it... > > Also one other thing that I've noticed, is that it's always the input > buffer that has bytes left; never the output buffer... > > Moreover, i've seen that close() reports EBADF, but due to the insane > amount of connections I can not say for certain that that's when the > connection goes into CLOSED state. The ip's do match, but it's very > common for the same ip's to make numerous connections too. > To get a bit more detail about the state of the tcb and socket buffers at the time the connection is shut down, you can use my SIFTR tool, available from: http://caia.swin.edu.au/urp/newtcp/tools.html The readme should explain how to use it. Please keep the "ppl" sysctl at 1. Once you have some data collected for tcbs you know end up in the unexpected CLOSED state, have a look at the relevant fields in the SIFTR log file and let us know what you find. Might be useful if you send the log file through as well for me to have a quick look. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 03:18:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9CF106564A for ; Thu, 26 Jun 2008 03:18:55 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id CEC6D8FC12 for ; Thu, 26 Jun 2008 03:18:54 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 92265 invoked by uid 89); 26 Jun 2008 03:19:56 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 26 Jun 2008 03:19:56 -0000 Message-ID: <48630AA3.3000800@ibctech.ca> Date: Wed, 25 Jun 2008 23:18:59 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Giulio Ferro References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> In-Reply-To: <4862B2AF.70202@zirakzigil.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 03:18:55 -0000 Giulio Ferro wrote: > I finally got the problem, and it had nothing to do either with vlans or > with carp. > > The firewall I was setting up was meant to replace an existing freebsd > firewall > which didn't use vlans (it had a lot of nics). > The problem was that the network port where our ISP brings the internet > connection > still had the old aliased mac addresses in its arp cache. Thank you Giulio (is it Gio?)... for replying everyone with a definitive conclusion. Thats fantastic for the followers of the thread, but the archives as well. > For some > reason when I > plugged in the new firewall, only the base non-aliased address was > updated in > the ISP switch arp cache (if someone can throw a guess at why, I'm eager > to listen). Well, you need to know what type of switch they had upstream, and why they weren't updating their ARP cache dynamically properly. Perhaps because their cache ttl was too long (due to the type of hardware, or administrative setting). I almost have to assume it wasn't a Cisco... only because I would have expected different behavior (less administrative setting) (this is my personal experience...I'm not trying to favour a brand in any way). Perhaps you could ask them to provide the command they issued to determine how they found the problem. Better yet, ask what type of device your box is connected to at their end of the VLAN. If you can find out what device they have at their end, it may almost be possible to non-destructively, and non-corruptively 'force' them to clear arp-cache remotely, and at the same time provide advice to the non-unscrupulous people who may run into this in the future. I'd be just as interested to know what they had at their end for hardware, as I have been waiting to hear what your resolution was throughout your time consuming troubleshooting... Steve From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 07:50:13 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5B6B1065671 for ; Thu, 26 Jun 2008 07:50:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A20BB8FC25 for ; Thu, 26 Jun 2008 07:50:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 40E6A46C10; Thu, 26 Jun 2008 03:50:13 -0400 (EDT) Date: Thu, 26 Jun 2008 08:50:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ali Niknam In-Reply-To: <4862BCF5.4070900@transip.nl> Message-ID: <20080626081831.V96707@fledge.watson.org> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 07:50:13 -0000 On Wed, 25 Jun 2008, Ali Niknam wrote: >> precisely matches that what you'd expect: lots of TCP connections in the >> CLOSED state reflecting a series of connections built by an application but >> then not properly discarded. Likewise, when the application is killed, all >> of the connections go away -- most likely because the file descriptors are >> all closed, allowing them to be garbage collected and connection state >> freed. If it is this sort of bug, then most likely you're missing a call >> to close() in a work loop somewhere, and in some exceptional case, you fall >> out of the loop without calling close(). > > I will double check this once more, but honestly, i strongly doubt it... > > Also one other thing that I've noticed, is that it's always the input buffer > that has bytes left; never the output buffer... > > Moreover, i've seen that close() reports EBADF, but due to the insane amount > of connections I can not say for certain that that's when the connection > goes into CLOSED state. The ip's do match, but it's very common for the same > ip's to make numerous connections too. I think the first logical step is to wait for the application to get into that state again, and then run procstat or fstat to dump the file descriptor away for the process. Presumably in the normal steady state, you expect to see a few IPC sockets (syslog, etc), a TCP listen socket, and some number of in-progress TCP sessions. The question, of course, is whether you see a lot more file descriptors than that, and in particular, ones that matched the CLOSED entries in netstat. If you find that there are lots of open file descriptors and they match up approximately with netstat, then it's an application bug that just manifests a bit differently in 7.x than in 6.x. On the other hand, if you see only a small number of open file descriptors, then we may be looking at something quite a bit more complicated. I would next seek to confirm the analysis that "they go away when the application is killed" -- do they really disappear at the very moment it exits, or do they kind of disappear over time and it just happens that by the time you run netstat after killing the application, they're gone. I.e., I'd try something like "netstat -na > file1 ; kill pid ; sleep 1 ; netstat -na > file2 ; diff -u file1 file2". If they really all go away in a large quantity the moment the process dies, then the reference model is working (i.e., they are freed), but perhaps references are being held onto in an unexpected way. For example, is the incomplete listen queue somehow getting filled with CLOSED sockets that are only garbage collected when close() is called on the listen socket? If we suspect that, we can actually test it by having your application close the listen socket and re-open it once in a while, and see if the CLOSED sockets fail to stack up. Speaking of which, I meant to ask: are you using accept filters, and if so, which one? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 08:12:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C9CB1065679 for ; Thu, 26 Jun 2008 08:12:27 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id B8F878FC13 for ; Thu, 26 Jun 2008 08:12:26 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 7D3DF3F7A; Thu, 26 Jun 2008 09:53:07 +0200 (CEST) Date: Thu, 26 Jun 2008 09:53:07 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080626075307.GA1401@zen.inc> References: <48629DE0.5000407@elischer.org> <7ec5b81263bb9dc933d392a8efb26136@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ec5b81263bb9dc933d392a8efb26136@localhost> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 08:12:27 -0000 On Wed, Jun 25, 2008 at 07:13:59PM -0500, mgrooms wrote: [...] > To my knowledge, here are the latest patch sets ... > > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff Yes: latest version of the patch will always be the file at that location with the most recent date. I have copies of repositories for HEAD, RELENG7 and RELENG6, and I can generate more up-to date patches if needed. I use patch for freebsd6 and freebsd7 in daily production, and can quite quickly test new versions if needed. I do NOT use directly the patch for HEAD actually, but should have a testing device for that soon. If some people have their own changes for those patches, please send them to me !!! What still lacks afaik in that patch: - support for NAT-OA. This is needed for transport mode when traffic is TCP (and when UDP traffic have a non zero checksum), such support needs some stuff in decapsulation process, complete support for NAT-OA payloads in PFKey, and complete support in userland. - Cleanup of PFKeyV2. Actually, NAT-T ports are not sent in a RFC compliant way (but it works). That cleanup needs also to be done in userland, and is on my TODO list (both kernel and userland). - Better detection of NAT-T support. Actually, ipsec-tools guess kernel support for NAT-T by checking some stuff in /usr/include. That just means you appliend the NAT-T patch, but that doesn't means you enabled NAT-T support in your kernel. Same problem exists for other implementations (at least Linux 2.6+ and NetBSD), a cleaner detection should also do "some checks" at runtime to ensure actual kernel really supports NAT-T. But that's an userland problem, and you can easilly force ipsec-tools compilation WITHOUT NAT-T support. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 09:53:45 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA2261065670 for ; Thu, 26 Jun 2008 09:53:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 58E608FC16 for ; Thu, 26 Jun 2008 09:53:44 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=cUhMQ/cdIgb+oy3bGSXlskU6NDjuz4xw0m0RQHCvWmuKVvCUzPGasoRXTlcUdQ/McNaSLRs/6KLP2bfOSrFh0UkRLARQ+TRcuPxGFohCNSIq2OV9RLkc2NSB4D9Tqc4CaCg9NIt0+SKCfG/1li6/Q1fSa+jI3fnjhZqkkJ+Y5Gs=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1KBo0V-0002wL-6I; Thu, 26 Jun 2008 13:43:11 +0400 Date: Thu, 26 Jun 2008 13:43:10 +0400 From: Eygene Ryabinkin To: net@freebsd.org Message-ID: <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> References: <486283B0.3060805@transip.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <486283B0.3060805@transip.nl> Sender: rea-fbsd@codelabs.ru Cc: Ali Niknam Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 09:53:45 -0000 Good day. Wed, Jun 25, 2008 at 07:43:12PM +0200, Ali Niknam wrote: > Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 > to FreeBSD 7.0 amd64. > > After upgrading I noticed a weird error/bug. It seems that after several > thousand TCP connections some seem to hang in 'CLOSED' state. > > netstat -n gives: > ... > tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED > tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED > tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED > tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED > ... Just a quick "me too" message: I also used to see this on my 7.x machines. This was with Apache servers in the proxy setup: one Apache was listening to the external requests and routing them to the internal servers that are also running Apache. I refrained from such setup and traded front-end Apache to nginx -- CLOSED sockets gone away. I had already tried to debug this situation and Mike Silbersack helped me with patching the kernel. At that days his patches (that went into 7.x) helped, but with higher request rate to the Apache, they seem to be back again. I can try to setup the testbed and verify if I will still be able to reproduce them. Will it be needed? > These never go away; they gradually increase and increase until the > application starts giving errors (probably because some socket or > filedescriptor limit is reached). When the application is killed these > entries disappear. > > The application in question is a self written DNS server, multithreaded, > and running fine for years without any troubles on both BSD 5.x as well > as 6.x. Also 32bits as well as 64bits on 6.x. Mine was Apache 2.2.x with fork model, no threading. -- Eygene From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 10:09:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 029C11065672 for ; Thu, 26 Jun 2008 10:09:05 +0000 (UTC) (envelope-from harunaga@harunaga.ru) Received: from Harunaga.ru (harunaga.ru [80.85.150.78]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA598FC1A for ; Thu, 26 Jun 2008 10:09:04 +0000 (UTC) (envelope-from harunaga@harunaga.ru) Received: from harunaga-pc.chics.ru (CorporateHouse.chics.ru [80.85.151.246]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by Harunaga.ru (Postfix) with ESMTP id 065C6159D88 for ; Thu, 26 Jun 2008 16:09:02 +0600 (YEKST) From: Daniil Harun To: freebsd-net@freebsd.org Date: Thu, 26 Jun 2008 16:09:00 +0600 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806261609.01289.harunaga@harunaga.ru> Subject: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: harunaga@harunaga.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 10:09:05 -0000 Dear sirs! Sorry for my bad English! I ask to help me, if you have some spare time. I'm using the patch for support IPSEC NAT Traversal on FreeBSD 7.0.Will not work NAT-T with Windows XP in the real situation. #cd /usr/src/sys patch < patch-natt-freebsd7-2008-03-11.diff Kernel config (FreeBSD 7.0): options IPSEC options IPSEC_NAT_T device enc device crypto device cryptodev Racoon config: listen { isakmp 80.85.151.51 [500]; isakmp_natt 80.85.151.51 [4500]; } timer { natt_keepalive 10 sec; } remote anonymous { exchange_mode main; my_identifier asn1dn; certificate_type x509 "ipsec-server.crt" "ipsec-server.key"; peers_certfile "ipsec-client.crt"; passive on; generate_policy on; nat_traversal force; proposal_check obey; # obey, strict, or claim proposal { authentication_method rsasig; encryption_algorithm 3des; hash_algorithm sha1; dh_group 2; } } sainfo anonymous { pfs_group 2; lifetime time 10 min; encryption_algorithm 3des, rijndael; authentication_algorithm hmac_sha1; compression_algorithm deflate; } #ipfw show 00001 0 0 allow ip from any to any via enc0 65535 0 0 allow ip from any to any Configure and apply policies on the windows ipsec. A host with Windows XP has address 80.85.145.224. A host with FreeBSD has address 80.85.151.51. Ping FreeBSD on Windows XP and run tcpdump on FreeBSD. # tcpdump -npti fxp0 host 80.85.145.224 IP 80.85.145.224.500 > 80.85.151.51.500: isakmp: phase 1 I ident IP 80.85.151.51.500 > 80.85.145.224.500: isakmp: phase 1 R ident IP 80.85.145.224.500 > 80.85.151.51.500: isakmp: phase 1 I ident IP 80.85.151.51.500 > 80.85.145.224.500: isakmp: phase 1 R ident IP 80.85.145.224.4500 > 80.85.151.51.4500: NONESP-encap: isakmp: phase 1 I ident[E] IP 80.85.145.224 > 80.85.151.51: udp IP 80.85.151.51.4500 > 80.85.145.224.4500: NONESP-encap: isakmp: phase 1 R ident[E] IP 80.85.151.51.4500 > 80.85.145.224.4500: NONESP-encap: isakmp: phase 2/others R inf[E] IP 80.85.145.224.4500 > 80.85.151.51.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E] IP 80.85.151.51.4500 > 80.85.145.224.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E] IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x1), length 76 IP 80.85.145.224.4500 > 80.85.151.51.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E] IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x2), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: UDP-encap: ESP(spi=0xa9d7fa75,seq=0x1), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: isakmp-nat-keep-alive IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x3), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: UDP-encap: ESP(spi=0xa9d7fa75,seq=0x2), length 76 IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x4), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: UDP-encap: ESP(spi=0xa9d7fa75,seq=0x3), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: isakmp-nat-keep-alive # tcpdump -npti enc0 (authentic,confidential): SPI 0x0786ecb5: IP 80.85.145.224 > 80.85.151.51: ICMP echo request, id 512, seq 4608, length 40 (authentic,confidential): SPI 0x60fa28ee: IP 80.85.151.51 > 80.85.145.224: ICMP echo reply, id 512, seq 4608, length 40 (authentic,confidential): SPI 0x0786ecb5: IP 80.85.145.224 > 80.85.151.51: ICMP echo request, id 512, seq 4864, length 40 (authentic,confidential): SPI 0x60fa28ee: IP 80.85.151.51 > 80.85.145.224: ICMP echo reply, id 512, seq 4864, length 40 (authentic,confidential): SPI 0x0786ecb5: IP 80.85.145.224 > 80.85.151.51: ICMP echo request, id 512, seq 5120, length 40 (authentic,confidential): SPI 0x60fa28ee: IP 80.85.151.51 > 80.85.145.224: ICMP echo reply, id 512, seq 5120, length 40 # /usr/local/sbin/setkey -D 80.85.151.51[4500] 80.85.145.224[4500] esp-udp mode=transport spi=1074885652(0x40117414) reqid=0(0x00000000) E: 3des-cbc 2753f418 16ae6b2d 7db165b1 78489da4 84c61b5c 74ba0eab A: hmac-sha1 8dbb660d 8d461664 db9f2576 b1c51494 24bc72f3 seq=0x00000001 replay=4 flags=0x00000000 state=mature created: Jun 25 22:33:08 2008 current: Jun 25 22:33:14 2008 diff: 6(s) hard: 900(s) soft: 900(s) last: Jun 25 22:33:09 2008 hard: 0(s) soft: 0(s) current: 96(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 1 hard: 0 soft: 0 sadb_seq=1 pid=9531 refcnt=2 80.85.145.224[4500] 80.85.151.51[4500] esp-udp mode=transport spi=145306844(0x08a934dc) reqid=0(0x00000000) E: 3des-cbc 236d1e55 e194f00c a18ed711 081baab3 2692c6f5 6607f06e A: hmac-sha1 74971750 35c1ed4a 7f435f86 b17a4195 7d1aee61 seq=0x00000001 replay=4 flags=0x00000000 state=mature created: Jun 25 22:33:08 2008 current: Jun 25 22:33:14 2008 diff: 6(s) hard: 900(s) soft: 900(s) last: Jun 25 22:33:09 2008 hard: 0(s) soft: 0(s) current: 60(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 1 hard: 0 soft: 0 sadb_seq=0 pid=9531 refcnt=1 # /usr/local/sbin/setkey -DP 80.85.145.224[any] 80.85.151.51[any] any in ipsec esp/transport//require spid=3366 seq=1 pid=9532 refcnt=1 80.85.151.51[any] 80.85.145.224[any] any out ipsec esp/transport//require spid=3367 seq=0 pid=9532 refcnt=1 All works, UDP and TCP traffic passes through IPSEC. Normal working L2TP over IPSEC. # /usr/local/sbin/setkey -DP 80.85.145.224[any] 80.85.151.51[1701] udp in ipsec esp/transport//require spid=3368 seq=1 pid=9606 refcnt=1 80.85.151.51[1701] 80.85.145.224[any] udp out ipsec esp/transport//require spid=3369 seq=0 pid=9606 refcnt=1 But when the host is placed over NAT, everything stops working. After negotiates IKE and key additions to the database SA traffic does not pass. "tcpdump enc0" shows that traffic is decoded normaly, but then he does not processed, packets discarded. Counters ipfw to rule 1 does not grow. At FreeBSD 6.2 I have the same problem (FAST_IPSEC or KAME IPSEC). How to fix it? I would be happy to answer any! -- Best regards, Harun Daniil From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 11:47:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 154B91065691 for ; Thu, 26 Jun 2008 11:47:55 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id C53F58FC1F for ; Thu, 26 Jun 2008 11:47:54 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id AE56E3F7A; Thu, 26 Jun 2008 13:47:52 +0200 (CEST) Date: Thu, 26 Jun 2008 13:47:52 +0200 From: VANHULLEBUS Yvan To: Daniil Harun Message-ID: <20080626114752.GA3121@zen.inc> References: <200806261609.01289.harunaga@harunaga.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806261609.01289.harunaga@harunaga.ru> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 11:47:55 -0000 On Thu, Jun 26, 2008 at 04:09:00PM +0600, Daniil Harun wrote: > Dear sirs! Hi. I forgot to reply your private mail this morning, but it's still better to have the question and the answer on a public ML, it may be useful for other people. > Sorry for my bad English! I ask to help me, if you have some spare time. > > I'm using the patch for support IPSEC NAT Traversal on FreeBSD 7.0.Will not > work NAT-T with Windows XP in the real situation. [....] > But when the host is placed over NAT, everything stops working. > After negotiates IKE and key additions to the database SA traffic does not > pass. "tcpdump enc0" shows that traffic is decoded normaly, but then he does > not processed, packets discarded. > Counters ipfw to rule 1 does not grow. At FreeBSD 6.2 I have the same problem > (FAST_IPSEC or KAME IPSEC). ESP transport with NAT-T may need NAT-OA support, which is not provided by the actual patch, nor by userland. "may", because checksums (which needs that NAT-OA payload to be correctly recomputed by the destination) are optionnal on UDP, and, afaik, L2TP is encapsulated in UDP datagrams. Looks like XP sets the checksums for UDP datagrams..... Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 13:44:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E64E9106566B for ; Thu, 26 Jun 2008 13:44:40 +0000 (UTC) (envelope-from harunaga@harunaga.ru) Received: from Harunaga.ru (harunaga.ru [80.85.150.78]) by mx1.freebsd.org (Postfix) with ESMTP id 9263A8FC23 for ; Thu, 26 Jun 2008 13:44:40 +0000 (UTC) (envelope-from harunaga@harunaga.ru) Received: from thinkpad.kharun.tvit.ru (ThinkPad.kharun.tvit.ru [80.85.145.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by Harunaga.ru (Postfix) with ESMTP id BCF69159DFD for ; Thu, 26 Jun 2008 19:44:38 +0600 (YEKST) From: Daniil Harun To: freebsd-net@freebsd.org Date: Thu, 26 Jun 2008 19:44:38 +0600 User-Agent: KMail/1.9.4 References: <200806261609.01289.harunaga@harunaga.ru> <20080626114752.GA3121@zen.inc> In-Reply-To: <20080626114752.GA3121@zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806261944.39032.harunaga@harunaga.ru> Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 13:44:41 -0000 Hi! > > But when the host is placed over NAT, everything stops working. > > After negotiates IKE and key additions to the database SA traffic does > > not pass. "tcpdump enc0" shows that traffic is decoded normaly, but then > > he does not processed, packets discarded. > > Counters ipfw to rule 1 does not grow. At FreeBSD 6.2 I have the same > > problem (FAST_IPSEC or KAME IPSEC). > > ESP transport with NAT-T may need NAT-OA support, which is not > provided by the actual patch, nor by userland. > > "may", because checksums (which needs that NAT-OA payload to be > correctly recomputed by the destination) are optionnal on UDP, and, > afaik, L2TP is encapsulated in UDP datagrams. > > Looks like XP sets the checksums for UDP datagrams..... In such a case should help it: sysctl net.inet.udp.checksum=0 ? -- Best regards, Harun Daniil From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 13:53:26 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B151065676; Thu, 26 Jun 2008 13:53:26 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 535638FC2C; Thu, 26 Jun 2008 13:53:26 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5QDrQjt047523; Thu, 26 Jun 2008 13:53:26 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5QDrQiu047519; Thu, 26 Jun 2008 13:53:26 GMT (envelope-from gavin) Date: Thu, 26 Jun 2008 13:53:26 GMT Message-Id: <200806261353.m5QDrQiu047519@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/125003: [gif] incorrect EtherIP header format. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 13:53:26 -0000 Old Synopsis: incorrect EtherIP header format. New Synopsis: [gif] incorrect EtherIP header format. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Thu Jun 26 13:52:03 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=125003 From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 14:55:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71A53106567B for ; Thu, 26 Jun 2008 14:55:51 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF648FC0A for ; Thu, 26 Jun 2008 14:55:51 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: by mail.geek.sh (Postfix, from userid 1000) id 8D52724D26; Thu, 26 Jun 2008 16:29:13 +0200 (SAST) Date: Thu, 26 Jun 2008 16:29:13 +0200 From: Aragon Gouveia To: freebsd-net@freebsd.org Message-ID: <20080626142913.GA11532@phat.za.net> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.10-RELEASE-p2 i386 Subject: FreeBSD 7 routing/ppp changed? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 14:55:51 -0000 Hi, I recently migrated a 6.2 system to 7.0-STABLE. One of the system's functions was a PPPoE gateway that performed Proxy ARP for its PPP clients. In 6.2 days when a connection was made the route entry for the PPP client showed: 192.168.9.245 192.168.9.2 UH 0 1 tun0 192.168.9.245 00:1b:78:37:d1:97 UHLS2 1 0 bge0 192.168.9.2 being the 6.2 system, and bge0 being its ethernet device. On the 7.0 system the route entry looks like this: 192.168.9.248 192.168.9.1 UGH 0 0 bge0 192.168.9.248 00:1f:29:78:25:9d UHLS2 1 0 bge0 And the PPPoE connection doesn't work. I have to manually remove the route entry and recreate it with the -interface argument to get things working. My PPP configs are the same on both machines as seen below. Is this a bug I need to PR? Thanks, Aragon <---ppp.conf---> default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) id: allow mode direct enable lqr echo proxy enable chap set ifaddr 192.168.9.1 192.168.9.241-192.168.9.254 accept dns set dns 192.168.9.1 <---grep pppoed /etc/rc.conf---> pppoed_enable="YES" pppoed_provider="id" pppoed_interface="bge0" From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 15:10:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB00106566C for ; Thu, 26 Jun 2008 15:10:03 +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 965208FC13 for ; Thu, 26 Jun 2008 15:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5QFA3XK053134 for ; Thu, 26 Jun 2008 15:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5QFA3Uq053133; Thu, 26 Jun 2008 15:10:03 GMT (envelope-from gnats) Date: Thu, 26 Jun 2008 15:10:03 GMT Message-Id: <200806261510.m5QFA3Uq053133@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrew Thompson Cc: Subject: Re: kern/125003: incorrect EtherIP header format. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Thompson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 15:10:03 -0000 The following reply was made to PR kern/125003; it has been noted by GNATS. From: Andrew Thompson To: Shunsuke SHINOMIYA Cc: bug-followup@FreeBSD.org Subject: Re: kern/125003: incorrect EtherIP header format. Date: Thu, 26 Jun 2008 07:34:24 -0700 Hi, It is unclear where the interoperability problem comes in. struct etherip_header { u_int8_t eip_ver; /* version/reserved */ u_int8_t eip_pad; /* required padding byte */ }; #define ETHERIP_VER_VERS_MASK 0x0f #define ETHERIP_VERSION 0x03 From rfc3378, 1. Prepend the 16-bit EtherIP header to the MAC frame. The EtherIP Version field MUST be set to 3 (three), and the EtherIP Reserved field MUST be set to 0 (zero). And the outgoing header is set to. eiphdr.eip_ver = ETHERIP_VERSION & ETHERIP_VER_VERS_MASK; eiphdr.eip_pad = 0; Which would conform to the requirement. Can you describe the problem you are seeing. regards, Andrew From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 15:13:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63DC2106564A for ; Thu, 26 Jun 2008 15:13:00 +0000 (UTC) (envelope-from petar@smokva.net) Received: from morrison.andev.ch (morrison.andev.ch [78.47.142.202]) by mx1.freebsd.org (Postfix) with ESMTP id 226138FC13 for ; Thu, 26 Jun 2008 15:12:59 +0000 (UTC) (envelope-from petar@smokva.net) Received: from pintail.smokva.net (84-74-146-124.dclient.hispeed.ch [84.74.146.124]) by morrison.andev.ch (Postfix) with ESMTP id A82555DB12 for ; Thu, 26 Jun 2008 17:13:03 +0200 (CEST) Date: Thu, 26 Jun 2008 17:12:57 +0200 From: Petar Bogdanovic To: freebsd-net@freebsd.org Message-ID: <20080626151257.GA3767@pintail.smokva.net> Mail-Followup-To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: ath hostap: antenna diversity or not? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 15:13:00 -0000 Hi, in order to compare the performance between antenna-diversity on and off I did a quick test with the following sysctl settings: # antenna-diversity on dev.ath.0.diversity=1 # antenna-diversity off dev.ath.0.diversity=0 dev.ath.0.txantenna=1 dev.ath.0.rxantenna=2 The performance was pretty much the same but I noticed that the link-quality reported by my laptop was notable lower with enabled antenna-diversity (AD): ~ 43/70 (AD on) ~ 51/70 (AD off) I've read a few things about AD on Wikipedia and it seems to be a good technique to achieve a better signal quality but OTOH there are people who recommend turning it off to get a better signal quality. So whats actually true here? Thanks, Petar From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 15:40:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07C0106564A for ; Thu, 26 Jun 2008 15: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 98C2D8FC1C for ; Thu, 26 Jun 2008 15:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5QFe4uY057274 for ; Thu, 26 Jun 2008 15:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5QFe4mL057273; Thu, 26 Jun 2008 15:40:04 GMT (envelope-from gnats) Date: Thu, 26 Jun 2008 15:40:04 GMT Message-Id: <200806261540.m5QFe4mL057273@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Hiroki Sato Cc: Subject: Re: kern/125003: incorrect EtherIP header format. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hiroki Sato List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 15:40:04 -0000 The following reply was made to PR kern/125003; it has been noted by GNATS. From: Hiroki Sato To: shino@fornext.org Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/125003: incorrect EtherIP header format. Date: Fri, 27 Jun 2008 00:30:14 +0900 (JST) ----Security_Multipart(Fri_Jun_27_00_30_14_2008_807)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shunsuke SHINOMIYA wrote in <20080626192225.9813.A2D40D1E@fornext.org>: sh> In current implementation, 0x03 is transmitted, and, next, 0x00 is sh> transmitted as version(3) and reserved(0x000) field. But I think that sh> 0x30 should be transmitted first from RFC3378. I don't understand why you think 0x30 is correct. -- | Hiroki SATO ----Security_Multipart(Fri_Jun_27_00_30_14_2008_807)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkhjtgYACgkQTyzT2CeTzy21ZQCfa0YYRixI0Sq5yb779GTsTtOX 9z0AoIdkDi+H/h2pSB30vTvZk60OwXIM =0Fi9 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_27_00_30_14_2008_807)---- From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 17:05:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B48F9106567D for ; Thu, 26 Jun 2008 17:05:16 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1078FC22 for ; Thu, 26 Jun 2008 17:05:16 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 59C7A79E2CA; Thu, 26 Jun 2008 12:05:15 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 15395-05; Thu, 26 Jun 2008 17:05:14 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id ED86C79E26A; Thu, 26 Jun 2008 12:05:13 -0500 (CDT) Received: from hole.shrew.net (localhost [127.0.0.1]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m5QH5Bcd054466; Thu, 26 Jun 2008 12:05:11 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: (from www@localhost) by hole.shrew.net (8.14.2/8.14.2/Submit) id m5QH581a054465; Thu, 26 Jun 2008 12:05:08 -0500 (CDT) (envelope-from mgrooms@shrew.net) X-Authentication-Warning: hole.shrew.net: www set sender to mgrooms@shrew.net using -f To: vanhu_bsd@zeninc.net MIME-Version: 1.0 Date: Thu, 26 Jun 2008 12:05:08 -0500 From: mgrooms Organization: Shrew Soft Inc In-Reply-To: References: Message-ID: <30025d295f8077e96bcb3f3a076c8bd1@localhost> X-Sender: mgrooms@shrew.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, harunaga@harunaga.ru Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mgrooms@shrew.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 17:05:16 -0000 On Thu, 26 Jun 2008 11:51:26 -0500, mgrooms wrote: > > ESP transport with NAT-T may need NAT-OA support, which is not > provided by the actual patch, nor by userland. > I checked in Timos patch for NAT-T original address support into ipsec-tools last December. This will be available in our 0.8 release. http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/dist/ipsec-tools/ChangeLog.diff?r1=1.139&r2=1.140 I believe we are just missing the kernel bits on FreeBSD. -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 18:49:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2AD91065674 for ; Thu, 26 Jun 2008 18:49:39 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 43DD48FC25 for ; Thu, 26 Jun 2008 18:49:39 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id CB5AB79E2CA; Thu, 26 Jun 2008 13:49:38 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 32416-09; Thu, 26 Jun 2008 18:49:38 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 6992179E26A; Thu, 26 Jun 2008 13:49:37 -0500 (CDT) Received: from hole.shrew.net (localhost [127.0.0.1]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m5QInYAR055262; Thu, 26 Jun 2008 13:49:34 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: (from www@localhost) by hole.shrew.net (8.14.2/8.14.2/Submit) id m5QInY1L055261; Thu, 26 Jun 2008 13:49:34 -0500 (CDT) (envelope-from mgrooms@shrew.net) X-Authentication-Warning: hole.shrew.net: www set sender to mgrooms@shrew.net using -f To: brooks@freebsd.org MIME-Version: 1.0 Date: Thu, 26 Jun 2008 13:49:34 -0500 From: mgrooms Organization: Shrew Soft Inc In-Reply-To: <48ca67dd60c19f94b4f21bbe88854da7@localhost> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> Message-ID: <86c7b60b19e63e9188701611ac0f6f17@localhost> X-Sender: mgrooms@shrew.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mgrooms@shrew.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 18:49:39 -0000 > On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote: >> On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer > wr= > ote: >> > do you have the ability to test this? >>=20 >> Absolutely. Is this the only thing from preventing it being merged > into= > HEAD? > > No. It's a large and complex patch an a subsystem (ipsec) that must not > be broken. We're a bit shorthanded in this area, but people have been > working on this for quite some time and IIRC aren't fully comfortable > with the patch yet. Every time the question of integrating the NAT-T patches is brought up, a post list this is usually where this thread dies. Forgive me for my persistence :) >From this thread and previous threads, its known that FreeBSD + NAT-T is being used in several production environments without issue. I use it myself to perform compatibility testing and have never encountered a problem with later versions of the patch. Not being a FreeBSD kernel developer, I can't comment on the correctness of the patch, only that it works well for me. So very respectfully, what needs to happen for this patch to be committed? FreeBSD is a great operating system with a great developer community. If the patch has been fully reviewed and problems have been found, what are they? If there is enough demand for this patch to be integrated, maybe other kernel developers would lend a hand in resolving the issues if they were made public. Both of the threads I started on this list were answered by developers willing to pitch in. If the patch hasn't been fully reviewed and its a lack of man hours required, again, maybe someone can lend a helping hand in this regard as well. Perhaps a full review with the intent to commit is happening right now but its just not public knowledge. A reply to this effect would silence annoying people like myself :) I'm not suggesting it should be MFCd tomorrow. A kernel source commit log occasionally suggests that a patch is being integrated so that it can receive more testing by the public at large. Maybe committing it to head is the best action to take? Its a compile time option for IPsec and another compile time option for NAT-T. Are we really talking about that much of a risk? I'm not trying to start a flame war here, but the patch has been floating around since before the 5.x days. There just seems to be a dark cloud hanging over it and I, and no doubt many others, really don't know why. Please help us understand these reasons and what can be done to help. Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 19:44:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472E71065673 for ; Thu, 26 Jun 2008 19:44:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6938FC24 for ; Thu, 26 Jun 2008 19:44:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E19B424A5 for ; Thu, 26 Jun 2008 12:44:33 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D2BA02D600D for ; Thu, 26 Jun 2008 12:44:33 -0700 (PDT) Message-ID: <4863F1B0.9060603@elischer.org> Date: Thu, 26 Jun 2008 12:44:48 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: need help from pf developer(s) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 19:44:36 -0000 If you are one of the people that know and love pf, I'd like to speak to you on one side about testing pf with vimage.. (and making it work as I'm sure it doesn't). From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 19:56:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F85A106566C for ; Thu, 26 Jun 2008 19:56:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 7E28B8FC25 for ; Thu, 26 Jun 2008 19:56:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 4E8FA247C; Thu, 26 Jun 2008 12:56:26 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 298332D6014; Thu, 26 Jun 2008 12:56:26 -0700 (PDT) Message-ID: <4863F479.8010206@elischer.org> Date: Thu, 26 Jun 2008 12:56:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mgrooms@shrew.net References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> In-Reply-To: <86c7b60b19e63e9188701611ac0f6f17@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, brooks@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 19:56:26 -0000 mgrooms wrote: >> On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote: >>> On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer >> wr= >> ote: >>>> do you have the ability to test this? >>> =20 >>> Absolutely. Is this the only thing from preventing it being merged >> into= >> HEAD? >> >> No. It's a large and complex patch an a subsystem (ipsec) that must not >> be broken. We're a bit shorthanded in this area, but people have been >> working on this for quite some time and IIRC aren't fully comfortable >> with the patch yet. > > Every time the question of integrating the NAT-T patches is brought up, a > post list this is usually where this thread dies. Forgive me for my > persistence :) > >>From this thread and previous threads, its known that FreeBSD + NAT-T is > being used in several production environments without issue. I use it > myself to perform compatibility testing and have never encountered a > problem with later versions of the patch. Not being a FreeBSD kernel > developer, I can't comment on the correctness of the patch, only that it > works well for me. So very respectfully, what needs to happen for this > patch to be committed? > > FreeBSD is a great operating system with a great developer community. If > the patch has been fully reviewed and problems have been found, what are > they? If there is enough demand for this patch to be integrated, maybe > other kernel developers would lend a hand in resolving the issues if they > were made public. Both of the threads I started on this list were answered > by developers willing to pitch in. If the patch hasn't been fully reviewed > and its a lack of man hours required, again, maybe someone can lend a > helping hand in this regard as well. Perhaps a full review with the intent > to commit is happening right now but its just not public knowledge. A reply > to this effect would silence annoying people like myself :) > > I'm not suggesting it should be MFCd tomorrow. A kernel source commit log > occasionally suggests that a patch is being integrated so that it can > receive more testing by the public at large. Maybe committing it to head is > the best action to take? Its a compile time option for IPsec and another > compile time option for NAT-T. Are we really talking about that much of a > risk? > > I'm not trying to start a flame war here, but the patch has been floating > around since before the 5.x days. There just seems to be a dark cloud > hanging over it and I, and no doubt many others, really don't know why. > Please help us understand these reasons and what can be done to help. I'm planning on committing it unless someone can provide a reason not to, as I've seen it working, needed it, and have not seen any bad byproducts. > > Thanks, > > -Matthew > > _______________________________________________ > 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 Thu Jun 26 20:06:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42271106567A for ; Thu, 26 Jun 2008 20:06:19 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 62F878FC0A for ; Thu, 26 Jun 2008 20:06:17 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 62420 invoked by uid 98); 26 Jun 2008 20:06:16 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.038011 secs); 26 Jun 2008 20:06:16 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.038011 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 26 Jun 2008 20:06:16 -0000 Message-ID: <4863F6B3.4020308@zirakzigil.org> Date: Thu, 26 Jun 2008 22:06:11 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: Steve Bertrand References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> In-Reply-To: <48630AA3.3000800@ibctech.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 20:06:19 -0000 Steve Bertrand wrote: > Thank you Giulio (is it Gio?) No, it's Giulio (english Julius) :-) > >> For some reason when I >> plugged in the new firewall, only the base non-aliased address was >> updated in >> the ISP switch arp cache (if someone can throw a guess at why, I'm >> eager to listen). > > Well, you need to know what type of switch they had upstream, and why > they weren't updating their ARP cache dynamically properly. Perhaps > because their cache ttl was too long (due to the type of hardware, or > administrative setting). > The strange thing is that they actually updated their arp entry for the base (non aliased) address, but not the others. I guess what I could do was to "poison" their arp cache for each address with a "is-at" message. Is there a way to force the sending of these messages for all the addresses of an interface? > I almost have to assume it wasn't a Cisco... only because I would have > expected different behavior (less administrative setting) (this is my > personal experience...I'm not trying to favour a brand in any way). > > Perhaps you could ask them to provide the command they issued to > determine how they found the problem. Better yet, ask what type of > device your box is connected to at their end of the VLAN. It was me who finally realized what the problem was. All I asked them to do was to reset the arp cache of the interface, and I guess they did that by ios (or cli or whatever), not something I could do without logging in into their switch... > > If you can find out what device they have at their end, it may almost > be possible to non-destructively, and non-corruptively 'force' them to > clear arp-cache remotely, and at the same time provide advice to the > non-unscrupulous people who may run into this in the future. I guess I could have used utilities like ettercap to set their arp table right, and this is what another person should do, if they have no other way to operate that change... > > I'd be just as interested to know what they had at their end for > hardware, as I have been waiting to hear what your resolution was > throughout your time consuming troubleshooting... Thanks for your support :-) I've seen many cisco devices in that farm, so I guess that's the answer. I image (since I don't really know) that every ip interface should periodically issue "who-has" messages for the directly-connected addresses, so maybe the problem would have solved itself, but I didn't really know how long that would have taken, and I couldn't stop the services provided by my customer too long... Anyway all is well as it ends well.. Giulio. From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 20:22:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 708D51065672 for ; Thu, 26 Jun 2008 20:22:01 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 987E78FC30 for ; Thu, 26 Jun 2008 20:22:00 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 62671 invoked by uid 98); 26 Jun 2008 20:21:59 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.042581 secs); 26 Jun 2008 20:21:59 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.042581 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 26 Jun 2008 20:21:59 -0000 Message-ID: <4863FA62.2030703@zirakzigil.org> Date: Thu, 26 Jun 2008 22:21:54 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: altq on vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 20:22:01 -0000 I've tried to set altq bandwidth control on a vlan interface, but this feature doesn't seem to be supported by the vlan driver. I've googled around and I've found that there should be a trivial patch to enable this feature: http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch If this is so trivial, why hasn't it been included in the freebsd source tree? Anyway has anybody tried that? How does that work? Are there other (better) patches around? Thanks in advance. From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 20:39:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B9AD1065686; Thu, 26 Jun 2008 20:39:06 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 611338FC1A; Thu, 26 Jun 2008 20:39:06 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id CB89079E2CA; Thu, 26 Jun 2008 15:39:05 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 46582-09; Thu, 26 Jun 2008 20:39:05 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 547FA79E26A; Thu, 26 Jun 2008 15:39:05 -0500 (CDT) Received: from hole.shrew.net (localhost [127.0.0.1]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m5QKd3m1055951; Thu, 26 Jun 2008 15:39:03 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: (from www@localhost) by hole.shrew.net (8.14.2/8.14.2/Submit) id m5QKd3o7055950; Thu, 26 Jun 2008 15:39:03 -0500 (CDT) (envelope-from mgrooms@shrew.net) X-Authentication-Warning: hole.shrew.net: www set sender to mgrooms@shrew.net using -f To: Julian Elischer MIME-Version: 1.0 Date: Thu, 26 Jun 2008 15:39:03 -0500 From: mgrooms Organization: Shrew Soft Inc In-Reply-To: <4863F479.8010206@elischer.org> References: <4863F479.8010206@elischer.org> Message-ID: X-Sender: mgrooms@shrew.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, brooks@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mgrooms@shrew.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 20:39:06 -0000 On Thu, 26 Jun 2008 12:56:41 -0700, Julian Elischer wrote: > mgrooms wrote: >> >> I'm not trying to start a flame war here, but the patch has been > floating >> around since before the 5.x days. There just seems to be a dark cloud >> hanging over it and I, and no doubt many others, really don't know why. >> Please help us understand these reasons and what can be done to help. > Woops. I meant to say that it had been floating around since before the 6.x days. My bad. > I'm planning on committing it unless someone can provide a reason not > to, as I've seen it working, needed it, and have not seen any bad > byproducts. > I appreciate your offer to help. At the very least, I hope we will see a published list of technical hurdles that need to be overcome before the patch can be applied. Thanks again, -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 20:40:17 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F69106564A; Thu, 26 Jun 2008 20:40:17 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D79FA8FC0A; Thu, 26 Jun 2008 20:40:16 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5QKeGZf083243; Thu, 26 Jun 2008 20:40:16 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5QKeGco083237; Thu, 26 Jun 2008 20:40:16 GMT (envelope-from gavin) Date: Thu, 26 Jun 2008 20:40:16 GMT Message-Id: <200806262040.m5QKeGco083237@freefall.freebsd.org> To: gavin@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Jun 2008 20:40:17 -0000 Old Synopsis: vr(4) does not see incoming multicast packets in non-promiscuous New Synopsis: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Thu Jun 26 20:36:10 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=125024 From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 03:23:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03A5E1065676 for ; Fri, 27 Jun 2008 03:23:20 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from atlas.gtcomm.net (atlas.gtcomm.net [67.215.15.242]) by mx1.freebsd.org (Postfix) with ESMTP id DC3618FC15 for ; Fri, 27 Jun 2008 03:23:19 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from c-76-108-179-28.hsd1.fl.comcast.net ([76.108.179.28] helo=[192.168.1.6]) by atlas.gtcomm.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KC4VP-0007qc-4j for freebsd-net@freebsd.org; Thu, 26 Jun 2008 23:20:11 -0400 Message-ID: <48645D9E.7090303@gtcomm.net> Date: Thu, 26 Jun 2008 23:25:18 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Weirdness - FBSD 7, Routing, Packet generator, em taskq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 03:23:20 -0000 I have a FreeBSD router set up with Full BGP routes and I'm doing some tests on using it for routing. 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 oddness..: Use a packet generator to generate random source ips and ports and send traffic through the router to a destination on the other side, single ip. What happens is the 'em0 taskq' starts to eat cpu... but the funny thing is immediately when I start the traffic (say, 100,000 pps) em0 taskq is about 15% cpu.. and then over the course of 2 minutes or so it climbs to 60% cpu.. This makes no sense.. The packets per second are continuous and it just routed 100kpps for 60 seconds with less cpu so why in the world would it slowly climb like that? It's an observation I suppose and I was hoping if someone could enlighten me on WHY.. :) I did test it on 3 different machines by the way. It even does this with just a handful of routes in the routing table , I tried that too just to rule that out. I don't remember Freebsd 4/5 doing this?? Thank you. Paul From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 03:45:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 806F1106566C; Fri, 27 Jun 2008 03:45:03 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2D93A8FC12; Fri, 27 Jun 2008 03:45:02 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5R3j2K4036257; Fri, 27 Jun 2008 03:45:02 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5R3j1BT036253; Fri, 27 Jun 2008 03:45:01 GMT (envelope-from yongari) Date: Fri, 27 Jun 2008 03:45:01 GMT Message-Id: <200806270345.m5R3j1BT036253@freefall.freebsd.org> To: 20080111.freebsd.org@ab.ote.we.lv, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 03:45:03 -0000 Synopsis: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Jun 27 03:43:26 UTC 2008 State-Changed-Why: Would you try patch at the following URL? http://people.freebsd.org/~yongari/vr/vr.cam.patch Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Jun 27 03:43:26 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=125024 From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 04:30:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B96106564A for ; Fri, 27 Jun 2008 04:30:21 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (unknown [IPv6:2001:470:1f00:ffff::5e5]) by mx1.freebsd.org (Postfix) with ESMTP id 4B04D8FC1A for ; Fri, 27 Jun 2008 04:30:21 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (cpe-24-161-6-139.hvc.res.rr.com [24.161.6.139]) (authenticated bits=0) by vjofn.tucs-beachin-obx-house.com (8.14.2/8.14.2) with ESMTP id m5R4U8Rm018126 for ; Fri, 27 Jun 2008 00:30:18 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6) with ESMTP id m5R4U5Cq025337 for ; Fri, 27 Jun 2008 00:30:05 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6/Submit) id m5R4U5Ib025336 for freebsd-net@freebsd.org; Fri, 27 Jun 2008 00:30:05 -0400 (EDT) (envelope-from tbohml) From: "Tuc at T-B-O-H.NET" Message-Id: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> To: freebsd-net@freebsd.org Date: Fri, 27 Jun 2008 00:30:05 -0400 (EDT) X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IPV6 problem : nd6_lookup: failed to add route for a neighbor X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 04:30:21 -0000 Hi, Running 5.5 (And no "upgrade" messages please, I'm forced to, its out of my hands) and trying to bring up HE's IPV6. I've got it running on a 4.10 system (Ok, feel free to tell me to upgrade, this one is more a lazy issue.. But I am making progress. I bought new drives that'll be here next week so I can load 7.0 from scratch) with no worries at all. Piece of cake, has been for ages. But once I brought it all up, I got : kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 and ALOT of them. Taking a quick look in Google, it seems that they claim its a prefix len issue, but I am running with a 128 prefix length even though it seems they say : Client IPv6 address: 2001:470:7:28::2/64 The script they suggest, and I used, is : ifconfig gif0 create ifconfig gif0 tunnel MYIP 216.66.22.2 ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 route -n add -inet6 default 2001:470:7:28::1 ifconfig gif0 up The tunnel came up, was passing traffic, but those messages were getting out of hand. I tried a prefixlen of 64, and I got: ifconfig: ioctl (SIOCAIFADDR): Invalid argument Sendmail seemed a bit cranky : Jun 26 23:53:19 MYHOST sendmail[17543]: gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 Suggestions where to start? Thanks, Tuc From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 06:10:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8348C1065678 for ; Fri, 27 Jun 2008 06:10:03 +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 7527E8FC13 for ; Fri, 27 Jun 2008 06:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5R6A36J060683 for ; Fri, 27 Jun 2008 06:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5R6A3hR060682; Fri, 27 Jun 2008 06:10:03 GMT (envelope-from gnats) Date: Fri, 27 Jun 2008 06:10:03 GMT Message-Id: <200806270610.m5R6A3hR060682@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Shunsuke SHINOMIYA Cc: Subject: Re[2]: kern/125003: incorrect EtherIP header format. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shunsuke SHINOMIYA List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2008 06:10:03 -0000 The following reply was made to PR kern/125003; it has been noted by GNATS. From: Shunsuke SHINOMIYA To: Hiroki Sato Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re[2]: kern/125003: incorrect EtherIP header format. Date: Fri, 27 Jun 2008 15:00:45 +0900 > sh> In current implementation, 0x03 is transmitted, and, next, 0x00 is > sh> transmitted as version(3) and reserved(0x000) field. But I think tha= t > sh> 0x30 should be transmitted first from RFC3378. >=20 > I don't understand why you think 0x30 is correct. =46rom RFC3378 > In summary, the EtherIP Header has two fields: >=20 > Bits 0-3: Protocol version > Bits 4-15: Reserved for future use >=20 > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | | | > | VERSION | RESERVED | > | | | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >=20 > Figure 2: EtherIP Header Format (in bits) >=20 , first octet(bit 0,MSB to 7) consists of VERSION and a part of RESERVED. And VERSION is high 4 bits of the octet. Am I misunderstanding this? --=20 Shunsuke SHINOMIYA From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 06:49:36 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28F91065670 for ; Fri, 27 Jun 2008 06:49:36 +0000 (UTC) (envelope-from freebsd-net@transip.nl) Received: from relay0.transip.nl (relay0.transip.nl [80.69.67.21]) by mx1.freebsd.org (Postfix) with ESMTP id B50328FC20 for ; Fri, 27 Jun 2008 06:49:36 +0000 (UTC) (envelope-from freebsd-net@transip.nl) Received: from [192.168.0.3] (ip86-50-212-87.adsl2.static.versatel.nl [87.212.50.86]) by relay0.transip.nl (Postfix) with ESMTP id D0F9E102C65; Fri, 27 Jun 2008 08:49:33 +0200 (CEST) Message-ID: <48648D70.50304@transip.nl> Date: Fri, 27 Jun 2008 08:49:20 +0200 From: Ali Niknam Organization: Transip BV User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eygene Ryabinkin References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> In-Reply-To: <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 06:49:37 -0000 Hi Eygene, > Just a quick "me too" message: I also used to see this on my 7.x > machines. This was with Apache servers in the proxy setup: one I'm wondering: where these 32 bit, or 64 bit machines? > I had already tried to debug this situation and Mike Silbersack > helped me with patching the kernel. At that days his patches (that > went into 7.x) helped, but with higher request rate to the Apache, > they seem to be back again. I can try to setup the testbed and > verify if I will still be able to reproduce them. Will it be needed? > Well, if your machine was indeed 64 bit, I for one would be very interested in knowing if it also appears in 32 bit. Although perhaps a little far fetched a recent experience has made me aware that 64-bitness just might break things :) Kind Regards, Ali From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 07:23:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E1D71065672 for ; Fri, 27 Jun 2008 07:23:28 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7078FC12 for ; Fri, 27 Jun 2008 07:23:27 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m5R7N7Ss015189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 17:23:20 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m5R7N2xj022816; Fri, 27 Jun 2008 17:23:02 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m5R7N1Q1022815; Fri, 27 Jun 2008 17:23:01 +1000 (EST) (envelope-from peter) Date: Fri, 27 Jun 2008 17:23:01 +1000 From: Peter Jeremy To: Giulio Ferro Message-ID: <20080627072301.GZ50631@server.vk2pj.dyndns.org> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g7w8+K/95kPelPD2" Content-Disposition: inline In-Reply-To: <4863F6B3.4020308@zirakzigil.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org Subject: Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 07:23:28 -0000 --g7w8+K/95kPelPD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jun-26 22:06:11 +0200, Giulio Ferro wrote: > I guess what I could do was to "poison" their arp cache for each >address with a "is-at" message. Is there a way to force the sending >of these messages for all the addresses of an interface? The kernel should send out gratuitous ARP requests whenever you assign an address to an interface. You could confirm that this is happening by tcpdumping the interface whilst you add aliases. Rummaging around in ports, you might find net/arping or net/p5-Net-ARP useful if you want to manually generate gratuitous ARP requests. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --g7w8+K/95kPelPD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhklVUACgkQ/opHv/APuIcz3QCgrwfIbdm214/HD2yZD5P7cgIS aJ4An2iMEy5dE9PQO2RmZfVZEf0cxUkp =bWWo -----END PGP SIGNATURE----- --g7w8+K/95kPelPD2-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 07:32:08 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017621065671; Fri, 27 Jun 2008 07:32:08 +0000 (UTC) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Received: from purple.the-7.net (purple.the-7.net [IPv6:2001:470:1f01:622:230:48ff:fe23:4c67]) by mx1.freebsd.org (Postfix) with ESMTP id DD29A8FC16; Fri, 27 Jun 2008 07:32:07 +0000 (UTC) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Received: from redion.astralblue.net (redion.astralblue.net [IPv6:2001:470:1f05:155:216:17ff:fed4:71f0]) by purple.the-7.net (8.14.2/8.14.2) with ESMTP id m5R7VtQ1000166; Fri, 27 Jun 2008 00:31:55 -0700 (PDT) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Message-ID: <48649776.9040509@ab.ote.we.lv> Date: Fri, 27 Jun 2008 00:32:06 -0700 From: "Eugene M. Kim" <20080111.freebsd.org@ab.ote.we.lv> User-Agent: Thunderbird 2.0.0.14 (X11/20080620) MIME-Version: 1.0 To: yongari@FreeBSD.org References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> In-Reply-To: <200806270345.m5R3j1BT036253@freefall.freebsd.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.7 required=10.0 tests=FROM_STARTS_WITH_NUMS, NO_RELAYS autolearn=disabled version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on purple.the-7.net Cc: freebsd-net@FreeBSD.org Subject: Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 07:32:08 -0000 yongari@FreeBSD.org wrote: > Would you try patch at the following URL? > http://people.freebsd.org/~yongari/vr/vr.cam.patch Nope, didn't fix it (symptom's still the same)... ;_; Regards, Eugene From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 07:44:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D8981065674; Fri, 27 Jun 2008 07:44:57 +0000 (UTC) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Received: from purple.the-7.net (purple.the-7.net [IPv6:2001:470:1f01:622:230:48ff:fe23:4c67]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED158FC0A; Fri, 27 Jun 2008 07:44:57 +0000 (UTC) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Received: from redion.astralblue.net (redion.astralblue.net [IPv6:2001:470:1f05:155:216:17ff:fed4:71f0]) by purple.the-7.net (8.14.2/8.14.2) with ESMTP id m5R7iiRI000652; Fri, 27 Jun 2008 00:44:44 -0700 (PDT) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Message-ID: <48649A77.6010402@ab.ote.we.lv> Date: Fri, 27 Jun 2008 00:44:55 -0700 From: "Eugene M. Kim" <20080111.freebsd.org@ab.ote.we.lv> User-Agent: Thunderbird 2.0.0.14 (X11/20080620) MIME-Version: 1.0 To: yongari@freebsd.org References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> In-Reply-To: <48649776.9040509@ab.ote.we.lv> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.7 required=10.0 tests=FROM_STARTS_WITH_NUMS, NO_RELAYS autolearn=disabled version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on purple.the-7.net Cc: freebsd-net@freebsd.org Subject: Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 07:44:57 -0000 FWIW, I stumbled upon this while browsing through old -net archives... Apparently re(4) had a similar (same?) problem. http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034339.html Cheers, Eugene From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 07:51:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AADF1065691 for ; Fri, 27 Jun 2008 07:51:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2C59D8FC18 for ; Fri, 27 Jun 2008 07:51:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so440592rvf.43 for ; Fri, 27 Jun 2008 00:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nm439QR3rYsC8BbT2K4HhphaHEEjkH8mISFHqWRAKXs=; b=Ci6wu4UETGoH32UlSKEcmEwPnSMXB1FNaMyqcqFo0rcJX2RWXj+DSg4wRig4bOH0cV Z1d3K7fjfQoaptpQ9O1Kdl/J7zofkBr5qgtZ0sDox/3M2ioxVUiU7GwLpDpjFMBOBHsu /PCU8vHpL1p5l5H+ITXo60GYRuKKB5gA+IxTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=eEgTRHxjqIsHqdvLIQXbQH8yFWp7ViM1Jy+CpOh9QaN3bLWqL/8b+9c+XDSijJJBeQ KC8JzFQrfx0xJaMwWuxHM7nTXEya6KPKP6M/hUPTuN2DULExhAytlCxdJkDk1eCDFaVi lzxbSVPPN/F6WoCXUmHAxc+zmw2xG/kAXzQJ4= Received: by 10.141.15.19 with SMTP id s19mr600830rvi.161.1214553118834; Fri, 27 Jun 2008 00:51:58 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id g31sm1939126rvb.2.2008.06.27.00.51.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Jun 2008 00:51:57 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m5R7nnJf069253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 16:49:49 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m5R7nm7k069252; Fri, 27 Jun 2008 16:49:48 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 27 Jun 2008 16:49:48 +0900 From: Pyun YongHyeon To: "Eugene M. Kim" <20080111.freebsd.org@ab.ote.we.lv> Message-ID: <20080627074948.GC67753@cdnetworks.co.kr> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48649776.9040509@ab.ote.we.lv> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 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: Fri, 27 Jun 2008 07:51:59 -0000 On Fri, Jun 27, 2008 at 12:32:06AM -0700, Eugene M. Kim wrote: > yongari@FreeBSD.org wrote: > > Would you try patch at the following URL? > > http://people.freebsd.org/~yongari/vr/vr.cam.patch > > Nope, didn't fix it (symptom's still the same)... ;_; > I've updated patch again. There was a bug that disabled multicasting filter. Back out previous patch and try again. The URL is the same as before. > Regards, > Eugene -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 07:52:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12CBD1065670 for ; Fri, 27 Jun 2008 07:52:29 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 513FD8FC1C for ; Fri, 27 Jun 2008 07:52:27 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 67871 invoked by uid 98); 27 Jun 2008 07:52:26 -0000 Received: from 89.96.52.22 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:0(89.96.52.22):. Processed in 0.037651 secs); 27 Jun 2008 07:52:26 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:0(89.96.52.22):. Processed in 0.037651 secs) Received: from unknown (HELO aurynmob2.giulioferro.it) (auryn@zirakzigil.org@89.96.52.22) by 0 with SMTP; 27 Jun 2008 07:52:25 -0000 Message-ID: <48649C31.90108@zirakzigil.org> Date: Fri, 27 Jun 2008 09:52:17 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4863FA62.2030703@zirakzigil.org> In-Reply-To: <4863FA62.2030703@zirakzigil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: altq on vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 07:52:29 -0000 Giulio Ferro wrote: > http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch Nope, this patch doesn't apply cleanly to freebsd 7... From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 07:59:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5643E1065678 for ; Fri, 27 Jun 2008 07:59:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 28A718FC12 for ; Fri, 27 Jun 2008 07:59:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so442880rvf.43 for ; Fri, 27 Jun 2008 00:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mVeUVjNfMB8fsa8N7sdaA6wDsDDrNHdV9IvTwAzMqrE=; b=R9cGXMpJ03MrsMfMR1WAUb+/oBUVdDjbCf/vq8k98fUe/0uPJSrD8R5d1P83cBLJdv TXmGWc0O+sQFdQGxmaGakqGZFBDUfod1S6fMZtLM4/8rnCQguq0xpetzUnlr9FKM0DPg z/Ztq+4FWcSs8o6xYBaoAqKVu8T+eoOabAPnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=qzmW6cK4qENjuWjvsihjY0FszZ5Pyn6+6Om9RJOZMnIpFmv/tYe0a4vFtlr6FHNHJn lkEKsjmW7/2NHH63Qs3HV/15gU+0DEe2EAnk+1QUCwYrArj/Y+6Y5/z5Pp2tj6MBy7Nu paTnmjrVK59sp7Fj/dzdqEQ7Wsjzm4QaXdSnU= Received: by 10.140.249.20 with SMTP id w20mr640670rvh.21.1214553558709; Fri, 27 Jun 2008 00:59:18 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id k2sm1943935rvb.4.2008.06.27.00.59.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Jun 2008 00:59:17 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m5R7v986069316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 16:57:09 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m5R7v8Ko069315; Fri, 27 Jun 2008 16:57:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 27 Jun 2008 16:57:08 +0900 From: Pyun YongHyeon To: "Eugene M. Kim" <20080111.freebsd.org@ab.ote.we.lv> Message-ID: <20080627075708.GD67753@cdnetworks.co.kr> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> <48649A77.6010402@ab.ote.we.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48649A77.6010402@ab.ote.we.lv> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, yongari@freebsd.org Subject: Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 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: Fri, 27 Jun 2008 07:59:19 -0000 On Fri, Jun 27, 2008 at 12:44:55AM -0700, Eugene M. Kim wrote: > FWIW, I stumbled upon this while browsing through old -net archives... > Apparently re(4) had a similar (same?) problem. > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html > http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034339.html > I believe these were already fixed in CURRENT/stable. I think your issue is a regression of vr(4) overhauling. Since VT6105M supports perfect filtering on multicast frames with CAM I've added that hardware capability but it seems that CAM programming wasn't correct. > Cheers, > Eugene -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 08:14:57 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 131291065679 for ; Fri, 27 Jun 2008 08:14:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E5A938FC19 for ; Fri, 27 Jun 2008 08:14:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5FEC546C15; Fri, 27 Jun 2008 04:14:56 -0400 (EDT) Date: Fri, 27 Jun 2008 09:14:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ali Niknam In-Reply-To: <20080626081831.V96707@fledge.watson.org> Message-ID: <20080627090939.M78484@fledge.watson.org> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> <20080626081831.V96707@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 08:14:57 -0000 On Thu, 26 Jun 2008, Robert Watson wrote: > I think the first logical step is to wait for the application to get into > that state again, and then run procstat or fstat to dump the file descriptor > away for the process. Presumably in the normal steady state, you expect to > see a few IPC sockets (syslog, etc), a TCP listen socket, and some number of > in-progress TCP sessions. The question, of course, is whether you see a lot > more file descriptors than that, and in particular, ones that matched the > CLOSED entries in netstat. If you find that there are lots of open file > descriptors and they match up approximately with netstat, then it's an > application bug that just manifests a bit differently in 7.x than in 6.x. > On the other hand, if you see only a small number of open file descriptors, > then we may be looking at something quite a bit more complicated. Just a public followup for those following the thread: Ali has sent me netstat and sockstat/fstat data. It looks like each of the TCP connections appear in the netstat output in the CLOSED state also appears in sockstat with a file descriptor. This suggests an bug in which file descriptors are occasionally leaked, perhaps early in their life cycle as there's a bit of data in the input buffer. However, it's unclear still if it's an application bug (occasionally missing a close() on an accepted file descriptor) or a kernel bug (accept() or close() misbehaving such that the application doesn't know the file descriptor is open, or has tried to close it but no succeeded). Ali mentioned in his e-mail that he was seeing EBADF on occasion from close(), which could mean a bug is causing the wrong file descriptor number to be passed in. If there's a kernel bug involved, then you could imagine it being along the lines of "accept(2) returns a file descriptor but also sets an error, so the application simply sees the error but the file descriptor remains installed in the process's file descriptor table", leading to the appearance of a leak. I've asked Ali to do a bit more debugging and tracing of the application to see if we can reach any conclusions about this. In particular, if he traces to a file all file descriptor numbers returned by accept(2), then we can later compare that file with the leaked descriptors present in netstat/sockstat and decide whether the application *should* have known they were open or not. I also spotted a bug in the netstat/sockstat output, unrelated, in which the port number of the inpcb is cleared when the connection closes, meaning that netstat shows '*' as the port number. This isn't really necessary, but does lead to potentially confusing output. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 08:17:29 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E1EC106567B; Fri, 27 Jun 2008 08:17:29 +0000 (UTC) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Received: from purple.the-7.net (purple.the-7.net [IPv6:2001:470:1f01:622:230:48ff:fe23:4c67]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC998FC15; Fri, 27 Jun 2008 08:17:29 +0000 (UTC) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Received: from redion.astralblue.net (redion.astralblue.net [IPv6:2001:470:1f05:155:216:17ff:fed4:71f0]) by purple.the-7.net (8.14.2/8.14.2) with ESMTP id m5R8HHxZ002529; Fri, 27 Jun 2008 01:17:17 -0700 (PDT) (envelope-from 20080111.freebsd.org@ab.ote.we.lv) Message-ID: <4864A217.3040309@ab.ote.we.lv> Date: Fri, 27 Jun 2008 01:17:27 -0700 From: "Eugene M. Kim" <20080111.freebsd.org@ab.ote.we.lv> User-Agent: Thunderbird 2.0.0.14 (X11/20080620) MIME-Version: 1.0 To: pyunyh@gmail.com References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> <20080627074948.GC67753@cdnetworks.co.kr> In-Reply-To: <20080627074948.GC67753@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.7 required=10.0 tests=FROM_STARTS_WITH_NUMS, NO_RELAYS autolearn=disabled version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on purple.the-7.net Cc: freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 08:17:29 -0000 Pyun YongHyeon wrote: > I've updated patch again. There was a bug that disabled > multicasting filter. Back out previous patch and try again. > The URL is the same as before. > > > Regards, > > Eugene > rtsol still doesn't work with vr0 being in non-promiscuous mode. However, apparently vr0 picked up router solicitations during system boot-up, as ifconfig shows the correct prefixes autoconfigured. It seems something goes wrong in between. 'o 'a Eugene From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 08:38:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7B72106567D for ; Fri, 27 Jun 2008 08:38:05 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 678308FC19 for ; Fri, 27 Jun 2008 08:38:05 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-012-241.pools.arcor-ip.net [88.66.12.241]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1KC9T143Z0-0006RP; Fri, 27 Jun 2008 10:38:04 +0200 Received: (qmail 41736 invoked from network); 27 Jun 2008 08:35:45 -0000 Received: from myhost.laiers.local (192.168.4.151) by laiers.local with SMTP; 27 Jun 2008 08:35:45 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 27 Jun 2008 10:36:12 +0200 User-Agent: KMail/1.9.9 References: <4863FA62.2030703@zirakzigil.org> In-Reply-To: <4863FA62.2030703@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806271036.12195.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/aHomHN4H3ftftcAw0+io1SoQk2xtpmx5InD5 YEdjeaCo02pzxioeabeZx/c6vv1zW8trzVWk0Ci1KKkpF4HN0E 8YuQGZfWdh1PqMI/3Nrug== Cc: Giulio Ferro Subject: Re: altq on vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 08:38:05 -0000 On Thursday 26 June 2008 22:21:54 Giulio Ferro wrote: > I've tried to set altq bandwidth control on a vlan interface, but this > feature > doesn't seem to be supported by the vlan driver. > > I've googled around and I've found that there should be a trivial patch > to enable this feature: > http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch > > If this is so trivial, why hasn't it been included in the freebsd > source tree? > > Anyway has anybody tried that? How does that work? Are there other > (better) patches around? You don't need a patch at all. What you do is: Queue on the physical interface, classify on the vlan interface. It is broken to allow ALTQ on a virtual interface if you can do it otherwise. in pf.conf speak: If you have "ifconfig vlanX vlandev bge0 ..." altq on bge0 .... queue { vlan0, vlan1, ... } queue vlan0 ... { vlan0_foo, vlan0_bar, ... } queue vlan0_foo queue vlan0_bar ... pass on vlanX ... queue vlanX_foobar And there you go. No patch - whatsoever - required here. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 12:14:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A45DB1065671 for ; Fri, 27 Jun 2008 12:14:58 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 4CE558FC1C for ; Fri, 27 Jun 2008 12:14:58 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 68781 invoked by uid 89); 27 Jun 2008 12:16:09 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 27 Jun 2008 12:16:08 -0000 Message-ID: <4864D9C9.2020207@ibctech.ca> Date: Fri, 27 Jun 2008 08:15:05 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Tuc at T-B-O-H.NET" References: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> In-Reply-To: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPV6 problem : nd6_lookup: failed to add route for a neighbor X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 12:14:58 -0000 Tuc at T-B-O-H.NET wrote: > Hi, > > Running 5.5 (And no "upgrade" messages please, I'm forced to, its > out of my hands) and trying to bring up HE's IPV6. > > I've got it running on a 4.10 system (Ok, feel free to tell me > to upgrade, this one is more a lazy issue.. But I am making progress. I > bought new drives that'll be here next week so I can load 7.0 from > scratch) with no worries at all. Piece of cake, has been for ages. > > But once I brought it all up, I got : > > kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 > > and ALOT of them. Taking a quick look in Google, it seems that they claim > its a prefix len issue, but I am running with a 128 prefix length even though it seems > they say : > > Client IPv6 address: 2001:470:7:28::2/64 > > The script they suggest, and I used, is : > > ifconfig gif0 create > ifconfig gif0 tunnel MYIP 216.66.22.2 > ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 > route -n add -inet6 default 2001:470:7:28::1 > ifconfig gif0 up > > The tunnel came up, was passing traffic, but those messages were > getting out of hand. I tried a prefixlen of 64, and I got: ...hmmmm. I'm not certain here, but since /128 represents only a single address, I can understand why FreeBSD is getting confused. A /128 is an IP within its own solitary subnet, so I'd have to guess that you need a route to the remote end of the tunnel before you can set it as a default gateway. I've been needing to set up a few more tunnels, so I'll try one with FreeBSD this morning with the same setup you have to try to replicate the problem (on 7.0). > ifconfig: ioctl (SIOCAIFADDR): Invalid argument What was the command that you had entered when you received the above error? When you tried to change prefix length, did you destroy the existing tunnel first? > Sendmail seemed a bit cranky : > > Jun 26 23:53:19 MYHOST sendmail[17543]: gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 I believe this is a reverse DNS issue. From how I perceive that message, Sendmail is trying to retrieve a hostname based on that IP. Steve From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 12:21:10 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4CC106567C for ; Fri, 27 Jun 2008 12:21:10 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2DDAC8FC43 for ; Fri, 27 Jun 2008 12:21:10 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=JEIMavvDh6oMrPKQtuFhnT3sGvXHs1Dsk1onPD/uOY4BoW8ItAXy/zn6Epc/lj2IfMM5Vwew/M9vuHXkuuQCUQxrcIMUFt680lVz398D9chERgQKt2mOSyphx88PJgJhstWBK91bCcO3N06Tlo3N6bfXgIvWiHItEHCafA2L7GE=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1KCCwu-000Egr-Ua; Fri, 27 Jun 2008 16:21:09 +0400 Date: Fri, 27 Jun 2008 16:21:07 +0400 From: Eygene Ryabinkin To: Ali Niknam Message-ID: References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <48648D70.50304@transip.nl> Sender: rea-fbsd@codelabs.ru Cc: net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 12:21:10 -0000 Ali, good day. Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: > > Just a quick "me too" message: I also used to see this on my 7.x > > machines. This was with Apache servers in the proxy setup: one > > I'm wondering: where these 32 bit, or 64 bit machines? amd64. > > I had already tried to debug this situation and Mike Silbersack > > helped me with patching the kernel. At that days his patches (that > > went into 7.x) helped, but with higher request rate to the Apache, > > they seem to be back again. I can try to setup the testbed and > > verify if I will still be able to reproduce them. Will it be needed? > > > > Well, if your machine was indeed 64 bit, I for one would be very > interested in knowing if it also appears in 32 bit. Have no i386 machines to test on, sorry. Moreover, I can not yet reproduce the problem on my amd64, but I am continuing experiments. -- Eygene Remember that it is hard to read the on-line manual while single-stepping the kernel. -- FreeBSD Developers handbook From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 12:33:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E9551065675 for ; Fri, 27 Jun 2008 12:33:30 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id B42F28FC17 for ; Fri, 27 Jun 2008 12:33:29 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 69301 invoked by uid 89); 27 Jun 2008 12:34:41 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 27 Jun 2008 12:34:41 -0000 Message-ID: <4864DE21.2030109@ibctech.ca> Date: Fri, 27 Jun 2008 08:33:37 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Peter Jeremy References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> <20080627072301.GZ50631@server.vk2pj.dyndns.org> In-Reply-To: <20080627072301.GZ50631@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Giulio Ferro Subject: Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 12:33:30 -0000 Peter Jeremy wrote: > On 2008-Jun-26 22:06:11 +0200, Giulio Ferro wrote: >> I guess what I could do was to "poison" their arp cache for each >> address with a "is-at" message. Is there a way to force the sending >> of these messages for all the addresses of an interface? > > The kernel should send out gratuitous ARP requests whenever you assign > an address to an interface. You could confirm that this is happening > by tcpdumping the interface whilst you add aliases. > > Rummaging around in ports, you might find net/arping or net/p5-Net-ARP > useful if you want to manually generate gratuitous ARP requests. ping -S src_addr should do the trick too, however, that obviously doesn't scale very well, so it's probably only best to test with.. Steve From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 13:02:58 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4467C106566B for ; Fri, 27 Jun 2008 13:02:58 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from atlas.gtcomm.net (atlas.gtcomm.net [67.215.15.242]) by mx1.freebsd.org (Postfix) with ESMTP id 290D48FC12 for ; Fri, 27 Jun 2008 13:02:58 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from c-76-108-179-28.hsd1.fl.comcast.net ([76.108.179.28] helo=[192.168.1.6]) by atlas.gtcomm.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCDFm-00006l-KA; Fri, 27 Jun 2008 08:40:38 -0400 Message-ID: <4864E0FE.40708@gtcomm.net> Date: Fri, 27 Jun 2008 08:45:50 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eygene Ryabinkin References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Ali Niknam , net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 13:02:58 -0000 I have the same 'problem' if that helps any.. Sockets stuck for over a month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. Eygene Ryabinkin wrote: > Ali, good day. > > Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: > >>> Just a quick "me too" message: I also used to see this on my 7.x >>> machines. This was with Apache servers in the proxy setup: one >>> >> I'm wondering: where these 32 bit, or 64 bit machines? >> > > amd64. > > >>> I had already tried to debug this situation and Mike Silbersack >>> helped me with patching the kernel. At that days his patches (that >>> went into 7.x) helped, but with higher request rate to the Apache, >>> they seem to be back again. I can try to setup the testbed and >>> verify if I will still be able to reproduce them. Will it be needed? >>> >>> >> Well, if your machine was indeed 64 bit, I for one would be very >> interested in knowing if it also appears in 32 bit. >> > > Have no i386 machines to test on, sorry. Moreover, I can not yet > reproduce the problem on my amd64, but I am continuing experiments. > From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 14:06:22 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 404251065672; Fri, 27 Jun 2008 14:06:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id ECDD18FC1A; Fri, 27 Jun 2008 14:06:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=QZHH2vstl7U5H4NSQRPPTNq6NSL+BX6klR0BA0WnTstN5rspAeqU1Ru5dOt465WPu0JV2AvUOlWwWwA/Y+a+/UxU+upc9q/3cmt5AIGJ9LlMIEpBig8hzi7bycBv29FG6WxtTGT3OiHrMmn+h5FpOefug/K74kwjgyHDkwggKxo=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1KCEai-000FNA-KJ; Fri, 27 Jun 2008 18:06:20 +0400 Date: Fri, 27 Jun 2008 18:06:19 +0400 From: Eygene Ryabinkin To: Paul Message-ID: References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4864E0FE.40708@gtcomm.net> Sender: rea-fbsd@codelabs.ru Cc: rwatson@freebsd.org, Ali Niknam , net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 14:06:22 -0000 Paul, good day. Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: > I have the same 'problem' if that helps any.. Sockets stuck for over a > month in CLOSED and they have a * for the port on the source IP. > tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED > 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > amd64 > Doesn't seem to cause any issues though. And what is listening to that port? Can you identify the application? Just for the record -- may be it will narrow down the search list. Robert Watson told us today at the morning that he spotted the bug that lead to the '*' instead of port number. Robert, can you post the patch -- it seems to be not yet committed, at least cvs-src list has no signs of it? By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, removing instruction 'inp->inp_lport = 0;'? -- Eygene Remember that it is hard to read the on-line manual while single-stepping the kernel. -- FreeBSD Developers handbook From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 15:06:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F5CA1065684; Fri, 27 Jun 2008 15:06:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2D88FC21; Fri, 27 Jun 2008 15:06:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail0.meer.net [209.157.152.14]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m5RF6d6s068708; Fri, 27 Jun 2008 08:06:54 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m5RF6LoK017332; Fri, 27 Jun 2008 08:06:21 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from dhcp-75.hudson-trading.com.neville-neil.com (hudson-trading.com [66.150.84.160] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m5RF6KDV075860; Fri, 27 Jun 2008 08:06:20 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 27 Jun 2008 11:06:19 -0400 Message-ID: From: "George V. Neville-Neil" To: Julian Elischer In-Reply-To: <4863F479.8010206@elischer.org> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> <4863F479.8010206@elischer.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.00 () [Tag at 5.00] X-CanItPRO-Stream: default X-Canit-Stats-ID: 793852 - 4029d9ccc652 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, brooks@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 15:06:57 -0000 At Thu, 26 Jun 2008 12:56:41 -0700, julian wrote: > > I'm planning on committing it unless someone can provide a reason not > to, as I've seen it working, needed it, and have not seen any bad > byproducts. > I'd be interested to know how you tested it. NAT-T and IPsec are non-trivial protocols/subsystems that can have far reaching impacts on the network stack. Also, are you planning to maintain it after committing it? The biggest problem with NAT-T hasn't been the code, it's been that the author, who is doing a great job on the code, has been too busy to maintain it anywhere but at work. That is not a slam on the person or the code, I have the highest respect for both, but it reflects and important reality of the situation. Unless you're stepping up to maintain it as well as commit it I think it should not be committed. I know the Bjoern has been working hard to pick up the IPsec stuff in his free time, and I value his input on this subject quite a bit. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 15:08:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB891065671 for ; Fri, 27 Jun 2008 15:08:35 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id CAA458FC19 for ; Fri, 27 Jun 2008 15:08:35 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail0.meer.net [209.157.152.14]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m5RF8XD8068771; Fri, 27 Jun 2008 08:08:33 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m5RF8VHh018539; Fri, 27 Jun 2008 08:08:31 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from dhcp-75.hudson-trading.com.neville-neil.com (hudson-trading.com [66.150.84.160] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m5RF8UcI076568; Fri, 27 Jun 2008 08:08:31 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 27 Jun 2008 11:08:30 -0400 Message-ID: From: gnn@freebsd.org To: Paul In-Reply-To: <48645D9E.7090303@gtcomm.net> References: <48645D9E.7090303@gtcomm.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 793860 - 6c5950b44c37 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: FreeBSD Net Subject: Re: Weirdness - FBSD 7, Routing, Packet generator, em taskq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 15:08:35 -0000 At Thu, 26 Jun 2008 23:25:18 -0400, Paul wrote: > > I have a FreeBSD router set up with Full BGP routes and I'm doing some > tests on using it for routing. > > 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > amd64 > > oddness..: > > Use a packet generator to generate random source ips and ports and send > traffic through the router to a destination on the other side, single ip. > What happens is the 'em0 taskq' starts to eat cpu... but the funny > thing is immediately when I start the traffic (say, 100,000 pps) em0 > taskq is about 15% cpu.. and then over the course of 2 minutes or so it > climbs to 60% cpu.. This makes no sense.. The packets per second are > continuous and it just routed 100kpps for 60 seconds with less cpu so > why in the world would it slowly climb like that? > > It's an observation I suppose and I was hoping if someone could > enlighten me on WHY.. :) I did test it on 3 different machines by the way. > It even does this with just a handful of routes in the routing table , I > tried that too just to rule that out. > I don't remember Freebsd 4/5 doing this?? > What are you using to measure the CPU time? Some tools take time to gather up enough samples. Also, have you tried to do any profiling on the kernel to see why this might be the case? http://www.watson.org/~robert/freebsd/netperf/profile/ Best, George From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 15:30:14 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6836F106574E for ; Fri, 27 Jun 2008 15:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDAD8FC1A for ; Fri, 27 Jun 2008 15:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5RFUDBV044572 for ; Fri, 27 Jun 2008 15:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5RFUD2V044569; Fri, 27 Jun 2008 15:30:13 GMT (envelope-from gnats) Date: Fri, 27 Jun 2008 15:30:13 GMT Message-Id: <200806271530.m5RFUD2V044569@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alex Samorukov Cc: Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Samorukov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2008 15:30:14 -0000 The following reply was made to PR kern/121257; it has been noted by GNATS. From: Alex Samorukov To: bug-followup@FreeBSD.org, vnovy@vnovy.net Cc: Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic Date: Fri, 27 Jun 2008 16:48:15 +0200 I can approve the problem. I found VERY slow outgoing speed on my new server with natd, and the problem was with TSO flag on public interface. Freebsd 7.0/i386, em network driver From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 16:58:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61C431065672 for ; Fri, 27 Jun 2008 16:58:05 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4DE8FC18 for ; Fri, 27 Jun 2008 16:58:05 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so636203rvf.43 for ; Fri, 27 Jun 2008 09:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BATOBJHsp9Nr6DxMePA8qtiNRC820XCc2EiSm0Q4kUU=; b=kp4SN6fEDGYTA+MPTgh2zfJFLjhRxeCEFkr4OmbkIn9fH8IhxldtGnF1amIo3vmPpv vgoHuHlruj/Eoijxu97wWW8OidWPVwOlltO3HoDbKfSh8nqByD/qi76lxt+liMJAkCAq Un8dSlBapNrkD1KkSZejhTyiaorcB+809w0n0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ETHQyKrrAFM6wRaUkuqF0AcOv++UqnLmMHTm6uGXpxOWAaTDs+IXsrlK1si71qOPoX 21OizmpUH4GjatdTg+9ZpspzjpnG4EMweVVEb8meTi0qHHqw8BnaX6JB5Qtc2UFIQu9e 14oJsINUnegh4xLEfJwwPnwgt78RRbYiAzN2g= Received: by 10.141.29.18 with SMTP id g18mr924518rvj.162.1214585879605; Fri, 27 Jun 2008 09:57:59 -0700 (PDT) Received: by 10.141.171.21 with HTTP; Fri, 27 Jun 2008 09:57:59 -0700 (PDT) Message-ID: <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> Date: Fri, 27 Jun 2008 13:57:59 -0300 From: "Alexandre Biancalana" To: "Max Laier" In-Reply-To: <200806271036.12195.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4863FA62.2030703@zirakzigil.org> <200806271036.12195.max@love2party.net> Cc: freebsd-net@freebsd.org, Giulio Ferro Subject: Re: altq on vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 16:58:05 -0000 On 6/27/08, Max Laier wrote: > > > You don't need a patch at all. What you do is: Queue on the physical > interface, classify on the vlan interface. It is broken to allow ALTQ on > a virtual interface if you can do it otherwise. > > in pf.conf speak: > > If you have "ifconfig vlanX vlandev bge0 ..." > > altq on bge0 .... queue { vlan0, vlan1, ... } > queue vlan0 ... { vlan0_foo, vlan0_bar, ... } > queue vlan0_foo > queue vlan0_bar > ... > > pass on vlanX ... queue vlanX_foobar > > And there you go. No patch - whatsoever - required here. But the patch simplify the cases where you need one queue per vlan. From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 17:16:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D07A9106566C for ; Fri, 27 Jun 2008 17:16:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id 72AC68FC1B for ; Fri, 27 Jun 2008 17:16:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-064-185-170.pools.arcor-ip.net [88.64.185.170]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KCHYd1h5W-0002TW; Fri, 27 Jun 2008 19:16:24 +0200 Received: (qmail 47716 invoked from network); 27 Jun 2008 17:14:04 -0000 Received: from myhost.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 27 Jun 2008 17:14:04 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 27 Jun 2008 19:14:30 +0200 User-Agent: KMail/1.9.9 References: <4863FA62.2030703@zirakzigil.org> <200806271036.12195.max@love2party.net> <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> In-Reply-To: <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806271914.30216.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18jHbuL7xmd1UTUx3BJG2qnsj39Rlu/kduvKzn FCul+CmEmccEKIcv48tc317XREya57K4eMf2gmxmNokZLuiHVS Jpe4N3m145d5EIx4uOWDg== Cc: Giulio Ferro , Alexandre Biancalana Subject: Re: altq on vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 17:16:25 -0000 On Friday 27 June 2008 18:57:59 Alexandre Biancalana wrote: > On 6/27/08, Max Laier wrote: > > You don't need a patch at all. What you do is: Queue on the > > physical interface, classify on the vlan interface. It is broken to > > allow ALTQ on a virtual interface if you can do it otherwise. > > > > in pf.conf speak: > > > > If you have "ifconfig vlanX vlandev bge0 ..." > > > > altq on bge0 .... queue { vlan0, vlan1, ... } > > queue vlan0 ... { vlan0_foo, vlan0_bar, ... } > > queue vlan0_foo > > queue vlan0_bar > > ... > > > > pass on vlanX ... queue vlanX_foobar > > > > And there you go. No patch - whatsoever - required here. > > But the patch simplify the cases where you need one queue per vlan. NO! It is just wrong! There is no relation between vlan queues on the same physical interface and thus you can't guarantee anything! Can we please stop with this nonsense and not bring up the patch every other month. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 17:28:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36AB3106566C for ; Fri, 27 Jun 2008 17:28:08 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (unknown [IPv6:2001:470:1f00:ffff::5e5]) by mx1.freebsd.org (Postfix) with ESMTP id 154398FC14 for ; Fri, 27 Jun 2008 17:28:07 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (cpe-24-161-6-139.hvc.res.rr.com [24.161.6.139]) (authenticated bits=0) by vjofn.tucs-beachin-obx-house.com (8.14.2/8.14.2) with ESMTP id m5RHRgL4027173; Fri, 27 Jun 2008 13:27:56 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6) with ESMTP id m5RHRhRJ033379; Fri, 27 Jun 2008 13:27:43 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6/Submit) id m5RHRfAn033378; Fri, 27 Jun 2008 13:27:41 -0400 (EDT) (envelope-from tbohml) From: "Tuc at T-B-O-H.NET" Message-Id: <200806271727.m5RHRfAn033378@himinbjorg.tucs-beachin-obx-house.com> To: steve@ibctech.ca (Steve Bertrand) Date: Fri, 27 Jun 2008 13:27:41 -0400 (EDT) In-Reply-To: <4864D9C9.2020207@ibctech.ca> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPV6 problem : nd6_lookup: failed to add route for a neighbor X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 17:28:08 -0000 > > kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 > > > > Client IPv6 address: 2001:470:7:28::2/64 > > > > The script they suggest, and I used, is : > > > > ifconfig gif0 create > > ifconfig gif0 tunnel MYIP 216.66.22.2 > > ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 > > route -n add -inet6 default 2001:470:7:28::1 > > ifconfig gif0 up > > > > The tunnel came up, was passing traffic, but those messages were > > getting out of hand. I tried a prefixlen of 64, and I got: > > ...hmmmm. I'm not certain here, but since /128 represents only a single > address, I can understand why FreeBSD is getting confused. A /128 is an > IP within its own solitary subnet, so I'd have to guess that you need a > route to the remote end of the tunnel before you can set it as a default > gateway. > Even though its a directly connected endpoint? I was going to ask if trying : route -n add -inet6 default gif0 might make it happier, but it seems route on FBSD 5.5 doesn't accept that format of command. :-/ I also saw suggestions to change the prefixlen to 127, but I get the sem ioctl issue. I don't want to say "But it works elsewhere", but... doing : ipv6_enable="YES" gif_interfaces="gif0" ipv6_defaultrouter="2001:470:1F00:FFFF::5E4" gifconfig_gif0="MYIP 64.71.128.82" ipv6_ifconfig_gif0="2001:470:1F00:FFFF::5E5 2001:470:1F00:FFFF::5E4 prefixlen 128" on a 4.10-STABLE system works fine... But I realize theres been alot of code work since that beast. > > I've been needing to set up a few more tunnels, so I'll try one with > FreeBSD this morning with the same setup you have to try to replicate > the problem (on 7.0). > Ok, thanks. I'm a bit confused also by something I found on the net... http://lists.freebsd.org/pipermail/freebsd-net/2006-May/010718.html Seemed to be a set of patches around this very issue. I've looked at a 7.0-STABLE system and I don't see those changes. But it could very well be that it was updated differently before finally getting into the codebase. I'm not sure how one goes about verifying it. CVSWEB? > > > ifconfig: ioctl (SIOCAIFADDR): Invalid argument > > What was the command that you had entered when you received the above > error? When you tried to change prefix length, did you destroy the > existing tunnel first? > Sorry. I tried : ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 64 I had destroyed the tunnel and started from scratch... > > > Sendmail seemed a bit cranky : > > > > Jun 26 23:53:19 MYHOST sendmail[17543]: gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 > > I believe this is a reverse DNS issue. From how I perceive that message, > Sendmail is trying to retrieve a hostname based on that IP. > Yea, not sure why I mentioned that. But in any case, not sure what to do to remedy the situation. Thanks, Tuc From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 18:25:22 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0A16106567F for ; Fri, 27 Jun 2008 18:25:22 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from atlas.gtcomm.net (atlas.gtcomm.net [67.215.15.242]) by mx1.freebsd.org (Postfix) with ESMTP id D65298FC0A for ; Fri, 27 Jun 2008 18:25:22 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from c-76-108-179-28.hsd1.fl.comcast.net ([76.108.179.28] helo=[192.168.1.6]) by atlas.gtcomm.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCIaF-0002LM-Pv; Fri, 27 Jun 2008 14:22:07 -0400 Message-ID: <48653108.4080806@gtcomm.net> Date: Fri, 27 Jun 2008 14:27:20 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Eygene Ryabinkin References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: rwatson@freebsd.org, Ali Niknam , net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 18:25:23 -0000 Hi Eygene.. It happens with telnet :) A lot of my closed entries are from telnet so I can't really put a finger on any specific application :/ Eygene Ryabinkin wrote: > Paul, good day. > > Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: > >> I have the same 'problem' if that helps any.. Sockets stuck for over a >> month in CLOSED and they have a * for the port on the source IP. >> tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED >> 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 >> amd64 >> Doesn't seem to cause any issues though. >> > > And what is listening to that port? Can you identify the application? > Just for the record -- may be it will narrow down the search list. > > Robert Watson told us today at the morning that he spotted the bug > that lead to the '*' instead of port number. Robert, can you post > the patch -- it seems to be not yet committed, at least cvs-src > list has no signs of it? > > By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, > removing instruction 'inp->inp_lport = 0;'? > From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 18:33:31 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C9F1065672 for ; Fri, 27 Jun 2008 18:33:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id D9AEC8FC17 for ; Fri, 27 Jun 2008 18:33:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5AD7546BA9; Fri, 27 Jun 2008 14:33:30 -0400 (EDT) Date: Fri, 27 Jun 2008 19:33:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eygene Ryabinkin In-Reply-To: Message-ID: <20080627193034.B32893@fledge.watson.org> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org, Ali Niknam , Paul Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 18:33:31 -0000 On Fri, 27 Jun 2008, Eygene Ryabinkin wrote: > Paul, good day. > > Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: >> I have the same 'problem' if that helps any.. Sockets stuck for over a >> month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 >> 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: >> Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. > > And what is listening to that port? Can you identify the application? Just > for the record -- may be it will narrow down the search list. > > Robert Watson told us today at the morning that he spotted the bug that lead > to the '*' instead of port number. Robert, can you post the patch -- it > seems to be not yet committed, at least cvs-src list has no signs of it? > > By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, > removing instruction 'inp->inp_lport = 0;'? Hi Eygene, I've not yet had a chance to put the patch together; it does involve removing that line, but it's somewhat more complicated because inp_lport is used to signal whether or not the inpcb is still in various linked list. My current thinking is that I'd actually like to make it an explicit flag that indicates being on the lists so that we can have the port set non-zero yet no longer be on the lists (which would cause the closed connection to occupy the tuple). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 18:34:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B910106566C for ; Fri, 27 Jun 2008 18:34:47 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from atlas.gtcomm.net (atlas.gtcomm.net [67.215.15.242]) by mx1.freebsd.org (Postfix) with ESMTP id 1022F8FC1D for ; Fri, 27 Jun 2008 18:34:47 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from c-76-108-179-28.hsd1.fl.comcast.net ([76.108.179.28] helo=[192.168.1.6]) by atlas.gtcomm.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KCIjP-0004mA-GC; Fri, 27 Jun 2008 14:31:35 -0400 Message-ID: <48653340.8060301@gtcomm.net> Date: Fri, 27 Jun 2008 14:36:48 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: gnn@freebsd.org References: <48645D9E.7090303@gtcomm.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Weirdness - FBSD 7, Routing, Packet generator, em taskq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 18:34:47 -0000 I'm watching top -S -I -s1 -H This is just more of an observation.. I'm not having a problem with it, just wondering why it's doing it.. It's almost like most of the system processes in 'top' are a 3-5 minute average instead of an instant percentage. If this is intended behavior I simply wanted to know :) Curiousity Mainly. Also, isn't the emX taskq supposed to be using no cpu when polling is enabled? I'm trying to get em interface to take in 500kpps or more but it just won't do it. The max I can get is close to 400k and then it starts loading up on errors (out of receive buffers, rx overruns) mainly because the cpu is near 100% on em0 taskq. :( We need a SMP em driver for 7.0 :) No profiling yet... just messing around.. Intel Dual port pci-express nic , opteron 2212 , 7.0-stable now AMD64 seeing how much it will take before it errors out so I can figure out something to do with it.. :P Thanks :) Paul gnn@freebsd.org wrote: > At Thu, 26 Jun 2008 23:25:18 -0400, > Paul wrote: > >> I have a FreeBSD router set up with Full BGP routes and I'm doing some >> tests on using it for routing. >> >> 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 >> amd64 >> >> oddness..: >> >> Use a packet generator to generate random source ips and ports and send >> traffic through the router to a destination on the other side, single ip. >> What happens is the 'em0 taskq' starts to eat cpu... but the funny >> thing is immediately when I start the traffic (say, 100,000 pps) em0 >> taskq is about 15% cpu.. and then over the course of 2 minutes or so it >> climbs to 60% cpu.. This makes no sense.. The packets per second are >> continuous and it just routed 100kpps for 60 seconds with less cpu so >> why in the world would it slowly climb like that? >> >> It's an observation I suppose and I was hoping if someone could >> enlighten me on WHY.. :) I did test it on 3 different machines by the way. >> It even does this with just a handful of routes in the routing table , I >> tried that too just to rule that out. >> I don't remember Freebsd 4/5 doing this?? >> >> > > What are you using to measure the CPU time? Some tools take time to > gather up enough samples. Also, have you tried to do any profiling on > the kernel to see why this might be the case? > > http://www.watson.org/~robert/freebsd/netperf/profile/ > > Best, > George > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 19:49:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16736106568D for ; Fri, 27 Jun 2008 19:49:15 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id ED2BD8FC1D for ; Fri, 27 Jun 2008 19:49:14 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so690887rvf.43 for ; Fri, 27 Jun 2008 12:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8bqSPBTm6uX/haepmRbluqxsWyov0Hv2Lt5Uaj21r2o=; b=efn6LNJ1zDc5MjaMeWD5udLeTtaNyTgbm4nyYWlaWr2kKhS5lqZ132DxVY1/eVNttM E3/Ktv/kpI76jpHVV6YXq5cUndmrCfZU818fSJTf9L4NF+m8ZJuNZGvVm4c6/g6+cKQD s5obOCl2+fsW8ErLLWcjB2l1HBeH07lfC9Sv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZOYwGRbRIjBQeoCAC8R30HqQWdO0w7k7buBjlaXNj3n3vge1alG43qUugXkBj+bXLc L3HXTF9DtUyy174/ZOQRXjQYSYQFOLeElm6Edq/hObRq6kSoGWIQncpzhnPSm1KTr347 2MJfWepU3TtRsEI98MxzENeskn0c/6zIjK3U4= Received: by 10.141.206.13 with SMTP id i13mr1009449rvq.211.1214596154544; Fri, 27 Jun 2008 12:49:14 -0700 (PDT) Received: by 10.141.171.21 with HTTP; Fri, 27 Jun 2008 12:49:14 -0700 (PDT) Message-ID: <8e10486b0806271249i3f395532k80c1d26ba0661d2c@mail.gmail.com> Date: Fri, 27 Jun 2008 16:49:14 -0300 From: "Alexandre Biancalana" To: "Max Laier" In-Reply-To: <200806271914.30216.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4863FA62.2030703@zirakzigil.org> <200806271036.12195.max@love2party.net> <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> <200806271914.30216.max@love2party.net> Cc: freebsd-net@freebsd.org, Giulio Ferro Subject: Re: altq on vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 19:49:15 -0000 > > NO! It is just wrong! There is no relation between vlan queues on the > same physical interface and thus you can't guarantee anything! Can we > please stop with this nonsense and not bring up the patch every other > month. Understood !! From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 19:57:54 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1A110656D4 for ; Fri, 27 Jun 2008 19:57:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C0EE58FC15 for ; Fri, 27 Jun 2008 19:57:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 19FB346C92; Fri, 27 Jun 2008 15:57:52 -0400 (EDT) Date: Fri, 27 Jun 2008 20:57:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul In-Reply-To: <4864E0FE.40708@gtcomm.net> Message-ID: <20080627205708.S40819@fledge.watson.org> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ali Niknam , net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 19:57:54 -0000 On Fri, 27 Jun 2008, Paul wrote: > I have the same 'problem' if that helps any.. Sockets stuck for over a month > in CLOSED and they have a * for the port on the source IP. tcp4 0 0 > 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: > Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. If you use "sockstat" to list the sockets open in processes, do any match the entry in netstat? If so, which? If you shut down that program, does the entry disappear from netstat? Robert N M Watson Computer Laboratory University of Cambridge > > > > Eygene Ryabinkin wrote: >> Ali, good day. >> >> Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: >> >>>> Just a quick "me too" message: I also used to see this on my 7.x >>>> machines. This was with Apache servers in the proxy setup: one >>>> >>> I'm wondering: where these 32 bit, or 64 bit machines? >>> >> >> amd64. >> >> >>>> I had already tried to debug this situation and Mike Silbersack >>>> helped me with patching the kernel. At that days his patches (that >>>> went into 7.x) helped, but with higher request rate to the Apache, >>>> they seem to be back again. I can try to setup the testbed and >>>> verify if I will still be able to reproduce them. Will it be needed? >>>> >>>> >>> Well, if your machine was indeed 64 bit, I for one would be very >>> interested in knowing if it also appears in 32 bit. >>> >> >> Have no i386 machines to test on, sorry. Moreover, I can not yet >> reproduce the problem on my amd64, but I am continuing experiments. >> > > _______________________________________________ > 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 Fri Jun 27 20:27:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB371065677 for ; Fri, 27 Jun 2008 20:27:14 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9D76F8FC19 for ; Fri, 27 Jun 2008 20:27:14 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so244044ywe.13 for ; Fri, 27 Jun 2008 13:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=rsntnIJ5l769WxfIHuMp9x18ip7LyliQeOJgrBODMSo=; b=AVB8Lly73U4qEth2t08srQqsuFzgXbERjpI2d4S2m+jA3q/nmZ/VC99QuhTcCiQ+QC voSeZRy8HLaSe+/45UqoL4eoMrbaM4nWZ3NDMwo6tbJjDXZCdQ9MO7Y6E2zOMkfFYHGw sy/PFKVcf3tam8pDWmy623LFxFdr/2R3UsP30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=J81dCFPOAz4Mx177Vyl1rGuGYocn1OqpUBeEpTWyhGvfgRL5k+t4ZNzsRXmKaTBlUv Mp0hIR1BFTOMQgGSAU70GG6iIerw+FKorUExJXl/H7rfipXOELuXwY7bVjf2ys4wGeXv RVl1CqEMUojGCo14fkAUYswMdgr8T7S/Lq2Io= Received: by 10.150.122.13 with SMTP id u13mr2797315ybc.180.1214596888443; Fri, 27 Jun 2008 13:01:28 -0700 (PDT) Received: by 10.151.154.17 with HTTP; Fri, 27 Jun 2008 13:01:28 -0700 (PDT) Message-ID: Date: Fri, 27 Jun 2008 13:01:28 -0700 From: "Freddie Cash" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Understanding where dummynet fits into an ipfw ruleset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 20:27:14 -0000 I'm trying to figure out how traffic shaping using dummynet fits into an ipfw ruleset. Mainly, I'm wondering where to put the "ipfw queue" rules (the ones that send the packets to dummynet), in relation to the packet filtering rules, or if it even matters. For instance, do the queue rules apply to all the rules in the set, or only to rules that follow after the queue rules (numerically)? Say I've got a firewall setup that does 1:1 NAT for a bunch of servers (allow incoming/outgoing traffic), as well as 1:many NAT for the workstations (allow outgoing) on the LAN. I want to add traffic shaping rules that give traffic from the workstations to specific IPs greater weight than general traffic from the workstations to the Internet (ie reserve 25% of the bandwidth for important services). Would I put the queue rules at the start of the ruleset or the end? Or in the middle, just above the rules for the workstations? Do I add them after all the bad packet checks and general deny rules that are at the top of the ruleset? Just wondering how the queue rules interact with the general packet filter rules, since they can have the same parameters. Thanks. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 21:00:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D51F51065678 for ; Fri, 27 Jun 2008 21:00:03 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 27E388FC12 for ; Fri, 27 Jun 2008 21:00:02 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 76643 invoked by uid 98); 27 Jun 2008 21:00:01 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.038509 secs); 27 Jun 2008 21:00:01 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.038509 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 27 Jun 2008 21:00:01 -0000 Message-ID: <486554CC.8050609@zirakzigil.org> Date: Fri, 27 Jun 2008 22:59:56 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: Peter Jeremy References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> <20080627072301.GZ50631@server.vk2pj.dyndns.org> In-Reply-To: <20080627072301.GZ50631@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 21:00:03 -0000 Peter Jeremy wrote: > On 2008-Jun-26 22:06:11 +0200, Giulio Ferro wrote: > >> I guess what I could do was to "poison" their arp cache for each >> address with a "is-at" message. Is there a way to force the sending >> of these messages for all the addresses of an interface? >> > > The kernel should send out gratuitous ARP requests whenever you assign > an address to an interface. You could confirm that this is happening > by tcpdumping the interface whilst you add aliases. > > Rummaging around in ports, you might find net/arping or net/p5-Net-ARP > useful if you want to manually generate gratuitous ARP requests. > > I have bad news for you all: this doesn't seem to happen for alias interfaces. I've just tried to replicate what happened days ago. I've verified that only the base (non alias) interface sends proper is-at messages. The aliases don't.... I could't either ping from one of those addresses or ping to one of them until I isssued: arping -S aliased-address router-address The router didn't know the mac addresses had changed until then... Can anyone confirm this? From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 21:41:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ABDB1065678 for ; Fri, 27 Jun 2008 21:41:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 93DAF8FC19 for ; Fri, 27 Jun 2008 21:41:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 5F22124C6; Fri, 27 Jun 2008 14:41:50 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D09E02D6014; Fri, 27 Jun 2008 14:41:49 -0700 (PDT) Message-ID: <48655EAD.6040905@elischer.org> Date: Fri, 27 Jun 2008 14:42:05 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "George V. Neville-Neil" References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> <4863F479.8010206@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mgrooms@shrew.net, brooks@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 21:41:50 -0000 George V. Neville-Neil wrote: > At Thu, 26 Jun 2008 12:56:41 -0700, > julian wrote: >> I'm planning on committing it unless someone can provide a reason not >> to, as I've seen it working, needed it, and have not seen any bad >> byproducts. >> > > I'd be interested to know how you tested it. NAT-T and IPsec are > non-trivial protocols/subsystems that can have far reaching impacts on > the network stack. Also, are you planning to maintain it after > committing it? The biggest problem with NAT-T hasn't been the code, > it's been that the author, who is doing a great job on the code, has > been too busy to maintain it anywhere but at work. That is not a slam > on the person or the code, I have the highest respect for both, but it > reflects and important reality of the situation. Unless you're > stepping up to maintain it as well as commit it I think it should not > be committed. I know the Bjoern has been working hard to pick up the > IPsec stuff in his free time, and I value his input on this subject > quite a bit. > > Best, > George NAT-T is needed for ipsec to work correctly with a bunch of vpn servers such as the cisco VPN server. It's been seen by dozens of people to do exactly that. It's added to every single pfsense and m0n0wall router out there. Code inspection also shows that it shouldn't compromise non-NAT_T sessions. so, It allows one to do things that many people need. It doesn't screw up existing applications (that I've ever heard of). The author is responsive and shows dedication. From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 21:50:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08755106564A for ; Fri, 27 Jun 2008 21:50:38 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 0271A8FC18 for ; Fri, 27 Jun 2008 21:50:37 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtp015-bge351000.mac.com (asmtp015-bge351000 [10.150.69.78]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id m5RLbQVb015595 for ; Fri, 27 Jun 2008 14:37:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K3500B005EC1V60@asmtp015.mac.com> for freebsd-net@freebsd.org; Fri, 27 Jun 2008 14:37:26 -0700 (PDT) Message-id: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> From: Chuck Swiger To: Freddie Cash In-reply-to: Date: Fri, 27 Jun 2008 14:37:24 -0700 References: X-Mailer: Apple Mail (2.924) Cc: freebsd-net@freebsd.org Subject: Re: Understanding where dummynet fits into an ipfw ruleset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 21:50:38 -0000 On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote: > Mainly, I'm wondering where to put the "ipfw queue" rules (the ones > that send the packets to dummynet), in relation to the packet > filtering rules, or if it even matters. > > For instance, do the queue rules apply to all the rules in the set, or > only to rules that follow after the queue rules (numerically)? That pretty depends on whether net.inet.ip.fw.one_pass sysctl is set: pipe pipe_nr Pass packet to a dummynet(4) ``pipe'' (for bandwidth limitation, delay, etc.). See the TRAFFIC SHAPER (DUMMYNET) CONFIGURATION Section for further information. The search terminates; however, on exit from the pipe and if the sysctl(8) variable net.inet.ip.fw.one_pass is not set, the packet is passed again to the firewall code starting from the next rule. > Would I put the queue rules at the start of the ruleset or the end? > Or in the middle, just above the rules for the workstations? Do I add > them after all the bad packet checks and general deny rules that are > at the top of the ruleset? > > Just wondering how the queue rules interact with the general packet > filter rules, since they can have the same parameters. It's reasonable to place the dummynet queue and pipe statements immediately after anti-spoofing checks, if net.inet.ip.fw.one_pass is false; that way, all traffic is shaped, including stuff that is later blocked by other IPFW statements. Since the inbound traffic has already passed through your external link(s) anyway, you might as well acknowledge that it has. If net.inet.ip.fw.one_pass is true, then you definitely want to apply your deny rules first, as once something matches a pipe rule, it's going to be passed. The tradeoff is that the accounting/fairness of traffic is less accurate but the firewall ruleset runs faster... -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 22:01:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 541221065679 for ; Fri, 27 Jun 2008 22:01:29 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1FDCC8FC14 for ; Fri, 27 Jun 2008 22:01:29 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so261391ywe.13 for ; Fri, 27 Jun 2008 15:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fg8UwLf4LgvijV4nAaLZSezv+S4ngwOuY1cgeUnN/Fo=; b=W93iXle7OwYCyh8P2bW9OfKtT0boq5YFAudbp/qHwX83KO14/kiJkauPM/3CAp2hDD VGUF04ida+vzAc9Lx2iTV7gTyw+9rJK/6TESzPM0+SGH+sygTW72x4NvavFtdbs/fXuN WdtfNydcNglZ+gZW08pq5ow2SaAbxX+xzqmnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=oa75m3srMyaTtPuDFEA4mz5zVnJDwmZEXMGlh3Pb2I+tOMBlbTRN1UYLVLqyqn9Sr5 UJoqFjYQoAS06RYSCZWVx+a15byaLHOo6HT6CCm/djER8DKR8fh+ZFPlFc3oSzghGnOL vGzVeMGzAWCPn4VfHnUkP8NulGyuVk8aBT3jg= Received: by 10.150.205.13 with SMTP id c13mr2945970ybg.239.1214604078590; Fri, 27 Jun 2008 15:01:18 -0700 (PDT) Received: by 10.151.154.17 with HTTP; Fri, 27 Jun 2008 15:01:18 -0700 (PDT) Message-ID: Date: Fri, 27 Jun 2008 15:01:18 -0700 From: "Freddie Cash" To: freebsd-net@freebsd.org In-Reply-To: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> Subject: Re: Understanding where dummynet fits into an ipfw ruleset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 22:01:29 -0000 On Fri, Jun 27, 2008 at 2:37 PM, Chuck Swiger wrote: > On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote: >> Mainly, I'm wondering where to put the "ipfw queue" rules (the ones >> that send the packets to dummynet), in relation to the packet >> filtering rules, or if it even matters. >> >> For instance, do the queue rules apply to all the rules in the set, or >> only to rules that follow after the queue rules (numerically)? > > That pretty depends on whether net.inet.ip.fw.one_pass sysctl is set: [snip man page snippet] >> Would I put the queue rules at the start of the ruleset or the end? >> Or in the middle, just above the rules for the workstations? Do I add >> them after all the bad packet checks and general deny rules that are >> at the top of the ruleset? >> >> Just wondering how the queue rules interact with the general packet >> filter rules, since they can have the same parameters. > > It's reasonable to place the dummynet queue and pipe statements immediately > after anti-spoofing checks, if net.inet.ip.fw.one_pass is false; that way, > all traffic is shaped, including stuff that is later blocked by other IPFW > statements. Since the inbound traffic has already passed through your > external link(s) anyway, you might as well acknowledge that it has. Makes sense. That's the bit that was messing me up (one_pass). I'm still working my head around how it (one_pass) integrates with all the rest (divert/natd, fwd, dummynet) in a single ruleset. Looking at sysctl output on a handful of systems, some of our firewalls has one_pass enabled, others don't. That's probably what's been tripping me up, as sometimes a ruleset worked, other times it didn't, depending on the FreeBSD release (4.x, 6.x, 7.x) the firewall started with. It's only recently that I've started standardising settings across firewalls with standard hardware configs, generic rc.conf/sysctl.conf, specific rc.conf.local, and so on. Which is why I'm asking. > If net.inet.ip.fw.one_pass is true, then you definitely want to apply your > deny rules first, as once something matches a pipe rule, it's going to be > passed. The tradeoff is that the accounting/fairness of traffic is less > accurate but the firewall ruleset runs faster... So, in this situation, the "allow" rules would be the queue rules? To add traffic shaping to the following, using one_pass=1: 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Would be: 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Or am I way off here? :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 22:27:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 112A1106564A for ; Fri, 27 Jun 2008 22:27:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id A68D48FC17 for ; Fri, 27 Jun 2008 22:27:52 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m5RMRdsF013465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2008 08:27:50 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m5RMRdYI027262; Sat, 28 Jun 2008 08:27:39 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m5RMRcYv027261; Sat, 28 Jun 2008 08:27:38 +1000 (EST) (envelope-from peter) Date: Sat, 28 Jun 2008 08:27:38 +1000 From: Peter Jeremy To: Giulio Ferro Message-ID: <20080627222738.GD50631@server.vk2pj.dyndns.org> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> <20080627072301.GZ50631@server.vk2pj.dyndns.org> <486554CC.8050609@zirakzigil.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fckbADODYWZD5TdN" Content-Disposition: inline In-Reply-To: <486554CC.8050609@zirakzigil.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org Subject: Re: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 22:27:53 -0000 --fckbADODYWZD5TdN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Jun-27 22:59:56 +0200, Giulio Ferro wrote: >Peter Jeremy wrote: >> The kernel should send out gratuitous ARP requests whenever you assign >> an address to an interface. You could confirm that this is happening >> by tcpdumping the interface whilst you add aliases. >> =20 >I have bad news for you all: this doesn't seem to happen for alias >interfaces. I've just tried to replicate what happened days >ago. I've verified that only the base (non alias) interface sends >proper is-at messages. The aliases don't.... I'm not seeing this on physical interfaces. I can't immediately verify this on VLAN interfaces but could at work next week. Adding 192.168.123.253 as an alias on FreeBSD 7.0-STABLE (mid May): 08:21:39.899113 00:0f:b0:74:9c:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x080= 6), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 Adding 192.168.123.253 as an alias on FreeBSD 6.3-PRERELEASE: 08:24:21.077266 00:12:0e:20:2b:ad > ff:ff:ff:ff:ff:ff, ethertype ARP (0x080= 6), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --fckbADODYWZD5TdN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhlaVoACgkQ/opHv/APuIc4AQCfej57A8ExjRk6KRGA2yZmxS1f Sh8AoK8ND7FdU/7wTajQkyX4hnVgDFc0 =D83f -----END PGP SIGNATURE----- --fckbADODYWZD5TdN-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 22:32:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BE731065670; Fri, 27 Jun 2008 22:32:45 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id EB74E8FC12; Fri, 27 Jun 2008 22:32:44 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 6A11679E2CA; Fri, 27 Jun 2008 17:32:44 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 47389-06; Fri, 27 Jun 2008 22:32:44 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id C3A7B79E26A; Fri, 27 Jun 2008 17:32:43 -0500 (CDT) Received: from hole.shrew.net (localhost [127.0.0.1]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m5RMWfih065181; Fri, 27 Jun 2008 17:32:41 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: (from www@localhost) by hole.shrew.net (8.14.2/8.14.2/Submit) id m5RMWfmJ065179; Fri, 27 Jun 2008 17:32:41 -0500 (CDT) (envelope-from mgrooms@shrew.net) X-Authentication-Warning: hole.shrew.net: www set sender to mgrooms@shrew.net using -f To: "George V. Neville-Neil" MIME-Version: 1.0 Date: Fri, 27 Jun 2008 17:32:41 -0500 From: mgrooms Organization: Shrew Soft Inc In-Reply-To: References: Message-ID: <5cf41abb4dd14f4e24213575c348c114@localhost> X-Sender: mgrooms@shrew.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, brooks@freebsd.org, Julian Elischer Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mgrooms@shrew.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2008 22:32:45 -0000 On Fri, 27 Jun 2008 11:06:19 -0400, "George V. Neville-Neil" wrote: > At Thu, 26 Jun 2008 12:56:41 -0700, > julian wrote: >> >> I'm planning on committing it unless someone can provide a reason not >> to, as I've seen it working, needed it, and have not seen any bad >> byproducts. >> > > I'd be interested to know how you tested it. NAT-T and IPsec are > non-trivial protocols/subsystems that can have far reaching impacts on > the network stack. Also, are you planning to maintain it after > committing it? The biggest problem with NAT-T hasn't been the code, > it's been that the author, who is doing a great job on the code, has > been too busy to maintain it anywhere but at work. That is not a slam > on the person or the code, I have the highest respect for both, but it > reflects and important reality of the situation. Unless you're > stepping up to maintain it as well as commit it I think it should not > be committed. I know the Bjoern has been working hard to pick up the > IPsec stuff in his free time, and I value his input on this subject > quite a bit. > I have tested the patch with Cisco (PIX/ASA), Juniper (GT/SSG), Fortigate, Zywall, Linux and NetBSD to ensure interoperability. Mostly, the RFC and draft 2 versions of the protocol were exercised. What other kinds of tests would you like to see? Objections ... 1) NAT-T and IPsec are non-trivial protocols/subsystems The patch hasn't been reviewed enough? The patch hasn't been tested enough? An unresolved issue has been identified? 2) It can have far reaching impacts on the network stack The changes are not been sufficiently protected by the supplied kernel configuration option? 3) The author has been too busy to maintain it anywhere but at work What does this mean? Since you find his level of commitment unacceptable, what would be required for the patch to be accepted? Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Fri Jun 27 23:20:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52EBF1065675 for ; Fri, 27 Jun 2008 23:20:17 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.73]) by mx1.freebsd.org (Postfix) with ESMTP id 41CC48FC14 for ; Fri, 27 Jun 2008 23:20:17 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtp015-bge351000.mac.com (asmtp015-bge351000 [10.150.69.78]) by smtpoutm.mac.com (Xserve/smtpout010/MantshX 4.0) with ESMTP id m5RNKH68012568 for ; Fri, 27 Jun 2008 16:20:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K3500D2SA5RG930@asmtp015.mac.com> for freebsd-net@freebsd.org; Fri, 27 Jun 2008 16:20:16 -0700 (PDT) Message-id: From: Chuck Swiger To: Freddie Cash In-reply-to: Date: Fri, 27 Jun 2008 16:20:15 -0700 References: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-net@freebsd.org Subject: Re: Understanding where dummynet fits into an ipfw ruleset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Jun 2008 23:20:17 -0000 On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: [ ... ] >> If net.inet.ip.fw.one_pass is true, then you definitely want to >> apply your >> deny rules first, as once something matches a pipe rule, it's going >> to be >> passed. The tradeoff is that the accounting/fairness of traffic is >> less >> accurate but the firewall ruleset runs faster... > > So, in this situation, the "allow" rules would be the queue rules? > > To add traffic shaping to the following, using one_pass=1: > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > 300 deny ip from any to 2.2.2.2 in recv em0 > > Would be: > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > 300 deny ip from any to 2.2.2.2 in recv em0 > > Or am I way off here? :) Hmm. If you have one_pass set, I believe that rule 200 would become superfluous. If it was off, rule 200 would be needed to permit traffic through. However, queue rulesets are used to classify traffic into different bins; then then get pulled out of the bins with packets waiting is proportion to the weights configured via something like: ipfw queue 1 config pipe 1 weight 10 ie, you have to attach queue(s) to a pipe for this classification or sorting to be meaningful. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 01:55:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76409106566B for ; Sat, 28 Jun 2008 01:55:06 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5FD8FC13 for ; Sat, 28 Jun 2008 01:55:05 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 368F117347; Sat, 28 Jun 2008 11:55:04 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (138.21.96.58.exetel.com.au [58.96.21.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 16D3C17209; Sat, 28 Jun 2008 11:55:00 +1000 (EST) Message-ID: <486599BD.7030804@modulus.org> Date: Sat, 28 Jun 2008 11:54:05 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: Paul , freebsd-net@freebsd.org References: <48645D9E.7090303@gtcomm.net> <48653340.8060301@gtcomm.net> In-Reply-To: <48653340.8060301@gtcomm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Weirdness - FBSD 7, Routing, Packet generator, em taskq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 01:55:06 -0000 Firstly, tried turning off polling? Some of us have found it to be detrimental to performance on the more modern systems. Its use was more practical on older systems were servicing interrupts took alot of CPU power, but the "em" driver supports delaying interrupts until more packets have arrived - see the sysctls available on the em man page. So you're probably better of turning off polling and playing with these tunables, by calculating how many packets you're likely to be able to fit in the tx/rx descriptor array before you need to generate an interrupt. Secondly try pressing shift+c inside top to display "raw cpu usage" instead of the default "weighted cpu usage". Finally, is your test portraying realistic conditions? I am reminded that 1GB/s with 1500 MTU is only roughly 80,000 pps. - Andrew From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 03:05:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F1781065672; Sat, 28 Jun 2008 03:05:15 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 278198FC0A; Sat, 28 Jun 2008 03:05:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from Mobile2.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost1.sentex.ca (8.14.2/8.14.2) with SMTP id m5S2YT48074115; Fri, 27 Jun 2008 22:34:30 -0400 (EDT) (envelope-from mike@sentex.net) From: mike@sentex.net To: "Bruce M. Simpson" Date: Fri, 27 Jun 2008 22:34:37 -0400 Message-ID: References: <4852E23E.2040505@gtcomm.net> <4854EBF1.7020708@FreeBSD.org> In-Reply-To: <4854EBF1.7020708@FreeBSD.org> X-Mailer: Forte Agent 4.2/32.1118 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-net@freebsd.org Subject: Re: Route messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 03:05:15 -0000 On Sun, 15 Jun 2008 11:16:17 +0100, in sentex.lists.freebsd.net you wrote: >Paul wrote: >> Get these with GRE tunnel on >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT=20 >> 2008 :/usr/obj/usr/src/sys/ROUTER amd64 >> But do not get them with 7.0-RELEASE >> >> Any ideas what changed? :) Wish there was some sort of changelog.. >> # of messages per second seems consistent with packets per second on=20 >> GRE interface.. >> No impact in routing, but definitely impact in cpu usage for all=20 >> processes monitoring the route messages. > >RTM_MISS is actually fairly common when you don't have a default route. > Hi, I am seeing this issue as well on a pair of recently deployed boxes, one running MPD and one acting as an area router in front of it. The MPD box has a default route and only has 400 routes or so. A steady stream of those messages, upwards of 500 per second.=20 got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags: locks: inits:=20 sockaddrs: default got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags: locks: inits:=20 sockaddrs: default Is there a way to try and track down what is generating those messages ? Its eating up a fair bit of cpu with quagga (the zebra process specifically) ---Mike From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 04:14:57 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CCD3106564A for ; Sat, 28 Jun 2008 04:14:57 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id A32258FC17 for ; Sat, 28 Jun 2008 04:14:56 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 99142 invoked from network); 28 Jun 2008 03:48:13 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 28 Jun 2008 03:48:13 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 27 Jun 2008 22:48:12 -0500 (CDT) From: Mike Silbersack To: Eygene Ryabinkin In-Reply-To: <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> Message-ID: <20080627224640.J20899@odysseus.silby.com> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ali Niknam , net@freebsd.org Subject: Re: FreeBSD 7.0: sockets stuck in CLOSED state... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 04:14:57 -0000 On Thu, 26 Jun 2008, Eygene Ryabinkin wrote: > I had already tried to debug this situation and Mike Silbersack > helped me with patching the kernel. At that days his patches (that > went into 7.x) helped, but with higher request rate to the Apache, > they seem to be back again. I can try to setup the testbed and > verify if I will still be able to reproduce them. Will it be needed? IIRC, the problem we found then had some interesting root causes, but the important point was the FreeBSD 7-prerelease was returning a different errno than FreeBSD 6 (and before) had been returning, which caused Apache to leak the FD. I wouldn't be at all surprised if there was a switched errno in some other error path that's causing similar problems. -Mike From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 06:14:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86BDB106566B for ; Sat, 28 Jun 2008 06:14:36 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 959B28FC13 for ; Sat, 28 Jun 2008 06:14:33 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id QAA07721; Sat, 28 Jun 2008 16:14:16 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 28 Jun 2008 16:14:15 +1000 (EST) From: Ian Smith To: Chuck Swiger In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Freddie Cash Subject: Re: Understanding where dummynet fits into an ipfw ruleset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 06:14:36 -0000 On Fri, 27 Jun 2008, Chuck Swiger wrote: > On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: > [ ... ] > >> If net.inet.ip.fw.one_pass is true, then you definitely want to > >> apply your > >> deny rules first, as once something matches a pipe rule, it's going > >> to be > >> passed. The tradeoff is that the accounting/fairness of traffic is > >> less > >> accurate but the firewall ruleset runs faster... > > > > So, in this situation, the "allow" rules would be the queue rules? > > > > To add traffic shaping to the following, using one_pass=1: > > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Would be: > > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Or am I way off here? :) > > Hmm. If you have one_pass set, I believe that rule 200 would become > superfluous. If it was off, rule 200 would be needed to permit > traffic through. I'm keen to be certain about this myself. I think that one_pass only affects the packet on the current pass, in this case on the incoming pass from ip_input at rule 100 above. So if one_pass is set, the packet is queued (and accepted in) and the search terminates, but with one_pass off, the packet is reinjected at rule 200 when it leaves the pipe after its limitation and/or delay, and would need to be specifically allowed. However I don't think that affects the outgoing pass, ie after routing the packet still has to go through the firewall again (from ip_output), so in this case it will be allowed if it's going out to 2.2.2.2 via em1, else is denied at rule 300. Another option might be to only apply pipe/queue actions to 'out' rules, but mixing that with both 1:many and 1:1 NAT will complicate matters .. > However, queue rulesets are used to classify traffic > into different bins; then then get pulled out of the bins with packets > waiting is proportion to the weights configured via something like: > > ipfw queue 1 config pipe 1 weight 10 > > ie, you have to attach queue(s) to a pipe for this classification or > sorting to be meaningful. Yes I suspect Freddie might want to use pipe rather than queue here too, if just for bandwidth limitation rather than weighted queueing by type of traffic? And is it only wanted for managing the inbound traffic? It's quite confusing at first that pipe and queue are both ipfw 'actions', and are also terms used as pipe and queue configuration parameters, as in a queue definition specifies a particular 'pipe pipe_nr' and that 'queue' is used to specify a pipe's queue size .. Caveat: I'm only using pipes so far, and on a bridge, not a router, where you only get one shot at allow/deny/pipe on packets incoming through bdg_forward, ie no 'out' rules, for bridged packets anyway. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 11:35:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B12E1065673 for ; Sat, 28 Jun 2008 11:35:24 +0000 (UTC) (envelope-from rehsack@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id B03B98FC1E for ; Sat, 28 Jun 2008 11:35:23 +0000 (UTC) (envelope-from rehsack@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id D307BE1A8440 for ; Sat, 28 Jun 2008 13:15:37 +0200 (CEST) Received: from [87.149.225.180] (helo=waldorf.muppets.liwing.de) by smtp05.web.de with esmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KCYP3-00012M-00 for freebsd-net@freebsd.org; Sat, 28 Jun 2008 13:15:37 +0200 Message-ID: <48661D57.3040505@web.de> Date: Sat, 28 Jun 2008 11:15:35 +0000 From: Jens Rehsack User-Agent: Thunderbird 2.0.0.14 (X11/20080608) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: rehsack@web.de X-Sender: rehsack@web.de X-Provags-ID: V01U2FsdGVkX1+L9o4ev4xm3FDwKybKia1efMggdmnvYEqrFZtc FpEbLNT1GRVw2kN7h1YCRXvw2SvYWOGrtmvEXAhumsZNqnDN7w xIu0s9BEs= Subject: unbreaking igmpproxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 11:35:24 -0000 Hi all, last week I tried to configure my fbsd-router to enhance it to forward multicast traffic as read on http://un.geeig.net/openbsd-vdsl.html. Sure - it's OpenBSD, but I thought with a little work, I will make it run. But I wont :-( I tried even mrouted(8) but it wont work, because the PPPoE interface to the provider has a netmask of 255.255.255.255 (is it called "host route"?). By the way, I decided to go deeper into igmpproxy: I created a port (using the patches from Markus Friedl from the obsd port), compile, install on router and it delivers: (1) Note: joinMcGroup: 224.0.0.2 on fxp0 (2) Debu: building IGMP packet with datalen=0 (3) Info: sendto to 224.0.0.1 on 10.62.10.12; Errno(22): Invalid argument (4) Debu: SENT Membership query from 10.62.10.12 to 224.0.0.1 Line 2 is added by me, because I want to be sure, that there is no crap in the packet. The code which sends the packet looks like the code in mrouted, where igmpproxy is derived from: sendto(MRouterFD, send_buf, (size_t)sendsize, 0, (struct sockaddr *)&sdst, sizeof(sdst)); send(2) tells, the EINVAL wont be delivered by send or sendto etc. - but there is it. I've searched a bit and seen in sys/kern/uipc_socket.c a routine 'sosend_generic' which seems to handle those sendto calls. This function can return EINVAL when the iovec belonging to the write has negative bytes to handle (sendsize is length of IP header + length of IGMP header) or the mbuf has negative length (I didn't check if the mbuf is source or dest - I mean to remember from VxWorks, that it could be both). But both arguments, mbuf and uio, I cannot influence ... The second 'question' may be the same, maybe not ... The recvfrom() call seems to get scambled network data - but not all of them, just a few ... This is what tcpdump sees: 1. 988526 AF IPv4 (2), length 40: (tos 0xc0, ttl 1, id 40489, offset 0, flags [none], proto IGMP (2), length 36, options (RA)) 217.0.119.167 > 224.0.0.1: igmp query v3 0x0000: 0200 0000 46c0 0024 9e29 0000 0102 5541 ....F..$.)....UA 0x0010: d900 77a7 e000 0001 9404 0000 1164 ec8c ..w..........d.. 0x0020: 0000 0000 020f 0000 ........ And this igmpproxy receives through recvfrom(2): Debu: received 36 bytes on fd 4 Debu: received packet: 46 c0 0c 00 27 6e 00 00 01 02 cb fc d9 00 77 a7 e0 00 00 01 Warn: received packet from 217.0.119.167 shorter (36 bytes) than hdr+data length (24+3048) As you can see, the bytes 3-12 (count begins at 1) contains special refuse. But why only 3-12? Why are the first 2 bytes not scrambled at all? Ok, the IP version and length might be filled separately, but the ToS field is ok. The source and target addresses are ok - but the rest of the IP header? What is going on there? I really have no idea where to search next. The socket open looks ok (compared to the explanation in Stevens 'Network Programming' and 'TCP/IP illustrated' and looks very similar to the code in mrouted). This is all tested with FreeBSD-7.0 stable. I compiled the igmpproxy using standard flags (-O2 -fno-strict-aliasing) and using '-O -g3' - same behaviour. Of course I tried to find related resources using google and the freebsd search - but there was nothing what really affects this problem. Best regards, Jens From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 11:41:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7ACE106567B for ; Sat, 28 Jun 2008 11:41:18 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.freebsd.org (Postfix) with ESMTP id EA6A88FC17 for ; Sat, 28 Jun 2008 11:41:17 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 72839 invoked from network); 28 Jun 2008 11:14:35 -0000 Received: from cicuta.babolo.ru (85.30.229.5) by ints.mail.pike.ru with SMTP; 28 Jun 2008 11:14:35 -0000 Received: (nullmailer pid 71932 invoked by uid 136); Sat, 28 Jun 2008 11:14:27 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <200806271914.30216.max@love2party.net> To: Max Laier Date: Sat, 28 Jun 2008 15:14:27 +0400 (MSD) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1214651667.267043.71931.nullmailer@cicuta.babolo.ru> Cc: freebsd-net@freebsd.org, Giulio Ferro , Alexandre Biancalana Subject: Re: altq on vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 11:41:18 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > On Friday 27 June 2008 18:57:59 Alexandre Biancalana wrote: > > On 6/27/08, Max Laier wrote: > > > You don't need a patch at all. What you do is: Queue on the > > > physical interface, classify on the vlan interface. It is broken to > > > allow ALTQ on a virtual interface if you can do it otherwise. > > > > > > in pf.conf speak: > > > > > > If you have "ifconfig vlanX vlandev bge0 ..." > > > > > > altq on bge0 .... queue { vlan0, vlan1, ... } > > > queue vlan0 ... { vlan0_foo, vlan0_bar, ... } > > > queue vlan0_foo > > > queue vlan0_bar > > > ... > > > > > > pass on vlanX ... queue vlanX_foobar > > > > > > And there you go. No patch - whatsoever - required here. > > > > But the patch simplify the cases where you need one queue per vlan. > > NO! It is just wrong! There is no relation between vlan queues on the > same physical interface and thus you can't guarantee anything! Can we > please stop with this nonsense and not bring up the patch every other > month. Remember vlan anoter end. Vlan queues on the same physical interface has sense. Let see typical vlan use: +--------+ 100M untagged vlan1 | |--------------.. +---------+ | | 100M untagged vlan2 1G | | 1G tagged | |---------------- --------+ FreeBSD +------------+ switch | 100M untagged vlan3 | | | |--------------.. +---------+ | | 100M untagged vlanN | |--------------- +--------+ There is noting interesting in common queue on 1G physical interface, the only right queues are that on vlans when number of vlans < 10. More of that, sum traffic on 1G tagged intervace is limited by incoming traffic from 1G external interface and so common queue on 1G tagged interface is not interesting even when number of vlans > 10. Sorry for bad English. From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 15:02:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17BE31065679 for ; Sat, 28 Jun 2008 15:02:00 +0000 (UTC) (envelope-from sergv326@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.234]) by mx1.freebsd.org (Postfix) with ESMTP id 80B588FC13 for ; Sat, 28 Jun 2008 15:01:59 +0000 (UTC) (envelope-from sergv326@gmail.com) Received: by hu-out-0506.google.com with SMTP id 34so2365592hue.8 for ; Sat, 28 Jun 2008 08:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=pbGY9XBTU9OVA2jnKkEBRRUUndZYjO6GK75zC2pxmlk=; b=Sp31A905fDmj/MHZuf/FmH/5GDaVMnCPPMlcwrCjR/cbFZMiEC0wuHIRVO3W6qYU8x btpGL+UOfzo64oRZGc2XjDXutl7cDEAlWREKcIoCq0n6ZTfaphEKjdcFpUqTL/ru9A5s ixEKmvWSYu+oTv/ImHto6H+6jvvAaUvqREYo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Doy508j9yUHXnqqbCxsjg/FiP2IqyTygcbLbhDAlDgHgMGIYmkgzXbqHfPxi/YFYK1 AD50NiUzH3hirdVq5G6EjjM3PocuwN/uFTNaCdLCyzhuynqE/1OR5ziThmpJBNojFp6C pDLDa04uu3vo2t+TN5WbDa0RMyBtXOtMdySqU= Received: by 10.210.129.10 with SMTP id b10mr2278311ebd.78.1214664495481; Sat, 28 Jun 2008 07:48:15 -0700 (PDT) Received: by 10.210.104.9 with HTTP; Sat, 28 Jun 2008 07:48:15 -0700 (PDT) Message-ID: Date: Sat, 28 Jun 2008 18:48:15 +0400 From: "serg vasilyev" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: setfib with mpd - ifconfig on p-t-p link trouble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 15:02:00 -0000 Hi ! there's must be a restriction in ifconfig or in kernel that preventing from adding a multiple p-t-p interface with same destination address. i'm trying to build a test system with setfib and multiple mpd instances which are creating PPPoE connection to same destination gateway and run into problem with second p-t-p interface. mpd did not add an IP and gateway for it setfib 1 mpd1 -p /tmp/mpd1.pid -f mpd1.conf sleep 2 setfib 2 mpd2 -p /tmp/mpd2.pid -f mpd2.conf on a first interface ng0 i have both src ip and dst ip but on second i have nothing # ifconfig ng0 ng0: flags=88d1 mtu 1492 inet x.x.x.x --> y.y.y.y netmask 0xffffffff # ifconfig ng1 ng1: flags=88d1 mtu 1492 when i try to add ip's personally # ifconfig ng1 z.z.z.z y.y.y.y ifconfig: ioctl (SIOCAIFADDR) File exist How to remove the given restriction on an ifconfig or kernel or something else P.S. Sorry for my english... From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 17:10:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEC5A106564A for ; Sat, 28 Jun 2008 17:10:03 +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 AA65D8FC12 for ; Sat, 28 Jun 2008 17:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5SHA3Dp009793 for ; Sat, 28 Jun 2008 17:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5SHA3q7009792; Sat, 28 Jun 2008 17:10:03 GMT (envelope-from gnats) Date: Sat, 28 Jun 2008 17:10:03 GMT Message-Id: <200806281710.m5SHA3q7009792@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Hiroki Sato Cc: Subject: Re: kern/125003: incorrect EtherIP header format. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hiroki Sato List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2008 17:10:03 -0000 The following reply was made to PR kern/125003; it has been noted by GNATS. From: Hiroki Sato To: shino@fornext.org Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/125003: incorrect EtherIP header format. Date: Sun, 29 Jun 2008 01:35:12 +0900 (JST) ----Security_Multipart(Sun_Jun_29_01_35_12_2008_272)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shunsuke SHINOMIYA wrote in <200806270610.m5R6A3hR060682@freefall.freebsd.org>: sh> =46rom RFC3378 sh> > In summary, the EtherIP Header has two fields: sh> >=20 sh> > Bits 0-3: Protocol version sh> > Bits 4-15: Reserved for future use sh> >=20 sh> > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 sh> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ sh> > | | | sh> > | VERSION | RESERVED | sh> > | | | sh> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ sh> >=20 sh> > Figure 2: EtherIP Header Format (in bits) sh> >=20 sh> sh> , first octet(bit 0,MSB to 7) consists of VERSION and a part of RESERVED. sh> And VERSION is high 4 bits of the octet. sh> Am I misunderstanding this? The VERSION is in bit 0-3 and LSB in this diagram is left. As Andrew also explained, these are the reasons why ETHERIP_VER_VERS_MASK is defined as 0x0f. Do you really have interoperability problem? If so, please let us know more detail information about it first. -- | Hiroki SATO ----Security_Multipart(Sun_Jun_29_01_35_12_2008_272)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkhmaEAACgkQTyzT2CeTzy12bwCfTQ2kE20quy6BU+vd9wYaNwS+ cxQAnA8yh2VRKHuRcxLZc459791hXOFY =a1zs -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun_29_01_35_12_2008_272)---- From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 17:50:33 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 127DC1065671; Sat, 28 Jun 2008 17:50:33 +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 D99D08FC13; Sat, 28 Jun 2008 17:50:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5SHoW4T014275; Sat, 28 Jun 2008 17:50:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5SHoWs6014271; Sat, 28 Jun 2008 17:50:32 GMT (envelope-from linimon) Date: Sat, 28 Jun 2008 17:50:32 GMT Message-Id: <200806281750.m5SHoWs6014271@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/125079: [ppp] host routes added by ppp with gateway flag (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 17:50:33 -0000 Old Synopsis: host routes added by ppp with gateway flag New Synopsis: [ppp] host routes added by ppp with gateway flag (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jun 28 17:49:57 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125079 From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 18:49:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1301B1065684 for ; Sat, 28 Jun 2008 18:49:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id AB5858FC15 for ; Sat, 28 Jun 2008 18:49:29 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E3F8F41C798 for ; Sat, 28 Jun 2008 20:49:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 3Uejg71+fGiu for ; Sat, 28 Jun 2008 20:49:27 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 5434841C796; Sat, 28 Jun 2008 20:49:27 +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 167C644487F for ; Sat, 28 Jun 2008 18:49:10 +0000 (UTC) Date: Sat, 28 Jun 2008 18:49:10 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org In-Reply-To: <5cf41abb4dd14f4e24213575c348c114@localhost> Message-ID: <20080628184119.W83875@maildrop.int.zabbadoz.net> References: <5cf41abb4dd14f4e24213575c348c114@localhost> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 18:49:30 -0000 Replying to the (randomly) last posting in this thread... Hi, okay, as patience seems to be a problem with some people and I do not want to say this on two fronts (public and internal) here are my comments. Yes, they will not be what you expect but seriously, as I said before in other contexts: IPsec is about security and not features. If you were worried about security you would have reviewed this patch in detail before, maybe side by side with the RFCs and contributed changes back to the author. So basically I know the hands that are seriously thinking about spending time on FreeBSD in-tree-IPsec in the not so distant future and have done in the past. The ten fingers attached to those hands are typing this email. I know others would really like to but cannot find the timeshare. I know others but they haven't yet committed themselves to anything but a hit-and-run stunt. Why in the future and not now? Basically because it's my free time, mostly evenings and weekends that I can spend on FreeBSD. If you want to change that, talk to my employer who'll happily let me work on FreeBSD if you pay for it;-) My current (private) project is called ``jails'' and I'll finish this first. The next project is IPsec again along with other security stuff and vimage reviews that not many people have committed themselves to either but lots of people crying for it. Where is FreeBSD with IPsec? I thought I'd say again what I said a few months back, which was "in a very good position" but to get back to that it'll take me a while. There are about a dozen serious PRs, lots of them came in late after 7 because people did not test their things after the transition, a batch of features, enhancements, patches on new stuff, and probably even more of I cannot think at the moment. I have 5 private (non public) `issues' about IPsec on my private list in addition to all this. IPsec is about security, so bug fixes first, then features. So what about NAT-T, which has been around for not as long as the jail patches I am working on at the moment? A lot of you are talking about "I have done testing". Right, good-good-scenario is what I get from the mails. Some say "this is mandatory to connect to vendor XYZ". Screw the vendor, if you have no NAT and still need it. I have (had) IPsecs to those boxes, since ~2000, and didn't need it if there was no NAT (why would I) - so please stop the propaganda/marketing or give the full facts. People ask about review. The reason it's not in (yet) is that I haven't had enough time to do the close line-by-line review and give all the feedback to Yvan. The reason for that, as I have stated multiple times before, is the lack of contiguous time. It needs to be contiguous - you cannot do this this Sunday and Thursday evening again having fought 10 different fires in the meantime. Why do I think this needs to be done? IPsec is about security and not about features. The current plan is (let me quote from a mail sent to Yvan on June 13: "Your patch will soon need more changes (due to FreeBSD changes) and chances are good that if you don't do that step for HEAD but force me to do it that you'll get the entire review." So you know my plan on this now. Some say "there are #ifdefs around the code - what's the problem committing but not enabling'. If the project is going to ship it, the project will have to maintain it, deal with the bugs, possibly issue SAs if there is a serious bug, have to make sure to keep ABI compatibilities for STABLE branches, ... that's a lot more hands than only mine if it gets there, so do not ask to screw others as well if you can avoid it. "But it works" - yes it does, as long as everyone behaves. You may find UDP packets eaten without any notice, you may have experienced panics, you may have found it work on one machine and not on the other, you may have tried to use it with FreeBSD base user space *oops* does not work but your setkey, libipsec, .. come from ipsec-tools anyway. You may.... Been there,... These days I am absolutely no longer worried about missing #ifdefs, style or other minor issues. What am I worried about? Go to line one, read again. After all this, let me say that the patch is good, else not that lot of people would use it (though I bet a lot do without knowing how and why;) and I really appreciate all the work done by Yvan and possibly others the patch was based on. But it's not finished yet. If you have read Yvan's mail this gives you an initial list. I'd say there is more missing to the RFCs and a bit more to FreeBSD and the line-by-line review but that's nothing most of you would probably `need' when saying "it works for me", "it works in our bundled software". That's why you have the patches. So what's the moral of the story? I have lately tried to explain to someone some aspects of what "to care" means. So if you know what "to care" means - the moral might be "If it's committed now - who cares?" Maybe it's - if I have to read another two dozen mails in this thread and another half a dozen internally it'll simply waste another of my Saturday afternoons. Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 18:58:50 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F061065673; Sat, 28 Jun 2008 18:58:50 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 270228FC16; Sat, 28 Jun 2008 18:58:50 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from freefall.freebsd.org (hrs@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5SIwnxW019449; Sat, 28 Jun 2008 18:58:49 GMT (envelope-from hrs@freefall.freebsd.org) Received: (from hrs@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5SIwnMK019445; Sat, 28 Jun 2008 18:58:49 GMT (envelope-from hrs) Date: Sat, 28 Jun 2008 18:58:49 GMT Message-Id: <200806281858.m5SIwnMK019445@freefall.freebsd.org> To: shino@fornext.org, hrs@FreeBSD.org, freebsd-net@FreeBSD.org From: hrs@FreeBSD.org Cc: Subject: Re: kern/125003: [gif] incorrect EtherIP header format. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 18:58:50 -0000 Synopsis: [gif] incorrect EtherIP header format. State-Changed-From-To: open->feedback State-Changed-By: hrs State-Changed-When: Sat Jun 28 18:57:46 UTC 2008 State-Changed-Why: We need a detail about this issue from the PR originator. http://www.freebsd.org/cgi/query-pr.cgi?pr=125003 From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 20:30:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C377F1065670 for ; Sat, 28 Jun 2008 20:30:44 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id A36E18FC0A for ; Sat, 28 Jun 2008 20:30:44 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-75-63-19-19.dsl.pltn13.sbcglobal.net [75.63.19.19]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id m5SKUp80025427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2008 13:30:51 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <48669F6F.1050005@monkeybrains.net> Date: Sat, 28 Jun 2008 13:30:39 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.12 (X11/20080310) MIME-Version: 1.0 To: Jack Vogel References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> <485C41C5.4090706@monkeybrains.net> <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> <485D5B9E.8020908@monkeybrains.net> <485ECF20.6000607@monkeybrains.net> In-Reply-To: <485ECF20.6000607@monkeybrains.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on pita.monkeybrains.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Seeking help understanding my "emX: watchdog timeout" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 20:30:44 -0000 Continuing the emX thread... ---------------------------------------- #man 4 em hw.em.txd Number of transmit descriptors allocated by the driver. The default value is 256. The 82542 and 82543-based adapters can handle up to 256 descriptors, while others can have up to 4096. I just upped values in my loader.conf: hw.em.rxd=1024 hw.em.txd=1024 Thanks Dmitriy -- your reply on jboss gave me idea to try tuning that value. ---------------------------------------- I tried upping the rx_processing_limit on my active interfaces and that caused MORE watchdog timeout events. In fact, they started to happen on em0 and em1 (previously not throwing errors). dev.em.0.rx_processing_limit=200 dev.em.1.rx_processing_limit=200 dev.em.2.rx_processing_limit=200 dev.em.4.rx_processing_limit=200 I am going to keep those values in with the new hw.em.rxd settings and back them out if watchdog events persist. ---------------------------------------- Questions to EM users: Do you use POLLING or MSI Interrupts with FreeBSD 7.x and PCIe Ethernet adapters? Do you see watchdog timeout events on your Intel adapters? ---------------------------------------- I emailed Intel and asked for help. They referred me to this document (not very helpful): http://downloadmirror.intel.com/10957/ENG/README.txt I replied and asked if other users are reporting watchdog timeout events. The tech was less than helpful -- here was the response from adaptersuppor@mailbox.cps.intel.com: >> Please be aware that you are the first person who reports those “watchdog timeouts”. >> >> Please note that this is an intermittent behavior, we have not been able to >> determine exactly when that issue happens, and to which exact adapter under >> which exact circumstances, in the moment that we have a problem we are able >> to recreate many times this will become a “known issue” and most certainly >> it will be posted in our website under the adapters that has that issue. Dude! Take an ESL class. I also CC'd freebsdnic@mailbox.intel.com. ---------------------------------------- Last week I tried changing this setting: > dev.em.2.tx_int_delay: 33 > dev.em.2.tx_abs_int_delay: 33 They did not help. Rudy From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 21:13:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C171F1065684 for ; Sat, 28 Jun 2008 21:13:03 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5D38FC14 for ; Sat, 28 Jun 2008 21:13:03 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from albator.zen.inc (albator.zen.inc [192.168.1.5]) by smtp.zeninc.net (smtpd) with ESMTP id CD1BD3F7A for ; Sat, 28 Jun 2008 23:12:59 +0200 (CEST) Received: by albator.zen.inc (Postfix, from userid 1000) id AD33D73248; Sat, 28 Jun 2008 23:13:00 +0200 (CEST) Date: Sat, 28 Jun 2008 23:13:00 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080628211300.GA3310@zen.inc> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> <4863F479.8010206@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 21:13:03 -0000 On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote: > At Thu, 26 Jun 2008 12:56:41 -0700, > julian wrote: > > > > I'm planning on committing it unless someone can provide a reason not > > to, as I've seen it working, needed it, and have not seen any bad > > byproducts. > > > > I'd be interested to know how you tested it. I can answer that question: - We do have "non regression tests", which test every night that "it works" in a "good scenario", with a peers who runs quite the same kernel, with the same patch and the same userland. We do also some "bad scenarios" tests, but not as much as I would like actually (it's much more complex to test). - We do have THOUSANDS of customers who use it for years now. And customers are really not well nown to always generate "good scenarios".... Customers can do some mistakes, can use some very strange stacks for peers, can use a lots of other IPSec stacks for peers, can have *a lot* of peers (of course with various implementations, configurations, NAT or not, etc...) for the same gate, etc... And how do I know that it works ? Well, when it doesn't work, I do know it, quite quickly most of the time ! As Bjoern said in another mail, we're talking about security. Security is my job, security is what we provide to our customers, and even if some of our customers just don't understant what they do, some others do *really* understand things, and do *really* test devices, check if it works, and quickly reports us problems (and ask for quick solutions). > NAT-T and IPsec are > non-trivial protocols/subsystems that can have far reaching impacts on > the network stack. Yes. > Also, are you planning to maintain it after > committing it? I plan to do that. > The biggest problem with NAT-T hasn't been the code, > it's been that the author, Really ? > who is doing a great job on the code, Thank you.... > has > been too busy to maintain it anywhere but at work. That is not exact, and I'm really sorry if you understood that after our discussion at the last EuroBSDCon. First, you can check that I'm sending this mail on saturday evening, which is out of my work hours :-) Then I can for example confirm that I did the whole migration from RELENG6 to RELENG7 on my free time, just because I needed a working FreeBSD7 + NAT-T patch at home before I've been asked to do it at work. Yes, I'm doing most of IPSec / NAT-T stuff at work, but it is mainly because I'm *paid* for that !!! Let me tell this again: working on FreeBSD's IPSec stack (and on NAT-T, of course, adn also on ipsec-tools) is a part of my job. What I told you some months ago is that there are some things that I cannot really do at work, because it takes lot of time and because those things are more "code cleanups" than "new features" (we were talking about PFKey V2 cleanups related to NAT-T ports). And if I did not spend that time to do that cleanup, that's not because I don't have such time, that's because I was starting to fear that the patch may be never commited, so I wasn't sure to want to continue spending lots of time on a patch "for nothing". If Bjoern or you told me some months ago "do that cleanup and we'll commit the patch", it would already have been done, and we would have *all* saved some time ! And yes, I do also spend some parts of my free time on things that are not related to FreeBSD's IPSec (and, to be completely honest, on things which are not related at all to computers....). > That is not a slam > on the person or the code, I have the highest respect for both, but it > reflects and important reality of the situation. I feel that "the reality of the situation" is that FreeBSD's IPSec stack needs more people *working on it*, not more people wasting their time about why some work should or shouldn't be reported. That is not a slam on the persons who are still working on the IPsec stack, I have the highest respect for them, but it reflects an important reality of the situation... > Unless you're > stepping up to maintain it as well as commit it I think it should not > be committed. I know the Bjoern has been working hard to pick up the > IPsec stuff in his free time, and I value his input on this subject > quite a bit. You said it yourself: actually, FreeBSD's IPSec stack is just maintained by one person, which worked hard on it, which does a great job on it, but which can spend only some parts of his free time on it. That is a problem. Of course, the solution can NOT be to ask Bjoern to spend more time on it (well, Bjoern, do that if you want :-). The only other solution I see is to find a way to help people who want to help you.... Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 22:18:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FF74106566B for ; Sat, 28 Jun 2008 22:18:20 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 269368FC0C for ; Sat, 28 Jun 2008 22:18:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 29BAD2360; Sat, 28 Jun 2008 15:18:20 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 864E92D60BD; Sat, 28 Jun 2008 15:18:18 -0700 (PDT) Message-ID: <4866B8BB.1040908@elischer.org> Date: Sat, 28 Jun 2008 15:18:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: serg vasilyev 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: setfib with mpd - ifconfig on p-t-p link trouble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 22:18:20 -0000 serg vasilyev wrote: > Hi ! > there's must be a restriction in ifconfig or in kernel that preventing from > adding a multiple p-t-p interface with same destination address. > i'm trying to build a test system with setfib and multiple mpd instances > which are creating PPPoE connection to same destination gateway and run into > problem with second p-t-p interface. > mpd did not add an IP and gateway for it this is a misunderstanding of what setfib does. You can only have one point to poitn interface with the same destination address. Having multiple routing tables does not automatically make it possible to have tow tunnels to the same place, (though theoretically maultipath routing might make this possible) because you still need to specify the remote address to specify the route's action. If you have multiple p2p links with the same remote address, you cannot specify which interface to use for a particular route. > > setfib 1 mpd1 -p /tmp/mpd1.pid -f mpd1.conf > sleep 2 > setfib 2 mpd2 -p /tmp/mpd2.pid -f mpd2.conf > > on a first interface ng0 i have both src ip and dst ip but on second i have > nothing > > # ifconfig ng0 > ng0: flags=88d1 mtu 1492 > inet x.x.x.x --> y.y.y.y netmask 0xffffffff > # ifconfig ng1 > ng1: flags=88d1 mtu 1492 > > when i try to add ip's personally > # ifconfig ng1 z.z.z.z y.y.y.y > ifconfig: ioctl (SIOCAIFADDR) File exist > > How to remove the given restriction on an ifconfig or kernel or something > else > P.S. Sorry for my english... you MAY be able to manually remove the link addresses from both routing tables after adding the first p2p link, and then add the second interface, and then remove the link address from the first fib, and add back the first link route from the first p3p link to teh first FIB. but I have not tested this. currently, adding an interface addres teh link layer route to ALL fibs, leaving it up to the admin to remove them from the fibs he does not want them in. This was a decision I took but the other option would have been to add it to only the 'current' fib, which would have been even more disruptive. ok I tested this with gre tunnels: ifconfig gre0 create ifconfig gre1 create ifconfig gre0 1.1.1.1 2.2.2.2 # remove conflicting routes setfib -0 route delete 2.2.2.2 setfib -1 route delete 2.2.2.2 #now set up the second link ifconfig gre1 3.3.3.3 2.2.2.2 # and remove the rotue we don't want setfib -0 route delete 2.2.2.2 # and replace it with the one we DO want, # (or one that is equivalent) setfib -0 route add 2.2.2.2 -iface gre0 wsa05:rjulian 34] ifconfig [...] gre0: flags=9011 mtu 1476 inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 gre1: flags=9011 mtu 1476 inet 3.3.3.3 --> 2.2.2.2 netmask 0xff000000 wsa05:rjulian 35] setfib -0 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif [...] 2.2.2.2 3.3.3.3 UH 0 0 gre1 [...] wsa05:rjulian 36] setfib -1 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif [...] 2.2.2.2 gre0 UGHS 0 0 gre0 [...] wsa05:rjulian 37] which would do what you want. now to make mpd know how to do that :-) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jun 28 22:39:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF3F4106564A for ; Sat, 28 Jun 2008 22:39:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id B50648FC15 for ; Sat, 28 Jun 2008 22:39:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A2FD12433; Sat, 28 Jun 2008 15:39:58 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id E48502D6017; Sat, 28 Jun 2008 15:39:57 -0700 (PDT) Message-ID: <4866BDCF.3020907@elischer.org> Date: Sat, 28 Jun 2008 15:40:15 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: serg vasilyev References: <4866B8BB.1040908@elischer.org> In-Reply-To: <4866B8BB.1040908@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: setfib with mpd - ifconfig on p-t-p link trouble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Jun 2008 22:39:59 -0000 Julian Elischer wrote: > serg vasilyev wrote: >> Hi ! >> there's must be a restriction in ifconfig or in kernel that preventing >> from >> adding a multiple p-t-p interface with same destination address. >> i'm trying to build a test system with setfib and multiple mpd instances >> which are creating PPPoE connection to same destination gateway and >> run into >> problem with second p-t-p interface. >> mpd did not add an IP and gateway for it > > > this is a misunderstanding of what setfib does. > You can only have one point to poitn interface with the same > destination address. > Having multiple routing tables does not automatically make it > possible to have tow tunnels to the same place, > (though theoretically maultipath routing might make this possible) > because you still need to specify the remote address to specify > the route's action. If you have multiple p2p links with the same > remote address, you cannot specify which interface to use for a > particular route. > > >> >> setfib 1 mpd1 -p /tmp/mpd1.pid -f mpd1.conf >> sleep 2 >> setfib 2 mpd2 -p /tmp/mpd2.pid -f mpd2.conf >> >> on a first interface ng0 i have both src ip and dst ip but on second i >> have >> nothing >> >> # ifconfig ng0 >> ng0: flags=88d1 mtu 1492 >> inet x.x.x.x --> y.y.y.y netmask 0xffffffff >> # ifconfig ng1 >> ng1: flags=88d1 mtu 1492 >> >> when i try to add ip's personally >> # ifconfig ng1 z.z.z.z y.y.y.y >> ifconfig: ioctl (SIOCAIFADDR) File exist >> >> How to remove the given restriction on an ifconfig or kernel or >> something >> else >> P.S. Sorry for my english... > you MAY be able to manually remove the link addresses from both > routing tables after adding the first p2p link, > and then add the second interface, and then > remove the link address from the first fib, > and add back the first link route from the first p3p link to teh first FIB. > > but I have not tested this. > > currently, adding an interface addres teh link layer route to ALL fibs, > leaving it up to the admin to remove them from the fibs he does > not want them in. This was a decision I took but the other option would > have been to add it to only the 'current' fib, which would have > been even more disruptive. > > ok I tested this with gre tunnels: > > ifconfig gre0 create > ifconfig gre1 create > ifconfig gre0 1.1.1.1 2.2.2.2 > # remove conflicting routes > setfib -0 route delete 2.2.2.2 > setfib -1 route delete 2.2.2.2 > #now set up the second link > ifconfig gre1 3.3.3.3 2.2.2.2 > # and remove the rotue we don't want > setfib -0 route delete 2.2.2.2 > # and replace it with the one we DO want, > # (or one that is equivalent) > setfib -0 route add 2.2.2.2 -iface gre0 > > > wsa05:rjulian 34] ifconfig > [...] > gre0: flags=9011 mtu 1476 > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > gre1: flags=9011 mtu 1476 > inet 3.3.3.3 --> 2.2.2.2 netmask 0xff000000 > > > wsa05:rjulian 35] setfib -0 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > [...] > 2.2.2.2 3.3.3.3 UH 0 0 gre1 > [...] > wsa05:rjulian 36] setfib -1 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > [...] > 2.2.2.2 gre0 UGHS 0 0 gre0 > [...] > wsa05:rjulian 37] > > which would do what you want. > now to make mpd know how to do that :-) actually setfib -1 route add 2.2.2.2 -iface gre0 -gateway 1.1.1.1 seems to do even better .. wsa05:rjulian 6] setfib -1 route add 2.2.2.2 -interface gre0 -gateway 1.1.1.1 add host 2.2.2.2: gateway gre0 wsa05:rjulian 7] setfib -1 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif [...] 2.2.2.2 1.1.1.1 UHS 0 0 gre0 [...] wsa05:rjulian 8] > > >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"