This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 159695 - Alcatel SpeedTouch 330 USB ADSL Modem HTTPS Connections Hang
Alcatel SpeedTouch 330 USB ADSL Modem HTTPS Connections Hang
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
https://EHcNFuse.eushc.org https://My...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-07 00:50 EDT by Gabriel Donnell
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-14 22:56:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com (2.89 MB, application/octet-stream)
2005-06-08 04:46 EDT, Gabriel Donnell
no flags Details
Server TCP Dump Binary Capture Output File http://mail.yahoo.com (1.53 MB, application/octet-stream)
2005-06-08 04:58 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File https://EHcNFuse.eushc.org (1.41 MB, application/octet-stream)
2005-06-08 05:05 EDT, Gabriel Donnell
no flags Details
Server TCP Dump Binary Capture Output File https://EHcNFuse.eushc.org (2.37 MB, application/octet-stream)
2005-06-08 05:13 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File https://MyDesktop.emory.org (3.18 MB, application/octet-stream)
2005-06-08 05:20 EDT, Gabriel Donnell
no flags Details
Server TCP Dump Binary Capture Output File https://MyDesktop.emory.org (3.06 MB, application/octet-stream)
2005-06-08 05:25 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 (31.82 KB, application/octet-stream)
2005-06-08 22:13 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com any (3.69 MB, application/octet-stream)
2005-06-08 22:25 EDT, Gabriel Donnell
no flags Details
IP Tables Configuration File SNAT (297 bytes, text/plain)
2005-06-08 22:32 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 SNAT (27.07 KB, application/octet-stream)
2005-06-08 22:38 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com any SNAT (2.49 MB, application/octet-stream)
2005-06-08 22:42 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 (57.61 KB, application/octet-stream)
2005-06-08 23:32 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com any (6.18 MB, application/octet-stream)
2005-06-08 23:37 EDT, Gabriel Donnell
no flags Details
Server TCP Dump Binary Capture Output File http://mail.yahoo.com any (3.43 MB, application/octet-stream)
2005-06-08 23:56 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 (166.84 KB, text/plain)
2005-06-12 21:37 EDT, Gabriel Donnell
no flags Details
Firewall TCP Dump Binary Capture Output File http://mail.yahoo.com ppp0 (166.84 KB, application/octet-stream)
2005-06-12 21:42 EDT, Gabriel Donnell
no flags Details
Server TCP Dump Binary Capture Output File http://mail.yahoo.com eth1 (162.88 KB, application/octet-stream)
2005-06-12 21:51 EDT, Gabriel Donnell
no flags Details
System Log PPPD Messages (3.56 KB, application/octet-stream)
2005-06-13 19:13 EDT, Gabriel Donnell
no flags Details
BellSouth ADSL PPP Interface Configuration Script (539 bytes, application/octet-stream)
2005-06-14 22:43 EDT, Gabriel Donnell
no flags Details

  None (edit)
Description Gabriel Donnell 2005-06-07 00:50:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3

Description of problem:
My Linux Firewall uses an Alcatel SpeedTouch 330 USB ADSL Modem to connect all the systems in my network to the Internet.  When I try to connect to various Secure Web Sites (HTTPS) with the other systems within my network, the connection hangs.  The Linux Firewall is able to connect to HTTPS with no problems.

This problem does not occur with Fedora Core 1.  I was not able to get the SpeedTouch DSL Modem does not work with Fedora Core 2.

I listed some example HTTPS URL in the URL Field of this ticket.  Also, for convenience, I listed them below:
- https://EHcNFuse.eushc.org
- https://MyDesktop.emory.org
- http://mail.yahoo.com
- http://orbitz.com

Version-Release number of selected component (if applicable):
kernel-2.6.11-1.27_FC3

How reproducible:
Always

Steps to Reproduce:
1. Follow the "Linux Kernel Speedtouch Driver for Fedora Core" instrucitons in the web site below for complete instructions to configure any Alcatel SpeedTouch USB ADSL Modem to work with Fedora Core 3.
  http://Linux-USB.org/SpeedTouch/fedora
  
2. For the Alcatel SpeedTouch 330 USB ADSL Modem to work with Fedora Core 3, the Firmware Extractor Instructions below may be all that is needed.
  http://Linux-USB.org/SpeedTouch/firmware/firmware.html

3. The System Configuration Network (system-config-network) GUI is very helpful with generating and modifying the configuration files specified in the "Linux Kernel Speedtouch Driver for Fedora Core" instructions.

4. Additional tweaks may be needed to actually establish the DSL PPP Connection.  If any assitance is needed, then I may be able to help.

5. If private IP Addresses are used for the other systems in the network, then use the iptables MASQUERADE or SNAT targets for their traffic that goes out to the Internet.

6. Try to connect to the Secure Web Sites below:
- https://EHcNFuse.eushc.org
- https://MyDesktop.emory.org

7. Log into a Yahoo Mail account from the web site below:
- http://mail.yahoo.com

8. Search for flights on the Orbitz Web Site below:
- http://orbitz.com

Actual Results:  For the other systems within the network, the web browser screen is blank while it continiously attempts to load the page.  The Firewall which has the DSL Interface, the web browser can load the page.

Expected Results:  The web page is loaded in the the browser screen for the Fireall and other systems with in the network.

Additional info:

The Fedore Core Alcatel SpeedTouch 330 USB ADSL Modem support description is below:

