Update to upstream version '0.1.8'
with Debian dir 9a5286ebd560e8bc8abeb8d91b19421265147dd1

When bringing up a session as a client, go-l2tp creates the dataplane
for that session once the controlplane has fully established.

The controlplane is considered to be fully established once go-l2tp's
ICCN message has been acknowledged by the server by the rules of the
L2TP reliable transport algorithm.

Depending on the implementation of the server, and the vagaries of UDP
transmission, it's possible that the control packet acknowledging the
ICCN might arrive after the first dataplane frame.

In this scenario, the Linux kernel doesn't know what to do with the
first data frame, because go-l2tp hasn't yet created the dataplane for
the session.  It defaults to passing the data frame up to userspace in
the hopes userspace will be able to do something with it.

As such, it's possible for go-l2tp's parsing code to see data frames.
It will typically reject these, although with a rather confusing error
message:

    level=error tunnel_name=t1 function=transport message="frame receive failed"
        error="malformed header: length 17024 exceeds buffer bounds of 30"

This error stems from the fact that the Linux kernel doesn't set the
length L2TP header field for data packets: that's perfectly legitimate,
but it results in a header with the tunnel ID at the offset the length
field would normally be for a control packet.

As a result, go-l2tp parses the tunnel ID as the packet length.  Since
tunnel IDs are often randomly generated it's likely that the tunnel ID
as a numeric value will be greater than the length of the frame on the
wire, and so go-l2tp will reject the frame early in the parsing process.

This generally isn't harmful, since the logging on a "malformed header"
is just informational: however it does confound debugging efforts.

However, in the edge case that the tunnel ID was less than or equal to
the length of the frame on the wire, go-l2tp wouldn't reject the frame
and would go ahead and try to (and fail to) parse it as a control frame.
This would almost certainly cause the tunnel to be torn down.

To avoid these problems, go-l2tp can check the message type bit in the
L2TP header prior to doing any further parsing.  That allows data frames
to be dropped earlier in the process with explicit logging.

ref: https://bbs.archlinux.org/viewtopic.php?pid=1970197#p1970197

We don't currently do anything useful with these messages, just log
them (it's worth noting xl2tpd takes the same approach with SLI).

Interestingly, while RFC2661 defines these control messages it doesn't
call them out explicitly in the FSM tables, so it's not clear when they
should be expected.

However from the context it makes sense they'd be handled after the
tunnel and session was established.

For the time being, since we're just ignoring the messages, there's
little point plumbing them through to the session, so this commit
doesn't do that.

Set-Link-Info might be sent by the LNS to the LAC to set PPP-negotiated
options.

RFC2661 states:

        These options can change at any time during the life
        of the call, thus the LAC MUST be able to update its internal
        call information and behavior on an active PPP session.

In order to do this, go-l2tp would need some way to dynamically send
updated ACCM information to pppd, which implies some kind of IPC between
pppd and go-l2tp.

WAN-Error-Notify shouldn't really be seen by go-l2tp currently since
it's supposed to be sent by the LAC to the LNS.  However we might as
well add minimal handling for it just in case.

Fixes #6

Add message specifications for the following L2TPv2 control messages:

 * WAN-Error-Notify (WEN) (RFC2661 section 6.13),
 * Set-Link-Info (SLI) (RFC2661 section 6.14).

We need to at least recognise the messages, otherwise receipt of one of
them from the peer will cause the tunnel instance to be torn down.

There are some lesser-used L2TPv2 AVPs which go-l2tp doesn't currently
do anything meaningful with.

However, if we do receive one of these AVPs, we do want to be able to at
least parse it: if not, we'll potentially end up tearing the tunnel down
if the AVP is flagged as mandatory by the peer.

Treat the following L2TPv2 AVPs as byte arrays:

 * Q.931 Cause Code (RFC2661 section 4.4.4)
 * Call Errors (RFC2661 section 4.4.6)
 * ACCM (RFC2661 section 4.4.6)

All of these AVPs have some degree of internal structure which the
parser can (and at some point should) learn to understand.

For the time being, the avpDataTypeBytes type implies a minimum of
processing by the parsing code, but allows the parser to handle the
AVPs without falling over.

While we're here, treat the draft-only Packet Proc Delay in the same
way: it's unlikely we'll see it in the wild, but you never know.

Finally, update the comment for the L2TPv3-only Pseudowire Caps AVP,
which can stay as avpDataTypeUnimplemented since go-l2tp doesn't
currently implement the v3 control plane.

Update to upstream version '0.1.7'
with Debian dir 07491e9f5dde3a2d310932ab3495172ad1a7dccf

Linux kernel 9d4c75800f61 ("ipv4, ipv6: Fix handling of transhdrlen in
__ip{,6}_append_data()") causes corruption of L2TPIP6 packets on the
wire; which in turn causes the L2TPIP6 test to time out when running on
kernels with that commit.

Unfortunately, 9d4c75800f61 has been backported to at least stable
kernel linux-6.1.y, impacting Debian Bookworm and possibly other
distros too.

To avoid breaking CI pipelines, remove the L2TPIP6 transport test for
the time being.

Revert "Remove Built-Using field for now as it is suseptible to rejects with dep changes. Re-add it once accepted"

This reverts commit 045091f6.

Remove Built-Using field for now as it is suseptible to rejects with dep changes. Re-add it once accepted

Update to upstream version '0.1.6'
with Debian dir 157a328d7ce21a31ce682a3973ef1f848fb1a3b2

Update to upstream version '0.1.5'
with Debian dir d51327a518f2ef89dab83736243c0a273a88ea0d

The go-l2tp programs require root permissions to run properly, so they
should really be installed as system administration commands (e.g. under
/usr/sbin).

As such, their manpages should be in section 8 of the man subsystem, not
section 1.

The upstream project is intended to supply a library for building L2TP
applications on Linux systems.  Although it includes some useful
programs, the primary focus is the library.

As such it makes more sense to have the packaging focus on a -dev package
first and foremost: this aligns with upstream, and should make it easier
to package potential future Go programs which depend on go-l2tp.

While we're at it, since the go-l2tp programs all require root
capabilities to run, install them under usr/sbin rather than usr/bin.

Update to upstream version '0.1.4'
with Debian dir a647456d003b7144eabbc29d7a977a5115752174

Older Pandoc versions used to emit invalid font selection markup (.e.g.
\f[C]); but we never noticed this because groff didn't complain about
it.

However, groff 1.23.0 has enhanced validation checking which will now
complain about the invalid markup, causing the Debian Lintian tool on
Sid to generate warnings.

Upstream pandoc has tweaked its roff output to avoid the problem.  So,
regenerate our manpages with a newer pandoc.