[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1231460091.11674.94.camel@Maple>
Date: Fri, 09 Jan 2009 00:14:51 +0000
From: John Dykstra <john.dykstra1@...il.com>
To: netdev@...r.kernel.org
Subject: Re: [Bugme-new] [Bug 12327] New: Intermittent TCP issues with =>
2.6.27
On Fri, 2009-01-09 at 00:04 +0900, Speedster wrote:
> Attached (all are the exact same attempted connection), and reveal some
> interesting information.
>
> The path the inbound traffic should take is
> 1. vlan50 (host)
> 2. tap interface vnet3 (host) / eth0 (guest)
> 3. ppp0 (guest)
>
> It looks as though when it is sent out the tap interface the payload
> length is incorrect in the PPPoE section of the frame. When it arrives
> via vlan50 it appears fine. Or at least that's what wireshark highlights
> for me :)
The length field in the PPPoE header doesn't change.
The packet arrives from the ISP with its PPPoE header length field
showing two extra bytes past the IP payload. The bridge or something
close to it trims those two bytes from the sk_buff, leaving a packet
whose PPPoE header is wrong, but whose upper headers make sense. The
PPPoE driver in the virtual machine then drops the packet.
I haven't unscrambled where the drop occurs in the PPPoE driver, but
that's presumably what changed in 2.6.27. It seems to me that the drop
is proper. What's wrong is trimming the sk_buff to match the IP header
while ignoring the L2 header, and that's apparently been that way for a
while (if I understand what the reporter is running where).
Or have I screwed up my first posting to netdev?
-- John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists