Recent changes to patches

Patches for multi ip_pools and IPv6

Issa Alkaht — Sun, 27 Jun 2021 11:21:45 -0000

These are patches to allow assigning IP to subscribers from different pools based on radius reply.
For IPv6 the code is modified to make L2TPNS send framed-ipv6-address to radius in accounting message.

The patches are applied in production environment, with no issues since a week ago.

Multiple bugfixes & features repository

Anonymous — Mon, 02 Jan 2012 21:52:52 -0000

Hi,

Some months ago I worked quite a bit on l2tpns to add features we needed here at FDN (a small french ISP) and bugfixes. My repository includes:
- RFC 4760 support (aka IPv6 routes announcement)(we ended up not using it, but it works)
- Netlink usage instead of ioctl
- Bugfixes
- Some cleanup
- Small enhancements

The first two items are on separate branches, other ones sit in fdn-mods or in master when they are generic enough (the latest modifications may not have been integrated into master because of lack of time). I based my work on the Debian sources and an import of your CVS, not your current git repository, as it didn't exist at the time.

This code (except RFC 4760 and the very latest fixes) has been running in production for 3 months now without problem.

One nice thing to plan now we have netlink support would be to “request” a proto number (the database seemed to be maintained by the iproute2 guys) so that we can mark the routes we had (we use BIRD to learn l2tpns routes coming from the RIB, matching on the interface name ; matching on the proto would be nicer). We could also think about adding an option to add routes to a specific kernel table.

The repository is here: http://dolka.fr/code/l2tpns.git/

Regards,
Benjamin

[patch] MacOSX rejects invalid HELLO message

Cyril Elkaim — Thu, 11 Mar 2010 18:35:46 -0000

MacOSX sends the following message when trying to connect to l2tpns "L2TP received invalid message (expected ICRP, received Hello)". It appears that the lastrec attribute of a tunnel is not correctly initialized during the tunnel creation. At least it's what I believe :)

Joined you'll find a patch that initialized this variable and seems to correct the problem (at least for me).

Patch for MS-NBNS (WinS) support

Manuel Garcia Montero — Thu, 19 Jun 2008 10:33:40 -0000

This simple patch adds support to asing via radius wins servers.

Attributes are, according to rfc2548:

MS-Primary-NBNS-Server
MS-Secondary-NBNS-Server

patch to allow for subnets smaller than a /24 in ip_pool

Leighton Weymouth — Fri, 28 Mar 2008 12:33:00 -0000

See bug description here:
https://sourceforge.net/tracker/index.php?func=detail&aid=1926823&group_id=97282&atid=617563

No TBFs assigned when rate limiting via RADIUS CoA

Daryl Tester — Tue, 24 Apr 2007 12:41:27 -0000

When setting/clearing rate limiting via RADIUS CoA,
the TBFs don't appear to be assigned so while the
session shows as being rate limited the users has full speed. The following trivial patch runs f->throttle() after the rate has been set.

Patch for multiple instances on same machine

Marcus — Mon, 02 Apr 2007 18:45:57 -0000

Here are some small modifications that may be useful for future versions. The main goal was to allow two instances running on the same machine
(running on different interfaces).

- new command line

-p <port> cli listening port (default: 23)
-l <addr> cli bind address (default: INADDR_ANY)

- configuration file

set ippool_file <filename> (default: const IPPOOLFILE)

Btw: Thanks for this great implementation... Any other implementations I've seen were awful but this works perfectly since about one year.

Below the diff against 2.1.21

