l2tpd-devel Mailing List for L2TP client / daemon
Status: Inactive
Brought to you by:
dami0nd
Menu
▾
▴
l2tpd-devel — L2TPd developement discussion
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(4) |
Mar
(13) |
Apr
(33) |
May
(10) |
Jun
(25) |
Jul
(30) |
Aug
(9) |
Sep
(9) |
Oct
(37) |
Nov
(11) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(41) |
Feb
(7) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2003 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(20) |
| 2004 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2005 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
(1) |
4
|
5
|
6
|
7
|
8
|
|
9
|
10
(1) |
11
|
12
|
13
|
14
(1) |
15
|
|
16
|
17
|
18
|
19
|
20
(1) |
21
|
22
|
|
23
|
24
|
25
|
26
(1) |
27
|
28
|
29
(1) |
|
30
|
31
|
|
|
|
|
|
|
From: justin <yb...@ho...> - 2001-12-29 07:01:33
|
aGksDQogSSB3YW50IHRvICB1c2UgQ2hhbGxlbmdlIGF1dGhlbnRpY2F0aW9uDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmwydHBkLmNvbmYgaW4g TEFDOg0KW2xhYyBkZWZhdWx0XSAgICAgIDsNCjsgbG5zID0gNjEuMTUxLjIzNC4xMjIgICAgOw0K ICBsbnMgPSAxOTIuMTY4LjAuMjU0ICAgIDsNCjsgcmVkaWFsID0geWVzICAgICAgOw0KOyByZWRp YWwgdGltZW91dCA9IDE1ICAgIDsgKiBXYWl0IG4gc2Vjb25kcyBiZXR3ZWVuIHJlZGlhbHMNCjsg bWF4IHJlZGlhbHMgPSA1ICAgICA7DQo7IGF1dG9kaWFsID0geWVzICAgICA7DQo7IGhpZGRlbiBi aXQgPSB5ZXMgICAgIDsgKiBVc2VyIGhpZGRlbiBBVlAncz8NCjsgbG9jYWwgaXAgPSAxOTIuMTY4 LjAuNDAgICA7DQogIHJlbW90ZSBpcCA9IDE5Mi4xNjguMC4yNTQgICA7DQogIGxlbmd0aCBiaXQg PSBubyAgICAgOyAqIFVzZSBsZW5ndGggYml0IGluIHBheWxvYWQ/DQo7IHJlcXVpcmUgcGFwID0g eWVzICAgICA7ICogUmVxdWlyZSBQQVAgYXV0aC4gYnkgcGVlcg0KOyByZXF1aXJlIGNoYXAgPSB5 ZXMgICAgIDsgKiBSZXF1aXJlIENIQVAgYXV0aC4gYnkgcGVlcg0KOyByZWZ1c2UgcGFwID0geWVz ICAgICA7ICogUmVmdXNlIFBBUCBhdXRoZW50aWNhdGlvbg0KOyByZWZ1c2UgY2hhcCA9IHllcyAg ICAgOyAqIFJlZnVzZSBDSEFQIGF1dGhlbnRpY2F0aW9uDQo7IHJlZnVzZSBhdXRoZW50aWNhdGlv biA9IHllcyAgICA7ICogUmVmdXNlIGF1dGhlbnRpY2F0aW9uIGFsdG9nZXRoZXINCjsgcmVxdWly ZSBhdXRoZW50aWNhdGlvbiA9IHllcyAgICA7ICogUmVxdWlyZSBwZWVyIHRvIGF1dGhlbnRpY2F0 ZQ0KICBuYW1lID0geWJ6aGcgICAgICA7ICogUmVwb3J0IHRoaXMgYXMgb3VyIGhvc3RuYW1lDQog IGhvc3RuYW1lID0geWJ6aGcgICAgIDsNCiAgcHBwIGRlYnVnID0gbm8gICAgIDsgKiBUdXJuIG9u IFBQUCBkZWJ1Z2dpbmcNCiAgY2FsbCByd3MgPSAxMCAgICAgIDsgKiBSV1MgZm9yIGNhbGwgKC0x IGlzIHZhbGlkKQ0KICB0dW5uZWwgcndzID0gNCAgICAgOyAqIFJXUyBmb3IgdHVubmVsIChtdXN0 IGJlID4gMCkNCiAgZmxvdyBiaXQgPSB5ZXMgICAgIDsgKiBJbmNsdWRlIHNlcXVlbmNlIG51bWJl cnMNCiAgY2hhbGxlbmdlID0geWVzICAgICA7ICogQ2hhbGxlbmdlIGF1dGhlbnRpY2F0ZSBwZWVy IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KbDJ0cC1zZWNyZXRzIGluIExBQzoNCiMgU2VjcmV0cyBmb3IgYXV0aGVudGljYXRpbmcgbDJ0 cCB0dW5uZWxzDQojdXMgdGhlbSBzZWNyZXQNCiMgKiAgbWFya28gYmxhaDINCiMgemV1cyAgbWFy a28gYmxhaA0KIyAqICogaW50ZXJvcA0KeWJ6aGcgbG9jYWxob3N0LmxvY2FsZG9tYWluICBhY3Rp b24NCmxvY2FsaG9zdC5sb2NhbGRvbWFpbiB5YnpoZyAgYWN0DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpsMnRwZC5jb25mIGluIExOUzoN CltsbnMgZGVmYXVsdF0gICAgOyBPdXIgZmFsbHRocm91Z2ggTE5TIGRlZmluaXRpb24NCiAgZXhj bHVzaXZlID0gbm8gICA7ICogT25seSBwZXJtaXQgb25lIHR1bm5lbCBwZXIgaG9zdA0KICBpcCBy YW5nZSA9IDE5Mi4xNjguMC4yIC0gMTkyLjE2OC4wLjI1NCA7ICogQWxsb2NhdGUgZnJvbSB0aGlz IElQIHJhbmdlDQo7IG5vIGlwIHJhbmdlID0gMTkyLjE2OC4wLjEwMy0xOTIuMTY4LjAuMTM1ICA7 ICogRXhjZXB0IHRoZXNlIGhvc3RzDQo7IGlwIHJhbmdlID0gMTkyLjE2OC4wLjUgIDsgKiBCdXQg dGhpcyBvbmUgaXMgb2theQ0KOyBpcCByYW5nZSA9IGxhYzEtbGFjMiAgIDsgKiBBbmQgYW55dGhp bmcgZnJvbSBsYWMxIHRvIGxhYzIncyBJUA0KOyBsYWMgPSAxOTIuMTY4LjAuNDAgICAgIDsgKiBU aGVzZSBjYW4gY29ubmVjdCBhcyBMQUMncw0KOyBubyBsYWMgPSB1bnRydXN0ZWQubWFya28ubmV0 ICA7ICogVGhpcyBndXkgY2FuJ3QgY29ubmVjdA0KOyBoaWRkZW4gYml0ID0gbm8gICA7ICogVXNl IGhpZGRlbiBBVlAncz8NCiAgbG9jYWwgaXAgPSAxOTIuMTY4LjAuMjU0ICA7ICogT3VyIGxvY2Fs IElQIHRvIHVzZQ0KOyBsb2NhbCBpcCA9IDYxLjE1MS4yMzQuMTcgIDsgKg0KICBsZW5ndGggYml0 ID0geWVzICAgOyAqIFVzZSBsZW5ndGggYml0IGluIHBheWxvYWQ/DQo7IHJlcXVpcmUgY2hhcCA9 IHllcyAgIDsgKiBSZXF1aXJlIENIQVAgYXV0aC4gYnkgcGVlcg0KOyByZWZ1c2UgcGFwID0geWVz ICAgOyAqIFJlZnVzZSBQQVAgYXV0aGVudGljYXRpb24NCjsgcmVmdXNlIGNoYXAgPSBubyAgIDsg KiBSZWZ1c2UgQ0hBUCBhdXRoZW50aWNhdGlvbg0KOyByZWZ1c2UgYXV0aGVudGljYXRpb24gPSBu byAgOyAqIFJlZnVzZSBhdXRoZW50aWNhdGlvbiBhbHRvZ2V0aGVyDQo7IHJlcXVpcmUgYXV0aGVu dGljYXRpb24gPSB5ZXMgIDsgKiBSZXF1aXJlIHBlZXIgdG8gYXV0aGVudGljYXRlDQo7IHVuaXgg YXV0aGVudGljYXRpb24gPSBubyAgOyAqIFVzZSAvZXRjL3Bhc3N3ZCBmb3IgYXV0aC4NCiAgbmFt ZSA9IGxvY2FsaG9zdC5sb2NhbGRvbWFpbiAgOyAqIFJlcG9ydCB0aGlzIGFzIG91ciBob3N0bmFt ZQ0KICBob3N0bmFtZSA9IGxvY2FsaG9zdC5sb2NhbGRvbWFpbiA7ICoNCiAgcHBwIGRlYnVnID0g bm8gICA7ICogVHVybiBvbiBQUFAgZGVidWdnaW5nDQogIGNhbGwgcndzID0gMTAgICAgOyAqIFJX UyBmb3IgY2FsbCAoLTEgaXMgdmFsaWQpDQogIHR1bm5lbCByd3MgPSA0ICAgOyAqIFJXUyBmb3Ig dHVubmVsIChtdXN0IGJlID4gMCkNCiAgZmxvdyBiaXQgPSB5ZXMgICA7ICogSW5jbHVkZSBzZXF1 ZW5jZSBudW1iZXJzDQogIGNoYWxsZW5nZSA9IHllcyAgIDsgKiBDaGFsbGVuZ2UgYXV0aGVudGlj YXRlIHBlZXIgOyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpsMnRwLXNlY3JldHMgaW4gTE5TOg0KIyBTZWNyZXRzIGZvciBhdXRo ZW50aWNhdGluZyBsMnRwIHR1bm5lbHMNCiMgdXMgdGhlbSBzZWNyZXQNCiMgKiAgbWFya28gYmxh aDINCiMgemV1cyAgbWFya28gYmxhaA0KbG9jYWxob3N0LmxvY2FsZG9tYWluIHliemhnIGFjdA0K eWJ6aGcgbG9jYWxob3N0LmxvY2FsZG9tYWluIGFjdGlvbg0KDQogICB3aGVuIGkgcnVuIHRoZXNl LCBleGlzdCBwcm9ibGVtcywgcmVzdWx0cyBhcyBmb2xsb3c6DQoNCmluIExOUyA6DQoNCltyb290 QGxvY2FsaG9zdCBsMnRwXSMgbDJ0cGQgJg0KVGhpcyBiaW5hcnkgZG9lcyBub3Qgc3VwcG9ydCBr ZXJuZWwgTDJUUC4NCmwydHBkIHZlcnNpb24gMC42MiBzdGFydGVkIG9uIGxvY2FsaG9zdC5sb2Nh bGRvbWFpbg0KV3JpdHRlbiBieSBNYXJrIFNwZW5jZXIsIENvcHlyaWdodCAoQykgMTk5OCwgQWR0 cmFuLCBJbmMuDQpGb3JrZWQgYnkgU2NvdHQgQmFsbW9zIGFuZCBEYXZpZCBTdGlwcCwgKEMpIDIw MDENCkxpbnV4IHZlcnNpb24gMi4yLjIwIG9uIGEgaTY4NiwgcG9ydCAxNzAxDQpbMV0gMjE2NA0K W3Jvb3RAbG9jYWxob3N0IGwydHBdIyBjb250cm9sX2ZpbmlzaDogQ29ubmVjdGlvbiBjbG9zZWQg dG8gMTkyLjE2OC4wLjQwLCBwb3J0IDE3MDEgKE5vIHNlY3JldCBrZXkgb24gb3VyIGVuZCksIExv Y2FsOiAxNzc2NywgUmVtb3RlOiAxNzc2Nw0KDQppbiBMQUM6DQpbcm9vdEB5YnpoZyByb290XSMg ZWNobyAidCAxOTIuMTY4LjAuMjU0Ij4vdmFyL3J1bi9sMnRwLWNvbnRyb2wNCltyb290QHliemhn IHJvb3RdIyBsMnRwX2NhbGw6Q29ubmVjdGluZyB0byBob3N0IDE5Mi4xNjguMC4yNTQsIHBvcnQg MTcwMQ0KaGFuZGxlX2NoYWxsZW5nZTogTm8gTE5TIG9yIExBQyB0byBoYW5kbGUNCmNoYWxsZW5n ZSENCmNvbnRyb2xfZmluaXNoOiBObyBzZWNyZXQgZm9yIGF1dGhlbnRpY2F0aW5nIHRvICdsb2Nh bGhvc3QubG9jYWxkb21haW4nDQpjYWxsX2Nsb3NlIDogQ29ubmVjdGlvbiAyMjc2NCBjbG9zZWQg dG8gMTkyLjE2OC4wLjI1NCwgcG9ydCAxNzAxIChObyBzZWNyZXQga2V5IG9uIG91ciBlbmQpDQoN Cg0KIGNhbiB5b3Uga25vdyBob3cgdG8gc2V0IGNvbmZpZ3VyYXRpb24gZmlsZXMgc3VjaCBhcyBs MnRwZC5jb25mIGFuZCBsMnRwLXNlY3JldHMNCiB0aGFua3MgYSBsb3QNCg0KQmVzdCB3aXNoZXMh DQpKdXN0aW4NCqGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaF5YnpoZ0AyNjMubmV0DQqhoaGh oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwMS0xMi0yOQ0K |
|
From: Robert W. <wa...@wa...> - 2001-12-26 09:51:30
|
On Wed, 26 Dec 2001 16:39:17 +0800, "Lukman W. Kusuma" writes: >Are you still alive? I think you should try at l2t...@li... ... cheers, &rw -- -- He who joyfully marches to music in rank and file has already earned my -- contempt. He has been given a large brain by mistake, since for him the -- spinal cord would fully suffice. -- Einstein |
|
From: <je...@au...> - 2001-12-20 01:34:38
|
I need to implement L2TP in a production environment to terminate ADSL connections. Is l2tpd stable enough for this? Also I may need to do RADIUS authentication and accounting. Is it just a matter of using the same modules for PPP that were written for portslave? Also is anyone working on packaging l2tpd in Debian? If no one else is doing it then I'll package the implmentation that I end up using. Thanks, -- Jeremy Lunn Melbourne, Australia http://www.jabber.org/ - the next generation of Instant Messaging. |
|
From: Eric S. <er...@tr...> - 2001-12-14 18:59:35
|
On Mon, 10 Dec 2001 ho...@ei... wrote:
> Seems to have problems here. I would appreciate if anyone who has set up a similar
> or same scenario to point me in the right direction or provide me with more information
> on howto set it up if available. My first aim is to get the scenario working without
> IPSec and then with it
Your configuration may be leading into ground that the l2tpd code has not
tread yet. This is the "compulsory tunneling" model, and it seems like you
might be expecting LAC-side l2tpd to do proxy authentication (i.e. forward
ppp auth info to the LNS-side l2tpd for LCP/IPCP negotiation. Also, check
your /etc/ppp/options file on both ends to make sure there's no 'noauth'
keyword lurking around somewhere.
By the way.. Although the following is not a direct answer to your question,
I have seen a couple of other posts in the archives asking along these lines
so maybe it will help someone.
With some effort, I have been able to use Freeswan+L2TPD to mimic the
the Win2K / WinXP builting VPN client. The LNS in my case is a
Lucent/Xedia Access Point 450 router, not another freeswan box. Here
are a few gotchas I ran into:
- I patched freeswan to use x509 certs and used an internal-only "standalone"
CA to assign a certificate for the linux box. Freeswan<->freeswan you can
probably just use rsasigs or PSK and be OK.
- the connection you want to L2TP over needs to specify 'type=transport'
in ipsec.conf
- freeswan _updown doesn't handle transport mode connections very well,
and will try to add a route to the eth0 network thru the
ipsec0 interface, which is not what you want. you want a host route to
the other tunnel endpoint through ipsec0.
- pppd will try to add a route to the LNS' IP address through the ppp0
interface, which is also not what you want. you want a route to the
remote network (behind the far gateway) through ppp0.
/etc/init.d/ipsec start
/usr/local/sbin/ipsec auto --up xedia-to-mobile-linux-l2tp
/sbin/route del -net <local-public-network> dev ipsec0
/sbin/route add -host <remote ip> dev ipsec0
/usr/local/sbin/l2tpd > /dev/null 2>&1 &
echo "c work" > /var/run/l2tp-control
/sbin/route del -host <remote ip> dev ppp0
/sbin/route add -net <tunneled-private-net> dev ppp0
- freeswan will not behave *exactly* like the win2k client as far as the
remote end is concerned; there's no way to specify 'any/any->udp/1701'
in the ike p2 exchange, as win2k does. i had to make a new security policy
for the transport-mode freeswan connections which says allows any port/any
protocol for both the local and remote endpoints.
in xedia-land it looks like this:
IPSEC TRANSPORT-INTERFACE.0.0.0.0 TRANSPORT.FREESWAN SUMMARY
Type* = clientGroup
Mode* = up
State = up
Last State Change = 676 (0 hours 0 min 6 secs)
Remote Addr = 0.0.0.0
Protocol* = 0
Local Port* = 0
Remote Port* = 0
Security Profile* = freeswan
IKE Authentication Method = none
Row Status* = active
IPSEC SECURITY-PROFILE.FREESWAN SUMMARY
Protocol* = esp Inactivity Timer* = 0
Encryption* = des3 Enable PFS* = true
Authentication* = md5 Oakley Group* = second
Compression* = null Assignment Status = assigned
Expiration Timer* = 3600 Row Status* = active
Expiration Volume* = 0
which matches up to an ipsec.conf entry with:
conn xedia-to-mobile-linux-l2tp
left=<remote ip>
leftrsasigkey=0x<longstring>
right=%defaultroute
rightcert=mycert.cer
type=transport
ikelifetime=8h
keylife=1h
pfs=yes
auto=add
- I had to hardcode the username/password into /etc/ppp/pap-secrets
which is sort of sub-optimal. I'd rather l2tpd force the user to
type his/her password instead of keeping it on disk, but I understand
this is difficult to do cleanly since its running as a daemon
/etc/l2tp/l2tpd.conf
[lac work]
lns = <remote ip>
refuse pap = no ; * Refuse PAP authentication
refuse chap = yes ; * Refuse CHAP authentication
;refuse authentication = no ; * Refuse authentication altogether
require authentication = no ; * Require peer to authenticate
name = <radius-username> ; * Report this as our hostname
/etc/ppp/pap-secrets
<radius-username> * <radius-password> *
- There is a bug with ESP fragment handling in the Freeswan version I used
(1.92) so any large packets which resulted in ESP frags (gateway->linux)
got dropped instead of reassembled. I hear this (is|will be) fixed in 1.94.
I was pretty suprised when the tunnel came up, but it does indeed work.
-=Eric
|
|
From: <ho...@ei...> - 2001-12-10 18:21:25
|
Hi All, Im trying to set up the following scenario with great difficulty. 10.0.1.1 10.0.1.2 100.1.1.X | | | | | | PC Dialup <----------> Gateway 1 <----------> Gateway 2 <----------> Corporate LAN Client ^ | | | L2TP TUNNEL OVER IPSEC TUNNEL Gateway 1: Running FreeSWAN and L2TP as LAC GAteway 2: Running FreeSWAN and L2TP as LNS The idea is that the PC Dialup Client initiates a PPP connection to the LAC.The LAC then tunnels the PPP connection to the LNS whereby access to the Corporate LAN is obtained and the Dialup PC is provided addresses from the Corporate LAN via PPP. First things first is to get the L2TP Tunnel up on its own with out IPSec running, and to initiate a call over it. The L2TP daemon being used is from sourceforge.net/projects/l2tpd V0.63 whcich is based off of L2TPd 0.61 from http://www.marko.net/l2tp # LAC Configuration # ----------------- [global] port = 1701 [lac test] lns = 10.1.1.2 local ip = 10.1.1.1 name = gw1 ppp debug = yes # LNS Configuration # ----------------- [global] port = 1701 [lns default] ip range = 192.168.100.1-192.168.100.3 lac = 10.1.1.1 local ip = 10.1.1.2 name = gw2 ppp debug = yes Creating a tunnel seams to be no problem, (echo "t 10.0.1.2" >/var/run/l2tp-control), But when I try to initiate a call on the tunnel identified locally as test (echo "c test" >/var/run/l2tp-control), I get the following logs ## GW1 - LAC :Dec 10 17:54 galway l2tpd[840]: This binary does not support kernel L2TP. :Dec 10 17:54 galway l2tpd[840]: l2tpd version 0.63 started on galway.acme.com :Dec 10 17:54 galway l2tpd[840]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc. :Dec 10 17:54 galway l2tpd[840]: Forked by Scott Balmos and David Stipp, (C) 2001 :Dec 10 17:54 galway l2tpd[840]: Linux version 2.2.16 on a i586, port 1701 :Dec 10 17:55 galway l2tpd[840]: l2tp_call:Connecting to host 10.1.1.2, port 1701 :Dec 10 17:55 galway l2tpd[840]: control_finish: Connection established to 10.1.1.2, 1701. Local: 17767, Remote: 17767. :Dec 10 17:55 galway l2tpd[840]: l2tp_call:Connecting to host 10.1.1.2, port 1701 :Dec 10 17:55 galway l2tpd[840]: control_finish: Connection established to 10.1.1.2, 1701. Local: 18547, Remote: 18547. :Dec 10 17:55 galway l2tpd[840]: lac_call: Calling on tunnel 18547 :Dec 10 17:55 galway l2tpd[840]: control_finish: Call established with 10.1.1.2, Local: 37962, Remote: 37962, Serial: 1 :Dec 10 17:55 galway pppd[841]: pppd 2.3.11 started by root, uid 0 :Dec 10 17:55 galway pppd[841]: Using interface ppp0 :Dec 10 17:55 galway pppd[841]: Connect: ppp0 <--> /dev/ttyp2 :Dec 10 17:55 galway pppd[841]: peer refused to authenticate: terminating link :Dec 10 17:55 galway pppd[841]: Connection terminated. :Dec 10 17:55 galway pppd[841]: Exit. :Dec 10 17:55 galway l2tpd[840]: call_close: Call 37962 to 10.1.1.2 disconnected ## GW2 - LNS :Dec 10 17:55 jh_156 l2tpd[799]: This binary does not support kernel L2TP. :Dec 10 17:55 jh_156 l2tpd[799]: l2tpd version 0.63 started on jh_156.acme.com :Dec 10 17:55 jh_156 l2tpd[799]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc. :Dec 10 17:55 jh_156 l2tpd[799]: Forked by Scott Balmos and David Stipp, (C) 2001 :Dec 10 17:55 jh_156 l2tpd[799]: Linux version 2.2.16 on a i686, port 1701 :Dec 10 17:55 jh_156 l2tpd[799]: control_finish: Connection established to 10.1.1.1, 1701. Local: 17767, Remote: 17767. LNS session is 'default' :Dec 10 17:55 jh_156 l2tpd[799]: control_finish: Connection established to 10.1.1.1, 1701. Local: 18547, Remote: 18547. LNS session is 'default' :Dec 10 17:55 jh_156 pppd[800]: pppd 2.3.11 started by root, uid 0 :Dec 10 17:55 jh_156 pppd[800]: Using interface ppp0 :Dec 10 17:55 jh_156 l2tpd[799]: control_finish: Call established with 10.1.1.1, Local: 37962, Remote: 37962, Serial: 1 :Dec 10 17:55 jh_156 pppd[800]: Connect: ppp0 <--> /dev/ttyp2 :Dec 10 17:55 jh_156 pppd[800]: peer refused to authenticate: terminating link :Dec 10 17:55 jh_156 pppd[800]: Connection terminated. :Dec 10 17:55 jh_156 l2tpd[799]: control_finish: Connection closed to 10.1.1.1, serial 1 () :Dec 10 17:55 jh_156 pppd[800]: Terminating on signal 15. :Dec 10 17:55 jh_156 pppd[800]: Exit. Seems to have problems here. I would appreciate if anyone who has set up a similar or same scenario to point me in the right direction or provide me with more information on howto set it up if available. My first aim is to get the scenario working without IPSec and then with it Regards, John. |
|
From: Vanja H. <va...@va...> - 2001-12-03 18:37:59
|
Hi!
I've been having trouble establishing l2tp connection to 3COM HiperARC device, and last weekend I got some free time to play
with it. ISP is using 3COM HARC devices for 1-way cable modem users, and they only provide Windows client. Therefore, I
needed l2tpd.
First, I was not getting any responses from 3COM device after pppd was started. It turned out that, for some reason, 3COM
HARC doesn't like this (control.c):
add_rxspeed_avp(buf,DEFAULT_RX_BPS);
(sorry - no line numbers, I've ruined original control.c badly, and am too lazy to extract it and see which line this is :)
After I have commented this line out, I was able to properly authenticate myself, and get an IP address assigned by the ISP.
However, real trouble begins here.
ppp0 device comes up, IP address is properly assigned, but no packets will go through it. What happens is that if I (for
example) try to ping some IP on the Internet, absolutelly nothing happens. But, if I send *any* kind of packet to the 3COM
device itself, l2tpd goes into 'loop' mode, and starts sending enormous amounts of traffic over ppp0. The traffic actually
goes nowhere, since ppp0 doesn't seem to be 'connected' properly (not sure if this is the right word :). None of the lights
on the modem are lit at any moment, so all the traffic just gets lost. I am talking about 100Mbyte per minute amounts of
traffic.
I have found where the 'looping' occurs, but I have no clue *why* it occurs.
In network.c, function "network_thread":
--
while ((result=read_packet(buf,sc->fd,SYNC_FRAMING))>0) {
add_payload_hdr(sc->container, sc, buf);
if (packet_dump) {
do_packet_dump(buf);
}
sc->prx = sc->pSr;
if (sc->zlb_xmit) {
deschedule(sc->zlb_xmit);
sc->zlb_xmit=NULL;
}
sc->tx_bytes += buf->len;
sc->tx_pkts++;
udp_xmit(buf);
recycle_payload(buf, sc->container->peer);
}
--
Once a packet is sent to the 3COM device (a simple ping will do the trick), l2tpd gets stuck in this while loop, and never
gets out. What I would like to find out is what exactly this loop does, and what is the file descriptor which is being read?
result is always more than 0, but I am not sure what read_packet() is reading, and from where.
Any help is appreciated.
Regards,
Vanja
|
