Bug 159695
|
Description
Gabriel Donnell
2005-06-07 04:50:06 UTC
In the Net Filter "Help: iptables NAT broken with pppoe" thread below, Albrecht Dreà reported a problem PPPoE NAT connections. This problem may be related to this ticket. However, I confirmed that the problem does not only occur with NAT connections. The same problem occured with Systems in the WAN which had Static Public IP Addresses. Hence, this may not be a problem with iptables. It may be a problem with the FC-3 Linux Kernel Alcatel SpeedTouch 330 USB ADSL Modem Driver. http://lists.netfilter.org/pipermail/netfilter/2005-May/060301.html David, are you willing to have a look? I know it's my area but I'm buried at this time. Seems unlikely that it's a problem with the SpeedTouch. Can you show a tcpdump of a failing https connection from the public IP address of ppp0? Created attachment 115207 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com I ran command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.153.140.121). tcpdump -i any -pUw- From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Created attachment 115208 [details] Server TCP Dump Binary Capture Output File http://mail.yahoo.com I ran command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Server (68.153.140.122). tcpdump -i any -pUw- From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Created attachment 115209 [details] Firewall TCP Dump Binary Capture Output File https://EHcNFuse.eushc.org Firewall TCP Dump Binary Capture Output File I ran command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.153.140.121). tcpdump -i any -pUw- From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Secure Web Site below: https://EHcNFuse.eushc.org 2. Waited as Mozilla went blank as it tried to load the page. Created attachment 115210 [details] Server TCP Dump Binary Capture Output File https://EHcNFuse.eushc.org I ran command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Server (68.153.140.122). tcpdump -i any -pUw- From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Secure Web Site below: https://EHcNFuse.eushc.org 2. Waited as Mozilla went blank as it tried to load the page. Created attachment 115211 [details] Firewall TCP Dump Binary Capture Output File https://MyDesktop.emory.org I ran command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.153.140.121). tcpdump -i any -pUw- From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Secure Web Site below: https://MyDesktop.emory.org 2. Waited as Mozilla went blank as it tried to load the page. Created attachment 115212 [details] Server TCP Dump Binary Capture Output File https://MyDesktop.emory.org I ran command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Server (68.153.140.122). tcpdump -i any -pUw- From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Secure Web Site below: https://MyDesktop.emory.org 2. Waited as Mozilla went blank as it tried to load the page. Did you attach the same file 6 times? It doesn't look very useful -- it's lots of internal SSH and X11 traffic. Please try to show only relevant traffic -- at least limit it to the ppp0 interface. I did not attach the same file 6 times. I attached TCP Dump Binary Capture Output Files from my Firewall (68.153.140.121) & Server (68.153.140.122) for each of the 3 https connections below: - http://mail.yahoo.com (Via Secure Authentication Link) - https://EHcNFuse.eushc.org (163.246.9.163) - https://MyDesktop.emory.org (163.246.9.6) I provided a description and comment for each attachment. Plus, I provided the steps I followed for each attachment. Please pay attention to the comments I provided with each attachment. It will help you know what to look for in the TCP Dump Binary Capture Output File. I did not limit the traffic to just the ppp0 interface because that may exclude other useful information. I read through several other Bugzilla Reports where the person investigating the problem requested more TCP Dump Information. You can easily filter out the desired information with the tcpdump filter expression. Also, you can use grep. I use the command line below to genrate the tcpdump text output file, and view it an editor. Then I use just search, filter and follow the desired network traffic by DNS Names, IP Address, Port Name and/or Port Number. tcpdump -r "$input" 1> "$output" gvim -n "$output" Am I right in thinking that none of those connections were made from the public IP address of ppp0 as requested? They all came from a different internal machine, thus bringing iptables and routing into the mix rather than merely testing the connectivity over the DSL modem? Please show a tcpdump including _only_ traffic from ppp0, showing a connection from the firewall _itself_ to some external https server. If at all possible it would be good if you could show a tcpdump from the server side too. If we co-ordinate times then perhaps we could use one of my own servers for that purpose. Correct, the TCP Dump Binary Capture Output Files included https traffic that was initiated only by my Linux Server (68.153.140.122), and not from my Linux Firewall (68.153.140.121). Hence, it does involve network routing and filtering. The https connections works fine on my Firewall which is the DSL Gateway with the ppp0 interface. I will generate the TCP Dump Binary Capture Output Files that will include https traffic that was initiated by my Firewall. We can co-ordinate a time for us to perform https connections to your server. Any weekday between 3:00 PM & 11:00 PM EST is good for me. During those times, I will be signed on to the following Instant Messengers (IM) & Accounts. - Yahoo: Gabriel_Donnell_RedHat - Skype: Gabriel_Donnell If you use Yahoo or Skype IM, then add me to your Buddy (Yahoo) or Contact (Skype) list. Otherwise, please let me now what IM you prefer to use. Created attachment 115245 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.19.102.69). tcpdump -i ppp0 -pUw- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. The ppp0 Remote IP Address is 65.14.248.11. However, this may not matter much. From my Firewall (68.19.102.69), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Logged out after Mozilla successfully loaded the page. Created attachment 115246 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com any I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.19.102.69). This is the same as the previous attachment with traffic from any Firewall NIC. tcpdump -i any -pUw- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. The ppp0 Remote IP Address is 65.14.248.11. However, this may not matter much. From my Firewall (68.19.102.69), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Logged out after Mozilla successfully loaded the page. Created attachment 115247 [details]
IP Tables Configuration File SNAT
I used the iptables SNAT target to change the Source IP Address of the
output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address
(68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall
WAN NIC.
I ran the command line below to create the SNAT Rule:
iptables --table nat --append POSTROUTING --out-interface ppp0 \
--source '!' 68.153.140.120/29 --jump SNAT --to-source 68.153.140.121
Created attachment 115248 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 SNAT I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.153.140.121). tcpdump -i ppp0 -pUw- I used the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. The ppp0 Remote IP Address is 65.14.248.11. However, this may not matter much. From my Firewall (68.153.140.121), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Logged out after Mozilla successfully loaded the page. Created attachment 115249 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com any SNAT I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.153.140.121). This is the same as the previous attachment with traffic from any Firewall NIC. tcpdump -i any -pUw- I used the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. The ppp0 Remote IP Address is 65.14.248.11. However, this may not matter much. From my Firewall (68.153.140.121), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Logged out after Mozilla successfully loaded the page. Created attachment 115250 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.19.102.69). tcpdump -i ppp0 -pUw- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. The ppp0 Remote IP Address is 65.14.248.11. However, this may not matter much. From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Created attachment 115251 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com any I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.19.102.69). This is the same as the previous attachment with traffic from any Firewall NIC. tcpdump -i any -pUw- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. The ppp0 Remote IP Address is 65.14.248.11. However, this may not matter much. From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Created attachment 115252 [details] Server TCP Dump Binary Capture Output File http://mail.yahoo.com any I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Server (68.153.140.122). tcpdump -i any -pUw- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.19.102.69) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. The ppp0 Remote IP Address is 65.14.248.11. However, this may not matter much. From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Sorry I did not attach the Server TCP Dump Binary Capture Output File with just the Server WAN NIC traffic. I specified eth2 as the interface instead of eth1. By the the time I figured it out I had a blank tcpdump file, I switched back to using the Netopia DSL Router. I only attached the Server TCP Dump Binary Capture Output File with traffic from any Server NIC. Just filter for network traffic the with the 68.153.140.122 IP Address. (In reply to comment #14) > We can co-ordinate a time for us to perform https connections to your server. > Any weekday between 3:00 PM & 11:00 PM EST is good for me. I've no idea what you mean by 'EST' -- there are at least two time zones in the world which locals call that, and I don't remember off-hand what either of them actually mean. Always use Universal Time when talking to people who aren't local. I'm running tcpdump now, filtering for 'host 68.153.140.122 or host 68.153.140.121 or host 68.19.102.69'. You can connect to https://www.infradead.org/ at your leisure and let me know when you've done so. Please attempt it from the internal machine 68.153.140.122 and also provide a tcpdump of the traffic on _its_ Ethernet interface along with a tcpdump from ppp0 of the firewall. Use the '-s' argument to make sure you capture whole packets. It might also be interesting to reduce the MTU on the eth0 interface of your internal machine, and see if that makes a difference. What is the MTU of your ppp link? Sorry about the time zone reference. Eastern Standard Time (EST) is used in the United States of America. New York is in EST the time zone. I was able to connect to the Secrued Web Site (https) below from all the systems. That includes the systems within my LAN which have private IP Addresses. https://www.InfraDead.org/ Strangely, the issue does not occur from all https sites. The problem may occur on ports other than https. The issue may occur with large amounts and/or more complex network traffic. I had no problems with connections to http, ssh, domain and ports. This is really wierd. The comment and inquiry about the Maximum Transfer Unit (MTU) hit the hammer directly on the nail. I noticed in the System Log (/var/log/messages) File, the Point to Point Protocol Daemon (pppd) reported an error with increasing the MTU and MRU to 1500, and it used 1492. I tried to set the MTU on the PPP Link to 1500, but it did not work. By default, the MTU on all the links is set to 1500. When I set the MTU to 1492 on the systems behind the Linux Firewall, the problem was corrected. There is temporary work around for the Linux Systems. To my knowledge, the MTU cannot be changed on Lose (What I call Windows) Systems. Unfortunately, my wife has a Lose (Win ... Windows) System which she needs to take her on-line courses for the University of Phoenix. Plus, many of my clients use Lose Systems. I am still in the process of converting them to use Linux 100%. Hence, I think changing the MTU to 1492 is not a possible work-around for networks with Lose Systems. As I mentioned when I submitted this problem, this issue occurs with Red Hat Linux (RHL) Fedora Core 3 (FC-3). I was never able to get the Alcatel SpeedTouch 330 USB ADSL Modem to work with RHL FC-2. The Alcatel SpeedTouch 330 USB ADSL Modem Source Code compiled and worked fine on RHL FC-1. Plus, on RHL FC-1, the pppd was able to set the MTU to 1500. Thus, we know there is a solution to the issue for RHL. I know one work around is to use RHL FC-1 for the Firewall. However, RHL FC-1 is outdated with Legacy Update Support. Plus, I prefer to use the latest RHL FC Release. Also, RHL FC-3 has better and cleaner Built-In and Plug & Play Support for the Alcatel SpeedTouch 330 USB ADSL Modem. In addition to that, RHL FC-3 has more support for the latest D-Link AirPlus G 803.11g Wireless Network Interface Cards. I am working on the Research & Development of a Linux-Based Wireless Solution for current and future clients and projects. Hence, RHL FC-3 or higher is a requirement. I need the failure to set the MTU to 1500 resolved for RHL FC-3 or higher. I have a strong programming background. Therefore, I can help implement the solution. If my assistance is needed, then please let me know. Addressing your last two posts in reverse order... you shouldn't have been able to use an MTU of 1500 before. You're using 'PPP over Ethernet' (over ATM). We have a virtual Ethernet link over the DSL line, and you're running PPP over that. The MTU of Ethernet cannot normally be higher than 1500. There is some overhead in each packet due to the size of the PPPoE header, so you really shouldn't be able to carry IP packets larger than 1492 over the PPPoE link. I'm not entirely sure what your earlier setup was doing -- perhaps it was sending packets on the virtual Ethernet which are too large? The real problem is that your systems ought to handle the slightly smaller MTU properly, but they don't. If they send a packet which needs fragmentation, your firewall should fragment it. If they send a packet which is marked 'Don't Fragment' but which needs fragmentation, your firewall should return an ICMP error accordingly. It is the firewalling code which is misbehaving. With the MTU on your internal server set back to 1500, can you reproduce the problem and show a simultaneous tcpdump from eth0 of your server (68.153.140.122) and ppp0 of your firewall. I'd like to the compare the traffic which each sees -- please make sure it's set to capture only ppp0 on the firewall. Created attachment 115344 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.218.115.52). tcpdump -i any -pUs0 -w- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.218.115.52) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. Please note that the ppp0 Local Public Dynamic IP Address (68.218.115.52) changes every time the DSL Connection is restarted. Hence, it is not a good IP Address to filter for without coordination. The ppp0 Remote IP Address is 65.14.248.11. This is the IP Address of the router on the ISP side. Its IP Address does not change much. However, the ppp0 remote IP Address does not matter. This is just information that I provided. From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Created attachment 115345 [details] Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Firewall (68.218.115.52). tcpdump -i any -pUs0 -w- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.218.115.52) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. Please note that the ppp0 Local Public Dynamic IP Address (68.218.115.52) changes every time the DSL Connection is restarted. Hence, it is not a good IP Address to filter for without coordination. The ppp0 Remote IP Address is 65.14.248.11. This is the IP Address of the router on the ISP side. Its IP Address does not change much. However, the ppp0 remote IP Address does not matter. This is just information that I provided. From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Created attachment 115346 [details] Server TCP Dump Binary Capture Output File http://mail.yahoo.com eth1 I ran the command line below on my Red Hat Linux (RHL) Fedore Core 3 (FC-3) Server (68.153.140.122). tcpdump -i any -pUs0 -w- I did not use the iptables SNAT target to change the Source IP Address of the output traffic through ppp0 from the ppp0 Local Public Dynamic IP Address (68.218.115.52) to the Public Static IP Address (68.153.140.121) of my Firewall WAN NIC. Please note that the ppp0 Local Public Dynamic IP Address (68.218.115.52) changes every time the DSL Connection is restarted. Hence, it is not a good IP Address to filter for without coordination. The ppp0 Remote IP Address is 65.14.248.11. This is the IP Address of the router on the ISP side. Its IP Address does not change much. However, the ppp0 remote IP Address does not matter. This is just information that I provided. From my RHL Server (68.153.140.122), I perfomed the following procedures with the Mozilla Web Browser: 1. Connected to the Yahoo Mail Web Site below: http://mail.yahoo.com 2. Clicked on the "Secure" link under the Authentication Fields. 3. Entered the Authentication Inforamtion in the fields below: - Yahoo! ID: - Password: 4. Waited as Mozilla went blank as it tried to load the page. Bull Shit ... I mean Bell South is my DSL ISP. They use PPP over ATM (PPPoATM) Technology. Their web site is below. However, there site and support offer very little or no information about Linux. http://BellSouth.com > We have a virtual Ethernet link over the DSL line, and you're running PPP over
> that.
Please let me know who you are referring to when you said "We" in the sentence
above. I assume you are referring to those who of use RHL FC-3, or those of who
use the Kernel that was released with RHL FC-3.
> I'm not entirely sure what your earlier setup was doing -- perhaps it was > sending packets on the virtual Ethernet which are too large? I do not know what System Configuration you are referring to when you said, "your earlier setup". I think you are referring to the RHL FC-1 Firewall which worked with the ppp0 MTU set to 1500. However, you could be referring to RHL FC-3 with the Ethernet (eth) NIC MTU set to 1492. Otherwise, you are referring to something else. For the RHL FC-1 Firewall, I downloaded and compiled the Alcatel SpeedTouch 330 USB ADSL Modem Source Code. Today, I found the Web Page below which provides some good instructions. However, the instructions were not available when I got it to work between late December, 2003 and early January, 2004. http://4p8.com/eric.brasseur/speedbundle_fedora.html The web site below has instructions for RHL FC-2. However, I have not tried them yet. http://4p8.com/eric.brasseur/fc2_speedtouch_usb.html I did nothing special to set the ppp0 MTU to 1500 with RHL FC-1 Firewall. Fortunately, the Speed Bundle 1.0 Package worked fine with RHL FC-1. Otherwise, I would not have been able to implement a Linux Firewall with the DSL Gateway for my clients in Jamaica around early January, 2004. The Speed Bundle 1.0 Source Code was able to get RHL FC-1 to work with the SpeedTouch 330 Modem. There may even be a solution for RHL FC-2. Therefore, I would think that same technology could be used for RHL FC-3 and higher. I had assumed that you were using PPPoE since you had mentioned it and I believe it's most prevalent in the US. Also, the failure to increase MTU above 1492 is consistent with the use of PPPoE. If you're using PPPoA, then you ought to be able to use an MTU of 1500 on the PPP link. How did you try this? By setting 'mtu=1500' in /etc/sysconfig/network-scripts/ifcfg-ppp0 ? What precisely was the result? By 'your earlier setup' I was referring to the FC-1 firewall which was using an MTU of 1500. Created attachment 115381 [details]
System Log PPPD Messages
I executed the command line to extract all the System Log PPPD Messages.
sed --{expression=/pppd/p,silent} /var/log/messages
Please note that pppd reported an error that it was not able to increase the
MTR & MRU to 1500. Plus, pppd indicated that it using 1492 for the MTU & MRU.
In this case, I did nothing to implicitly set the MTU to 1500. It seems like
that is the default configuration by pppd or RHL Network Configuration.
After the DSL ppp0 link was up, I could see that the MTU was 1492 with the command below: ip link show ppp0 I used the command below to set the MTU to 1500. No error was reported. ip link set ppp0 mtu 1500 After running the command, I the MTU value was listed as being 1500. However, the problem was not resolved. The https sites still hung. I see this in your output: Jun 10 19:14:00 firewall pppd[11942]: mru 1492 # (from command line) Jun 10 19:14:00 firewall pppd[11942]: mtu 1492 # (from command line) Please explicitly set the MTU in /etc/sysconfig/network-scripts/ifcfg-ppp0 Created attachment 115451 [details]
BellSouth ADSL PPP Interface Configuration Script
David Woodhouse, you are a genius. Explicitly setting the MRU & MTU to 1500 in
the BellSouth ADSL PPP Interface Configuration Script (ICS) below resolved the
problem. I attached the file for review.
/etc/sysconfig/network-scripts/ifcfg-BellSouth
If the ADSL PPP ICS does not define MRU & MTU, then the Roaring Penguin
Software (RPS) ADSL Connect Script below defines the the MRU & MTU to 1492.
That is because the RPS ADSL Scripts use PPPoE Configurations by default.
/sbin/adsl-connect
Over a month ago I had to review the RPS ADSL Scripts to determine what variables to define in the ADSL PPP ICS to get PPPoATM to work. I am surprised and disappointed that I did not pay more attention to the MRU & MTU specifications. That was a HUGE MISTAKE by me. For RHL FC-1, I did not use the RPS ADSL Scripts. I used the SpeedBundle Scripts which worked very well. Plus, the over-head of starting and stopping the modem_run utility made it harder to use the RPS ADSL Scripts. Since RHL FC-3 has more built-in support for the Alcatel SpeedTouch 330 USB ADSL Modem, I decided to use the RPS ADSL Scripts. In addition to that, the RPS ADSL Scripts are integrated in the Network Services. I really feel stupid, and wasted a lot of our time. I am very sorry for torturing you with the analysis all the TCP Dump Binary Files. I really appreciate your patience and assistance. It would be nice if RHL Network Configuration Utility below had more support for xDSL Parameters. I seen a request for that. I would like to help with that enhancement. However, I will see what enhancements RHL FC-4 provides for xDSL in the utility below. system-config-network (In reply to comment #43) > I am very sorry for torturing you with the analysis all the TCP Dump Binary > Files. It's OK -- I didn't look at most of them :) There is a bug here though -- even with the lower MTU, the connections ought to have worked through the firewall. That bug may be at your end, or it may be at the server end, if ICMP is filtered there. I suspect the latter. |