Re: Strange PPPoe problem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 25 Mar 2006 22:44:11 -0600
anoop aryal <aaryal@foresightint.com> wrote:
> 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.
<snip>
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-----
Reply to: