Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jul 2007 12:44:02 +1200
From:      Andrew Thompson <thompsa@FreeBSD.org>
To:        Alexey Karagodov <karagodov@gmail.com>
Cc:        Stephen.Clark@seclark.us, freebsd-stable@freebsd.org
Subject:   Re: pmtud + ipnat RELENG_6_2 appears to be broken
Message-ID:  <20070725004402.GA13665@heff.fud.org.nz>
In-Reply-To: <c7aff4ef0707241615u385f379bo36b07a3a788ea4b7@mail.gmail.com>
References:  <469624D1.20108@seclark.us> <4696823B.9020107@seclark.us> <AF67C2DA-4E77-48C5-B380-56D5D39043F4@mac.com> <46969129.60409@seclark.us> <3C09F7E4-C15A-4B9E-94A3-C4997C73C0BD@mac.com> <c7aff4ef0707241615u385f379bo36b07a3a788ea4b7@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 25, 2007 at 03:15:17AM +0400, 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
> )

lagg on RELENG_6 is currently broken due to subtle differences that
wernt taken into account when it was MFCd. Can you please test this
patch.


Index: if_lagg.c
===================================================================
RCS file: /home/ncvs/src/sys/net/if_lagg.c,v
retrieving revision 1.11.2.3
diff -u -p -r1.11.2.3 if_lagg.c
--- if_lagg.c	12 Jul 2007 20:40:24 -0000	1.11.2.3
+++ if_lagg.c	25 Jul 2007 00:43:24 -0000
@@ -319,6 +319,7 @@ lagg_lladdr(struct lagg_softc *sc, uint8
 	if (memcmp(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN) == 0)
 		return;
 
+	bcopy(lladdr, IFP2ENADDR(ifp), ETHER_ADDR_LEN);
 	bcopy(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN);
 	/* Let the protocol know the MAC has changed */
 	if (sc->sc_lladdr != NULL)


> 2007/7/13, Chuck Swiger <cswiger@mac.com>:
> >
> >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"
> >
> _______________________________________________
> 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"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070725004402.GA13665>