[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] ICMP replies RaQ issues..
- Subject: Re: [cobalt-users] ICMP replies RaQ issues..
- From: "E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>
- Date: Thu Apr 11 09:36:22 2002
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
> Date: Thu, 11 Apr 2002 18:46:54 +0200
> From: Benedict <j@xxxxxxxxxxx>
[ original message snipped ]
Bah, I sent the last message instead of cancelling to rewrite.
First, check out /etc/protocols -- note that ICMP, UDP, and TCP
are all IP protocols. "ICMP on port 80" makes _no sense_.
Second, running a RaQ over DSL and masquerading is going through
a lot of pain for no real gain. Why? If you must use DSL, why
not get the proper IP space, or at least bridge if you can only
get one IP address.
Third, I doubt it's the wrong MTU being answered. My suspicion
is that ICMP type 3 is getting blocked, which breaks path MTU
discovery.
Path MTU discovery works by a machine sending out a packet with
the DF (don't fragment) bit set... if it's larger than the MTU
somewhere along the line, you receive an ICMP unreachable with
code 4, fragmentation needed but DF set. Try it a few times, and
whallah! the MTU is learned.
Your RaQ automagically handles this behind the scenes. It's part
of the IP stack, and has _nothing_ to do with Apache.
Now the big question: Where is ICMP going awry? If ipchains
doesn't have an erroneous rule to block all ICMP (well, at least
type 3), then it's your router giving you grief.
--
Eddy
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.