V1.3, 09-APR-2008

Update version number. We forgot to do so for the 1.2 release, so 1.2
claims it is 1.1!!

Fix a bug in the handling of the host_name AVP which would cause junk
characters on the end of the name, depending on the order of the AVPs
in the message. If this AVP is followed by an AVP with its Mandatory
bit set, the host_name string isn't null-terminated, so OpenL2TP
includes extra characters in the string. Since the host_name AVP can
be used by OpenL2TP to find a matching peer profile or to do simple
tunnel authentication, this was causing tunnel setup problems with
some vendor equipment (Huawei). This problem was reported by Keith

Remove the validation checks on the M-bit of AVPs. The L2TP spec
specifies whether the M-bit should be set or clear for each AVP, so
OpenL2TP used to validate that and reject messages from peers that did
not conform to the spec. It has recently been found that Huawei L2TP
implementations set the M-bit incorrectly in some AVPs which caused
tunnel setup problems. But further research into L2TPv3 (which is not
yet supported by OpenL2TP) found that L2TPv3 _requires_ that L2TPv2
implementations do not validate AVP M-bit values against the L2TPv2
spec. So for L2TPv3 interopability, this check has been removed.

Rewrite the pppd-to-openl2tpd interface to use regular Unix domain
sockets rather than RPC. This interface is used by pppd to tell
openl2tpd when the ppp interface comes up or goes down. While RPC is
good for the management interface where the command client and L2TP
server may run on machines with different architectures, the pppd
processes always run on the same CPU as openl2tpd, so the complexity
of RPC is overkill. Users won't see any behaviour change - things
should work exactly as before. Heavy users (ISPs) might notice some
performance improvement when setting up or tearing down thousands of
PPP sessions.