Bug 997949 - IP0 bad-hlen 0 in WCCP gre tunnel
Summary: IP0 bad-hlen 0 in WCCP gre tunnel
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-16 15:25 UTC by Fabrice
Modified: 2013-10-08 16:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-08 16:17:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Fabrice 2013-08-16 15:25:52 UTC
Description of problem:

I have a server using squid in a WCCP setup. After an upgrade of a server to use kernel-3.10.6-200.fc19.x86_64, the WCCP gre tunnel is dropping packets. I was able to trace the issue to a "IP0 bad-hlen 0" in the tunnel itself.

I could see the gre packets on the Ethernet interface but they got dropped with the following error once they reached the gre tunnel itself.

tcpdump -pni gre1
12:47:33.881584 IP0 bad-hlen 0
12:47:33.885758 IP0 bad-hlen 0
12:47:33.999602 IP0 bad-hlen 0

With the previous kernel though (no other changes in the configuration), kernel-3.9.5-301.fc19.x86_64, things work perfectly. I have rolled back to kernel-3.9.5-301.fc19.x86_64 and it is working again. The issue seems to start somewhere within kernel-3.10.6-200.fc19.x86_64.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Brand new install of Fedora 19
2. setup squid with WCCP (works)
3. upgrade kernel to kernel-3.10.6-200.fc19.x86_64 and things fail

Actual results:


Expected results:

Not failing ? :)

Additional info:

I've used tcpdump on both the Ethernet interface and the gre tunnel with both kernel version. In both cases, I can see the GRE packets on the Ethernet interface like this:

tcpdump -pni ens32 proto gre    
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 65535 bytes
08:21:33.836354 IP x.x.x.x > x.x.x.x: GREv0, length 48: gre-proto-0x883e
08:21:33.836478 IP x.x.x.x > x.x.x.x: GREv0, length 48: gre-proto-0x883e
08:21:33.836806 IP x.x.x.x > x.x.x.x: GREv0, length 48: gre-proto-0x883e
08:21:33.836889 IP x.x.x.x > x.x.x.x: GREv0, length 48: gre-proto-0x883e

With kernel-3.9.5-301.fc19.x86_64, the packets are reaching the gre tunnel correctly and then are handled by squid as they should, however, with kernel-3.10.6-200.fc19.x86_64, tcpdump shows this and nothing happens:

tcpdump -pni gre1
12:47:33.881584 IP0 bad-hlen 0
12:47:33.885758 IP0 bad-hlen 0
12:47:33.999602 IP0 bad-hlen 0

Comment 1 Josh Boyer 2013-09-18 20:50:50 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 2 Josh Boyer 2013-10-08 16:17:45 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.