Recent changes to bugs

wrong size in vsnprintf in l2tpns.c function _log - solved

Oliver Kaufmann — Tue, 02 Aug 2011 11:40:57 -0000

Bug in l2tpns.c in in function _log: Fix included (please verify).

// fixed size of 4095 in vsnprintf is wrong, must not be greater than sizeof(message) from the struct. Otherwise you get *** buffer overflow detected *** when compiled under recent gcc. With this fix, l2tpns compiles and works again.
// replace as shown in l2tpns.c in function _log
- vsnprintf(ringbuffer->buffer[ringbuffer->tail].message, 4095, format, ap);
+ vsnprintf(ringbuffer->buffer[ringbuffer->tail].message, sizeof(ringbuffer->buffer[ringbuffer->tail].message), format, ap);

l2tpns not closing tunnels correctly

J Gropefruit — Tue, 29 Mar 2011 20:23:32 -0000

l2tpns manages its tunnels in a way that is causing us some headaches. We are not receiving radius accounting-records for STOP events when each user disconnects, and we are seeing events in l2tpns's logs indicating not-so-graceful tunnel-disconnects, regardless of the users' disconnect-method.

It seems as if l2tpns does not acknowledge tunnels being terminated (either deliberately by the user, or due to a failure on the client-side), and as a result, is not sending a STOP-accounting Radius record to our logs when it should.

We ARE successfully receiving START and INTERIM-UPDATE records ..... but STOP records show up rarely (and sporadically).

Observe this variety of different 'disconnect events' in our logs:

2011-03-29 12:29:34 01/00 Shutting down tunnel 1 (Stopped)
2011-03-29 12:29:51 03/00 New tunnel from PUB.IP.PUB.IP:52984 ID 3
2011-03-29 12:30:07 03/00 Out of sequence tunnel 3, (5 is not the expected 4)
2011-03-29 12:30:20 02/00 Kill tunnel 2: Expired
2011-03-29 12:30:20 02/00 New tunnel from PUB.IP.PUB.IP:58116 ID 2
2011-03-29 12:30:31 02/00 Out of sequence tunnel 2, (5 is not the expected 4)
2011-03-29 12:30:37 04/00 New tunnel from PUB.IP.PUB.IP:59366 ID 4
2011-03-29 12:30:44 01/00 Kill tunnel 1: Expired
2011-03-29 12:31:00 04/00 Out of sequence tunnel 4, (5 is not the expected 4)
2011-03-29 12:31:12 01/00 New tunnel from PUB.IP.PUB.IP:60088 ID 1
2011-03-29 13:00:16 01/00 Kill tunnel 1: Timeout on control message
2011-03-29 13:01:45 02/00 Out of sequence tunnel 2, (5 is not the expected 4)
2011-03-29 13:03:49 02/00 Kill tunnel 2: Timeout on control message

However, as I said, we ARE seeing acknowledgments that the session STARTS and we receive very timely INTERIM-UPDATES for still-connected sessions.

We have tried a few releases (2.1.21-1.1, 2.1.21-1.5 and we also custom-compiled our own 2.1.21-1.5 build with which to test).

We are testing on Debian Lenny amd64.

no free tunnel !!!!

Anonymous — Wed, 11 Feb 2009 08:24:16 -0000

The error information is "
Can't find a free tunnel! There shouldn't be this many in use".

l2tpns version 2.1.21.
The max number of users is 499. Why can't the server support more users?

Throttling incompatible with IPv6

Anonymous — Wed, 13 Aug 2008 11:34:57 -0000

Hi,

I spent the last few hours scratching my head over why I couldn't get IPv6 working... the main problem was a total block of traffic in the direction of LNS --> CPE.

Running Wireshark on the LNS' tun0 showed ICMPv6 requests arriving from the CPE and being replied to by the LNS although the CPE didn't show these packets as being received.

After backing up my config at both ends, I tried lots of stuff eventually ending in removing the throttling for this session (reason: it is provisioned as 24Mbit/s by the telco but throttled down to 8Mbit/s) and IPv6 connectivity worked in both directions.

Putting the config back to sane defaults (incl. throttling) and then removing the throttling demonstrated that this was definitely the case.

Throttling works perfectly with any IPv4 traffic; so there are no problems there, or with IPv6, just so long as they are not running in unison.

I can be mailed at grm@fcvyfol.arg (ROT13'd to protect against spam!) but I'm happy to test any patches or help to debug this further.

I would also be interested in implementing a patch for this but would appreciate a quick explanation as to the 'journey of a packet through l2tpns' so I know where to concentrate my efforts.

Regards,
Terry

ip_pool does not support ip ranges smaller than a /24

Anonymous — Thu, 27 Mar 2008 06:02:35 -0000

It apears that ranges smaller than a /24 are not handled correctly by l2tpns.

For example, if you add 192.168.2.64/26 to the ip_pool config file, l2tpns will still hand out 192.168.2.64 as the first address when this should be reserved as the network address.

I believe this should be an easy fix in the l2tpns.c add_to_ip_pool function.

I would attempt it myself, but my c programming is not that flash :)