diff l2tpns-2.1.21/cli.c l2tpns-2.1.21-mz/cli.c
132c132
< void init_cli(char *hostname)
---
> void init_cli(char *hostname, char *cliaddr, int cliport)
270a271,289
> addr.sin_family = AF_INET;
> addr.sin_port = htons(cliport);
>
> if (cliaddr && *cliaddr)
> {
> addr.sin_addr.s_addr = htonl(INADDR_ANY);
> }
> else
> {
> struct hostent *hp = gethostbyname2(cliaddr, AF_INET);
> if (hp == NULL || hp->h_addr_list[0] == NULL)
> {
> LOG(0, 0, 0, "Error resolving cli bind address %s: %s\n",
cliaddr, strerror(errno));
> return;
> }
> bcopy(hp->h_addr_list[0], &addr.sin_addr, hp->h_length);
> }
>
>
279,280c298
< addr.sin_family = AF_INET;
< addr.sin_port = htons(23);
---
>
283c301,302
< LOG(0, 0, 0, "Error listening on cli port 23: %s\n",
strerror(errno));
---
> LOG(0, 0, 0, "Error listening on cli address %s:%d: %s\n",
> inet_ntoa(addr.sin_addr), cliport, strerror(errno));
Common subdirectories: l2tpns-2.1.21/Docs and l2tpns-2.1.21-mz/Docs
Common subdirectories: l2tpns-2.1.21/etc and l2tpns-2.1.21-mz/etc
diff l2tpns-2.1.21/l2tpns.c l2tpns-2.1.21-mz/l2tpns.c
72a73,74
> char cliaddr[1000] = ""; // us.
> int cliport = 23; // port to bind cli, default is 23
149a152
> CONFIG("ippool_file", ippool_file, STRING),
4013c4016
< if (!(f = fopen(IPPOOLFILE, "r")))
---
> if (!(f = fopen(config->ippool_file, "r")))
4015c4018
< LOG(0, 0, 0, "Can't load pool file " IPPOOLFILE ": %s\n",
strerror(errno));
---
> LOG(0, 0, 0, "Can't load pool file %s: %s\n",
config->ippool_file, strerror(errno));
4177c4180
< while ((i = getopt(argc, argv, "dvc:h:")) >= 0)
---
> while ((i = getopt(argc, argv, "dvc:h:p:l:")) >= 0)
4196a4200,4205
> case 'l':
> snprintf(cliaddr, sizeof(cliaddr), "%s", optarg);
> break;
> case 'p':
> cliport = atoi(optarg);
> break;
4200a4210,4211
> "\t-l <address>\tCLI listen address (default:
any)\n"
> "\t-p <port>\tCLI listen port (default:
23)\n"
4216c4227
< init_cli(hostname);
---
> init_cli(hostname, cliaddr, cliport);
4381a4393,4397
> if (! *config->ippool_file)
> {
> strncpy(config->ippool_file, IPPOOLFILE,
sizeof(config->ippool_file));
> }
>
diff l2tpns-2.1.21/l2tpns.h l2tpns-2.1.21-mz/l2tpns.h
613c613,615
< // slaves is less
than this value.
---
>
> // slaves is
less than this value.
> char ippool_file[256]; // file to read ip
pool from (default is IPPOOLFILE)
794c796
< void init_cli(char *hostname);
---
> void init_cli(char *hostname, char *cliaddr, int cliport);
Common subdirectories: l2tpns-2.1.21/scripts and l2tpns-2.1.21-mz/scripts
Common subdirectories: l2tpns-2.1.21/test and l2tpns-2.1.21-mz/test

[PATCH] l2tpns MLPPP bug fixes, new features

Anonymous — Sun, 11 Mar 2007 08:50:45 -0000

Submitted by Muhammad Tayseer Alquoatli <IDOIT.IEF@gmail.com>
The submitted patch should be applied to l2tpns HEAD. The following changes has been done:

- Handle session shutdown gracefully regarding leaving the bundle (bug
that is caused when a all session leaves a bundle then another join)
- IP assignment is done only for the first session in the bundle (save
IP waste for multiple MLPPP sessions)
- Route is being added only for the first session in the bundle (less
routes on l2tpns system)
- Fix route deletion problem for MLPPP sessions (bug that caused when
a session leaves a bundle)
- Uniformity of sequence number space satisfied (according to RFC1990)
- Fix reassembling fragmented packets and handling lost fragments
(according to RFC 1990)
- Fragmentation algorithm now is implemented in a generic way
(fragmentation across N session rather than two)
- Sequence numbers extraction mask has been corrected (bug in
extracting sequence numbers)
- some clustering support fixes
- Upload/Download statistics has been corrected
- add "kill_timedout_sessions" config option

changes are tested with l2tpns-2.2.0 patched code.

Add support for the RADIUS Class attribute

Geoffrey D. Bennett — Wed, 31 Jan 2007 23:01:23 -0000

RFC 2865 says about the Class attribute: "This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported."

I've not got a cluster yet, so I have no idea if I got that bit right, but the rest seems to work for me.

Fix retx of control packets

Geoffrey D. Bennett — Wed, 31 Jan 2007 22:53:21 -0000

If the tunnel[t].window is a multiple of 256, retransmissions of lost control packets will not happen, and instead the tunnel will be dropped. This problem happens because tunnel[t].window is a uint16, but the value is being temporarily stored in a uint8 when retransmissions are done.