- Fedora Core 1 (FC-1), I had to download and compile the source code from the location below.
  http://PRDownloads.SourceForge.net/linux-usb/speedbundle-1.0.tar.gz?download

- Fedora Core 2 (FC-2), the Alcatel SpeedTouch 330 USB ADSL Modem support is not built into the Linux Kernel.  Plus, I was not able to compile the source code because it was not completely compatible with the Kernel Source Code.

- Fedora Core 3 (FC-3), the Alcatel SpeedTouch 330 USB ADSL Modem support is built into the Linux Kernel.  This made configuring it to work with very easy.  It works well for all the connections I tried.  I only had problems with some HTTPS Connections.

System Environment Configuration
- The Firewall has the following Network Interface Cards (NIC):
  - ppp0: ISP DSL PPP Connection with Dynamic Public Local IP Address.
  - eth0: LAN with Private IP Addresses.
  - eth1: DMZ with Private IP Addresses.
  - eth2: WAN with Static Public Local IP Addresses.

- The Source IP Address of the LAN & DMZ traffic that goes to the ppp0 (ISP) or eth2 (WAN) NIC was modified with iptables MASQUERADE or SNAT targets.

- The Kernel Network Parameters below are appropriately defined and have the same values for the FC-1 & FC-3 Firewalls:
  /proc/sys/net/ipv4/ip_forward
  /proc/sys/net/ipv4/conf/{lo,ppp0,eth{0,1,2}}/{forwarding,rp_filter}
Comment 1 Gabriel Donnell 2005-06-07 00:58:28 EDT
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
Comment 2 Pete Zaitcev 2005-06-07 01:13:39 EDT
David, are you willing to have a look? I know it's my area but
I'm buried at this time.
Comment 3 David Woodhouse 2005-06-07 03:48:12 EDT
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?

Comment 4 Gabriel Donnell 2005-06-08 04:46:36 EDT
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.
Comment 5 Gabriel Donnell 2005-06-08 04:58:53 EDT
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.
Comment 6 Gabriel Donnell 2005-06-08 05:05:36 EDT
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.
Comment 7 Gabriel Donnell 2005-06-08 05:13:29 EDT
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.
Comment 8 Gabriel Donnell 2005-06-08 05:20:10 EDT
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.
Comment 9 Gabriel Donnell 2005-06-08 05:25:50 EDT
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.
Comment 10 David Woodhouse 2005-06-08 11:45:17 EDT
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.
Comment 11 Gabriel Donnell 2005-06-08 16:35:44 EDT
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"
Comment 12 David Woodhouse 2005-06-08 18:35:28 EDT
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.
Comment 13 Gabriel Donnell 2005-06-08 21:11:42 EDT
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.
Comment 14 Gabriel Donnell 2005-06-08 21:26:49 EDT
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.
Comment 15 Gabriel Donnell 2005-06-08 22:13:32 EDT
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.
Comment 16 Gabriel Donnell 2005-06-08 22:25:25 EDT
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.
Comment 17 Gabriel Donnell 2005-06-08 22:32:52 EDT
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
Comment 18 Gabriel Donnell 2005-06-08 22:38:33 EDT
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.
Comment 19 Gabriel Donnell 2005-06-08 22:42:24 EDT
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.
Comment 20 Gabriel Donnell 2005-06-08 23:32:04 EDT
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.
Comment 21 Gabriel Donnell 2005-06-08 23:37:53 EDT
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.
Comment 22 Gabriel Donnell 2005-06-08 23:56:24 EDT
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.
Comment 23 Gabriel Donnell 2005-06-09 00:17:34 EDT
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.
Comment 24 David Woodhouse 2005-06-09 11:08:07 EDT
(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?

Comment 25 Gabriel Donnell 2005-06-12 01:14:32 EDT
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.
Comment 26 Gabriel Donnell 2005-06-12 01:24:06 EDT
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.
Comment 27 Gabriel Donnell 2005-06-12 02:28:20 EDT
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.
Comment 28 Gabriel Donnell 2005-06-12 02:29:06 EDT
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.
Comment 29 Gabriel Donnell 2005-06-12 02:30:27 EDT
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.
Comment 30 David Woodhouse 2005-06-12 02:40:38 EDT
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. 
Comment 31 Gabriel Donnell 2005-06-12 21:37:12 EDT
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.
Comment 32 Gabriel Donnell 2005-06-12 21:42:26 EDT
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.
Comment 33 Gabriel Donnell 2005-06-12 21:51:34 EDT
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.
Comment 34 Gabriel Donnell 2005-06-12 22:49:12 EDT
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
Comment 35 Gabriel Donnell 2005-06-12 22:58:23 EDT
> 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.
Comment 36 Gabriel Donnell 2005-06-13 00:13:08 EDT
> 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.
Comment 37 David Woodhouse 2005-06-13 03:54:15 EDT
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. 
Comment 38 Gabriel Donnell 2005-06-13 19:13:33 EDT
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.
Comment 39 Gabriel Donnell 2005-06-13 21:13:12 EDT
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.
Comment 40 David Woodhouse 2005-06-14 03:34:44 EDT
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
Comment 41 Gabriel Donnell 2005-06-14 22:43:25 EDT
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
Comment 42 Gabriel Donnell 2005-06-14 22:48:36 EDT
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.
Comment 43 Gabriel Donnell 2005-06-14 22:49:50 EDT
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
Comment 44 David Woodhouse 2005-06-15 02:38:11 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.