[ale] http behind pppoe ?
Larry Grenevitch
lg1450 at bellsouth.net
Sun Feb 2 22:44:51 EST 2003
If you are trying to use SMB over a PPOE there are problems unless you change
packet settings. Microsoft has this on their Knowledge base somewhere under
PPOE and SMB or File Copy. The problem is that the MTU for TCPIP is usually
1500; however, PPOE uses some of that so you end up with something like 1460,
which causes a problem for Microsoft's SMB file transfer. HTTP and FTP work
just fine. In the past I had to have both a high speed connection and a dial
up connection and the file transfer would go over the high speed connection
and the tail end which needed the MTU of 1500 went over the dial up
connection. But you are probably better just to change the parameters for
SMB I think it was packet size????
On Friday 24 January 2003 11:13 pm, Matty wrote:
> On Fri, 24 Jan 2003, Keith R. Watson wrote:
> > At 12:38 PM 1/24/2003 -0500, James CE Johnson wrote:
> > >I'm unfortunate enough to live behind the bastardization that is PPPoE
> > >rather than having a nice, static IP. Since the switch (from the nice,
> > >static IP to the bastardization that is PPPoE) I've noticed that web
> > >requests to my server seem to have "issues". To be specific, it seems
> > > that in some cases the browser isn't getting the entire page sent by
> > > the server.
> > >
> > >Other protocols (eg -- ssh) seem to exhibit similar behavior but since
> > > the bulk of my traffic is http that's where I see it most.
> > >
> > >I have absolutely no idea why this is happening but I'm hoping someone
> > > out there in ALE-land has already been down this dark and disturbing
> > > road and will be kind enough to lend me a hand.
> > >
> > >Thanks,
> > >J
> >
> > James,
> >
> > When we first started using Cable/DSL routers such Linksys with ISP's
> > that use PPPOE, we encountered problems. I spent a day resolving the
> > issue. Here is a copy of the report.
> >
> > keith
> >
> >
> > VPN Connection to Georgia Tech Over Residential ADSL Test
> >
> > Keith R. Watson
> > keith.watson at gtri.gatech.edu
> >
> > 4/25/2001
> >
> > Test machines:
> >
> > Windows NT 4.0 (AIST Build v3.01)
> > Windows 98 SE (Standard KRW home build)
> >
> >
> > Test Network:
> >
> > Earthlink residential ADSL using PPPOE
> > ZyXEL Prestige 642M ATM to Ethernet bridge (DSL modem)
> > Linksys BEFSR41 NAT Router with BIOS v1.37 (PPPOE provided by
> > BEFSR41) 10 Port 10Mb Ethernet Hub
> >
> > (Also did a series of tests using WinPoET v2.0
> > on both machines. The results were the same as
> > using the BEFSR41)
> >
> >
> > Software:
> >
> > WinPoET v2.0
> > Secure Remote v4.1
> >
> >
> > Test Scenario:
> >
> > 1. Establish VPN connection to the Georgia Tech Checkpoint Firewall
> > 2. Mount an SMB share
> > 3. Copy a large file from the SMB share (>1K)
> > 4. Establish Telnet session to casbah.gatech.edu
> > 5. Connect to https://webwise.gtri.gatech.edu/
> >
> >
> > Tests (results were the same for both workstations):
> >
> > MTU = 1500 (this is the default for ethernet
> >
> > 1. Established VPN
> > 2. SMB mount succeeded.
> > 3. File copy <1K succeeded, >1K failed
> > 4. Telnet succeeded
> > 5. https failed
> >
> >
> > MTU = 576
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copiy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https succeeded
> >
> >
> > MTU = 1464
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K failed
> > 4. Telnet succeeded
> > 5. https failed
> >
> >
> > MTU = 1400
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https succeeded
> >
> >
> > MTU = 1440
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https failed
> >
> >
> > MTU = 1420
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https succeeded
> >
> >
> > MTU = 1430
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https succeeded
> >
> >
> > MTU = 1435
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https succeeded
> >
> >
> > MTU = 1438
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https succeeded
> >
> >
> > MTU = 1439
> >
> > 1. Established VPN
> > 2. SMB mount succeeded
> > 3. File copy <1K succeeded, >1K succeeded
> > 4. Telnet succeeded
> > 5. https failed
> >
> >
> > Conclusions:
> >
> > A larger header is required for HTTPS over a VPN.
> > When the MTU is set to 1500 the packets are fragmented
> > whenever the data size to be transmitted is >1K.
> >
> > header size + data size > 1500 bytes
>
> This is definitely a cool topic. I am using a MTU size of 1454 (NO IPSEC)
> with my FreeBSD 4.7-RELEASE-p3 firewall. I spent a good deal of time
> researching the internals of PPP/ATM/Ethernet, and came up with this
> value based on the following information:
>
> Data = ?? Bytes
> TCP Header = 20 Bytes
> IP Header = 20 Bytes
> PPP Headers = 8 Bytes (Assumes address/control fields
> are omitted)
> Ethernet Headers = 18 Bytes
> ATM Cell = 53 Bytes (48 Bytes data, 5 bytes for headers)
> --
> 66 Bytes
>
> After looking at this info, I wanted to find a combination of
> headers and data that would fill each and every 53 byte ATM
> cell. I did some math, and determined that 1414 bytes of data
> could be encapsulated within each TCP segment:
>
> 1414 bytes of data + 66 bytes worth of headers / 48 bytes \
> = 30 cells w/ 48 bytes, and one cell with 40 bytes
>
> ATM also requires an 8 byte Segmentation and Reassembly trailer for each
> frame (similar to the IP identification field). If we factor in the
> trailer:
>
> (1480 (headers + data) + 8 bytes (segmentation and reassembly trailer) \
> = 1488) / 48 = 31
>
> Now as long as I read TCP/IP Illustrated I, and my deploying ADSL book
> correctly, all the numbers should be correct (please let me know if you
> see anythign fubar). This should optimize large transfers of
> data on your PPPoE connection, since you are filling each and every
> ATM cell. Since I am a geek and like to keep up to date with new
> releases of RedHat, I tend to pull down 600MB ISOs when they become
> available. Since ATM requires all cells to be padded to 53 bytes, you
> might as well fill each byte with something. As you can tell, I am not a
> big fan of padding. :)
>
> Thought this might be useful,
> - Ryan
>
> > Setting MTU to 1438 prevents the packets
> > from fragmenting by limiting the amount of data in
> > the packet.
> >
> > header size + data size = 1500 bytes
> >
> >
> > Since not all possible scenarios were tested
> > an MTU value of less than 1438 should be used
> > to provide a safety margin. However, as MTU
> > decreases more packets are needed to send the
> > same amount of data. Therefore a safe compromise
> > would be to set MTU to 1400.
> >
> > -------------
> >
> > Keith R. Watson GTRI/ITD
> > Systems Support Specialist III Georgia Tech Research Institute
> > keith.watson at gtri.gatech.edu Atlanta, GA 30332-0816
> > 404-894-0836
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale
More information about the Ale
mailing list