From owner-freebsd-stable@FreeBSD.ORG Wed Jul 25 00:00:07 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA84D16A419 for ; Wed, 25 Jul 2007 00:00:07 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout06.prod.mesa1.secureserver.net (smtpout06-04.prod.mesa1.secureserver.net [64.202.165.227]) by mx1.freebsd.org (Postfix) with SMTP id 961DC13C46C for ; Wed, 25 Jul 2007 00:00:07 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 4803 invoked from network); 25 Jul 2007 00:00:06 -0000 Received: from unknown (24.144.77.243) by smtpout06-04.prod.mesa1.secureserver.net (64.202.165.227) with ESMTP; 25 Jul 2007 00:00:05 -0000 Message-ID: <46A69285.1030801@seclark.us> Date: Tue, 24 Jul 2007 20:00:05 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexey Karagodov References: <469624D1.20108@seclark.us> <4696823B.9020107@seclark.us> <46969129.60409@seclark.us> <3C09F7E4-C15A-4B9E-94A3-C4997C73C0BD@mac.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: pmtud + ipnat RELENG_6_2 appears to be broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 00:00:07 -0000 Alexey Karagodov wrote: > is there any progress? > > just one "me too" > > this problem appeared for me when i try to use vlan over lagg ( to em > NICs ) > > thanx > kernel: vlan301: discard oversize frame (ether type 800 flags 3 len > 1514 > max 1510) > > > > 2007/7/13, Chuck Swiger >: > > On Jul 12, 2007, at 1:38 PM, Stephen Clark wrote: > >> The MTU is actually defined in reference to a network segment such > >> as an "ethernet collision domain", and applies to all machines > >> sending traffic to that segment. If the MTU is really 1280, > >> nobody else should be sending larger packets, and the drivers > >> will drop any larger packets they receive and generate the > >> appropriate ICMP error.... > > > > First thanks for responding but thats the problem, > > this did't generate an icmp when the packet was dropped. > > > > kernel: rl0: discard oversize frame (ether type 800 flags 3 len > > 1514 > max > > 1294) > > > > This message did not result in any icmp packet. > > > > I was running tcpdump looking for them. > > Taking a quick look at ether_input() in src/sys/net/if_ethersubr.c > suggests that you are right-- if the incoming packet exceeds the MTU > being set, the input errors count for that interface is incremented, > but no ICMP_UNREACH_NEEDFRAG is generated even if DF flag is set. > > You might file a PR and see whether you can get Andre or one of the > other networking gurus interested in fixing this. Or maybe I'll give > it a try myself if I can get some free time.... :-) > > -- > -Chuck > > > _______________________________________________ > freebsd-stable@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org " > > No progress - still being discussed on freebsd-net mailing list as: Re: 6.2 mtu now limits size of incomming packet Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)