Bug 121316 - kernel: cipcb0: got short packet from A.B.C.D
kernel: cipcb0: got short packet from A.B.C.D
Product: Fedora
Classification: Fedora
Component: cipe (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-04-20 08:53 EDT by Andrew Meredith
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-01 10:50:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Meredith 2004-04-20 08:53:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
The following copied in from bug number 89512


Opened by Bruno Negrao (bnegrao@engepel.com.br) on 2003-04-23 13:42

Description of problem:
When connected using CIPE, this protocol will not recognize too small
packets passing through the tunnel, it will act as the packets never
existed!!I found on the CIPE developer's site that this is really a
bug on all versions of cipe previous to the 1.5.4.
Bellow, I cut and pasted the information I found on 

To:  cipe-l@inka.de 
Subject:  BUG: crasher [IMPORTANT PATCH] 
From:  Olaf Titz <olaf@bigred.inka.de> 
Date:  Mon, 07 Jan 2002 21:17:18 +0100 


This must be an old problem, why was it never found? :-) To my
knowledge it exists in all published versions of CIPE. It causes a
crash when CIPE receives too small packets. Thanks to Larry McVoy for
alerting me to this bug.

The attached patch is from the CVS but applies cleanly to 1.5.2.


Index: cipe/sock.c
RCS file:
retrieving revision 1.36
diff -u -r1.36 sock.c
--- cipe/sock.c 2001/12/29 20:23:04     1.36
+++ cipe/sock.c 2002/01/06 18:28:56
@@ -199,6 +199,11 @@
        goto framerr;
+    if (length<cipehdrlen+(c->sockshost?sizeof(struct
sockshdr):0)) {
+        printk(KERN_INFO "%s: got short packet from %s\n",
+               cipe_ntoa(saddr(skb)));
+       goto framerr;
+    }

     n=alloc_skb(skb->len, GFP_KERNEL);
     if (!n) {
@@ -390,10 +395,8 @@
     return NULL;

-#if 0
     ++c->stat.rx_frame_errors; /* slightly abuse this */
     if (n)

=== end of patch ===

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

How reproducible:

Steps to Reproduce:
To reproduce the problem, try a 'ping' with the '-s 0' option, this
will produce icmp packets carrying 0 bytes of data, what generates a
packet of only 8 bytes (originated of the ICMP header).
This way:
ping -s 0 
Where is the p-t-p addres of your peer machine.

Actual Results:  The ping will end with 100% of loss.

But if you simply try a 'ping' it will work. Why? Because the
ping command sends by default a 56 bytes of data in each packet, which
raises a packet with a total of 64 bytes.

'ping -s 0' should work as it works for machines not using CIPE.1.

Additional info:

Of course when this problem happens on small ICMP packets this is not
serious, but, when happening on small TCP packets(or other protocols),
it could cause real problems.

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