Re: Strange PPPoe problem
- From: Jacob S <stormspotter@xxxxxxxxxxx>
- Date: Mon, 3 Apr 2006 08:27:38 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 25 Mar 2006 22:44:11 -0600
anoop aryal <aaryal@xxxxxxxxxxxxxxxx> wrote:
On Saturday 25 March 2006 09:24 pm, Jacob S wrote:<snip>
[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.
I took some time to try this on the mail server today... E-mail still
has the same problem when both my firewall and the server have the
first 3 iptables rules applied. Which must mean it's one of the routers
between me and the server. I suspected this would be the case, as I
never had this problem with my old dsl line. It was only after
switching to a fiber optic line (through a different isp) that I
started having this problem. But I was interested in experimenting with
it just the same.
Thanks for your help and the great explanations.
Jacob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEMSLOkpJ43hY3cTURAre+AJ9tm1oVhJRY2xCOXccqVSVpq2unigCdEs1k
PAx5oFaOIm5+w/SuLQqFQGQ=
=oWDE
-----END PGP SIGNATURE-----
- Prev by Date: Re: nvidia - what is preferred installation route
- Next by Date: d-i building problems
- Previous by thread: nvidia - what is preferred installation route
- Next by thread: d-i building problems
- Index(es):
Relevant Pages
|
