ppp-2.4.2 released

ppp-2.4.2 released

[Paul Mackerras]

I have just released ppp-2.4.2, available at either:

ftp://ftp.samba.org/pub/ppp/ppp-2.4.2.tar.gz

or

http://ftp.samba.org/ftp/ppp/ppp-2.4.2.tar.gz

It's been a long time since the last release.  Hopefully the next
release won't take as long.  This release fixes a lot of bugs and adds
several new features.

From the README:

What's new in ppp-2.4.2.
************************

* The CHAP code has been rewritten.  Pppd now has support for MS-CHAP
  V1 and V2 authentication, both as server and client.  The new CHAP
  code is cleaner than the old code and avoids some copyright problems
  that existed in the old code.

* MPPE (Microsoft Point-to-Point Encryption) support has been added,
  although the current implementation shouldn't be considered
  completely secure.  (There is no assurance that the current code
  won't ever transmit an unencrypted packet.)

* James Carlson's implementation of the Extensible Authentication
  Protocol (EAP) has been added.

* Support for the Encryption Control Protocol (ECP) has been added.

* Some new plug-ins have been included:
  - A plug-in for kernel-mode PPPoE (PPP over Ethernet)
  - A plug-in for supplying the PAP password over a pipe from another
    process
  - A plug-in for authenticating using a Radius server.

* Updates and bug-fixes for the Solaris port.

* The CBCP (Call Back Control Protocol) code has been updated.  There
  are new options `remotenumber' and `allow-number'.

* Extra hooks for plugins to use have been added.

* There is now a `maxoctets' option, which causes pppd to terminate
  the link once the number of bytes passed on the link exceeds a given
  value.

* There are now options to control whether pppd can use the IPCP
  IP-Address and IP-Addresses options: `ipcp-no-address' and
  `ipcp-no-addresses'.

* Fixed several bugs, including potential buffer overflows in chat.

Paul.

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Fri, Jan 16, 2004 at 05:28:25PM +1100, Paul Mackerras wrote:
> I have just released ppp-2.4.2, available at either:
> 
> ftp://ftp.samba.org/pub/ppp/ppp-2.4.2.tar.gz
> 
> or
> 
> http://ftp.samba.org/ftp/ppp/ppp-2.4.2.tar.gz
> 
> It's been a long time since the last release.  Hopefully the next
> release won't take as long.  This release fixes a lot of bugs and adds
> several new features.
> 

There's still the MTU bug (with MPPE) left..

pppd/ccp.c near line 1192:

/*
 * We need to decrease the interface MTU by MPPE_PAD
 * because MPPE frames **grow**.  The kernel [must]
 * allocate MPPE_PAD extra bytes in xmit buffers.
 */
mtu = netif_get_mtu(f->unit);
if (mtu)
    netif_set_mtu(f->unit, mtu - MPPE_PAD);
else
    newret = CONFREJ;


MPPE_PAD is defined as 4.

Now, what happens when you are using MPPE, is, that the server sets the MTU
to x-4 and the client to x.

Is this a problem? yes. see http://nrg.joroinen.fi/yle.log
The log shows what happens when the client tries to open http connection to
www.yle.fi web server. In the example (log) MTU is defined as 1400 in the ppp
server config, but because of the code above, the ppp server sets the mtu to
1396 and the ppp client to 1400.

During PMTUD (Path MTU Discovery), the ppp server rejects all the packets
that the web server is trying to send to the ppp client.. causing that the
ppp client won't get the web page loaded at all (the web browser just waits
and nothing happens). The web server is sending packets which are 1400 bytes 
in size, but because of the 1396 MTU of the ppp server, they are dropped.

This does not happen with all web sites.. anyway, this should be fixed since
it's really annoying. When I remove the "- MPPE_PAD" code, everything seems
to be fine.

Also if I change the MTU of the ppp interface (in the server) during
ppp session (with ifconfig/ip), connections start to work well.

Thanks.

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Clive Nicolson]

http://ftp.samba.org/ftp/ppp/ppp-2.4.2.tar.gz does not appear to be a valid URL.

and

ftp://ftp.samba.org/pub/ppp/ppp-2.4.2.tar.gz will not build "out of the box"
under linux as <pcap.h> is not found by pcap-int.h .

Re: ppp-2.4.2 released

[Arvin Schnell]

On Sat, Jan 17, 2004 at 01:16:21AM +1300, Clive Nicolson wrote:
> http://ftp.samba.org/ftp/ppp/ppp-2.4.2.tar.gz does not appear to be a valid URL.
> 
> and
> 
> ftp://ftp.samba.org/pub/ppp/ppp-2.4.2.tar.gz will not build "out of the box"
> under linux as <pcap.h> is not found by pcap-int.h .

You need to install libpcap or disable filter support (see
Makefile.linux).

ciao Arvin

-- 
Dipl.-Phys. Arvin Schnell
SuSE Linux AG
Research & Development
email: arvin@suse.de

Re: ppp-2.4.2 released

[Paul Mackerras]

Clive Nicolson writes:

> http://ftp.samba.org/ftp/ppp/ppp-2.4.2.tar.gz does not appear to be a valid URL.

Sorry, use www.samba.org instead.

> and
> 
> ftp://ftp.samba.org/pub/ppp/ppp-2.4.2.tar.gz will not build "out of the box"
> under linux as <pcap.h> is not found by pcap-int.h .

It builds out of the box on my Debian sid box - you need the
libpcap-dev package installed though.  If you really don't have
pcap.h, set FILTER=n in pppd/Makefile.linux.

Paul.

Re: ppp-2.4.2 released

[Bill Unruh]

On Sat, 17 Jan 2004, Paul Mackerras wrote:

> Clive Nicolson writes:
> > ftp://ftp.samba.org/pub/ppp/ppp-2.4.2.tar.gz will not build "out of the box"
> > under linux as <pcap.h> is not found by pcap-int.h .
> 
> It builds out of the box on my Debian sid box - you need the
> libpcap-dev package installed though.  If you really don't have
> pcap.h, set FILTER=n in pppd/Makefile.linux.

The rpm 
libpcap0-devel on Mandrake systems (8.1 to 9.1 anyway) and probably
Redhat systems.

Re: ppp-2.4.2 released

[Paul Mackerras]

Pasi Kärkkäinen writes:

> There's still the MTU bug (with MPPE) left..

Well, somehow we have to allow for the extra 4 bytes that MPPE adds -
and it is reasonable and valid to have the network interface MTU be
smaller than the PPP mtu/mru values.  Arguably the code that reduces
the MTU isn't expressed as well as it could be, but I'm not yet
convinced it's actually wrong.

Frank, what is your opinion?

Paul.

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Sat, Jan 17, 2004 at 10:18:24AM +1100, Paul Mackerras wrote:
> Pasi Kärkkäinen writes:
> 
> > There's still the MTU bug (with MPPE) left..
> 
> Well, somehow we have to allow for the extra 4 bytes that MPPE adds -
> and it is reasonable and valid to have the network interface MTU be
> smaller than the PPP mtu/mru values.  Arguably the code that reduces
> the MTU isn't expressed as well as it could be, but I'm not yet
> convinced it's actually wrong.
> 

Hmm.. I'm not very familiar with MPPE internals, but anyway this seems to
cause problems in PMTUD with many web sites.. blocking access to them
entirely.

Are there any other opensource ppp/mppe packages that could be used to check
how this in handled in them..

> Frank, what is your opinion?
> 
> Paul.
> 

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Jan Dubiec]

On  Fri, 16 Jan 2004 10:48:47 +0200, Pasi Kärkkäinen <pasik@iki.fi> wrote:
[.....]
> There's still the MTU bug (with MPPE) left..
> 
> pppd/ccp.c near line 1192:
> 
> /*
>  * We need to decrease the interface MTU by MPPE_PAD
>  * because MPPE frames **grow**.  The kernel [must]
>  * allocate MPPE_PAD extra bytes in xmit buffers.
>  */
> mtu = netif_get_mtu(f->unit);
> if (mtu)
>     netif_set_mtu(f->unit, mtu - MPPE_PAD);
> else
>     newret = CONFREJ;
[.....]
> This does not happen with all web sites.. anyway, this should be fixed since
> it's really annoying. When I remove the "- MPPE_PAD" code, everything seems
> to be fine.
> 
> Also if I change the MTU of the ppp interface (in the server) during
> ppp session (with ifconfig/ip), connections start to work well.
Quite interesting problem. IMO the code you quoted should be just
removed because according to RFC1547 MTU is only information for
higher level protocols about "the maximum allowable length for a
packet (q.v.) transmitted over a point-to-point link without incurring
network layer fragmentation." Of course a PPP implementation should be
able to handle overhead added by MPPE - in our case apropriate code is
located in drivers/net/ppp_generic.c in the kernel sources.

According to RFC1661:
 - when negotiated MRU is less than 1500 octets, a PPP implementation
   must still be able to receive at least 1500 octets,
 - when PFC is negotiated, a PPP implementation is still required to
   receive frames with uncompressed protocol field.

So why not to handle MPPE overhead without changing MTU value? I am
sure that RFC3078, unfortunately silently, assumes that.

Regards,
/J.D.
-- 
Jan Dubiec, jdx@slackware.pl, mobile: +48 602 101787

G³êboka wiara wymaga p³ytkiego rozumu i nik³ej wiedzy.

Re: ppp-2.4.2 released

[Frank Cusack]

On Sat, Jan 17, 2004 at 12:45:18PM +0200, Pasi K?rkk?inen wrote:
> On Sat, Jan 17, 2004 at 10:18:24AM +1100, Paul Mackerras wrote:
> > Pasi Kärkkäinen writes:
> > 
> > > There's still the MTU bug (with MPPE) left..

What bug is that?

> > Well, somehow we have to allow for the extra 4 bytes that MPPE adds -
> > and it is reasonable and valid to have the network interface MTU be
> > smaller than the PPP mtu/mru values.  Arguably the code that reduces
> > the MTU isn't expressed as well as it could be, but I'm not yet
> > convinced it's actually wrong.
> > 
> 
> Hmm.. I'm not very familiar with MPPE internals, but anyway this seems to
> cause problems in PMTUD with many web sites.. blocking access to them
> entirely.
> 
> Are there any other opensource ppp/mppe packages that could be used to check
> how this in handled in them..

Everyone else ignores MTU and requires the user to manually set it.  If
the user does not set it, the peer sends frames which are too large, and
just expects that the receiver will handle it.

> > Frank, what is your opinion?

One choice would be to require MPP and send frags when we PPP frame
would be too large.  Reducing the interface MTU seems better.

How does this create a PMTU-D problem?

/fc

Re: ppp-2.4.2 released

[Frank Cusack]

Paul,

Any particular reason you removed the mppe patch from 2.4.2?  OK, it
does have a race where a few packets can escape unencrypted, but still.
Anyway, I plan to work up a more suitable patch for the kernel proper.

Are you now ok with me autoconf'ing things?  I was waiting for 2.4.2
before starting.

/fc

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Mon, Feb 02, 2004 at 01:27:03AM -0800, Frank Cusack wrote:
> On Sat, Jan 17, 2004 at 12:45:18PM +0200, Pasi K?rkk?inen wrote:
> > On Sat, Jan 17, 2004 at 10:18:24AM +1100, Paul Mackerras wrote:
> > > Pasi Kärkkäinen writes:
> > > 
> > > > There's still the MTU bug (with MPPE) left..
> 
> What bug is that?
> 

I've sent couple of mails about this.. I'll explain it below.


> > > Well, somehow we have to allow for the extra 4 bytes that MPPE adds -
> > > and it is reasonable and valid to have the network interface MTU be
> > > smaller than the PPP mtu/mru values.  Arguably the code that reduces
> > > the MTU isn't expressed as well as it could be, but I'm not yet
> > > convinced it's actually wrong.
> > > 
> > 
> > Hmm.. I'm not very familiar with MPPE internals, but anyway this seems to
> > cause problems in PMTUD with many web sites.. blocking access to them
> > entirely.
> > 
> > Are there any other opensource ppp/mppe packages that could be used to check
> > how this in handled in them..
> 
> Everyone else ignores MTU and requires the user to manually set it.  If
> the user does not set it, the peer sends frames which are too large, and
> just expects that the receiver will handle it.
> 
> > > Frank, what is your opinion?
> 
> One choice would be to require MPP and send frags when we PPP frame
> would be too large.  Reducing the interface MTU seems better.
> 
> How does this create a PMTU-D problem?
> 

Check http://nrg.joroinen.fi/yle.log

It's a tcpdump log from pptp server (running pppd 2.4.2).

The pptp-client tries to load www.yle.fi in the web browser, but the
pptp-server _rejects_ all the packets coming from www.yle.fi web server.

why? Because the pptp-server ppp-interface MTU is set to x-4, when
pptp-client ppp-interface mtu is set to x. 
x is the value that is defined in the ppp-server config file.

Basicly the pptp-server tells to web-server (all the time) that the
web-server needs to fragment the packets, because they cannot fit to the 
ppp-tunnel (and the packets have Dont Fragment-bit set). This is part of the
PMTUD.

Now, the problem is, that the web-server is already sending packets which
have *right* size (the size client told), but the pptp-server rejects them
because of the ppp-interface MTU is too low (in the pptp server). 

pppd/ccp.c near line 1192:

mtu = netif_get_mtu(f->unit);
if (mtu)
    netif_set_mtu(f->unit, mtu - MPPE_PAD);
else
    newret = CONFREJ;

MPPE_PAD is defined as 4.


The pptp client sets the MTU to x (for example 1400), and the pptp server sets 
the MTU to x-4 (1396). This obviously happens only when using MPPE.

The pptp-client is not able to load the web page at all, because the client
doesn't receive any data from the web server! the pptp-server rejects the
incoming (http) packets.

This does not happen with all web sites.

-- Pasi Kärkkäinen 
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Frank Cusack]

On Mon, Feb 02, 2004 at 12:56:52PM +0200, Pasi K?rkk?inen wrote:
> Check http://nrg.joroinen.fi/yle.log
> 
> It's a tcpdump log from pptp server (running pppd 2.4.2).
> 
> The pptp-client tries to load www.yle.fi in the web browser, but the
> pptp-server _rejects_ all the packets coming from www.yle.fi web server.
> 
> why? Because the pptp-server ppp-interface MTU is set to x-4, when
> pptp-client ppp-interface mtu is set to x. 
> x is the value that is defined in the ppp-server config file.

I see.  So the client is not running pppd?  This client will send frames
larger than the link MTU. :(

> Basicly the pptp-server tells to web-server (all the time) that the
> web-server needs to fragment the packets, because they cannot fit to the 
> ppp-tunnel (and the packets have Dont Fragment-bit set). This is part of the
> PMTUD.

Yes, that is correct operation.

> Now, the problem is, that the web-server is already sending packets which
> have *right* size (the size client told), but the pptp-server rejects them
> because of the ppp-interface MTU is too low (in the pptp server). 

The right size?  The server is doing PMTU-D (evidenced by DF bit) but
not handling ICMP frag-needed messages.  This is broken.  Consider that
*any* link in the path could have a smaller MTU.  The TCP session will
still have the same MSS because the endpoints don't know about the
smaller MTU (unless they've already performed and cached PMTU-D data
between themselves; I think most implementations do this).

RFC 2923 is some interesting things to say on this subject.

So I'm loathe to "fix" this because pppd is doing the right thing.
If the site in question isn't going to handle ICMP frag-needed, then
it shouldn't be setting DF!

It wouldn't be hard to add an option mppe-broken-pmtu-for-stupid-sites
or something equally nasty sounding.  But you will have a problem with
1500 MTU links (as oppposed to the 1400 in your example -- does pptpd
automatically reduce by 100 for some reason?)  And you can't fix the
case when some other link has a smaller MTU.  I guess there could
be another option capping the point at which the MTU isn't reduced.
Now we're talking about ugly workarounds for someone else's problem.
ugh.

I'd really rather not change correct operation.

/fc

Re: ppp-2.4.2 released

[James Cameron]

On Mon, Feb 02, 2004 at 12:56:52PM +0200, Pasi K?rkk?inen wrote:
> Check http://nrg.joroinen.fi/yle.log
> It's a tcpdump log from pptp server (running pppd 2.4.2).

The reason why PMTU-D is not working here is that the ICMP "need to
frag" message did not change behaviour of www.yle.fi.  The pptp-server
host is doing the right thing in generating this ICMP response; it's how
PMTU-D is supposed to work.  The www.yle.fi server should reduce the
MSS and retransmit a shorter packet.

Possible reasons why it isn't working;

- the "need to frag" MTU in the ICMP response by pptp-server is wrong,
  (but it says 1396, data segment was 1360, plus 40, so it seems right
  to me),

- the ICMP response is not reaching www.yle.fi, (a common problem after
  that ICMP propogating worm, many admins shut off ICMP blindly),

- www.yle.fi is ignoring ICMP responses.

> why? Because the pptp-server ppp-interface MTU is set to x-4, when
> pptp-client ppp-interface mtu is set to x. 
> x is the value that is defined in the ppp-server config file.

What evidence do you have that the pptp-client ppp-interface MTU is set
to X?  Is your evidence just the MSS in the SYN packet?

> Now, the problem is, that the web-server is already sending packets which
> have *right* size (the size client told), but the pptp-server rejects them
> because of the ppp-interface MTU is too low (in the pptp server). 

The client cannot know the right size for the path, so it only suggests
an MSS of 1360 during the SYN packet.  Where did the client get this
size from?  (presumably the client isn't running pppd 2.4.2?)

So even if the pptp-client host is incorrectly setting the interface
MTU, and hence the MSS in the SYN packet, PMTU-D should work to sustain
the connection.

Note that the www.yle.fi is honouring the MSS in the SYN packet.

(While it isn't what you want, there is a hack in iptables that will
clamp the MSS to the PMTU ... "iptables --append FORWARD --protocol tcp 
--tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu" or even
"--set-mss 1346" see http://lartc.org/howto/lartc.cookbook.mtu-mss.html)

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Mon, Feb 02, 2004 at 10:09:56AM -0800, Frank Cusack wrote:
> On Mon, Feb 02, 2004 at 12:56:52PM +0200, Pasi K?rkk?inen wrote:
> > Check http://nrg.joroinen.fi/yle.log
> > 
> > It's a tcpdump log from pptp server (running pppd 2.4.2).
> > 
> > The pptp-client tries to load www.yle.fi in the web browser, but the
> > pptp-server _rejects_ all the packets coming from www.yle.fi web server.
> > 
> > why? Because the pptp-server ppp-interface MTU is set to x-4, when
> > pptp-client ppp-interface mtu is set to x. 
> > x is the value that is defined in the ppp-server config file.
> 
> I see.  So the client is not running pppd?  This client will send frames
> larger than the link MTU. :(
> 

The client in this case was winxp.

> > Basicly the pptp-server tells to web-server (all the time) that the
> > web-server needs to fragment the packets, because they cannot fit to the 
> > ppp-tunnel (and the packets have Dont Fragment-bit set). This is part of the
> > PMTUD.
> 
> Yes, that is correct operation.
> 

Yep, just like it should be. Except that the pmtud fails and the client
doesn't receive anything.

> > Now, the problem is, that the web-server is already sending packets which
> > have *right* size (the size client told), but the pptp-server rejects them
> > because of the ppp-interface MTU is too low (in the pptp server). 
> 
> The right size?  The server is doing PMTU-D (evidenced by DF bit) but
> not handling ICMP frag-needed messages.  This is broken.  Consider that
> *any* link in the path could have a smaller MTU.  The TCP session will
> still have the same MSS because the endpoints don't know about the
> smaller MTU (unless they've already performed and cached PMTU-D data
> between themselves; I think most implementations do this).
> 

It seems that the www.yle.fi web server doesn't send packets shorter than
mss+headers (=mtu). MSS is determined in the pptp-client from the ppp
MTU/MRU.

www.yle.fi is accepting icmp / fragmentation needed. The problem is not with
icmp.  

> RFC 2923 is some interesting things to say on this subject.
> 
> So I'm loathe to "fix" this because pppd is doing the right thing.
> If the site in question isn't going to handle ICMP frag-needed, then
> it shouldn't be setting DF!
> 
> It wouldn't be hard to add an option mppe-broken-pmtu-for-stupid-sites
> or something equally nasty sounding.  But you will have a problem with
> 1500 MTU links (as oppposed to the 1400 in your example -- does pptpd
> automatically reduce by 100 for some reason?)  And you can't fix the
> case when some other link has a smaller MTU.  I guess there could
> be another option capping the point at which the MTU isn't reduced.
> Now we're talking about ugly workarounds for someone else's problem.
> ugh.
> 
> I'd really rather not change correct operation.
> 

I'm not sure what is the correct behaviour, but www.yle.fi doesn't send
shorter packets than mss+headers (mss told by the client).

And the client get's the mss from mtu/mru of the ppp link. So if you specify
mtu/mru as 1400 in the ppp-server config file, the client get's 1400 bytes
mtu/mru. The ppp-server (running mppe) now sets the mtu/mru to 1396. 

And then when www.yle.fi is sending packets of size 1400 (with DF set), the
server rejects them. 

The last couple of lines in the log (nrg.joroinen.fi/yle.log) are repeated for 
some time, and then the connection dies. The client receives absolutely 
nothing (the browser just waits and waits).

So either pppd is broken, or www.yle.fi tcp/ip stack is broken..

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Tue, Feb 03, 2004 at 10:11:59AM +1100, James Cameron wrote:
> On Mon, Feb 02, 2004 at 12:56:52PM +0200, Pasi K?rkk?inen wrote:
> > Check http://nrg.joroinen.fi/yle.log
> > It's a tcpdump log from pptp server (running pppd 2.4.2).
> 
> The reason why PMTU-D is not working here is that the ICMP "need to
> frag" message did not change behaviour of www.yle.fi.  The pptp-server
> host is doing the right thing in generating this ICMP response; it's how
> PMTU-D is supposed to work.  The www.yle.fi server should reduce the
> MSS and retransmit a shorter packet.
> 

The reason why www.yle.fi is not reducing the size, is that the size already
is what the client told (mss+headers). I think so..

> Possible reasons why it isn't working;
> 
> - the "need to frag" MTU in the ICMP response by pptp-server is wrong,
>   (but it says 1396, data segment was 1360, plus 40, so it seems right
>   to me),
> 

Yep. 

> - the ICMP response is not reaching www.yle.fi, (a common problem after
>   that ICMP propogating worm, many admins shut off ICMP blindly),
> 

ICMP is working well between the sites.. and the fragmentation needed packets
are going to to the www.yle.fi web server.

> - www.yle.fi is ignoring ICMP responses.
>

Hmm.. I don't think so. 

btw. the same web site works well with win2k-server's pptp server.
 

> > why? Because the pptp-server ppp-interface MTU is set to x-4, when
> > pptp-client ppp-interface mtu is set to x. 
> > x is the value that is defined in the ppp-server config file.
> 
> What evidence do you have that the pptp-client ppp-interface MTU is set
> to X?  Is your evidence just the MSS in the SYN packet?
> 

Yep. If I understood the code right, only the MTU of the interface is
changed, but the client get's the MTU specified in the config file.. ?

> > Now, the problem is, that the web-server is already sending packets which
> > have *right* size (the size client told), but the pptp-server rejects them
> > because of the ppp-interface MTU is too low (in the pptp server). 
> 
> The client cannot know the right size for the path, so it only suggests
> an MSS of 1360 during the SYN packet.  Where did the client get this
> size from?  (presumably the client isn't running pppd 2.4.2?)
>

The client in this case was winxp. I think it calculates the MSS from the
MTU/MRU of the PPP link.
 
> So even if the pptp-client host is incorrectly setting the interface
> MTU, and hence the MSS in the SYN packet, PMTU-D should work to sustain
> the connection.
>

I think so too. but www.yle.fi web server doesn't want to go below
mss (told by the client) + headers.
 
> Note that the www.yle.fi is honouring the MSS in the SYN packet.
>

Yep, it is.
 
> (While it isn't what you want, there is a hack in iptables that will
> clamp the MSS to the PMTU ... "iptables --append FORWARD --protocol tcp 
> --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu" or even
> "--set-mss 1346" see http://lartc.org/howto/lartc.cookbook.mtu-mss.html)
> 

I'll take a look at this. Thanks.

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Frank Cusack]

On Tue, Feb 03, 2004 at 01:17:56PM +0200, Pasi K?rkk?inen wrote:
> I'm not sure what is the correct behaviour, but www.yle.fi doesn't send
> shorter packets than mss+headers (mss told by the client).

That's incorrect on behalf of www.yle.fi.  The client can never know the
PMTU in the server->client direction.  Even in the client->server direction,
it can change during the lifetime of a connection.  Read the RFC I mentioned.

When doing PMTU-D, one must not clamp the segment size to the MSS.

> So either pppd is broken, or www.yle.fi tcp/ip stack is broken..

The latter.

/fc

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Tue, Feb 03, 2004 at 06:33:23AM -0800, Frank Cusack wrote:
> On Tue, Feb 03, 2004 at 01:17:56PM +0200, Pasi K?rkk?inen wrote:
> > I'm not sure what is the correct behaviour, but www.yle.fi doesn't send
> > shorter packets than mss+headers (mss told by the client).
> 
> That's incorrect on behalf of www.yle.fi.  The client can never know the
> PMTU in the server->client direction.  Even in the client->server direction,
> it can change during the lifetime of a connection.  Read the RFC I mentioned.
> 
> When doing PMTU-D, one must not clamp the segment size to the MSS.
> 

OK.


> > So either pppd is broken, or www.yle.fi tcp/ip stack is broken..
> 
> The latter.
> 

OK. The problem is that www.yle.fi is not the only site showing
this problem. There are many others too.

I wonder what the right(tm) solution is.. (this problem does not happen with
microsoft pptp-server also running mppe).

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Frank Cusack]

On Tue, Feb 03, 2004 at 06:33:23AM -0800, Frank Cusack wrote:
> When doing PMTU-D, one must not clamp the segment size to the MSS.

Excuse me.  Of course, one must always clamp segment size to MSS.  What
I meant was that during the course of an existing session, the stack
must be able to REDUCE the segment size below the MSS.

> > So either pppd is broken, or www.yle.fi tcp/ip stack is broken..
> 
> The latter.

Even more -- if it's receiving the frag-needed messages and not caching
them, it sounds broken.  ie, even if it is "ignoring" or mishandling them
for the current session, it should be caching the result and for the next
connection within some reasonable time window -- certainly within the amount
of time a user would hit 'reload' -- use a smaller MSS.

Is www.yle.fi behind a load balancer?  The worst problems I've seen with
MSS is when load balancers are involved.

(I have spent a lot of time debugging PMTU-D in the past. ;))

/fc

Re: ppp-2.4.2 released

[Andy Gay]

fcusack@fcusack.com wrote:

>On Tue, Feb 03, 2004 at 06:33:23AM -0800, Frank Cusack wrote:
>
>Even more -- if it's receiving the frag-needed messages and not caching
>them, it sounds broken.  ie, even if it is "ignoring" or mishandling them
>for the current session, it should be caching the result and for the next
>connection within some reasonable time window -- certainly within the amount
>of time a user would hit 'reload' -- use a smaller MSS.
>  
>
Maybe the frag-needed messages aren't geting through, as was suggested 
in an earlier message. I just tried to ping www.yle.fi, got no response, 
but I can connect to port 80 on it. Likely someone is blocking all ICMP 
to it.
A traceroute to its address (194.252.88.100) stops at 194.252.88.68, 
which is probably the router at the site. So it's not getting time 
exceeded messages out. You may be able to get somewhere by contacting 
the site admins (if you can find out who that is) and asking them to 
ensure that (at least) ICMP frag-needed is not blocked there.

/Andy

Re: ppp-2.4.2 released

[Frank Cusack]

On Tue, Feb 03, 2004 at 05:10:38PM +0200, Pasi K?rkk?inen wrote:
> OK. The problem is that www.yle.fi is not the only site showing
> this problem. There are many others too.

Yeah, lots of sites don't handle PMTU-D correctly. :(

> I wonder what the right(tm) solution is.. (this problem does not happen with
> microsoft pptp-server also running mppe).

MS pptp-server is broken for ppp though.  It sends frames that are too
large (>MTU).  This will break some pppd's.  Maybe I can work up a patch
in the next few days.  Don't hold your breath, though.

/fc

Re: ppp-2.4.2 released

[James Cameron]

On Tue, Feb 03, 2004 at 08:25:55AM -0800, Frank Cusack wrote:
> MS pptp-server is broken for ppp though.  It sends frames that are too
> large (>MTU).  This will break some pppd's.  Maybe I can work up a patch
> in the next few days.  Don't hold your breath, though.

If you need motivation, section 3.3.4 of RFC1812 says that a router (in
this case pppd) SHOULD be willing to receive a packet as large as the
maximum frame size even if that is larger than the MTU.

http://www.faqs.org/rfcs/rfc1812.html

It then goes on to say ...

      If a network is using an MTU smaller than the maximum frame size
      for the Link Layer, a router may receive packets larger than the
      MTU from misconfigured and incompletely initialized hosts.  The
      Robustness Principle indicates that the router should successfully
      receive these packets if possible.

I've no idea what supercedes RFC1812.

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

Re: ppp-2.4.2 released

[James Cameron]

On Tue, Feb 03, 2004 at 01:24:27PM +0200, Pasi K?rkk?inen wrote:
> The reason why www.yle.fi is not reducing the size, is that the size already
> is what the client told (mss+headers). I think so..

No, I disagree.  I'll repeat a critical aspect; the client CANNOT know
the right MTU for the path as a whole.  Sure, it knows the MTU of the
link next to it, and it will start a connection with an MSS that is
compatible with that ... but the client has no knowledge of the network
between the router (the pptp-server) and www.yle.fi.

e.g.

    www.yle.fi = router = router .. router = pptp-server -- client

    = is a link with MTU of 1500
    -- is a link with MTU of 1400
    .. is a link with MTU of  600

(I know this is not the case, I'm using it as an illustration of
principle).

Path MTU discovery overrides MSS in a TCP connection.  It must do, or
else a link somewhere else along the way with a small MTU would never be
handled properly.

Have you proved ICMP fragmentation needed packets have arrived at
www.yle.fi?  A packet trace at that host would be the proof.

> I think so too. but www.yle.fi web server doesn't want to go below
> mss (told by the client) + headers.

Just repeating myself; www.yle.fi MUST go below the client's MSS if
PMTUD results in a lower value.  As Frank said, the MTU might be
assymetric.  As I say, it might be that there's another restricted link.
The evidence you present leads me to suspect ICMP filtering.

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Tue, Feb 03, 2004 at 07:13:39AM -0800, Frank Cusack wrote:
> On Tue, Feb 03, 2004 at 06:33:23AM -0800, Frank Cusack wrote:
> > When doing PMTU-D, one must not clamp the segment size to the MSS.
> 
> Excuse me.  Of course, one must always clamp segment size to MSS.  What
> I meant was that during the course of an existing session, the stack
> must be able to REDUCE the segment size below the MSS.
> 
> > > So either pppd is broken, or www.yle.fi tcp/ip stack is broken..
> > 
> > The latter.
> 
> Even more -- if it's receiving the frag-needed messages and not caching
> them, it sounds broken.  ie, even if it is "ignoring" or mishandling them
> for the current session, it should be caching the result and for the next
> connection within some reasonable time window -- certainly within the amount
> of time a user would hit 'reload' -- use a smaller MSS.
> 
> Is www.yle.fi behind a load balancer?  The worst problems I've seen with
> MSS is when load balancers are involved.
>

I think so.. netcraft says the OS is unknown, but it's running Apache on
Unix.. 
 
> (I have spent a lot of time debugging PMTU-D in the past. ;))
> 

Heh.. well at least you learn well how things _should_ work :)

I'll contact www.yle.fi admins and ask about the pmtud problem.

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Tue, Feb 03, 2004 at 11:24:42AM -0500, Andy Gay wrote:
> 
> 
> fcusack@fcusack.com wrote:
> 
> >On Tue, Feb 03, 2004 at 06:33:23AM -0800, Frank Cusack wrote:
> >
> >Even more -- if it's receiving the frag-needed messages and not caching
> >them, it sounds broken.  ie, even if it is "ignoring" or mishandling them
> >for the current session, it should be caching the result and for the next
> >connection within some reasonable time window -- certainly within the 
> >amount
> >of time a user would hit 'reload' -- use a smaller MSS.
> > 
> >
> Maybe the frag-needed messages aren't geting through, as was suggested 
> in an earlier message. I just tried to ping www.yle.fi, got no response, 
> but I can connect to port 80 on it. Likely someone is blocking all ICMP 
> to it.
>

At least it reacts to pmtud frag needed icmp packets.. but still doesn't
work right.

I think it's some kind of loadbalanced (netcraft says the OS is unknown),
which is causing the problems.

> A traceroute to its address (194.252.88.100) stops at 194.252.88.68, 
> which is probably the router at the site. So it's not getting time 
> exceeded messages out. You may be able to get somewhere by contacting 
> the site admins (if you can find out who that is) and asking them to 
> ensure that (at least) ICMP frag-needed is not blocked there.
> 

Yeah. I'll do this.

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Wed, Feb 04, 2004 at 09:11:05AM +1100, James Cameron wrote:
> On Tue, Feb 03, 2004 at 01:24:27PM +0200, Pasi K?rkk?inen wrote:
> > The reason why www.yle.fi is not reducing the size, is that the size already
> > is what the client told (mss+headers). I think so..
> 
> No, I disagree.  I'll repeat a critical aspect; the client CANNOT know
> the right MTU for the path as a whole.  Sure, it knows the MTU of the
> link next to it, and it will start a connection with an MSS that is
> compatible with that ... but the client has no knowledge of the network
> between the router (the pptp-server) and www.yle.fi.
> 
> e.g.
> 
>     www.yle.fi = router = router .. router = pptp-server -- client
> 
>     = is a link with MTU of 1500
>     -- is a link with MTU of 1400
>     .. is a link with MTU of  600
> 
> (I know this is not the case, I'm using it as an illustration of
> principle).
> 
> Path MTU discovery overrides MSS in a TCP connection.  It must do, or
> else a link somewhere else along the way with a small MTU would never be
> handled properly.
> 

Good diagram. That clarified the whole thing. 

> Have you proved ICMP fragmentation needed packets have arrived at
> www.yle.fi?  A packet trace at that host would be the proof.
> 

I'll ask them.. 

> > I think so too. but www.yle.fi web server doesn't want to go below
> > mss (told by the client) + headers.
> 
> Just repeating myself; www.yle.fi MUST go below the client's MSS if
> PMTUD results in a lower value.  As Frank said, the MTU might be
> assymetric.  As I say, it might be that there's another restricted link.
> The evidence you present leads me to suspect ICMP filtering.
> 

Yep. This is obvious now. Maybe it's broken icmp handling in the
loadbalancer..

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Re: ppp-2.4.2 released

[Bernard Blackham]

A while ago, Pasi wrote:
> > > > > There's still the MTU bug (with MPPE) left..

> > What bug is that?

> I've sent couple of mails about this.. I'll explain it below.

> Now, the problem is, that the web-server is already sending packets which
> have *right* size (the size client told), but the pptp-server rejects them
> because of the ppp-interface MTU is too low (in the pptp server). 
> 
> pppd/ccp.c near line 1192:
> 
> mtu = netif_get_mtu(f->unit);
> if (mtu)
>     netif_set_mtu(f->unit, mtu - MPPE_PAD);
> else
>     newret = CONFREJ;
> 
> MPPE_PAD is defined as 4.
> 
> 
> The pptp client sets the MTU to x (for example 1400), and the pptp server sets 
> the MTU to x-4 (1396). This obviously happens only when using MPPE.
> 
> The pptp-client is not able to load the web page at all, because the client
> doesn't receive any data from the web server! the pptp-server rejects the
> incoming (http) packets.
> 
> This does not happen with all web sites.

Just a metoo message - I've been experiencing the exact same
problems here. We have a poptop server serving over 100 concurrent
connections and many users have noted that they weren't able to
access the campus website.

The campus website is behind a Cisco load balancer, so this may be a
suspect in breaking PMTU. Disabling the above lines of code also
solved the problem here though and we've had few complaints since.

Regards,

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>

Re: ppp-2.4.2 released

[Pasi Kärkkäinen]

On Wed, Mar 03, 2004 at 07:13:08AM +0800, Bernard Blackham wrote:
> A while ago, Pasi wrote:
> > > > > > There's still the MTU bug (with MPPE) left..
> 
> > > What bug is that?
> 
> > I've sent couple of mails about this.. I'll explain it below.
> 
> > Now, the problem is, that the web-server is already sending packets which
> > have *right* size (the size client told), but the pptp-server rejects them
> > because of the ppp-interface MTU is too low (in the pptp server). 
> > 
> > pppd/ccp.c near line 1192:
> > 
> > mtu = netif_get_mtu(f->unit);
> > if (mtu)
> >     netif_set_mtu(f->unit, mtu - MPPE_PAD);
> > else
> >     newret = CONFREJ;
> > 
> > MPPE_PAD is defined as 4.
> > 
> > 
> > The pptp client sets the MTU to x (for example 1400), and the pptp server sets 
> > the MTU to x-4 (1396). This obviously happens only when using MPPE.
> > 
> > The pptp-client is not able to load the web page at all, because the client
> > doesn't receive any data from the web server! the pptp-server rejects the
> > incoming (http) packets.
> > 
> > This does not happen with all web sites.
> 
> Just a metoo message - I've been experiencing the exact same
> problems here. We have a poptop server serving over 100 concurrent
> connections and many users have noted that they weren't able to
> access the campus website.
> 
> The campus website is behind a Cisco load balancer, so this may be a
> suspect in breaking PMTU. Disabling the above lines of code also
> solved the problem here though and we've had few complaints since.
> 

Good to hear. 

Even if this is not a pppd bug, I think we should create some kind of
workaround (option?) for this?

Other ppp-servers don't seem to have this same problem.. so it makes you
feel that pppd is broken :)

-- Pasi Kärkkäinen
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.