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 layer.
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
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
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
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]
-
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 that you
