Re: Strange PPPoe problem
- From: anoop aryal <aaryal@xxxxxxxxxxxxxxxx>
- Date: Sat, 25 Mar 2006 22:44:11 -0600
On Saturday 25 March 2006 09:24 pm, Jacob S wrote:
[snip]
# ping longbow.arroway.com -c 1 -M do -s 1472
PING longbow.arroway.com (66.252.129.166) 1472(1500) bytes of data.
From pool-71-244-52-50.dllstx.fios.verizon.net (71.244.52.50)
icmp_seq=1 Frag needed and DF set (mtu = 1492)
--- longbow.arroway.com ping statistics ---
0 packets transmitted, 0 received, +1 errors
# ping longbow.arroway.com -c 1 -M do -s 1464
PING longbow.arroway.com (66.252.129.166) 1464(1492) bytes of data.
1472 bytes from longbow.arroway.com (66.252.129.166): icmp_seq=1
ttl=49 time=163 ms
--- longbow.arroway.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 163.150/163.150/163.150/0.000 ms
So then I added the line
pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1464"
no, the mtu is 1492. you use 1464 in the ping because your are
specifying the ping payload. the total packet size ends up being
1464+28 = 1492. (which is what you had to begin with.) all is not
lost, we know PMTU works on your end provided you leave the three
iptable rules mentioned above. it seems like a firewall on the mail
server is causing icmp 3/4s from reaching the mail server. we can't
do much about the firewall. ie, the mail server replied with packets
with size = 1500 (most likely) with DF set, the other endpoint of
your DSL sent back an icmp 3/4 message back to the mail server to
send smaller packets, the firewall protecting the mail server dropped
it and the mail server never knew to send you packets of 1492 or less.
there is a 'hack' that may fix this. try and put this in your ruleset
in the *mangle table (assuming your dsl interface is ppp0):
-A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS
--clamp-mss-to-pmtu
or use this from the command line if you don't already have the
*mangle section:
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o
ppp0 -j TCPMSS --clamp-mss-to-pmtu
what this does is sets the mss of the initial SYN packet to pmtu -
40. the reciever (the mail server in this instance), then, uses the
mss to calculate the reply packet size instead of the default of
1500. by doing this it would have created packets of the right size
(1492) and therefore doesn't need PMTU to work.
again, the above rule is in addition to the previous three.
Very nice! That time it worked. E-mail downloaded sucessfully several
times now. :-) I'll add those 4 lines to my firewall script.
The mail server I'm downloading from is also a Debian machine... where
I have root access (even though it's not my own server). Is there
anything I should (can?) change in it's iptables firewall so that other
users don't have to fuss with this kind of a problem?
apply the first three rules on the mail server.
drop the fourth rule from your (home?) linux box. if you apply the first three
rules to the mail server, the whole thing should work without the fourth
rule. the fourth rule is a hack to make it work when the firewall on the
other end drops icmp 3/4 messages. or you can leave it in... shouldn't really
hurt.
full explanation follows:
ok, what you want to do is basically repeat the ping process but from the
opposite end.
now, you want your mail server getting the icmp 3/4 replies from your DSL
providers router.
in the diagram below:
A -------- B ---------X---------[cloud]------------- C --------------- D
let's say A is a client on your internal network. B the linux box where you
have the iptables, C is the firewall protecting your mail server. and D is
your mail server. note that A and B can be the same machine (the first three
rules will have removed the distinction for our purposes.) and C and D can
also be on the same machine... X is the other point in your dsl line (some
router owned by your DSL provider).
any how, what needs to happen is that when you ping with a packet size of 1500
from D to B (remember to subtract 28; just do what you did before but from
the opposite end), you should get an icmp 3/4 from X to C, and C needs to let
it thru to D. apply the first three rules to let icmp 3/4 thru in C. and ping
again from D and see if you get "frag needed" messages back to D. if you do
get the messages, you're done. if not, you'll need the clamp-mss rule since
someone else is the PMTU black hole and you can't do anything about it.
if you can get the icmp reply thru from X to C to D, you can discard the
"clamp-mss" rule in B. or leave it in. because the whole purpose was to let D
know that the link between B and X is 1492. you can let that be known by B
initiating the connection with a suggestion to D on how big the reply should
be. Or, you can let D find out about the 1492 link between B and X via the
normal process of PMTU by letting icmp 3/4 thru in your firewall so that D
can receive the icmp messages coming from X.
hope that clears it up for you. let me know if you have questions.
--
anoop
aaryal@xxxxxxxxxxxxxxxx
--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
- Follow-Ups:
- Re: Strange PPPoe problem
- From: Thilo Six
- Re: Strange PPPoe problem
- References:
- Strange PPPoe problem
- From: Jacob S
- Re: Strange PPPoe problem
- From: anoop aryal
- Re: Strange PPPoe problem
- From: Jacob S
- Strange PPPoe problem
- Prev by Date: Re: OT - dvd recording differences
- Next by Date: updating drivers for an ATI card
- Previous by thread: Re: Strange PPPoe problem
- Next by thread: Re: Strange PPPoe problem
- Index(es):
Relevant Pages
|
