Re: Strange PPPoe problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 25 Mar 2006 22:44:11 -0600 anoop aryal [EMAIL PROTECTED] 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-
Re: Strange PPPoe problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 24 Mar 2006 10:33:07 -0600 anoop aryal [EMAIL PROTECTED] wrote: On Friday 24 March 2006 06:55 am, Jacob S wrote: On Thu, 23 Mar 2006 14:35:20 -0600 anoop aryal [EMAIL PROTECTED] wrote: On Thursday 23 March 2006 10:58, Jacob S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy list, I recently changed ISPs, away from static ips on a dsl line to a single dynamic ip on Veriz*n's new Fi*S (fiber optic) service. The new service uses PPPoe - not a problem, or so I thought - I have PPPoe on my firewall. Now, I have used PPPoe from this very same firewall on a different dsl line before and it worked great. But for some reason when I do PPPoe for the new fiber line only http traffic works properly. When downloading e-mail, everything is fine until it tries to download the mail (I see it login, get the number of messages to download, and then it tries to start downloading). At this point the e-mail just hangs until it finally times out. It does not seem to be port-related, as I have setup the e-mail server with port-forwarding rules to allow me to download mail on non-standard ports and it exhibits the same problem. And if I do PPPoe on the provided D-Link router, instead of on my firewall, everything (including e-mail) works great. snip google PMTU to read about this in more detail, but it seriously sounds like icmp 3/4 packets are being dropped somewhere. if you setup your firewall to allow icmp packets of type 3/4 thru, you should be all set (well, you'd hope so anyway). a set of rules like so should do the trick: -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT -A OUTPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT then, make sure you have the iputils-ping package installed (not the netkit-ping) and try: ping your.mail.host -c 1 -M do -s 1472 and you should get back an icmp reply saying what the mtu should be. subtract 28 from it and try pinging with that size and it should go thru. eg, if the reply says mtu = 1492, try: ping your.mail.host -c 1 -M do -s 1464 and it should go thru just fine. if you get a request timeout, that means that some routers are just dropping your packets without an icmp 3/4 message. keep reducing the size of your packet and see if you can get anything thru. read up on PMTU for possible solutions. there are ways to stop automatic PMTU discovery etc. Ok, things are getting stranger here. I ran the iptables rules you suggested and here's the ping results: # 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
Re: Strange PPPoe problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 24 Mar 2006 11:49:56 -0500 Gene Heskett [EMAIL PROTECTED] wrote: On Friday 24 March 2006 07:55, Jacob S wrote: snip So then I added the line pty /usr/sbin/pppoe -I eth0 -T 80 -m 1464 to /etc/ppp/peers/dsl-provider, but the problem continued. After commenting that line back out (so that no pty... -m declaration had been made in the dsl-provider config), I was able to sucessfully download one single e-mail from a server. There was only one e-mail in that account and it downloaded like normal. So I sent an e-mail to that account, being that it was on a different server from my normal tests, but that one would not download sucessfully. So it would seem like it had something to do with the size and speed of the one that downloaded properly. In short, it's still a no go and I have no clue why. The D-Link router still works great, but pppoe from the firewall doesn't. The d-link works... And does this also go thru the same iptables rules as the PPPoE? If so, then playing with iptables is only going to break something. In any event, a run of /etc/init.d/iptables stop (as root of course) will open things up and prove or disprove that theory. I wouldn't leave it off for very long though. If you persist in using PPPoE rather than a good router, then I believe I'd take this problem to the Roaring Penguin folks to see if they've a new version that fixes this, or can use you for a test bed to see about fixing it. No, the d-link has it's own firewall stuff. It connects directly to the network line, in place of a modem. (Since this fiber optic service does not have a modem). I tried disabling iptables on the firewall to see if I still had the same problem, except I do not have a way of downloading e-mail on the firewall. And since iptables was no longer doing NAT, I could not do anything web related from my client machines. :-) I also upgraded from a 2.4.24-2-586tsc kernel to a 2.6.8-2-386 kernel tonight to see if it would help anything. It did not seem to have any affect on the problem. Thanks, Jacob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEJgpwkpJ43hY3cTURAkNfAJkB5mDZzXVOFTWmn1dI0iyROfjtagCg3+Va PZFLA9APnapatMPzY49Jv3s= =yXlF -END PGP SIGNATURE-
Re: Strange PPPoe problem
Jacob S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 23 Mar 2006 17:53:17 +0100 jmt [EMAIL PROTECTED] wrote: So, this problem has me stumped. I've tried playing around with the PPPoe options in /etc/ppp/peers/dsl-provider, and re-ran pppoeconf a couple times, but I can't get around the e-mail freeze. Does anybody else know what might cause a problem like this? Try this in your dsl-provider file : pty /usr/sbin/pppoe -I eth0 -T 80 -m 1452 or pty /usr/sbin/pppoe -I eth0 -T 80 -m 1412 and in the same file, set : mtu 1492 Same results. Web works fine, e-mail hangs after getting the number of new messages available. :-( I also tried playing with flow control - changing it to software instead of hardware, since there is no modem with fiber. (In actuality, I guess the modem is the ONT on the outside of my house, which converts the signal from fiber to ethernet and back.) Did you verify the MTU size (eg. by ifconfig)? For some reason I can't change the MTU size in the dsl-provider file -- it stays at 1492. I had to change it in a script in /etc/network/if-up.d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strange PPPoe problem
On Thursday 23 March 2006 10:58, Jacob S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy list, I recently changed ISPs, away from static ips on a dsl line to a single dynamic ip on Veriz*n's new Fi*S (fiber optic) service. The new service uses PPPoe - not a problem, or so I thought - I have PPPoe on my firewall. Now, I have used PPPoe from this very same firewall on a different dsl line before and it worked great. But for some reason when I do PPPoe for the new fiber line only http traffic works properly. When downloading e-mail, everything is fine until it tries to download the mail (I see it login, get the number of messages to download, and then it tries to start downloading). At this point the e-mail just hangs until it finally times out. It does not seem to be port-related, as I have setup the e-mail server with port-forwarding rules to allow me to download mail on non-standard ports and it exhibits the same problem. And if I do PPPoe on the provided D-Link router, instead of on my firewall, everything (including e-mail) works great. Then I suggest you use it, as, provided you replace the d-link with a linksys, something like a BEFSX41, you'll also have a very good firewall for free AND it will all Just Work(TM). I spent 2 weeks trying to make rp's PPPoE for linux work but like you, way too many things just didn't work. The security of the d-link product has been questioned at length on the lists, and I can testify that the seimans speedstream product is likewise rather poor, it was owned and trashed here inside of 2 weeks, with outside config access supposedly denied from the WAN ports. My linksys has let someone by just far enough to make a log entry as they were being dropped by a combination of portsentry, tcpwrappers, and iptables, 3 times in 3 years, 2 of which came from known sources when one of vz dns servers was owned and attacked me. The third one came from a chinese address block and didn't get any farther that the log. For 3 years of 24/7/365 dsl service, I think thats very good security indeed. So, this problem has me stumped. I've tried playing around with the PPPoe options in /etc/ppp/peers/dsl-provider, and re-ran pppoeconf a couple times, but I can't get around the e-mail freeze. Does anybody else know what might cause a problem like this? TIA, Jacob -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIsWmkpJ43hY3cTURAsrTAJ4mQR1eLZkyROcapMPQqSmNOJNWygCggb3i yKSy9J3jbAWgjv42iZK3UZM= =HAUe -END PGP SIGNATURE- -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strange PPPoe problem
On Thursday 23 March 2006 01:13 pm, Jacob S wrote: On Thu, 23 Mar 2006 12:27:26 -0500 Gene Heskett [EMAIL PROTECTED] wrote: On Thursday 23 March 2006 10:58, Jacob S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy list, I recently changed ISPs, away from static ips on a dsl line to a single dynamic ip on Veriz*n's new Fi*S (fiber optic) service. The new service uses PPPoe - not a problem, or so I thought - I have PPPoe on my firewall. Now, I have used PPPoe from this very same firewall on a different dsl line before and it worked great. But for some reason when I do PPPoe for the new fiber line only http traffic works properly. When downloading e-mail, everything is fine until it tries to download the mail (I see it login, get the number of messages to download, and then it tries to start downloading). At this point the e-mail just hangs until it finally times out. It does not seem to be port-related, as I have setup the e-mail server with port-forwarding rules to allow me to download mail on non-standard ports and it exhibits the same problem. And if I do PPPoe on the provided D-Link router, instead of on my firewall, everything (including e-mail) works great. Then I suggest you use it, as, provided you replace the d-link with a linksys, something like a BEFSX41, you'll also have a very good firewall for free AND it will all Just Work(TM). I spent 2 weeks trying to make rp's PPPoE for linux work but like you, way too many things just didn't work. The security of the d-link product has been questioned at length on the lists, and I can testify that the seimans speedstream product is likewise rather poor, it was owned and trashed here inside of 2 weeks, with outside config access supposedly denied from the WAN ports. My linksys has let someone by just far enough to make a log entry as they were being dropped by a combination of portsentry, tcpwrappers, and iptables, 3 times in 3 years, 2 of which came from known sources when one of vz dns servers was owned and attacked me. The third one came from a chinese address block and didn't get any farther that the log. For 3 years of 24/7/365 dsl service, I think thats very good security indeed. Thanks, but I'd rather keep playing with Linux to figure out why it's not working i would too. ;) than dump more money into the problem. My solution to this point is using my firewall as the only computer connected to the D-Link router. It works pretty well this way, but it means I'm stuck with their firewall on the router, instead of having full control from my Linux firewall. google PMTU to read about this in more detail, but it seriously sounds like icmp 3/4 packets are being dropped somewhere. if you setup your firewall to allow icmp packets of type 3/4 thru, you should be all set (well, you'd hope so anyway). a set of rules like so should do the trick: -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT -A OUTPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT then, make sure you have the iputils-ping package installed (not the netkit-ping) and try: ping your.mail.host -c 1 -M do -s 1472 and you should get back an icmp reply saying what the mtu should be. subtract 28 from it and try pinging with that size and it should go thru. eg, if the reply says mtu = 1492, try: ping your.mail.host -c 1 -M do -s 1464 and it should go thru just fine. if you get a request timeout, that means that some routers are just dropping your packets without an icmp 3/4 message. keep reducing the size of your packet and see if you can get anything thru. read up on PMTU for possible solutions. there are ways to stop automatic PMTU discovery etc. hope it helps. anoop. Jacob -- anoop [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