unhide_value problem

Anonymous — Tue, 03 Jul 2007 15:09:02 -0000

I think that the code in the unhide_value fonction is the code for hiding values.
the patch to convert the code is in attachment

cannot compile 2.1.1

Anonymous — Thu, 16 Jun 2005 01:08:54 -0000

make

gcc -o l2tpns arp.o cli.o cluster.o constants.o
control.o icmp.o l2tpns.o ll.o md5.o ppp.o radius.o
tbf.o util.o bgp.o -lm -lcli -ldl
cli.o(.text+0xcfd): In function `cli_arg_help':
/usr/local/src/l2tpns-2.1.1/cli.c:371: undefined
reference to `cli_error'
cli.o(.text+0xd39):/usr/local/src/l2tpns-2.1.1/cli.c:378:
undefined reference to `cli_error'
cli.o(.text+0x2fcc): In function `cmd_drop_user':
/usr/local/src/l2tpns-2.1.1/cli.c:1180: undefined
reference to `cli_error'
cli.o(.text+0x2fe0):/usr/local/src/l2tpns-2.1.1/cli.c:1172:
undefined reference to `cli_error'
cli.o(.text+0x30ba): In function `cmd_drop_tunnel':
/usr/local/src/l2tpns-2.1.1/cli.c:1221: undefined
reference to `cli_error'
cli.o(.text+0x312c):/usr/local/src/l2tpns-2.1.1/cli.c:1213:
more undefined references to `cli_error' follow
collect2: ld returned 1 exit status
make: *** [l2tpns] Error 1

CHAP not working with Windows 2000 client

Anonymous — Wed, 01 Jun 2005 09:06:32 -0000

I'm trying l2tpns with a Windows 2000 client using CHAP
authentication. This setup (with the same client
config) works Ok in l2tpd, and also works Ok in l2tpns
if I set up the client to use PAP.

However, when using CHAP l2tpns prints this to the log
(full log attached):

PPP LCP Packet type 1 (ConfigReq len 44)
Length: 44
Magic-Number 57856b41
Protocol-Field-Compression
Address-and-Control-Field-Compression
Unknown PPP LCP Option type 13
Unknown PPP LCP Option type 17
Unknown PPP LCP Option type 19
Rejecting PPP LCP Option type 13
Rejecting PPP LCP Option type 17
Rejecting PPP LCP Option type 19
Sending ConfigRej
Sending LCP ConfigReq for PAP
LCP: ConfigReq (14 bytes)...
PPP LCP Packet type 1 (ConfigReq len 14)
Length: 14
Magic-Number 57856b41
Protocol-Field-Compression
Sending ConfigAck
Sending LCP ConfigReq for PAP
Remote end sent a ConfigNak. Ignoring
PPP LCP Packet type 3 (ConfigNak len 9)
Length: 9
Remote end sent a ConfigNak. Ignoring
PPP LCP Packet type 3 (ConfigNak len 9)
Length: 9

It seems that l2tpns does not request CHAP
authentication, and I have not found a way to make it
use CHAP rather than PAP. The client times out, as it's
ConfigNak message refusing PAP is ignored.

socket() returns -1 if it fails, not 0.

Bjorn Augestad — Wed, 10 Nov 2004 14:52:55 -0000

Below is a code snippet where you have a bug:

void host_unreachable(ipt destination, u16 id, ipt
source, char *packet, int packet_len)
{
char buf[128] = {0};
struct iphdr *iph;
struct icmphdr *icmp;
char *data;
int len = 0, on = 1, icmp_socket;
struct sockaddr_in whereto = {0};

if (!(icmp_socket = socket(AF_INET, SOCK_RAW,
IPPROTO_RAW)))
return;

I guess the summary says it all, socket() returns -1 if
it fails.

HTH
boa

Windows 98 Client Hangs

Anonymous — Tue, 10 Aug 2004 22:46:21 -0000

When using a Ascent APX (LAC) to trunk the calls back
to L2TPNS 2.01, Windows 98 crashes or hangs, and
Windows 95 will not connect. To partially fix the
problem, set the APX to only allow PAP authentication.
This will allow Windows 98 SE client to connect,
however Windows 95 clients still cannot connect. It
seems the problem is that L2TPNS is requiring PAP
authentication from the client/LAC, however for
win95/98/me clients that initially used CHAP to auth
the LAC would request a re-auth using PAP protocol, and
at this point the win95/98/me client hangs