Herbert Xu wrote:
> Thanks. It turns out to be a bug in the GRE layer. I added that
> bug when I introduced skb_postpull_rcsum.
>
> [GRE]: Fix hardware checksum modification
>
> The skb_postpull_rcsum introduced a bug to the checksum modification.
> Although the length pulled is offset bytes, the
On Tue, Dec 13, 2005 at 06:30:38AM +, Paul Erkkila wrote:
>
> GRE tunnel.
>
> ip tunnel:
> tunnel0: gre/ip remote xx.xx.xx.xx local xx.xx.xx.xx ttl 255 key
> xx.xx.xx.xx
> Checksum in received packet is required.
> Checksum output packets.
Thanks. It turns out to be a bug in the GRE
Herbert Xu wrote:
>
> Which one of these is actually carrying the tunnel traffic?
>
# ethtool -i eth1
driver: 3c59x
version: LK1.1.19
firmware-version:
bus-info: :03:01.0
>
>> tunnel0: hw csum failure.
>>
>
> What sort of a tunnel is this? If it's GRE please include any
> options t
On Mon, Dec 12, 2005 at 09:13:24PM -0800, Andrew Morton wrote:
>
> - no skge driver in this box
> - 02:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit
> Ethernet Controller (LOM)
> - 03:01.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX
> [Boomerang]
>
On Mon, Dec 12, 2005 at 09:13:24PM -0800, Andrew Morton wrote:
>
> The hw checksum checking code is new since 2.6.14. Could someone
> check it please?
>
> Or is Paul's hardware broken?
Thanks I'll take a look. At least we can be sure that it's not the
remote end :)
--
Visit Openswan at http:/
The hw checksum checking code is new since 2.6.14. Could someone
check it please?
Or is Paul's hardware broken?
Begin forwarded message:
Date: Mon, 12 Dec 2005 01:17:59 +
From: Paul Erkkila <[EMAIL PROTECTED]>
To: linux-net@vger.kernel.org, Linux Kernel Mailing List
Subject: 2.6.15-rc5
