lkml.org 
[lkml]   [1997]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectBUG: Apache/Stronghold and Linux 2.0.X (fwd)
Oh well, as some have pointed out, the included diff didn't get out, so 
here's my message again, with the diff the causes me problems at the end.

Sorry for the inconvenienve.

Christophe Dupre Universite de Montreal
Montreal, Qc, Canada
"Nous ne sommes pas libres de ne pas etre libres, nous sommes obliges de
l'etre" - Fernando Savater

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s:++ a-- C++(+++) UL++++$ UISV++ P+++ L+++ !E---- W+++$ N+ o? K w---
O M- V-- PS+ PE+ Y+ PGP+ t+ 5++ X+ R+ tv+ b++ DI- D G+ e>++ h- r++ z+
------END GEEK CODE BLOCK------

#include <disclaimer.h>

---------- Forwarded message ----------
Date: Fri, 10 Jan 1997 18:53:18 -0500 (EST)
From: DUPRE Christophe <duprec@jsp.umontreal.ca>
To: tuc@stormking.com
Cc: Linux Kernel <linux-kernel@vger.rutgers.edu>, linux-net@vger.rutgers.edu
Subject: BUG: Apache/Stronghold and Linux 2.0.X

Many peoples have reported problems running Apache 1.1.1 (latest non-beta
version) and Stronghold 1.3.2 (latest non-beta version) under Linux 2.0.x.
I'm one of these persons, and I believe that Linux is the culprit. So I
experimented a bit, and here are my results. But first, the facts:

Here's my primary server:
Pentium 133, with Intel 430FX
64 Megs RAM
Adaptec 2940 with 1gig Hard drive and tape backup
NE2000 compatible network card
IDE CDROM
Linux 2.0.0

And my development workstation:
PentiumPRO 200
48 megs RAM
Adaptec 2940UW with 2 gigs Hard drive
Kingston network card (DEC 21041)
Linux 2.0.27

That's the starting configuration. Both works perfectly with Stronghold
1.3.2.

Now, I wanted to upgrade the server to 2.0.27 to fix various security
problems (mostly the ping of death). After upgrading, stronghold gave
problems: The web browser would successfully pull the 4 first files for
each page then wait for a long time for the fifth then fail. My Netscape
is configured to open 4 simultaneous connections - I don't know if
there's a connection between those values as I haven't experimented.
So I decided to upgrade kernel by kernel to see where the problem arized.
I did not exactly try all the kernels between 2.0.0 and 2.0.27, but I did
a binary search, trying 2.0.0, then 2.0.14, then 2.0.20, then 2.0.24.
All of these worked, compiled with the same options.
Then 2.0.25 didn't work. So I applied manually all the diffs included in
patch-2.0.25 to see which one broke stronghold, and I found the one
included at the end of this message. Now since I'm no network guru, I
have no idea what to do now, except post this here...

Please note the following :
- Stronghold works with linux-2.0.27 on my workstation which is not so
dissimilar to my server, except the processing power, so this MAY be a
kind of race condition.
- I have not tried 2.0.26
- both computers have the same compiler, libraries, etc...
- The workstation runs X11, not the server
- The problem shows up reliably, even just after bootup, with minimal load.

I am willing to do some further testing if deemed appropriate by any
kernel guru.

I hope this bug report is complete enough, please contact me if more info
is needed.

-----------------
Included DIFF:
(I'm sure some carriage returns will be added by my editor - can't do
better right now...)

diff -u --recursive --new-file v2.0.24/linux/net/ipv4/icmp.c
linux/net/ipv4/icmp.c
--- v2.0.24/linux/net/ipv4/icmp.c Thu Oct 31 12:08:55 1996
+++ linux/net/ipv4/icmp.c Wed Nov 6 14:39:47 1996
@@ -38,6 +38,7 @@
* path MTU bug.
* Thomas Quinot : ICMP Dest Unreach codes up to 15 are
* valid (RFC 1812).
+ * Alan Cox : Spoofing and junk icmp protections.
*
*
* RFC1122 (Host Requirements -- Comm. Layer) Status:
@@ -639,6 +640,7 @@
int hash;
struct inet_protocol *ipprot;
unsigned char *dp;
+ int match_addr=0;

iph = (struct iphdr *) (icmph + 1);

@@ -655,8 +657,9 @@
case ICMP_PROT_UNREACH:
/* printk(KERN_INFO "ICMP: %s:%d: protocol unreachable.\n",
in_ntoa(iph->daddr), (int)iph->protocol);*/
- break;
+ /* Drop through */
case ICMP_PORT_UNREACH:
+ match_addr=1;
break;
case ICMP_FRAG_NEEDED:
#ifdef CONFIG_NO_PATH_MTU_DISCOVERY
@@ -747,42 +750,46 @@
* RFC 1122: 3.2.2 MUST extract the protocol ID from the
passed header.
* RFC 1122: 3.2.2.1 MUST pass ICMP unreach messages to the
transport layer.
* RFC 1122: 3.2.2.2 MUST pass ICMP time expired messages to
transport layer.
- */
-
- /*
- * Get the protocol(s).
- */
-
- hash = iph->protocol & (MAX_INET_PROTOS -1);
-
- /*
- * This can't change while we are doing it.
*
- * FIXME: Deliver to appropriate raw sockets too.
+ * Rule: Require port unreachable and protocol unreachable come
+ * from the host in question. Stop junk spoofs.
*/
-
- ipprot = (struct inet_protocol *) inet_protos[hash];
- while(ipprot != NULL)
- {
- struct inet_protocol *nextip;
-
- nextip = (struct inet_protocol *) ipprot->next;

- /*
- * Pass it off to everyone who wants it.
+ if(!match_addr || saddr == iph->daddr)
+ {
+ /*
+ * Get the protocol(s).
*/
+
+ hash = iph->protocol & (MAX_INET_PROTOS -1);

- /* RFC1122: OK. Passes appropriate ICMP errors to the */
- /* appropriate protocol layer (MUST), as per 3.2.2. */
-
- if (iph->protocol == ipprot->protocol &&
ipprot->err_handler)
+ /*
+ * This can't change while we are doing it.
+ */
+
+ ipprot = (struct inet_protocol *) inet_protos[hash];
+ while(ipprot != NULL)
{
- ipprot->err_handler(icmph->type, icmph->code, dp,
+ struct inet_protocol *nextip;
+
+ nextip = (struct inet_protocol *) ipprot->next;
+
+ /*
+ * Pass it off to everyone who wants it.
+ */
+
+ /* RFC1122: OK. Passes appropriate ICMP errors to
the */
+ /* appropriate protocol layer (MUST), as per
3.2.2. */
+
+ if (iph->protocol == ipprot->protocol &&
ipprot->err_handler)
+ {
+ ipprot->err_handler(icmph->type,
icmph->code, dp,
iph->daddr, iph->saddr, ipprot);
- }
+ }

- ipprot = nextip;
- }
+ ipprot = nextip;
+ }
+ }
kfree_skb(skb, FREE_READ);
}


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.027 / U:1.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site