From: Stephen Hemminger <shemminger@osdl.org>
To: Mark Zipp <mark.r.zipp@gmail.com>
Cc: bridge@osdl.org
Subject: Re: [Bridge] Problem bridging frames with bridge and real interface MTU > 1527
Date: Tue, 23 May 2006 18:50:29 -0700 [thread overview]
Message-ID: <4473BBE5.3050802@osdl.org> (raw)
In-Reply-To: <a9a0929d0605231816u28c5515ay19b2527d60724cef@mail.gmail.com>
Mark Zipp wrote:
> Hi Stephen,
>
> Thanks very much for getting back to me.
>
> On 24/05/06, Stephen Hemminger <shemminger@osdl.org> wrote:
>> On Tue, 23 May 2006 10:07:13 +0930
>> "Mark Zipp" <mark.r.zipp@gmail.com> wrote:
>>
>
> <snip>
>>
>> The only bridge related dropping is here in br_forward.c
>>
>> int br_dev_queue_push_xmit(struct sk_buff *skb)
>> {
>> /* drop mtu oversized packets except tso */
>> if (packet_length(skb) > skb->dev->mtu &&
>> !skb_shinfo(skb)->tso_size)
>> kfree_skb(skb);
>>
>> Are you doing VLAN's? There was a bug not fixed until 2.6.17 that
>> didn't
>> account for VLAN header properly.
>>
>
> No I'm not doing VLANs, just plain IP inside ethernet frames.
>
> There was a new ArchLinux kernel package available, which, going by
> its version number, corresponds to the 2.6.16.18 kernel. I've
> installed that, and been able to send 2000 byte IP pings through the
> bridge, so my problem seems to have disappeared.
>
>> Are you doing filtering? Some netfilter module might be dropping the
>> packets.
>>
>
> I did have some filtering enabled originally, I've just tested my 2K
> pings with and without having blanket permit lines in the incoming and
> outgoing iptables rules, and have had complete success in either case.
>
> I haven't tested it with the traffic IP/GRE traffic I originally
> encountered it with yesterday, I doubt I'll now have a problem with
> it, I'll let you know if I do.
>
> (I'll create a new email to the list to start a new thread about
> another thing that I think could be another bug in the bridge code -
> ports go through some, if not all of the STP port states even when STP
> is not running)
>
> 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.
next prev parent reply other threads:[~2006-05-24 1:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-23 0:37 [Bridge] Problem bridging frames with bridge and real interface MTU > 1527 Mark Zipp
2006-05-23 18:06 ` Stephen Hemminger
2006-05-24 1:16 ` Mark Zipp
2006-05-24 1:50 ` Stephen Hemminger [this message]
2006-06-01 0:40 ` Mark Zipp
2006-06-02 17:03 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4473BBE5.3050802@osdl.org \
--to=shemminger@osdl.org \
--cc=bridge@osdl.org \
--cc=mark.r.zipp@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox