Bug 997949 - IP0 bad-hlen 0 in WCCP gre tunnel
IP0 bad-hlen 0 in WCCP gre tunnel
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-16 11:25 EDT by Fabrice
Modified: 2013-10-08 12:17 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-08 12:17:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabrice 2013-08-16 11:25:52 EDT
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 16:50:50 EDT
*********** 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 12:17:45 EDT
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.