From owner-freebsd-net@FreeBSD.ORG Mon Jan 1 11:08:50 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5675016A47B for ; Mon, 1 Jan 2007 11:08:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4699113C4B9 for ; Mon, 1 Jan 2007 11:08:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l01B8o3a048940 for ; Mon, 1 Jan 2007 11:08:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l01B8mbf048936 for freebsd-net@FreeBSD.org; Mon, 1 Jan 2007 11:08:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Jan 2007 11:08:48 GMT Message-Id: <200701011108.l01B8mbf048936@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 11:08:50 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/106722 net [net] [patch] ifconfig may not connect an interface to 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network 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/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong 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 kern/106999 net [netgraph] [patch] ng_ksocket fails to clear multicast 10 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 1 13:30:42 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C724E16A47C; Mon, 1 Jan 2007 13:30:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9DFF813C455; Mon, 1 Jan 2007 13:30:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l01DUfQ3065815; Mon, 1 Jan 2007 13:30:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l01DUfVK065811; Mon, 1 Jan 2007 13:30:41 GMT (envelope-from linimon) Date: Mon, 1 Jan 2007 13:30:41 GMT From: Mark Linimon Message-Id: <200701011330.l01DUfVK065811@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (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: Mon, 01 Jan 2007 13:30:42 -0000 Old Synopsis: IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 New Synopsis: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 1 13:28:53 UTC 2007 Responsible-Changed-Why: Perhaps someone on -net has an idea. http://www.freebsd.org/cgi/query-pr.cgi?pr=107358 From owner-freebsd-net@FreeBSD.ORG Mon Jan 1 14:22:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10C6416A412 for ; Mon, 1 Jan 2007 14:22:54 +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 422D713C458 for ; Mon, 1 Jan 2007 14:22:53 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 65736 invoked from network); 1 Jan 2007 13:56:10 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 1 Jan 2007 13:56:10 -0000 Received: (nullmailer pid 67044 invoked by uid 136); Mon, 01 Jan 2007 14:00:16 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20061228203100.GA1165@gort.synoptic.org> To: Matthew Hudson Date: Mon, 1 Jan 2007 17:00:16 +0300 (MSK) 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: <1167660016.168305.67043.nullmailer@cicuta.babolo.ru> Cc: Stephan Wehner , freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 14:22:54 -0000 > On Wed, Dec 27, 2006 at 10:08:25PM -0800, Stephan Wehner wrote: ... > Oh, also, going back to the 198.168 address seen in the client dumps, > it's clear that you're going through a NAT firewall or VPN or something > on the way to your server. Thus are you able to reproduce this problem > from a different external network? > > Actually, I just realized that you've provided enough information for me > to run this test myself which I've now done. I ran the following test; > > i=0; while true; do ((i++)); echo $i; curl http://stbgo.org > /dev/null; done > > I was able to make over 64 consecutive connections without a single failure > before I stopped the test (didn't want to spam your site). How sure > are you that this isn't a client-side problem? /usr/ports/net/scand/ designed for such a problem on client side when overactive. From owner-freebsd-net@FreeBSD.ORG Mon Jan 1 17:01:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 303AB16A40F for ; Mon, 1 Jan 2007 17:01:25 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id BEA9613C44B for ; Mon, 1 Jan 2007 17:01:24 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4199622uge for ; Mon, 01 Jan 2007 09:01:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type; b=HRL+HuWYYf8u5hUuX+b+6kPJzfaTn6uat7mWwlgnrgkYbh4waLvOAs82prTCGBwa+jbXUSlZmH96feosm/gXvAxNDdtqYxHBrDGEc7QO6ls2n0+uTn/HrXm6AOdicJ9EBTLWLmPeongRRg52PjbjoWuy1HHZX44BG8hvgDvUG7o= Received: by 10.66.221.6 with SMTP id t6mr24557295ugg.1167669200604; Mon, 01 Jan 2007 08:33:20 -0800 (PST) Received: from ?192.168.123.201? ( [195.241.221.201]) by mx.google.com with ESMTP id l33sm25117365ugc.2007.01.01.08.33.19; Mon, 01 Jan 2007 08:33:19 -0800 (PST) Message-ID: <459937C8.3030506@gmail.com> Date: Mon, 01 Jan 2007 17:33:12 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.9 (X11/20061224) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------040501020001060804030002" Subject: wpi results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jan 2007 17:01:25 -0000 This is a multi-part message in MIME format. --------------040501020001060804030002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I build the wpi driver (version 20061109) on 7.0 CURRENT (20061229). It works fine, but it hangs my laptop after 'a while'. The only thing that keeps working is escaping to ddb. The laptop has the 4222 version of the wpi chipset. Loading it # kldload ./wpi_ucode.ko # kldload ./if_wpi.ko gives a message 'bus_dmamem_alloc failed to align properly' and a LOR (attached). Sometimes it gives a message 'rx tail flags error 702' Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------040501020001060804030002 Content-Type: text/plain; name="wpi-20061109-lor.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="wpi-20061109-lor.txt" lock order reversal: 1st 0xcb1bbb50 wpi0 (network driver) @ if_wpi.c:1549 2nd 0xc0752dac udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:286 KDB: stack backtrace: db_trace_self_wrapper(c0694ada,e7a48a18,c052c795,c0696b95,c0752dac,...) at db_trace_self_wrapper+0x27 kdb_backtrace(c0696b95,c0752dac,c06965b9,c06965b9,c06a0cea,...) at kdb_backtrace+0x2f witness_checkorder(c0752dac,9,c06a0cea,11e,0,...) at witness_checkorder+0x6e4 _mtx_lock_flags(c0752dac,0,c06a0cea,11e,c04f9293,...) at _mtx_lock_flags+0xb9 udp_input(c52c8100,14,c4e78000,1,0,...) at udp_input+0x221 ip_input(c52c8100,c0690e78,c52f782e,c4e78000,c52f782e,...) at ip_input+0x657 netisr_dispatch(2,c52c8100,6,3,0,...) at netisr_dispatch+0x68 ether_demux(c4e78000,c52c8100,3,0,3,9) at ether_demux+0x2e6 ether_input(c4e78000,c52c8100,cb1bba20,c52c8100,18,...) at ether_input+0x26f ieee80211_deliver_data(c52c8100,e7a48c1c,6,18,c052bf63,...) at ieee80211_deliver_data+0x80 ieee80211_input(cb1bb004,c52c8100,c4e06c00,49,0,...) at ieee80211_input+0xb71 wpi_intr(cb1bb000,e7a48cd4,c04eec15,c0703690,1,...) at wpi_intr+0x8e7 ithread_execute_handlers(c59326c0,c4d72800,c068ef3a,30e,c59286c0,...) at ithread_execute_handlers+0x14c ithread_loop(c78907a0,e7a48d38,c068ed1e,328,c59326c0,...) at ithread_loop+0x78 fork_exit(c04e067c,c78907a0,e7a48d38) at fork_exit+0xcc fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe7a48d6c, ebp = 0 --- --------------040501020001060804030002-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 1 21:47:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00BC316A407 for ; Mon, 1 Jan 2007 21:47:40 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 94FB013C448 for ; Mon, 1 Jan 2007 21:47:39 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id l01Lla3e003744; Mon, 1 Jan 2007 21:47:36 GMT Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.13.8/8.13.8) with ESMTP id l01LlamO054843; Mon, 1 Jan 2007 21:47:36 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.13.8/8.13.8/Submit) with ESMTP id l01LlZsR054840; Mon, 1 Jan 2007 21:47:36 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 1 Jan 2007 21:47:35 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Rene Ladan In-Reply-To: <459937C8.3030506@gmail.com> Message-ID: <20070101214540.R44321@ury.york.ac.uk> References: <459937C8.3030506@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-net@freebsd.org Subject: Re: wpi results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Jan 2007 21:47:40 -0000 On Mon, 1 Jan 2007, Rene Ladan wrote: > I build the wpi driver (version 20061109) on 7.0 CURRENT (20061229). It > works fine, but it hangs my laptop after 'a while'. The only thing that > keeps working is escaping to ddb. The laptop has the 4222 version of > the wpi chipset. I'm working on the driver at the moment, and I've a workaround for this hang. I'll send you my newest version of the driver in the next day or two. Gavin From owner-freebsd-net@FreeBSD.ORG Tue Jan 2 04:08:01 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0262416A407 for ; Tue, 2 Jan 2007 04:08:01 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7EDAB13C44C for ; Tue, 2 Jan 2007 04:08:00 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4270188uge for ; Mon, 01 Jan 2007 20:07:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EY8OiWycp2fyt0hNePkVYmqxfm8nlRi0Jwh/zlOX51u5XB7CtSlrR7gaT4oqFV3fpnCtJqmfZqhOdDIC2AG50xSZhOjD9mMrss8mcoumg9wAj2KllAqrKiBYSQ9T5Ntb8OzqKwfkN1ubTJBREojbDeGHJzqq6RWjcn4gosZYHzc= Received: by 10.78.131.8 with SMTP id e8mr1852509hud.1167710879405; Mon, 01 Jan 2007 20:07:59 -0800 (PST) Received: by 10.78.149.5 with HTTP; Mon, 1 Jan 2007 20:07:59 -0800 (PST) Message-ID: Date: Mon, 1 Jan 2007 20:07:59 -0800 From: "Stephan Wehner" To: .@babolo.ru In-Reply-To: <1167660016.168305.67043.nullmailer@cicuta.babolo.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061228203100.GA1165@gort.synoptic.org> <1167660016.168305.67043.nullmailer@cicuta.babolo.ru> Cc: freebsd-net@freebsd.org, Matthew Hudson Subject: Re: Diagnose co-location networking problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 04:08:01 -0000 Hello again, to give a short summary; I contacted this list to ask for help with diagnosing a problem with a co-located server (accessible at http://stbgo.org) running FreeBSD 6.1. When I swamp it with requests (simply, lynx -dump http://stbgo.org > /dev/null in a loop) some responses take 90 seconds -- far too long. This is reproducible, but seemingly not from other source addresses - only my own (home) machine, 64.114.83.92 The recommendations have been to look at the traceroute output, and at tcpdump from both ends; the tcpdump output was so far only available from the client side, since the server's kernel didn't support tcpdump. (Also, to "swamp" a different port and see the result - planned next step) The traceroute brought up a host with name a.core.65-110-0-1.van.data-fortress.com which sits between my server and the Internet. (As far as I can tell, this looks legitimate. The co-location provider says their machines perform no filtering) Traceroute from the client is not available; this service provider blocked it for some reason, and I can live without it. (tcptraceroute was suggested, but that gave no meaningful output; I may try again from a different machine on the local network) Now to where I got in the mean time. I recompiled the server's kernel so that tcpdump is available. Client tcpdump command ----------------------------------------------------------------------------- $ sudo /usr/sbin/tcpdump -n -s 1600 -w clientside.dmp host stbgo.org tcpdump: listening on eth0 398 packets received by filter 0 packets dropped by kernel Server tcpdump command --------------------------------------------------------------- $ sudo /usr/sbin/tcpdump -n -s 1600 -w /tmp/serverside.dmp tcpdump: listening on bge0, link-type EN10MB (Ethernet), capture size 1600 bytes Hm, dispatch protocol error: type 3 plen 4 302 packets captured 303 packets received by filter 0 packets dropped by kernel During the times that these two commands ran, this was executed on the client. Client swamping command ---------------------------------------------------------------- $ ruby o 0 : Mon Jan 01 14:09:38 PST 2007 -- done at Mon Jan 01 14:09:39 PST 2007. Took 0.532589 1 : Mon Jan 01 14:09:39 PST 2007 -- done at Mon Jan 01 14:09:39 PST 2007. Took 0.368819 2 : Mon Jan 01 14:09:39 PST 2007 -- done at Mon Jan 01 14:09:39 PST 2007. Took 0.352839 3 : Mon Jan 01 14:09:39 PST 2007 -- done at Mon Jan 01 14:09:40 PST 2007. Took 0.45799 4 : Mon Jan 01 14:09:40 PST 2007 -- done at Mon Jan 01 14:09:40 PST 2007. Took 0.369304 5 : Mon Jan 01 14:09:40 PST 2007 -- done at Mon Jan 01 14:09:41 PST 2007. Took 0.446588 6 : Mon Jan 01 14:09:41 PST 2007 -- done at Mon Jan 01 14:09:41 PST 2007. Took 0.345532 7 : Mon Jan 01 14:09:41 PST 2007 -- done at Mon Jan 01 14:09:41 PST 2007. Took 0.354955 8 : Mon Jan 01 14:09:41 PST 2007 -- done at Mon Jan 01 14:09:42 PST 2007. Took 0.465013 9 : Mon Jan 01 14:09:42 PST 2007 -- done at Mon Jan 01 14:09:42 PST 2007. Took 0.431748 10 : Mon Jan 01 14:09:42 PST 2007 -- done at Mon Jan 01 14:09:43 PST 2007. Took 0.368716 11 : Mon Jan 01 14:09:43 PST 2007 -- done at Mon Jan 01 14:09:43 PST 2007. Took 0.451658 12 : Mon Jan 01 14:09:43 PST 2007 -- done at Mon Jan 01 14:11:17 PST 2007. Took 93.492797 13 : Mon Jan 01 14:11:17 PST 2007 -- done at Mon Jan 01 14:11:17 PST 2007. Took 0.425495 14 : Mon Jan 01 14:11:17 PST 2007 -- done at Mon Jan 01 14:11:17 PST 2007. Took 0.430457 The "swamping script - o -" accesses the webserver 15 times in a loop without pausing, and records the elapsed time. Note #12 took 93.49 seconds Looking at the tcpdump dump files with tcptrace I find these connection entries --- (Client side) --- Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 398 packets seen, 398 TCP packets traced elapsed wallclock time: 0:00:00.109089, 3648 pkts/sec analyzed trace file elapsed time: 0:02:12.449926 TCP connection info: 16 TCP connections traced: TCP connection 1: host a: sucrose.sugarmotor.net:35012 host b: vps-18-138.virtualprivateservers.ca:pcanywherestat complete conn: no (SYNs: 0) (FINs: 0) first packet: Mon Jan 1 14:09:14.224706 2007 last packet: Mon Jan 1 14:11:26.674632 2007 elapsed time: 0:02:12.449926 total packets: 137 filename: /tmp/clientside.dmp a->b: b->a: total packets: 90 total packets: 47 ack pkts sent: 90 ack pkts sent: 47 pure acks sent: 47 pure acks sent: 0 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 2240 unique bytes sent: 2480 actual data pkts: 43 actual data pkts: 47 actual data bytes: 2240 actual data bytes: 2480 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 43 pushed data pkts: 47 SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0 req 1323 ws/ts: N/Y req 1323 ws/ts: N/Y urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 0 bytes mss requested: 0 bytes max segm size: 224 bytes max segm size: 128 bytes min segm size: 48 bytes min segm size: 32 bytes avg segm size: 52 bytes avg segm size: 52 bytes max win adv: 19856 bytes max win adv: 33304 bytes min win adv: 19856 bytes min win adv: 33304 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 19856 bytes avg win adv: 33304 bytes initial window: 48 bytes initial window: 0 bytes initial window: 1 pkts initial window: 0 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 132.431 secs data xmit time: 132.434 secs idletime max: 99997.8 ms idletime max: 100015.9 ms throughput: 17 Bps throughput: 19 Bps ================================ TCP connection 2: host c: sucrose.sugarmotor.net:35041 host d: vps-18-138.virtualprivateservers.ca:80 complete conn: yes first packet: Mon Jan 1 14:09:38.899996 2007 last packet: Mon Jan 1 14:09:39.215879 2007 elapsed time: 0:00:00.315883 total packets: 17 filename: /tmp/clientside.dmp c->d: d->c: total packets: 9 total packets: 8 ack pkts sent: 8 ack pkts sent: 8 pure acks sent: 5 pure acks sent: 2 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 2500 unique bytes sent: 3750 actual data pkts: 2 actual data pkts: 5 actual data bytes: 2500 actual data bytes: 3750 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 3 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 0 adv wind scale: 1 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 1448 bytes max segm size: 1448 bytes min segm size: 1052 bytes min segm size: 65 bytes avg segm size: 1249 bytes avg segm size: 749 bytes max win adv: 14480 bytes max win adv: 66608 bytes min win adv: 5840 bytes min win adv: 65556 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 9148 bytes avg win adv: 66457 bytes initial window: 2500 bytes initial window: 189 bytes initial window: 2 pkts initial window: 1 pkts ttl stream length: 2500 bytes ttl stream length: 3750 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 0.000 secs data xmit time: 0.026 secs idletime max: 257.0 ms idletime max: 203.1 ms throughput: 7914 Bps throughput: 11871 Bps ===== : : ...12 similar connections... : : TCP connection 14: host aa: sucrose.sugarmotor.net:35053 host ab: vps-18-138.virtualprivateservers.ca:80 complete conn: yes first packet: Mon Jan 1 14:09:43.755058 2007 last packet: Mon Jan 1 14:11:17.122339 2007 elapsed time: 0:01:33.367281 total packets: 23 filename: /tmp/clientside.dmp aa->ab: ab->aa: total packets: 14 total packets: 9 ack pkts sent: 8 ack pkts sent: 9 pure acks sent: 5 pure acks sent: 3 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 2500 unique bytes sent: 3750 actual data pkts: 2 actual data pkts: 5 actual data bytes: 2500 actual data bytes: 3750 rexmt data pkts: 5 rexmt data pkts: 0 rexmt data bytes: 5 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 3 SYN/FIN pkts sent: 6/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 0 adv wind scale: 1 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 1448 bytes max segm size: 1448 bytes min segm size: 1052 bytes min segm size: 65 bytes avg segm size: 1249 bytes avg segm size: 749 bytes max win adv: 14480 bytes max win adv: 66608 bytes min win adv: 5840 bytes min win adv: 66606 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 9148 bytes avg win adv: 66607 bytes initial window: 1448 bytes initial window: 189 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 2500 bytes ttl stream length: 3750 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 0.137 secs data xmit time: 0.027 secs idletime max: 48000.0 ms idletime max: 139.8 ms throughput: 27 Bps throughput: 40 Bps What is TCP Connection 1 about ("PCanywhere"); why for 2 minutes? Could it be the ssh shell which is open at the same time? TCP Connection 14 seems to be the one corresponding to the ca. 90 seconds response time recorded by the ruby command. It is the only one with a line SYN/FIN pkts sent: 6/1 All others have 1/1 in the first column (or 0/0 for the PCAnywhere connection) To match things up, below is the excerpt from the serverside dump for the same connections. Should I look closely into the dump files themselves to see further? What to look for? Or can anything be concluded with this alone? Thanks a lot, and happy new year -- Stephan --- (Server side) --- TCP connection 1: host a: vps-18-138.virtualprivateservers.ca:pcanywherestat host b: zz83092.cipherkey.net:55116 complete conn: no (SYNs: 0) (FINs: 0) first packet: Mon Jan 1 14:13:20.414784 2007 last packet: Mon Jan 1 14:15:00.446913 2007 elapsed time: 0:01:40.032128 total packets: 5 filename: /tmp/serverside.dmp a->b: b->a: total packets: 2 total packets: 3 ack pkts sent: 2 ack pkts sent: 3 pure acks sent: 0 pure acks sent: 2 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 160 unique bytes sent: 224 actual data pkts: 2 actual data pkts: 1 actual data bytes: 160 actual data bytes: 224 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 1 SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0 req 1323 ws/ts: N/Y req 1323 ws/ts: N/Y urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 0 bytes mss requested: 0 bytes max segm size: 128 bytes max segm size: 224 bytes min segm size: 32 bytes min segm size: 224 bytes avg segm size: 79 bytes avg segm size: 223 bytes max win adv: 33304 bytes max win adv: 19856 bytes min win adv: 33304 bytes min win adv: 19856 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 33304 bytes avg win adv: 19856 bytes initial window: 128 bytes initial window: 0 bytes initial window: 1 pkts initial window: 0 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 100.016 secs data xmit time: 0.000 secs idletime max: 100015.6 ms idletime max: 99999.4 ms throughput: 2 Bps throughput: 2 Bps ================================ TCP connection 2: host c: zz83092.cipherkey.net:55402 host d: vps-18-138.virtualprivateservers.ca:80 complete conn: yes first packet: Mon Jan 1 14:13:26.336098 2007 last packet: Mon Jan 1 14:13:26.637267 2007 elapsed time: 0:00:00.301169 total packets: 17 filename: /tmp/serverside.dmp c->d: d->c: total packets: 9 total packets: 8 ack pkts sent: 8 ack pkts sent: 8 pure acks sent: 5 pure acks sent: 2 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 2500 unique bytes sent: 3750 actual data pkts: 2 actual data pkts: 5 actual data bytes: 2500 actual data bytes: 3750 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 3 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 0 adv wind scale: 1 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 1448 bytes max segm size: 1448 bytes min segm size: 1052 bytes min segm size: 65 bytes avg segm size: 1249 bytes avg segm size: 749 bytes max win adv: 14480 bytes max win adv: 66608 bytes min win adv: 5840 bytes min win adv: 65556 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 9148 bytes avg win adv: 66457 bytes initial window: 2500 bytes initial window: 2237 bytes initial window: 2 pkts initial window: 3 pkts ttl stream length: 2500 bytes ttl stream length: 3750 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 0.015 secs data xmit time: 0.017 secs idletime max: 218.1 ms idletime max: 201.4 ms throughput: 8301 Bps throughput: 12451 Bps ========== : : : TCP connection 14: host aa: zz83092.cipherkey.net:55402 host ab: vps-18-138.virtualprivateservers.ca:80 complete conn: yes first packet: Mon Jan 1 14:13:31.191783 2007 last packet: Mon Jan 1 14:15:04.543351 2007 elapsed time: 0:01:33.351567 total packets: 23 filename: /tmp/serverside.dmp aa->ab: ab->aa: total packets: 14 total packets: 9 ack pkts sent: 8 ack pkts sent: 9 pure acks sent: 5 pure acks sent: 3 sack pkts sent: 0 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 0 max sack blks/ack: 0 unique bytes sent: 2500 unique bytes sent: 3750 actual data pkts: 2 actual data pkts: 5 actual data bytes: 2500 actual data bytes: 3750 rexmt data pkts: 5 rexmt data pkts: 0 rexmt data bytes: 5 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 3 SYN/FIN pkts sent: 6/1 SYN/FIN pkts sent: 1/1 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 0 adv wind scale: 1 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 1448 bytes max segm size: 1448 bytes min segm size: 1052 bytes min segm size: 65 bytes avg segm size: 1249 bytes avg segm size: 749 bytes max win adv: 14480 bytes max win adv: 66608 bytes min win adv: 5840 bytes min win adv: 66606 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 9148 bytes avg win adv: 66607 bytes initial window: 1448 bytes initial window: 2237 bytes initial window: 1 pkts initial window: 3 pkts ttl stream length: 2500 bytes ttl stream length: 3750 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 0.131 secs data xmit time: 0.020 secs idletime max: 47998.4 ms idletime max: 141.9 ms throughput: 27 Bps throughput: 40 Bps From owner-freebsd-net@FreeBSD.ORG Tue Jan 2 11:26:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4442116A403 for ; Tue, 2 Jan 2007 11:26:41 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: from web51909.mail.yahoo.com (web51909.mail.yahoo.com [206.190.48.72]) by mx1.freebsd.org (Postfix) with SMTP id D764413C428 for ; Tue, 2 Jan 2007 11:26:40 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: (qmail 94229 invoked by uid 60001); 2 Jan 2007 10:59:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EHLnYOmnBdU33d9TN0/7StQ25eyZ0yT4yxZBt6mL2s4YqyHDD2O9phAaGEBQn6vC+OZ18JCru/eqCpA3ZKVTyW2FQCp+pPZfwSsYFhbUIj4G49vqVhkMF9hKQ2LEJBE9hvZpthwXcHLEPtU7lgLUHEUXfFWkO75isM+JkVo3x8Q= ; Message-ID: <20070102105959.94227.qmail@web51909.mail.yahoo.com> X-YMail-OSG: zWzSraoVM1nJhnKYGOZmFPgZLHaqZOXimj1TJr0RGsPmNB7vrxYTjdl2ZrXEokIuJWOhSziHgvvEv7Q0hUW5sFFTOk0ofy4QRFnOTLocsfoatIlwWtp6ZA-- Received: from [164.164.171.199] by web51909.mail.yahoo.com via HTTP; Tue, 02 Jan 2007 02:59:59 PST Date: Tue, 2 Jan 2007 02:59:59 -0800 (PST) From: ashoke saha To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jan 2007 11:26:41 -0000 Hi , just joined the mailibng list. I was implementing NAT traversal based on the patch and my kernel was panicking because of wrong ipsec config, which it should not whatever be the config. Looks like there is a small issue in the code http://ipsec-tools.sourceforge.net/freebsd6-natt.diff which might already be fixed. Look at the call of the function udp4_espinudp () in udp append. Now under certain circumstances it is possible that udp4_espinudp () calls m_pullup() and it would add a new pkt header to the mbuf chain. But udp_append() is still holding the old head, whose PKTHDR flag is now off. It then sends the pkt further up and kernel does as panic as it does not see PKTHDR flag. ashoke. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Tue Jan 2 11:56:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9670816A407 for ; Tue, 2 Jan 2007 11:56:23 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 315E113C45A for ; Tue, 2 Jan 2007 11:56:22 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4318564uge for ; Tue, 02 Jan 2007 03:56:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=LYcBPJpGAcbhHzdIikwyUZzAZsyZWSK1JC5azwlDd+9bQig6TAaFYq9eIByPFUeTWsT3e/7204kIvC8tUku1pQUFhDCgeEmFJfGDh2lbDMmpJh+vOPMlco8jwVQJK4Fzv9+m3OwIvMKnzKvZQk6cDWCKo5Y9vNJjFxLvsz3E5OM= Received: by 10.67.19.17 with SMTP id w17mr26975674ugi.1167738982055; Tue, 02 Jan 2007 03:56:22 -0800 (PST) Received: from ?192.168.123.201? ( [195.241.221.201]) by mx.google.com with ESMTP id m4sm25923713ugc.2007.01.02.03.56.20; Tue, 02 Jan 2007 03:56:21 -0800 (PST) Message-ID: <459A4862.8080203@gmail.com> Date: Tue, 02 Jan 2007 12:56:18 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.9 (X11/20061224) MIME-Version: 1.0 To: Gavin Atkinson References: <459937C8.3030506@gmail.com> <20070101214540.R44321@ury.york.ac.uk> In-Reply-To: <20070101214540.R44321@ury.york.ac.uk> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: wpi results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jan 2007 11:56:23 -0000 Gavin Atkinson schreef: > On Mon, 1 Jan 2007, Rene Ladan wrote: > >> I build the wpi driver (version 20061109) on 7.0 CURRENT (20061229). It >> works fine, but it hangs my laptop after 'a while'. The only thing that >> keeps working is escaping to ddb. The laptop has the 4222 version of >> the wpi chipset. > > I'm working on the driver at the moment, and I've a workaround for this > hang. I'll send you my newest version of the driver in the next day or > two. > 'after a while' seems to be 'with some modest load' like cvsup / git pull / loading the cvs-ports archives of last December. Thanks for working on it. > Gavin > Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-net@FreeBSD.ORG Tue Jan 2 14:13:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32F5516A40F for ; Tue, 2 Jan 2007 14:13:54 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id E8CB713C459 for ; Tue, 2 Jan 2007 14:13:53 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from jayce.zen.inc (jayce.zen.inc [192.168.1.7]) by smtp.zeninc.net (smtpd) with ESMTP id 0B6D63F38 for ; Tue, 2 Jan 2007 15:13:51 +0100 (CET) Received: by jayce.zen.inc (Postfix, from userid 1000) id 337112E2C4; Tue, 2 Jan 2007 15:13:52 +0100 (CET) Date: Tue, 2 Jan 2007 15:13:52 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070102141351.GA1604@jayce.zen.inc> References: <20070102105959.94227.qmail@web51909.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070102105959.94227.qmail@web51909.mail.yahoo.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jan 2007 14:13:54 -0000 On Tue, Jan 02, 2007 at 02:59:59AM -0800, ashoke saha wrote: > Hi , Hi. > just joined the mailibng list. I was implementing > NAT traversal based on the patch and my kernel was > panicking because of wrong ipsec config, which it > should not whatever be the config. > > Looks like there is a small issue in the code > http://ipsec-tools.sourceforge.net/freebsd6-natt.diff > which might already be fixed. > > Look at the call of the function > udp4_espinudp () in udp append. Now under certain > circumstances it is possible that udp4_espinudp () > calls m_pullup() and it would add a new pkt header to > the mbuf chain. But udp_append() is still holding the > old head, whose PKTHDR flag is now off. It then sends > the pkt further up and kernel does as panic as it does > not see PKTHDR flag. I already fixed "something like that" a few months ago. Are you using the latest version of the patch ? MD5 sum of the patch file should be 510ac07e6aa95d34e1e05da0695e4059, is that what you get ? Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Tue Jan 2 20:01:29 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2765A16A407 for ; Tue, 2 Jan 2007 20:01:29 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 04E5D13C45B for ; Tue, 2 Jan 2007 20:01:28 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Tue, 02 Jan 2007 11:31:04 -0800 X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 99F212AF; Tue, 2 Jan 2007 11:31:04 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 728A42AE; Tue, 2 Jan 2007 11:31:04 -0800 (PST) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ESG03694; Tue, 2 Jan 2007 11:31:03 -0800 (PST) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 840CF69CA3; Tue, 2 Jan 2007 11:31:03 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Jan 2007 11:31:02 -0800 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90302B2E59D@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20061230233343.U745@epsplex.bde.org> Thread-Topic: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] Thread-Index: AccsGMf1wrNyTCYeRKeImBwMyunyAwCggGbQ From: "David Christensen" To: "Bruce Evans" , "Doug Barton" X-WSS-ID: 69846D722CC15700556-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: RE: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Jan 2007 20:01:29 -0000 > These happen under loads that can't be handled, and generally cause > thousands of input errors every second. The hardware records dropped > packets separately from other input errors, but unfortunately=20 > all types > of input errors are counted together in if_ierrors, and I haven't done > more than muck around in ddb to separate them. There are a couple places I can suggest you look to understand if there are any resource limitations being encountered by the controller. The first is register 0x4450 (bits 15:0 for 5700 to 5704 and bits 8:0 for other controllers) which shows the number of internal=20 free RX MBUFs on the controller. (In this case an MBUF is an internal=20 128 byte data structure used by the controller.) This value is especially=20 important on 5700 to 5704 devices since those devices share a pool of=20 MBUFs between the RX and TX data paths, unlike the 5705 and later devices which use separate MBUF pools for RX and TX data. As the value approaches=20 0, the controller will either start to generate pause frames or simply=20 drop packets as specified by the values in registers 0x4410, 0x4414, and 0x4418. If you see ifInDiscards incrementing then this is a definite possibility. You would also see bit 4 of register 0x4400 set if this occurs. I also noticed on -CURRENT that register 0x2c18 was set to a rather high value (0x40). This register controls how many bge_rx_bd's will be fetched at one time. A high value will reduce PCI bus utilization as it will fetch more BD's in a single transaction, but it will increase latency and could potentially deplete the available internal MBUFs as the controller waits for the driver to populate additional bge_rx_bd's. Try using a smaller=20 value such as 0x08. It would be really interesting if you could add a sysctl that would bring out the hardware statistics maintained by the device, similar to what exists in the "bce" driver. With this information we could focus on individual blocks to see where the packet loss is occurring and may be able to come up with more ideas on tuning the controller. > bge also has a "mini" rx ring which FreeBSD doesn't use. I=20 > don't really > understand this or the interaction of the separate rx rings, but hope > that the mini ring can be used to handle small packets and would only > need an mbuf (not an mbuf cluster) for each packet, and with=20 > it and the > jumbo ring the total hardware buffering would be 1024(mini) +=20 > 512(std) + > 256(jumbo), with the 1024-entry event ring only used to communicate > with the host and its size not really limiting buffering. Meeting a > latency requirement of 1024+512 tiny-packet times is much easier than > meeting one of 192 or 20 tiny-packet times. (I only actually saw the > limits of 20 and 192 for full-sized (non jumbo) packets.) Mini rings are only supported by 57XX controllers that support external SSRAM, and the only controller that supports that is the 5700. This=20 feature was never used in production so I wouldn't consider it an option since you'll never find the right hardware to support it. Dave From owner-freebsd-net@FreeBSD.ORG Wed Jan 3 02:33:34 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECC0E16A407; Wed, 3 Jan 2007 02:33:33 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB9213C457; Wed, 3 Jan 2007 02:33:33 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 375345A0FA6; Wed, 3 Jan 2007 13:33:32 +1100 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 82AF48C0D; Wed, 3 Jan 2007 13:33:30 +1100 (EST) Date: Wed, 3 Jan 2007 13:33:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: David Christensen In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90302B2E59D@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <20070103121817.R2083@epsplex.bde.org> References: <09BFF2FA5EAB4A45B6655E151BBDD90302B2E59D@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Doug Barton , net@freebsd.org Subject: RE: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jan 2007 02:33:34 -0000 On Tue, 2 Jan 2007, David Christensen wrote: >> These happen under loads that can't be handled, and generally cause >> thousands of input errors every second. The hardware records dropped >> packets separately from other input errors, but unfortunately >> all types >> of input errors are counted together in if_ierrors, and I haven't done >> more than muck around in ddb to separate them. > > There are a couple places I can suggest you look to understand if there > are any resource limitations being encountered by the controller. I mostly understand the resource limits but not errors caused by mii accesses. The following debugging code: % diff -c2 ./amd64/amd64/io_apic.c~ ./amd64/amd64/io_apic.c % *** ./amd64/amd64/io_apic.c~ Wed Nov 22 03:09:32 2006 % --- ./amd64/amd64/io_apic.c Sun Dec 24 06:50:14 2006 % *************** % *** 2841,2845 **** % --- 2961,2968 ---- % stdcnt++; % if (cur_rx->bge_flags & BGE_RXBDFLAG_ERROR) { % + if (bge_errsrc & 1) % ifp->if_ierrors++; % + if (bge_errsrc & 8) % + printf("errflag %#x\n", cur_rx->bge_error_flag); % bge_newbuf_std(sc, sc->bge_std, m); % continue; gives (except under loads so high that the interrupt handler can't keep up): - no input errors except the ones recorded here - the ones recorded here are always 0x04 (LINK_LOSS). These happen under high loads if and only if at least 1 device register is read in mii code. They are easy to avoid by not calling mii_tick(). Why is FreeBSD polling link status in bge_tick() anyway? I think the interrupt for link status change works on most devices. > The > first is register 0x4450 (bits 15:0 for 5700 to 5704 and bits 8:0 for > other controllers) which shows the number of internal > free RX MBUFs on the controller. (In this case an MBUF is an internal > 128 byte data structure used by the controller.) This value is > especially > important on 5700 to 5704 devices since those devices share a pool of > MBUFs between the RX and TX data paths, unlike the 5705 and later > devices > which use separate MBUF pools for RX and TX data. As the value > approaches > 0, the controller will either start to generate pause frames or simply > drop packets as specified by the values in registers 0x4410, 0x4414, and > > 0x4418. If you see ifInDiscards incrementing then this is a definite > possibility. You would also see bit 4 of register 0x4400 set if this > occurs. Thanks, I'll check that. Contention between RX and TX would explain some other behaviour that I saw and want to avoid. I want to set the parameters to large values under high loads. Nearly 512 descriptors should work for RX, but on a 5701 there is a magic limit of just 20 when TX is combined with RX, and a not so magic limit of 64 less than the number of host RX mbufs for RX only. The magic 20 is remarkably independent of other coalescing parameters, but I think it depends on the details of the loads and the inteaction of all the layers of buffering. ifInDiscards shows this error. Hmm, my original reply to this thread may have covered the main point. ifInDiscards wasn't added to if_ierrors until last January, so the sometimes-huge numbers of errors for packet drops were not reported in RELENG_5. > I also noticed on -CURRENT that register 0x2c18 was set to a rather high > value (0x40). This register controls how many bge_rx_bd's will be > fetched at > one time. A high value will reduce PCI bus utilization as it will fetch > more BD's in a single transaction, but it will increase latency and > could > potentially deplete the available internal MBUFs as the controller waits > for the driver to populate additional bge_rx_bd's. Try using a smaller > value such as 0x08. This seems to be from misreading the data sheet where it says to use a value of /8. The old data sheet that I have emphasizes that the value should be low for the std rx ring and gives a value of 25. The N/8 is for something nearby. Decreasing this to 8 or so changes the above magic 20 to about 28 (not nearly as much increase as the reduction). I couldn't understand what this parameter does from the data sheet -- why is it called a threshold when (as you described it above) it is a burst size? > It would be really interesting if you could add a sysctl that would > bring > out the hardware statistics maintained by the device, similar to what > exists > in the "bce" driver. With this information we could focus on individual > blocks to see where the packet loss is occurring and may be able to come > up with more ideas on tuning the controller. I might get around to that if no one else does. I saw a few more statistics with a Broadcom Windows utility for another machine with a 5705. Not the ones I really wanted to see of course, but they indicated that the FreeBSD side (with a 5701) is working OK, and the WindXP side (with a 5705) is working better in some respects than the 5705 under FreeBSD -- the 5705 can receive at a higher rate than under FreeBSD, until this activity crashes the utility and WinXP. Pause frames don't seem to be working right -- apparently, only WinXP generates them, and I had to turn them off for WinXP to get anywhere near the maximum packet rate. While I'm here I'll ask you why coalescing doesn't work at all on my 5705 (rev A3) under FreeBSD. I use sysctls to tune it on the 5701 and am now writing dynamic tuning. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Jan 3 04:28:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58DDC16A415 for ; Wed, 3 Jan 2007 04:28:05 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: from web51904.mail.yahoo.com (web51904.mail.yahoo.com [206.190.48.67]) by mx1.freebsd.org (Postfix) with SMTP id C1B1513C448 for ; Wed, 3 Jan 2007 04:28:04 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: (qmail 49157 invoked by uid 60001); 3 Jan 2007 04:28:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=afuNdFOKxCfTnwmuW09J3A984JA+xAE0NXMitaOldzgA7YtVhFFHiZlgt22TnDkyMRQ6gO3GVvTDrhHFMPdYKqAok5d730d+PAhDXOWOR7ZQ2DkMtooIb7KU0pEY4EoAGtusYpN/lut+M08j63935ou6SO4so0+n94vDMhrWiIY=; X-YMail-OSG: fPUUTx8VM1lfzXRf1.Tqn4EDm8JWAXOFa07yYvkEJFAJuborRqdV7UlGgrqZ7jlcGit4FTK0htZ6UmauxfIBu5CYYvYo.5uEbD4TNeezsjamECAeE8g0Wg-- Received: from [164.164.171.194] by web51904.mail.yahoo.com via HTTP; Tue, 02 Jan 2007 20:28:01 PST Date: Tue, 2 Jan 2007 20:28:01 -0800 (PST) From: ashoke saha To: VANHULLEBUS Yvan , freebsd-net@freebsd.org In-Reply-To: <20070102141351.GA1604@jayce.zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <369726.48848.qm@web51904.mail.yahoo.com> Cc: Subject: Re: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jan 2007 04:28:05 -0000 not new. 6/7 months old. Also, quite sometime back 1 yr .... looked like there are issues in PFKEY interface in scalibility . if you create more than 300 ipsecpolicy and ipsec SA's PFKEY used to fail as kernel was using one mbuf cluster (2K or 4k dont remmember) for each policy or SA. That way it was running out of mbuf cluster limit for process. maybe that is also fixed. ashoke. --- VANHULLEBUS Yvan wrote: > On Tue, Jan 02, 2007 at 02:59:59AM -0800, ashoke > saha wrote: > > Hi , > > Hi. > > > > just joined the mailibng list. I was implementing > > > NAT traversal based on the patch and my kernel was > > panicking because of wrong ipsec config, which it > > should not whatever be the config. > > > > Looks like there is a small issue in the code > > > http://ipsec-tools.sourceforge.net/freebsd6-natt.diff > > > which might already be fixed. > > > > Look at the call of the function > > udp4_espinudp () in udp append. Now under certain > > circumstances it is possible that udp4_espinudp () > > calls m_pullup() and it would add a new pkt header > to > > the mbuf chain. But udp_append() is still holding > the > > old head, whose PKTHDR flag is now off. It then > sends > > the pkt further up and kernel does as panic as it > does > > not see PKTHDR flag. > > I already fixed "something like that" a few months > ago. > > Are you using the latest version of the patch ? > > MD5 sum of the patch file should be > 510ac07e6aa95d34e1e05da0695e4059, > is that what you get ? > > > > Yvan. > > -- > NETASQ > http://www.netasq.com > _______________________________________________ > 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" > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Wed Jan 3 08:07:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A94716A403 for ; Wed, 3 Jan 2007 08:07:09 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id D2B6213C455 for ; Wed, 3 Jan 2007 08:07:08 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 46C613F17; Wed, 3 Jan 2007 09:07:05 +0100 (CET) Date: Wed, 3 Jan 2007 09:07:05 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070103080704.GA486@zen.inc> References: <20070102141351.GA1604@jayce.zen.inc> <369726.48848.qm@web51904.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <369726.48848.qm@web51904.mail.yahoo.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jan 2007 08:07:09 -0000 On Tue, Jan 02, 2007 at 08:28:01PM -0800, ashoke saha wrote: > not new. 6/7 months old. Ok, please try with the latest version of the patch, it should be fixed. > Also, quite sometime back 1 yr .... looked like there > are issues in PFKEY interface in scalibility . if you > create more than 300 ipsecpolicy and ipsec SA's PFKEY > used to fail as kernel was using one mbuf cluster (2K > or 4k dont remmember) for each policy or SA. That way > it was running out of mbuf cluster limit for process. Yep. > maybe that is also fixed. There is no public patch afaik. However, I have 2 solutions to fix that: - There is a "bug" in a macro in socket code. basically, some long vars are converted to ints to make some checks, then the result is converted to a long again. I already posted a quick patch here a few monthes ago, I'll send it as a pr as soon as I'll have time to do a complete and clean fix (I don't remember exactly what , but I noticed that some calls to that macro would need to be fixed when the macro is fixed). This solution reduces the problem, but doesn't really fix it (but there is *really* a bug which needs to be fixed here). - The way SPD / SAs are dumped between kernel/userland is ugly, because you use 1 message for each entry. We solved the problem by creating a custom PFKey request: userland sends a buffer address/size to the kernel, and the kernel will fill this buffer with results, then will send ONE message to the userland, with the used size. This works well, but is really not RFC compliant ! Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Wed Jan 3 09:54:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B362E16A40F for ; Wed, 3 Jan 2007 09:54:05 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: from web51909.mail.yahoo.com (web51909.mail.yahoo.com [206.190.48.72]) by mx1.freebsd.org (Postfix) with SMTP id 6B17E13C44B for ; Wed, 3 Jan 2007 09:54:05 +0000 (UTC) (envelope-from ashoke@rocketmail.com) Received: (qmail 42191 invoked by uid 60001); 3 Jan 2007 09:54:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2eoXPXnJzVeMBCd7YRaAZcdvBy+D9zTrykZ67GLupnXHoZbLi0GLjLQ8zEejO5DLYpceqHd78cuqHJOaeZ1hKzgvOCZ7elJUKEVUcoC5ucpbYIqylVeBzedjJyAnS0qzGO3kWd//RMJM/NaUDedJkTT9mAY6qFHZgtOxH6v1dIc= ; Message-ID: <20070103095404.42189.qmail@web51909.mail.yahoo.com> X-YMail-OSG: EnuSqlEVM1ms6SudV1G6oPKtleZeluPGw7rw0L9G1dSd3y8rSctQ5pDnQZADXqmgWbpPVM21iuo5zoL9JbY6AFhBTm2wUCfOlkMKDB3v7NeNta0ufnIMag-- Received: from [164.164.171.194] by web51909.mail.yahoo.com via HTTP; Wed, 03 Jan 2007 01:54:04 PST Date: Wed, 3 Jan 2007 01:54:04 -0800 (PST) From: ashoke saha To: VANHULLEBUS Yvan , freebsd-net@freebsd.org In-Reply-To: <20070103080704.GA486@zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Jan 2007 09:54:05 -0000 yes, i also did my own pvt patch . i think PFKEY needs to be modified for scalability . We should be able to send multiple commands, SPIs, policy id and different actions for each etc. ashoke. --- VANHULLEBUS Yvan wrote: > On Tue, Jan 02, 2007 at 08:28:01PM -0800, ashoke > saha wrote: > > not new. 6/7 months old. > > Ok, please try with the latest version of the patch, > it should be > fixed. > > > > Also, quite sometime back 1 yr .... looked like > there > > are issues in PFKEY interface in scalibility . if > you > > create more than 300 ipsecpolicy and ipsec SA's > PFKEY > > used to fail as kernel was using one mbuf cluster > (2K > > or 4k dont remmember) for each policy or SA. That > way > > it was running out of mbuf cluster limit for > process. > > Yep. > > > > maybe that is also fixed. > > There is no public patch afaik. > > However, I have 2 solutions to fix that: > > - There is a "bug" in a macro in socket code. > basically, some long > vars are converted to ints to make some checks, > then the result is > converted to a long again. I already posted a > quick patch here a few > monthes ago, I'll send it as a pr as soon as I'll > have time to do a > complete and clean fix (I don't remember exactly > what , but I > noticed that some calls to that macro would need > to be fixed when > the macro is fixed). This solution reduces the > problem, but doesn't > really fix it (but there is *really* a bug which > needs to be fixed > here). > > - The way SPD / SAs are dumped between > kernel/userland is ugly, > because you use 1 message for each entry. We > solved the problem by > creating a custom PFKey request: userland sends a > buffer > address/size to the kernel, and the kernel will > fill this buffer > with results, then will send ONE message to the > userland, with the > used size. This works well, but is really not RFC > compliant ! > > > > Yvan. > > -- > NETASQ > http://www.netasq.com > _______________________________________________ > 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" > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Thu Jan 4 07:24:05 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 822E516A40F; Thu, 4 Jan 2007 07:24:05 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5954C13C442; Thu, 4 Jan 2007 07:24:05 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l047O5Os082007; Thu, 4 Jan 2007 07:24:05 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l047O5Yb082003; Thu, 4 Jan 2007 07:24:05 GMT (envelope-from remko) Date: Thu, 4 Jan 2007 07:24:05 GMT From: Remko Lodder Message-Id: <200701040724.l047O5Yb082003@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: i386/107504: Page Fault when attempting to run most network applications (sshd, sendmail, etc) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jan 2007 07:24:05 -0000 Synopsis: Page Fault when attempting to run most network applications (sshd, sendmail, etc) Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Jan 4 07:23:32 UTC 2007 Responsible-Changed-Why: Hello Networking team, can you please have a look at the reported issues. http://www.freebsd.org/cgi/query-pr.cgi?pr=107504 From owner-freebsd-net@FreeBSD.ORG Thu Jan 4 08:47:45 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 297FE16A47B; Thu, 4 Jan 2007 08:47:45 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1955813C457; Thu, 4 Jan 2007 08:47:45 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (delphij@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l048liYA093014; Thu, 4 Jan 2007 08:47:44 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l048liZ7093010; Thu, 4 Jan 2007 08:47:44 GMT (envelope-from delphij) Date: Thu, 4 Jan 2007 08:47:44 GMT From: Xin LI Message-Id: <200701040847.l048liZ7093010@freefall.freebsd.org> To: havenster@gmail.com, delphij@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: i386/107504: Page Fault when attempting to run most network applications (sshd, sendmail, etc) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jan 2007 08:47:45 -0000 Synopsis: Page Fault when attempting to run most network applications (sshd, sendmail, etc) State-Changed-From-To: open->feedback State-Changed-By: delphij State-Changed-When: Thu Jan 4 08:41:55 UTC 2007 State-Changed-Why: Hi, Haven, I think this is a known and fixed issue. Would you please confirm that your src/sys/netinet/tcp_subr.c is 1.228.2.13 or higher? If it is not, and you have src/sys/netinet/tcp_subr.c:1.228.2.12 *and* you have src/sys/netinet/tcp_usrreq.c:1.124.2.5, please re-cvsup your source tree and rebuild/install kernel. If you are not able to do cvsup, please manually apply the patch available at: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_subr.c.diff?r1=1.228.2.12&r2=1.228.2.13 http://www.freebsd.org/cgi/query-pr.cgi?pr=107504 From owner-freebsd-net@FreeBSD.ORG Thu Jan 4 08:48:05 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32EB216A40F; Thu, 4 Jan 2007 08:48:05 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0C31513C441; Thu, 4 Jan 2007 08:48:05 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (delphij@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l048m4lH093059; Thu, 4 Jan 2007 08:48:04 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l048m4s4093055; Thu, 4 Jan 2007 08:48:04 GMT (envelope-from delphij) Date: Thu, 4 Jan 2007 08:48:04 GMT From: Xin LI Message-Id: <200701040848.l048m4s4093055@freefall.freebsd.org> To: delphij@FreeBSD.org, freebsd-net@FreeBSD.org, delphij@FreeBSD.org Cc: Subject: Re: i386/107504: Page Fault when attempting to run most network applications (sshd, sendmail, etc) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jan 2007 08:48:05 -0000 Synopsis: Page Fault when attempting to run most network applications (sshd, sendmail, etc) Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Thu Jan 4 08:47:51 UTC 2007 Responsible-Changed-Why: Handle this. http://www.freebsd.org/cgi/query-pr.cgi?pr=107504 From owner-freebsd-net@FreeBSD.ORG Thu Jan 4 18:56:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45EAA16A506 for ; Thu, 4 Jan 2007 18:56:28 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id EEEF413C45E for ; Thu, 4 Jan 2007 18:56:27 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 2973BEB5B6A for ; Fri, 5 Jan 2007 02:56:27 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id VjHX3lZUYBlg for ; Fri, 5 Jan 2007 02:56:15 +0800 (CST) Received: from [192.168.1.32] (unknown [221.217.208.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id D5FDAEB58FC for ; Fri, 5 Jan 2007 02:56:15 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:x-enigmail-version:content-type; b=BPQZ30Fx9ebcGvXetzgmOAP8OGMd+mnpV1rE0o9VtsgPBq3z0LWu8iYjq8NlPmqWr MNh8noYCc2n6xb+PQPEPg== Message-ID: <459D4D88.2030708@delphij.net> Date: Fri, 05 Jan 2007 02:55:04 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigE8E5B60124D080CEC28E3C00" Subject: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Jan 2007 18:56:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE8E5B60124D080CEC28E3C00 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear colleagues, I have a strange question about our way of handling INADDR_BROADCAST, the behavior looks different from all other operating systems I have tried, except Mac OS X ;-) By ping'ing 255.255.255.255 from FreeBSD (mostly RELENG_6 with some unrelated patches) or Mac OS X, I got response from another subnet (I guess that there is some configuration problem in the network, though), but no boxes (running various operating systems) on local network responds the ping. However, with OpenBSD, Linux and Windows, ping'ing 255.255.255.255 would get response from local network. Just curious why there is such difference. Literally, I think INADDR_BROADCAST is supposed to reach local network nodes, no? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enigE8E5B60124D080CEC28E3C00 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnU2IOfuToMruuMARA7W5AJ4+h4Hwd5AQxMOAo1hderRpNGVLFACfRORw ANomTBdSE7dEsT2ktkE10LU= =8q9u -----END PGP SIGNATURE----- --------------enigE8E5B60124D080CEC28E3C00-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 4 19:34:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33E0D16A403 for ; Thu, 4 Jan 2007 19:34:17 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: from gort.synoptic.org (gort.synoptic.org [216.254.17.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1790613C457 for ; Thu, 4 Jan 2007 19:34:17 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: by gort.synoptic.org (Postfix, from userid 1000) id D1FD26352885; Thu, 4 Jan 2007 11:34:16 -0800 (PST) Date: Thu, 4 Jan 2007 11:34:16 -0800 From: Matthew Hudson To: Stephan Wehner , freebsd-net@freebsd.org Message-ID: <20070104193416.GA47635@gort.synoptic.org> References: <20061228203100.GA1165@gort.synoptic.org> <1167660016.168305.67043.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: Diagnose co-location networking problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 19:34:17 -0000 On Mon, Jan 01, 2007 at 08:07:59PM -0800, Stephan Wehner wrote: > Hello again, > > to give a short summary; I contacted this list to ask for help with > diagnosing a problem with a co-located server (accessible at > http://stbgo.org) running FreeBSD 6.1. When I swamp it with requests > (simply, lynx -dump http://stbgo.org > /dev/null in a loop) > some responses take 90 seconds -- far too long. This is reproducible, > but seemingly not from other source addresses - only my own (home) > machine, 64.114.83.92 Stephan, I haven't yet looked at the new data you've reported because of the last point that you mention, the point that I brought up in my previous email, is of critical importance. There is currently evidence that suggests the possibility that this problem is not reproduceable from anywhere but your home network. If that is indeed the case then what you have is likely not a problem with the FreeBSD networking code on your colocated box but rather a problem with your home network. If so, then this is the wrong forum to seek assistance in troubleshooting a non-FreeBSD networking problem. Before we can meaningfully assist you with your issue here, we're going to need to see evidence that shifts the finger of blame back towards the FreeBSD networking code and away from your home network where it is currently pointing. cheers, -- Matthew Hudson From owner-freebsd-net@FreeBSD.ORG Fri Jan 5 06:33:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D37216A407 for ; Fri, 5 Jan 2007 06:33:19 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 07DB313C45D for ; Fri, 5 Jan 2007 06:33:18 +0000 (UTC) (envelope-from stephanwehner@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so7738031nfc for ; Thu, 04 Jan 2007 22:33:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cet4+yA7DVjj2ToyzxTAm+i9aOYpspnqv8LQND+3RavpfU4nQT2xEVwrTA3R6pwMQ3Oy42P1/L1StM6ysq3HVAFp9u7efk0Yx+5upgF6yhRD0yAmXLo9k/Mb27O6JI+LfrJ6RAKl9aaO2bQr/NMblC2huIFAK0+OXDoj/NeQmek= Received: by 10.78.181.13 with SMTP id d13mr6136036huf.1167978797778; Thu, 04 Jan 2007 22:33:17 -0800 (PST) Received: by 10.78.149.5 with HTTP; Thu, 4 Jan 2007 22:33:17 -0800 (PST) Message-ID: Date: Thu, 4 Jan 2007 22:33:17 -0800 From: "Stephan Wehner" To: "Matthew Hudson" In-Reply-To: <20070104193416.GA47635@gort.synoptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061228203100.GA1165@gort.synoptic.org> <1167660016.168305.67043.nullmailer@cicuta.babolo.ru> <20070104193416.GA47635@gort.synoptic.org> Cc: freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2007 06:33:19 -0000 > Stephan, > > I haven't yet looked at the new data you've reported because of the > last point that you mention, the point that I brought up in my > previous email, is of critical importance. There is currently > evidence that suggests the possibility that this problem is not > reproduceable from anywhere but your home network. If that is indeed > the case then what you have is likely not a problem with the FreeBSD > networking code on your colocated box but rather a problem with > your home network. If so, then this is the wrong forum to seek > assistance in troubleshooting a non-FreeBSD networking problem. Yes, it does look like that - a problem at my home end. Thanks a lot for the assistance! Stephan > Before we can meaningfully assist you with your issue here, we're > going to need to see evidence that shifts the finger of blame > back towards the FreeBSD networking code and away from your home > network where it is currently pointing. > > cheers, > -- > Matthew Hudson > > -- Stephan Wehner > http://stephan.sugarmotor.org > http://stephansmap.org > http://www.trafficlife.com > http://www.buckmaster.ca From owner-freebsd-net@FreeBSD.ORG Fri Jan 5 09:42:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0062A16A412 for ; Fri, 5 Jan 2007 09:42:49 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id B4E8C13C455 for ; Fri, 5 Jan 2007 09:42:49 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 18DDE3F17; Fri, 5 Jan 2007 10:42:48 +0100 (CET) Date: Fri, 5 Jan 2007 10:42:47 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070105094247.GA29706@zen.inc> References: <20070103080704.GA486@zen.inc> <20070103095404.42189.qmail@web51909.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070103095404.42189.qmail@web51909.mail.yahoo.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jan 2007 09:42:50 -0000 On Wed, Jan 03, 2007 at 01:54:04AM -0800, ashoke saha wrote: > yes, i also did my own pvt patch . i think PFKEY needs > to be modified for scalability . We should be able to > send multiple commands, SPIs, policy id and different > actions for each etc. Some kind of "PFKeyV3" would allow such changes, and would also have another advantage: standardization of lots of common extensions. But it would be a really heavy work to do that, and I guess IETF people will answer something like "ike is dead, ikev2 is the future".... Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 5 11:34:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 168F616A403 for ; Fri, 5 Jan 2007 11:34:52 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C844313C441 for ; Fri, 5 Jan 2007 11:34:51 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1H2nLT-000DRQ-LA; Fri, 05 Jan 2007 14:34:47 +0300 Date: Fri, 5 Jan 2007 14:34:42 +0300 From: Eygene Ryabinkin To: LI Xin Message-ID: <20070105113442.GH37482@codelabs.ru> References: <459D4D88.2030708@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <459D4D88.2030708@delphij.net> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jan 2007 11:34:52 -0000 Li, good day! > By ping'ing 255.255.255.255 from FreeBSD (mostly RELENG_6 with some > unrelated patches) or Mac OS X, I got response from another subnet (I > guess that there is some configuration problem in the network, though), > but no boxes (running various operating systems) on local network > responds the ping. > > However, with OpenBSD, Linux and Windows, ping'ing 255.255.255.255 would > get response from local network. I can provide an insight into the packets seen, but no real explanation if thigs should go that way at this time. When FBSD is pinging 0xffffffff it does not use the Ethernet broadcasts, when the link-level destination MAC is set to 0xffffffffffff, using some 'known MAC' instead. For the network broadcast address -- it does use link-level broadcasts. For me the 'known MAC' is that of our border router that serves as the default destination. And my box doing the ARP request for the precisely the IP of the router before pinging 255.255.255.255. You can try to empty your ARP table and then ping 255.255.255.255 watching for the ARP requests and the link-level header of the ICMP packets. > Just curious why there is such difference. Literally, I think > INADDR_BROADCAST is supposed to reach local network nodes, no? I should have a look into the sources -- may be there are some hints why it works this way. -- Eygene From owner-freebsd-net@FreeBSD.ORG Fri Jan 5 16:20:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 714D916A5CD for ; Fri, 5 Jan 2007 16:20:32 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C30A813C4A6 for ; Fri, 5 Jan 2007 16:20:31 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from twilight.mbslab.kiae.ru (twilight.mbslab.kiae.ru [144.206.177.41]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1H2rnu-000Dig-Pe; Fri, 05 Jan 2007 19:20:27 +0300 Date: Fri, 5 Jan 2007 19:20:22 +0300 From: Eygene Ryabinkin To: LI Xin Message-ID: <20070105162022.GA1503@twilight.mbslab.kiae.ru> References: <459D4D88.2030708@delphij.net> <20070105113442.GH37482@codelabs.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20070105113442.GH37482@codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jan 2007 16:20:32 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline I am CC'ing this message to Gleb Smirnov. Gleb, my apologies if you're not interested in this stuff. > When FBSD is pinging 0xffffffff it does not use the Ethernet broadcasts, > when the link-level destination MAC is set to 0xffffffffffff, using some > 'known MAC' instead. For the network broadcast address -- it does use > link-level broadcasts. > > For me the 'known MAC' is that of our border router that serves as > the default destination. And my box doing the ARP request for the > precisely the IP of the router before pinging 255.255.255.255. You can > try to empty your ARP table and then ping 255.255.255.255 watching > for the ARP requests and the link-level header of the ICMP packets. OK, I've found that in order to ping undirected broadcast address one should add some functionality to the 'ping' utility. The explanation of the behaviour you notes is the following: when ping is requesting 255.255.255.255 as the destination the IP layer does the lookup the route for the 255.255.255.255. In my case the route lookup yielded 'default destination'. And the code in the /sys/netinet/ip_output.c do no checks for the broadcast address if the looked up destination is the gateway (lines 257-258 in the revision 1.242.2.17). So the packet was not recognised as the broadcast and was sent with the destination MAC of the gateway. Our gateway responds to such packets. Your probably responds too. > > Just curious why there is such difference. Literally, I think > > INADDR_BROADCAST is supposed to reach local network nodes, no? Yes, the appendix II of the STD0005 (RFC 791) specifies that it is the case: the packet should go to all hosts 'on the wire'. I've prepared the patch for the ping (RELENG-6, 6.2-PRERELEASE) that adds '-b' option that permits to ping to 255.255.255.255. An argument to '-b' specifies the broadcast address of the interface that will be used for the transmission. If you're interested, please, test the patch. I see one caveat now: no Linux stations respond to my pings with '-b' option. I will try to see why, but later. One use-case for the '-b' is the following: suppose you're on the unknown network in which you know some IPs, but the netmask is not known or you see the errorneous netmask. Then setting the netmask to some value and pinging to the resulting network broadcast will not reveal hosts in the local network. But using '-b' with the resulting network broadcast address and the 255.255.255.255 as the destination will do the work. -- Eygene --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="broadcast.patch" --- /usr/src/sbin/ping/ping.c.orig Fri Jan 5 17:11:24 2007 +++ /usr/src/sbin/ping/ping.c Fri Jan 5 18:48:54 2007 @@ -144,6 +144,7 @@ #define F_TIME 0x100000 #define F_SWEEP 0x200000 #define F_WAITTIME 0x400000 +#define F_BIF 0x800000 /* * MAX_DUP_CHK is the number of bits in received table, i.e. the maximum @@ -219,7 +220,7 @@ char *const *argv; { struct sockaddr_in from, sock_in; - struct in_addr ifaddr; + struct in_addr ifaddr, bifaddr; struct timeval last, intvl; struct iovec iov; struct ip *ip; @@ -264,7 +265,7 @@ outpack = outpackhdr + sizeof(struct ip); while ((ch = getopt(argc, argv, - "Aac:DdfG:g:h:I:i:Ll:M:m:nop:QqRrS:s:T:t:vW:z:" + "Aab:c:DdfG:g:h:I:i:Ll:M:m:nop:QqRrS:s:T:t:vW:z:" #ifdef IPSEC #ifdef IPSEC_POLICY_IPSEC "P:" @@ -279,6 +280,13 @@ case 'a': options |= F_AUDIBLE; break; + case 'b': + if (inet_aton(optarg, &bifaddr) == 0) + errx(EX_USAGE, + "invalid broadcast interface: `%s'", + optarg); + options |= F_BIF; + break; case 'c': ultmp = strtoul(optarg, &ep, 0); if (*ep || ep == optarg || ultmp > LONG_MAX || !ultmp) @@ -584,6 +592,8 @@ && !IN_MULTICAST(ntohl(to->sin_addr.s_addr))) errx(EX_USAGE, "-I, -L, -T flags cannot be used with unicast destination"); + if ((options & F_MIF) && (options & F_BIF)) + errx(EX_USAGE, "-b and -I: incompatible options"); if (datalen >= TIMEVAL_LEN) /* can we time transfer */ timing = 1; @@ -605,6 +615,21 @@ if (options & F_SO_DONTROUTE) (void)setsockopt(s, SOL_SOCKET, SO_DONTROUTE, (char *)&hold, sizeof(hold)); + if (to->sin_addr.s_addr == INADDR_BROADCAST) { + if ((options & F_BIF) == 0) { + errx(EX_USAGE, + "Broadcast ping requested, but '-b' option was not given"); + } + /* Should instruct IP stack to use broadcast destination. */ + if (setsockopt(s, IPPROTO_IP, IP_ONESBCAST, (char *)&hold, + sizeof(hold)) < 0) { + errx(EX_OSERR, + "setsockopt(IPPROTO_IP, IP_ONESBCAST) failed"); + } + bcopy(&bifaddr, &(whereto.sin_addr), sizeof(whereto.sin_addr)); + printf("WARNING: will ping to broadcast address using %s.\n", + inet_ntoa(bifaddr)); + } #ifdef IPSEC #ifdef IPSEC_POLICY_IPSEC if (options & F_POLICY) { --- /usr/src/sbin/ping/ping.8.orig Fri Jan 5 18:48:10 2007 +++ /usr/src/sbin/ping/ping.8 Fri Jan 5 18:55:50 2007 @@ -39,6 +39,7 @@ .Sh SYNOPSIS .Nm .Op Fl AaDdfnoQqRrv +.Op Fl b Ar bcastaddr .Op Fl c Ar count .Op Fl G Ar sweepmaxsize .Op Fl g Ar sweepminsize @@ -112,6 +113,12 @@ character in the output when any packet is received. This option is ignored if other format options are present. +.It Fl b Ar bcastaddr +Ping to the broadcast address (255.255.255.255). Argument +.Ar bcastaddr +specifies the broadcast address of the interface that will be +used for transmission. This option is mutually exclusive with +.Fl I . .It Fl c Ar count Stop after sending (and receiving) @@ -165,6 +172,8 @@ .It Fl I Ar iface Source multicast packets with the given interface address. This flag only applies if the ping destination is a multicast address. +This option is mutually exclusive with +.Fl b . .It Fl i Ar wait Wait .Ar wait --y0ulUmNC+osPPQO6-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 6 19:05:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FEB316A403 for ; Sat, 6 Jan 2007 19:05:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id EBD7A13C459 for ; Sat, 6 Jan 2007 19:05:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 08D375DF5D; Sat, 6 Jan 2007 13:40:09 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sat, 06 Jan 2007 13:40:09 -0500 X-Sasl-enc: 52f3AFkGGpejYgV2JmfEtSRzLlfN0t4TndTHuOu5VQaA 1168108808 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D6754130F2; Sat, 6 Jan 2007 13:40:07 -0500 (EST) Message-ID: <459FEDBC.4070008@FreeBSD.org> Date: Sat, 06 Jan 2007 18:43:08 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: LI Xin References: <459D4D88.2030708@delphij.net> In-Reply-To: <459D4D88.2030708@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jan 2007 19:05:24 -0000 LI Xin wrote: > Dear colleagues, > > I have a strange question about our way of handling INADDR_BROADCAST, > the behavior looks different from all other operating systems I have > tried, except Mac OS X ;-) > > By ping'ing 255.255.255.255 from FreeBSD (mostly RELENG_6 with some > unrelated patches) or Mac OS X, I got response from another subnet (I > guess that there is some configuration problem in the network, though), > but no boxes (running various operating systems) on local network > responds the ping. > > However, with OpenBSD, Linux and Windows, ping'ing 255.255.255.255 would > get response from local network. > > Just curious why there is such difference. Literally, I think > INADDR_BROADCAST is supposed to reach local network nodes, no? > With FreeBSD's stack, sending packets to the undirected broadcast address INADDR_BROADCAST will result in the first ifnet with IPv4 configured and IFF_BROADCAST set being selected as the source ifnet. See ip_output.c for details. In my local network, pinging 255.255.255.255 from my FreeBSD laptop (running 6.2-RC1) results in a single unicast ICMP reply from the edge router, with its source address on the same LAN. The IP_SENDONES socket option may be used to select the source interface for undirected broadcasts, by sending to a directed broadcast address. The stack will munge the directed address to 255.255.255.255 before it goes on the wire. This came from BSD/OS; See ip(4) for details. You might want to take a look at NetBSD's stack, which has recently had IPv4 source address selection logic added to it to support schemes such as link-local addressing (Zeroconf/Rendezvous). It would be great if someone had time to look at this and perhaps port it. Regards, BMS