On Thu, 1 Jun 2006 10:10:28 +0930 "Mark Zipp" <[EMAIL PROTECTED]> wrote:
> Hi Stephen, > > > On 24/05/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > <snip> > > > > Thanks for your help, > > > Mark. > > The problem (as I remember it) was often with ip_conntrack. It > > reassembles fragmented > > IP packets to look at them, then didn't fragment on output. > > > > Strange thing was that even after I was able to successfully do 2024 > byte pings through the bridge, with and without iptables connection > tracking rules in place, I still encountered the problem with the > oversized IP/GRE traffic that I'm trying to capture. What I think is > also interesting is that even though when I set the MTUs on the > ethernet interfaces and the bridge to 1527, not only does it all work, > the bridge is also forwarding frames that have a 1528 byte MTU (IP + > GRE + original 1500 byte IP packet), which I think should make the > bridge drop the frames as too large, yet setting the MTU 1528 on the > bridge and interfaces makes it fail. > > Maybe it is the different ways IP connection tracking treats ICMP / > Ping traffice verses IP/GRE traffic that is causing the issue. > > I've got some more testing to do again, this time around I'll try the > 2024 byte MTU on the bridge, and a blind iptables permit all to and > from the bridge interfaces, which should hopefully eliminate ip > connection tracking from the equation, therefore identifying it as the > cause. > > Thanks for your time, > Mark. You may want to either add some debug tracing or just try capturing packets to see the resulting traffic. I suspect connection tracking may be the culprit since it often does higher layer filtering. _______________________________________________ Bridge mailing list [email protected] https://lists.osdl.org/mailman/listinfo/bridge
