From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 04:18:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01377106566B for ; Fri, 7 Mar 2008 04:18:56 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: from ards.ru (mail.ards.ru [212.76.164.163]) by mx1.freebsd.org (Postfix) with SMTP id C519F8FC13 for ; Fri, 7 Mar 2008 04:18:54 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: (qmail 6531 invoked by uid 0); 7 Mar 2008 09:18:51 +0500 Received: from (10.1.201.55); 7 Mar 2008 04:18:51 -0000 X-lion-scan: 0 X-lion-envelope: F_lion_2000@mail.ru Tfreebsd-net@freebsd.org X-RELAYCLIENT: 1 Received: from wtm-ards-itoa01.net.ards.corp (HELO wtmardsITOA01) (10.1.201.55) by mail.net.ards.corp with SMTP; 7 Mar 2008 09:18:51 +0500 From: "Sergey" <_lion_2000@mail.ru> To: References: <000001c87f43$c8075800$37c9010a@Net.ARDS.Corp> <20080306161818.GD15130@verio.net> Date: Fri, 7 Mar 2008 09:18:51 +0500 Message-ID: <001101c8800a$596d4220$37c9010a@Net.ARDS.Corp> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080306161818.GD15130@verio.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach/qQPMwdmhNDt7SEKSSxXiz74OOgAYPJnA Subject: RE: Path MTU 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, 07 Mar 2008 04:18:58 -0000 > Is it possible that you have PF or IPFW filter rules in place > that drop ICMP? Just because tcpdump shows you the frame > arrived at your system, does not mean that it was "seen" by > the kernel. No, it's virgin clean install, without any packet filtering enabled > > here comes icmp frag packets. strange what sometimes > tcpdump complains > > about tcp header in icmp packet and sometimes not > > The reason for this complaint is that frag_needed packets > return a portion of the original IP frame back to the sender, > but the number of bytes is not sufficient to see the entire > TCP header. However, there is enough to see the src/dest > IP's and src/dest port numbers, as tcpdump shows you. But > tcpdump cannot decode past the end of the returned frame, so > it shows an error. I c