l2tpd-devel Mailing List for L2TP client / daemon (Page 10)
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
|
|
From: Jeff M. <je...@ig...> - 2001-06-01 19:05:33
|
Also sprach Patrick Faget >As you requested, I'am sending the L2TPD log and the file (l2tpd.log) >with the packets traffic. Desconsider the first two packets in the >file. Yeah...Cisco CDP...always fun to see though. I also pretty much ignored the arp stuff as I'm pretty sure there's not a problem there. :) >check_control: control, cid = 0, Ns = 1, Nr = 1 Hrmm...that didn't give me much of anything more useful than we already had... >Jun 1 15:30:28 mvx-10-8-0-34.0.8.10.in-addr.arpa 1/4: [1/4/49/0] LAN session >info >: Conn=(? 53333/28800 65/120) Auth=(29 0/0 0/0) Sess=(0 121/7 96/4) [MBID >1965; 2130828000->7999] [mundivox.com] And the log from the Max about pretty much devoid of useful content (can't say that I'm terribly surprised there)... The tcpdump, however, was quite useful. :) It looks like you're trying to do challenge authentication in both directions. In other words, the Max is asking the l2tpd to authenticate itself, and l2tpd is asking the Max to *also* authenticate itself...This is doable, if you wanted to do it this way, but then the Max complains (in the StopCCN) that the peer is not authorized to establish a control channel. I suspect this means that the Max wants the l2tpd to respond to its challenge, but doesn't expect to be challenged itself. I *think* you can achieve this scenario by removing the "challenge" keyword (and associated value, of course) from your l2tpd.conf. Alternatively, you can likely set up the Max to accept the challenge from l2tpd. This may sound like contradictory information from what I told you before (on the marko.net list I believe), as I didn't have really good information at that point about what was going on with the connection. You will also need to determine where you would want challenge authentication to occur, and configure it accordingly. Challenge authentication may not be as useful as it first appears since there likely will be authentication that will be carried within PPP for each of the sessions eventually created. The challenge that we're dealing with here only covers the actual tunnel itself, it doesn't really do any authentication of the sessions that will eventually be carried within the tunnel. I hope I haven't hopelessly muddled the intent of this and confused you. :) Let me know if/how I can help farther...(and there's a standing offer to call me at the numbers below...particularly when it involves getting interoperability with a new piece of equipment...and since we haven't confirmed interoperability with anything from Ascend yet...this would definitely qualify) :) -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Patrick F. <pf...@mu...> - 2001-06-01 18:42:37
|
As you requested, I'am sending the L2TPD log and the file (l2tpd.log) with the packets traffic. Desconsider the first two packets in the file. -DDEBUG_CONTROL root@pfaget:/usr/local/src/l2tpd# ./l2tpd This binary does not support kernel L2TP. l2tpd version 0.63 started on pfaget Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc. Forked by Scott Balmos and David Stipp, (C) 2001 Linux version 2.2.19 on a i586, port 1701 check_control: control, cid = 0, Ns = 0, Nr = 0 handle_avps: no handler for atribute 5 (Tie Breaker). check_control: control, cid = 0, Ns = 1, Nr = 1 check_control: control, cid = 0, Ns = 1, Nr = 1 check_control: control, cid = 0, Ns = 1, Nr = 1 result_code_avp: result code out or range (0). Ignoring. control_finish: Peer tried to disconnect without specifying result code. death_handler: Fatal signal 2 received call_close : Connection 29 closed to 200.196.48.22, port 7019 (Server closing) SYSLOG INFORMATION FROM MAX TNT Jun 1 15:30:00 mvx-10-8-0-34.0.8.10.in-addr.arpa 1/17: [1/2/1/5] Incoming Call, 2130828000 [MBID 1965; 2130828000->7999] Jun 1 15:30:00 mvx-10-8-0-34.0.8.10.in-addr.arpa 1/17: [1/4/49/0] Assigned to port, 2130828000 [MBID 1965; 2130828000->7999] Jun 1 15:30:00 mvx-10-8-0-34.0.8.10.in-addr.arpa 1/17: [1/2/1/5] Call Connected,2130828000 [MBID 1965; 2130828000->7999] Jun 1 15:30:28 mvx-10-8-0-34.0.8.10.in-addr.arpa 1/17: [1/4/49/0] Call Terminated MBID 1965; 2130828000->7999] Jun 1 15:30:28 mvx-10-8-0-34.0.8.10.in-addr.arpa 1/4: [1/4/49/0] STOP: 'mundivox. com'; cause 120.; progress 65.; host 0.0.0.0 [MBID 1965; 2130828000->7999] [mundivox.com] Jun 1 15:30:28 mvx-10-8-0-34.0.8.10.in-addr.arpa 1/4: [1/4/49/0] LAN session info : Conn=(? 53333/28800 65/120) Auth=(29 0/0 0/0) Sess=(0 121/7 96/4) [MBID 1965; 2130828000->7999] [mundivox.com] Regards, Patrick Faget |
|
From: Jeff M. <je...@ig...> - 2001-05-31 14:31:55
|
Also sprach Patrick Faget > I'am trying to make a L2TP tunnel between L2TPD(working as LNS) and >a MAX TNT unit from Lucent (working as LAC). > Jeff Mcadams is helping me and now I'am sending a detailed log >about my setup tests. I think that I'am very near to reach the >integration. I included the radius log, that is used by MAX TNT. As you >can see on the detail log above, there is a message of unsupported >protocol that I'am studying now. However, I don't know yet if this >message is generatedbecause of MAX TNT or because of L2TPD. >-----------L2TPD LOG------------------------------------------------- ... >handle_avps: no handler for atribute 5 (Tie Breaker). >result_code_avp: result code out or range (0). Ignoring. ... Hrmm...something is breaking in between these two messages...don't have enough debug information outputting here to be sure what though. Let's try adding...uhm... "-DDEBUG_CONTROL" to the DFLAGS entry in the Makefile and recompile with that debug setting...I think that should give us some extra output (hopefully) on the setup of the control connection that might tell us what's going on... >-----------PACKETS LOG------------------------------------------------- >root@pfaget:/usr/sbin# tcpdump -r tcp.log Alternatively, if you could send me that tcp.log file so I could pull it up in something a bit more verbose about what's going on (like ethereal)...that would be quite useful as well. (Did you create that file with a snaplen of 1500? Hopefully, so we can be sure to have the whole packet and not have anything truncated) >09:44:23.326462 ras-rj-1.mundivox.com.7019 > >mvx-200-196-48-121.mundivox.com.1701: l2tp:[TLS](0/0)Ns=0,Nr=0 >*MSGTYPE(SCCRQ) |... OK...start control connection request sent to l2tpd >09:44:23.329711 mvx-200-196-48-121.mundivox.com.1701 > >ras-rj-1.mundivox.com.7019: l2tp:[TLS](28/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) |... l2tpd sends out the reply....the Max should respond with a SCCCN (Start Control Connection CoNnected) >09:44:23.333538 ras-rj-1.mundivox.com.7019 > >mvx-200-196-48-121.mundivox.com.1701: l2tp:[TLS](17767/0)Ns=1,Nr=1 ZLB >09:44:23.340514 ras-rj-1.mundivox.com.7019 > >mvx-200-196-48-121.mundivox.com.1701: l2tp:[TLS](17767/0)Ns=1,Nr=1 ZLB >09:44:23.341442 ras-rj-1.mundivox.com.7019 > Instead, we just get ZLB (Zero Length Body" messages...which are basically just used to say "yeah, I got your message"...not sure why we're not getting a SCCCN from it though... Any possibility of getting a debug log from the Max itself to see if *its* complaining about anything? >mvx-200-196-48-121.mundivox.com.1701: l2tp:[TLS](17767/0)Ns=1,Nr=1 >*MSGTYPE(StopCCN) |... Then l2tpd sends out a request to tear down the control connection >09:44:23.342378 mvx-200-196-48-121.mundivox.com.1701 > >ras-rj-1.mundivox.com.7019: l2tp:[TLS](28/0)Ns=1,Nr=2 ZLB Then l2tpd sends out a ZLB...not sure for what though... >09:45:30.172076 mvx-200-196-48-121.mundivox.com.1701 > >ras-rj-1.mundivox.com.7019: l2tp:[TLS](28/0)Ns=1,Nr=2 *MSGTYPE(StopCCN) |... Then another stop request... > Ascend-Disconnect-Cause = Protocol-Disabled-Or-Unsupported Well...the Max is *clearly* not liking *something* we're sending...we just don't know what yet. So...if you can get a log from the Max, and/or the extra debug from l2tpd, and/or a tcpdump file (from -w) with snaplen of 1500 (-s 1500, to be safe)...hopefully we can figure out a big better what's going on. -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Huiban Y. <Yoa...@sr...> - 2001-05-30 18:16:13
|
Hi all,
I'm trying to understand the kernel implementation of l2tp, and I have
several questions concerning this issue.
I did some ASCII art, so use a "square" font like Courrier to admire it !
If you see something wrong (high probability, I'm relatively new in
Linux), you're encouraged to correct !
1) the current implementation is :
user space l2tp :
+-------------+ +------------+
| pppd | | l2tpd |
+-------------+ +------------+
| | |
| +----------+ |
| | |
User space +------+ +------+ +---------------+
-----------------| tty |-----| pty |------| UDP socket FD |---------
Kernel Space +------+ +------+ +---------------+
| | |
+-------------+ |
|
|
----------------------------------------------------------------------
Network |
2) Is this the kernel space implementation ?
Kernel space l2tp :
+-------------+ +------------+
| pppd | | l2tpd |
+-------------+ +------------+
| |
| |
User space +----------------+ +------------+
-------------| PPP Channel FD |-----------| control FD |--------------
Kernel Space +----------------+ +------------+
| |
| |
+----------+ +---------+
Payload | | Control
| |
+---------------+
| kernel L2tp |
+---------------+
|
|
+---------------+
| UDP |
+---------------+
|
----------------------------------------------------------------------
Network |
- L2tpd controls "kernel L2tp" through ioctl() calls on "control FD".
3) I don't see very well how the "control FD" schould be implemented.
Could someone help ?
Best regards,
Yoann.
|
|
From: Jeff M. <je...@ig...> - 2001-05-30 17:19:58
|
Also sprach Huiban Yoann >I'm trying to understand the kernel implementation of l2tp, and I have >several questions concerning this issue. Well...its important to remember that there is no kernel implementation of L2TP at this point! :) Hopefully we'll get to that point, but its going to be a bit... > - L2tpd controls "kernel L2tp" through ioctl() calls on "control FD". Your representation fits pretty well with my initial thoughts on how this would all happen. Obviously, since no work has really begun on this work...there is a lot to figure out what's going on and how it would eventually work, but you and I at least have a pretty common idea of how it would work...but I think we're both in about the same boat as far as kernel implementations are concerned...ie, never having worked with it, so still feeling our way a lot. :) >3) I don't see very well how the "control FD" schould be implemented. >Could someone help ? Good question. Feel free to throw out ideas, since we're just getting started in this area...someone needs to come up with an initial sketch of how it would be done...no real reason it couldn't be you. :) -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Huiban Y. <Yoa...@sr...> - 2001-05-30 17:11:48
|
Hi all,
I'm trying to understand the kernel implementation of l2tp, and I have
several questions concerning this issue.
I did some ASCII art, so use a "square" font like Courrier to admire it !
If you see something wrong (high probability, I'm relatively new in
Linux), you're encouraged to correct !
1) the current implementation is :
user space l2tp :
+-------------+ +------------+
| pppd | | l2tpd |
+-------------+ +------------+
| | |
| +----------+ |
| | |
User space +------+ +------+ +---------------+
-----------------| tty |-----| pty |------| UDP socket FD |---------
Kernel Space +------+ +------+ +---------------+
| | |
+-------------+ |
|
|
----------------------------------------------------------------------
Network |
2) Is this the kernel space implementation ?
Kernel space l2tp :
+-------------+ +------------+
| pppd | | l2tpd |
+-------------+ +------------+
| |
| |
User space +----------------+ +------------+
-------------| PPP Channel FD |-----------| control FD |--------------
Kernel Space +----------------+ +------------+
| |
| |
+----------+ +---------+
Payload | | Control
| |
+---------------+
| kernel L2tp |
+---------------+
|
|
+---------------+
| UDP |
+---------------+
|
----------------------------------------------------------------------
Network |
- L2tpd controls "kernel L2tp" through ioctl() calls on "control FD".
3) I don't see very well how the "control FD" schould be implemented.
Could someone help ?
Best regards,
Yoann.
|
|
From: Boby S <bo...@ta...> - 2001-05-19 09:53:14
|
Hi All, Iam Boby form Banglore, India. Sorry for disturbing you. I have some doubts regarding L2TP code for linux.I compiled the l2tp source code with hard coded options for LAC and LNS. My deployment of L2TP is as follows __________ _____ ________ __________ | | | | | | | | | Remote Peer| ----Null Modem(Serial Cable)------|LAC- |===LAN== |--LNS-- |--Null Modem----|-Destination | |__________ | |_____| |_______ | |_________ | Iam able to establish tunnel ,call connection and start pppd from L2TP. PPP is running fine between Remote peer and LAC. Iam continiously pumping the data from Remote perr, but the psudo ttty (master fd )call->fd is not able to read the data from the ppp driver (In network.c) The read function always returns zero. I am not getting why it is happening like that. When I recive ICRP messagem, I am adding additional options such that the arguments for PPPD will be like this execv (/usr/sbin/pppd, passive -detach local lock noauth localaddr:remoteaddr /dev/ttyS1 38400 ) Its creating the interface ppp0 in LAC properly and Remote peer.Iam using is COM1 for ppp. Iam sending data from remote peer, but the call ->fd iam getting using psudo tty is not able to read the data.Please tell me what could be the problem. Thanks in advance, With Best Regards, Boby. |
|
From: Jeff M. <je...@ig...> - 2001-05-16 18:51:25
|
Also sprach Huiban Yoann >The loop in l2tpd.c:do_control() function can cause l2tpd to send >control messages without listening to the peer (ie : reading on the >socket by going through select statement). If there are lot's of >messages in the control pipe (more than the peer's receive window >size), it will lead to problems (non acknowledgment, >retransmission...). I haven't forgotten your message...its still in my inbox. Just have insufficient quantities of tuits to really look into the matter more fully at this point. Rest assured though, I haven't forgotten it! :) >Suppressing the while(cnt) loop >(and modifying the read method as proposed in > From: Deja User > Sent: Monday, April 23, 2001 2:12 AM > To: je...@ig... > Cc: l2...@ma... > Subject: Re: question regarding multiple calls per tunnel) >would perhaps be a good thing ? -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Huiban Y. <Yoa...@sr...> - 2001-05-16 16:37:18
|
Hi all, The loop in l2tpd.c:do_control() function can cause l2tpd to send control messages without listening to the peer (ie : reading on the socket by going through select statement). If there are lot's of messages in the control pipe (more than the peer's receive window size), it will lead to problems (non acknowledgment, retransmission...). Suppressing the while(cnt) loop (and modifying the read method as proposed in From: Deja User Sent: Monday, April 23, 2001 2:12 AM To: je...@ig... Cc: l2...@ma... Subject: Re: question regarding multiple calls per tunnel) would perhaps be a good thing ? Thanks, Yoann |
|
From: Jeff M. <je...@ig...> - 2001-05-03 11:46:46
|
Also sprach Deja User >Is there any way to avoid going thru all the calls to get the pppds and >instead get only those pppds (and hence, search for only those calls) >on which there is data. That's kinda what's happening already. That's what the select is for near the top of that function. It only returns when there is data to be read on a file descriptor that its checking for. The select has to check for all the different file descriptors, the control FIFO, the server socket, and all the ptys that connect to the pppds. When select returns, at least one of those file descriptors has data on it...its just a matter of checking which one. That's the purpose of the FD_ISSET calls (actually, I believe that's a macro). Unfortunately, the only way to find the file descriptor that has the data to be read is to check them all (at least that I'm aware). The check should be pretty low overhead though, since the FD_ISSET checks to see if that file descriptor is one of the ones that caused select to return, and if not, no other processing of that file descriptor happens, it loops on through to the next. I'm not sure of any way to speed this up any. -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Deja U. <ci...@my...> - 2001-05-03 04:31:22
|
Hi, In the network_thread() function in the file network.c, there is an infinite for loop in which we check whether there is any data on the pppd of all the calls. Is there any way to avoid going thru all the calls to get the pppds and instead get only those pppds (and hence, search for only those calls) on which there is data. citl ------------------------------------------------------------ --== Sent via Deja.com ==-- http://www.deja.com/ |
|
From: Jens Z. <xj...@se...> - 2001-05-02 07:46:33
|
Hey. First of all, big thanks for the resumption of the l2tpd projekt.=20 I search for a 'Outgoing Call (OCRQ, OCRP,OCCN)' option for the l2tpd. So I have some question concerning the 'OCxx'. Did anybody develop (begin to develop) a 'Outgoing Call' for the l2tpd? Is there a itention to develop a 'Outgoing Call' in the future? I see the 'OCxx' is prepared in the avp.c. Is it big work to develop the = 'OCxx'? Best regards, Jens Zerbst |
|
From: Ignacio G. <ig...@lu...> - 2001-04-30 18:46:55
|
Why would there be any problem? The ICRQs sent by the LAC must have an
assigned session id that the LNS must use on the L2TP headers of the
ICRP that it sends back to the LAC. This is discussed in RFC2661, near
the bottom of page 26:
"The L2TP peer MUST place this value in the Session ID header field
of all control and data messages that it subsequently transmits over
the tunnel that belong to this session."
At 11:25 AM 4/30/01 -0700, Deja User wrote:
>Suppose the LAC sends two ICRQs and the LNS sends back two ICRPs in response to these two messages. How should the LNS map the ICRP to the right ICRQ?
>
>citl
>
>>To: l2...@ma...
>>From: Ignacio Goyret <ig...@lu...>
>>Cc: l2t...@li...
>>Subject: [L2tpd-devel] Re: state machine of l2tp
>>Reply-To: l2t...@li...
>>Date: Fri, 27 Apr 2001 09:35:10 -0700
>>
>>Don't know about l2tpd, but rfc2661 definitely allows it.
>>It is pretty common for a high density system.
>>
>>
>>
>>At 12:32 AM 4/27/01 -0700, Deja User wrote:
>>>Hi,
>>>
>>>Does the l2tp state machine allow us to negotiate more than one call at the same time i.e., can I have one call in the ICRQ state (waiting for an ICRP) and a second call also going to the ICRQ state (waiting for an ICRP)? ( I think the present version of l2tp allows only one outstanding call in this kind of state).
>>>
>>>Also, I just now came to know that the below is not true.
>>>
>>>i.e., t->call_head->xxx cannot be assigned to c->xxx (xxx = cid, bearer, dialing etc).
>>>
>>>
>>>citl
>>>
>>>>To: mar...@ma... l2...@ma...
>>>>From: ci...@my...
>>>>Date: Wed, 25 Apr 2001 21:52:36
>>>>Subject: doubt in avp.c
>>>>
>>>>Hi,
>>>>
>>>>In the function avp.c:assigned_call_avp() the following line of code is present
>>>>
>>>> if (c->msgtype == CDN) {
>>>> c->qcid = ntohs(raw[3]);
>>>> } else if (c->msgtype == ICRQ) {
>>>> t->call_head->cid = ntohs(raw[3]);
>>>> } else if (c->msgtype == ICRP) {
>>>> c->cid = ntohs(raw[3]);
>>>> }
>>>>
>>>>In the second if statement, why do we assign raw[3] to t->call_head->cid? Is this going to be the same as c->cid?
>>>>
>>>>I have similar doubt with the assignment for the following variables. All functions in avp.c
>>>>
>>>>1. t->call_head->bearer in bearer_type_avp()
>>>>2. t->call_head->dialing in dialing_number_avp()
>>>>3. t->call_head->dialed in dialed_number_avp()
>>>>4. t->call_head->subaddy in sub_address_avp()
>>>>5. t->call_head->serno in call_serno_avp()
>>>>
>>>>citl
>>>
>>>
>>>------------------------------------------------------------
>>>--== Sent via Deja.com ==--
>>>http://www.deja.com/
>>>
>>
>>_______________________________________________
>>L2tpd-devel mailing list
>>L2t...@li...
>>http://lists.sourceforge.net/lists/listinfo/l2tpd-devel
>
>
>------------------------------------------------------------
>--== Sent via Deja.com ==--
>http://www.deja.com/
>
|
|
From: Deja U. <ci...@my...> - 2001-04-30 18:25:59
|
Suppose the LAC sends two ICRQs and the LNS sends back two ICRPs in response to these two messages. How should the LNS map the ICRP to the right ICRQ?
citl
>To: l2...@ma...
>From: Ignacio Goyret <ig...@lu...>
>Cc: l2t...@li...
>Subject: [L2tpd-devel] Re: state machine of l2tp
>Reply-To: l2t...@li...
>Date: Fri, 27 Apr 2001 09:35:10 -0700
>
>Don't know about l2tpd, but rfc2661 definitely allows it.
>It is pretty common for a high density system.
>
>
>
>At 12:32 AM 4/27/01 -0700, Deja User wrote:
>>Hi,
>>
>>Does the l2tp state machine allow us to negotiate more than one call at the same time i.e., can I have one call in the ICRQ state (waiting for an ICRP) and a second call also going to the ICRQ state (waiting for an ICRP)? ( I think the present version of l2tp allows only one outstanding call in this kind of state).
>>
>>Also, I just now came to know that the below is not true.
>>
>>i.e., t->call_head->xxx cannot be assigned to c->xxx (xxx = cid, bearer, dialing etc).
>>
>>
>>citl
>>
>>>To: mar...@ma... l2...@ma...
>>>From: ci...@my...
>>>Date: Wed, 25 Apr 2001 21:52:36
>>>Subject: doubt in avp.c
>>>
>>>Hi,
>>>
>>>In the function avp.c:assigned_call_avp() the following line of code is present
>>>
>>> if (c->msgtype == CDN) {
>>> c->qcid = ntohs(raw[3]);
>>> } else if (c->msgtype == ICRQ) {
>>> t->call_head->cid = ntohs(raw[3]);
>>> } else if (c->msgtype == ICRP) {
>>> c->cid = ntohs(raw[3]);
>>> }
>>>
>>>In the second if statement, why do we assign raw[3] to t->call_head->cid? Is this going to be the same as c->cid?
>>>
>>>I have similar doubt with the assignment for the following variables. All functions in avp.c
>>>
>>>1. t->call_head->bearer in bearer_type_avp()
>>>2. t->call_head->dialing in dialing_number_avp()
>>>3. t->call_head->dialed in dialed_number_avp()
>>>4. t->call_head->subaddy in sub_address_avp()
>>>5. t->call_head->serno in call_serno_avp()
>>>
>>>citl
>>
>>
>>------------------------------------------------------------
>>--== Sent via Deja.com ==--
>>http://www.deja.com/
>>
>
>_______________________________________________
>L2tpd-devel mailing list
>L2t...@li...
>http://lists.sourceforge.net/lists/listinfo/l2tpd-devel
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
|
|
From: Deja U. <ci...@my...> - 2001-04-29 07:19:30
|
Hi,
I was making some changes to the l2tp code and doing some testing. I got the following as the data being sent.
network_thread: call 22714 tunnel 17767
packet dump:
HEX: { 63 63 45 67 58 BA 00 02 00 02 FF 03 C0 21 01 01 00 14 02 06 00 00 00 00 05 06 2D DF 79 01 07 02 08 02 }
Isn't this strange? It has the lbit set. But the tunnel id gets into the 3,4 byte positions of this packet [ htons(0x45 67) = 17767 ] while it should have got into positions 5,6.
Why could this be happening?
[I have not modified the function add_payload_hdr() function.]
citl
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
|
|
From: Ehreth I. <imr...@sy...> - 2001-04-27 23:35:55
|
Hi Deja User writes: > What is the purpose of the the self call (struct call *self ) in a tunnel? > > citl > > ------------------------------------------------------------ > --== Sent via Deja.com ==-- > http://www.deja.com/ It has two purpose as far as I know. * It is used to hold some information about the tunnel what is common to the call. * There are places in the code always requiring a valid call structure. The self call is used to pass as the call when there is no valid call. gothi |
|
From: Ignacio G. <ig...@lu...> - 2001-04-27 17:14:23
|
Don't know about l2tpd, but rfc2661 definitely allows it.
It is pretty common for a high density system.
At 12:32 AM 4/27/01 -0700, Deja User wrote:
>Hi,
>
>Does the l2tp state machine allow us to negotiate more than one call at the same time i.e., can I have one call in the ICRQ state (waiting for an ICRP) and a second call also going to the ICRQ state (waiting for an ICRP)? ( I think the present version of l2tp allows only one outstanding call in this kind of state).
>
>Also, I just now came to know that the below is not true.
>
>i.e., t->call_head->xxx cannot be assigned to c->xxx (xxx = cid, bearer, dialing etc).
>
>
>citl
>
>>To: mar...@ma... l2...@ma...
>>From: ci...@my...
>>Date: Wed, 25 Apr 2001 21:52:36
>>Subject: doubt in avp.c
>>
>>Hi,
>>
>>In the function avp.c:assigned_call_avp() the following line of code is present
>>
>> if (c->msgtype == CDN) {
>> c->qcid = ntohs(raw[3]);
>> } else if (c->msgtype == ICRQ) {
>> t->call_head->cid = ntohs(raw[3]);
>> } else if (c->msgtype == ICRP) {
>> c->cid = ntohs(raw[3]);
>> }
>>
>>In the second if statement, why do we assign raw[3] to t->call_head->cid? Is this going to be the same as c->cid?
>>
>>I have similar doubt with the assignment for the following variables. All functions in avp.c
>>
>>1. t->call_head->bearer in bearer_type_avp()
>>2. t->call_head->dialing in dialing_number_avp()
>>3. t->call_head->dialed in dialed_number_avp()
>>4. t->call_head->subaddy in sub_address_avp()
>>5. t->call_head->serno in call_serno_avp()
>>
>>citl
>
>
>------------------------------------------------------------
>--== Sent via Deja.com ==--
>http://www.deja.com/
>
|
|
From: Deja U. <ci...@my...> - 2001-04-27 07:32:25
|
Hi,
Does the l2tp state machine allow us to negotiate more than one call at the same time i.e., can I have one call in the ICRQ state (waiting for an ICRP) and a second call also going to the ICRQ state (waiting for an ICRP)? ( I think the present version of l2tp allows only one outstanding call in this kind of state).
Also, I just now came to know that the below is not true.
i.e., t->call_head->xxx cannot be assigned to c->xxx (xxx = cid, bearer, dialing etc).
citl
>To: mar...@ma... l2...@ma...
>From: ci...@my...
>Date: Wed, 25 Apr 2001 21:52:36
>Subject: doubt in avp.c
>
>Hi,
>
>In the function avp.c:assigned_call_avp() the following line of code is present
>
> if (c->msgtype == CDN) {
> c->qcid = ntohs(raw[3]);
> } else if (c->msgtype == ICRQ) {
> t->call_head->cid = ntohs(raw[3]);
> } else if (c->msgtype == ICRP) {
> c->cid = ntohs(raw[3]);
> }
>
>In the second if statement, why do we assign raw[3] to t->call_head->cid? Is this going to be the same as c->cid?
>
>I have similar doubt with the assignment for the following variables. All functions in avp.c
>
>1. t->call_head->bearer in bearer_type_avp()
>2. t->call_head->dialing in dialing_number_avp()
>3. t->call_head->dialed in dialed_number_avp()
>4. t->call_head->subaddy in sub_address_avp()
>5. t->call_head->serno in call_serno_avp()
>
>citl
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
|
|
From: Deja U. <ci...@my...> - 2001-04-26 21:29:47
|
What is the purpose of the the self call (struct call *self ) in a tunnel? citl ------------------------------------------------------------ --== Sent via Deja.com ==-- http://www.deja.com/ |
|
From: Jeff M. <je...@ig...> - 2001-04-26 14:17:44
|
Also sprach Boby S >I have some doubts regarding L2TP installation on linux. I downloaded >L2TP source(l2tpd-0.61 and 0.62 ) from the net and I have PPP- version >2.4 code. How I can integrate L2TP with PPP stack? Since I did not >find any modification for L2TP on PPP code (version 2.4), do I need to >modify the PPP code? if so, could you please tell me what I should >modify. If anybody could suggest me operations including modifications >in sequential order I would be more grateful. In short I would like to >know the installation procedure of L2TP with PPP on linux. There is no need to do any changes to PPP or pppd. l2tpd is completely userspace, which is inefficient, but also means that pppd and the kernel PPP support just sees at pty with PPP frames arriving and being sent. PPP and pppd don't need to know anything beyond that. Just compile l2tpd, and run it. It'll tell you what files it needs (probably /etc/l2tp/l2tpd.conf is all), the rest is all run-time configuration. -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Boby S <bo...@ta...> - 2001-04-26 14:07:59
|
Hi All, I have some doubts regarding L2TP installation on linux. I downloaded L2TP source(l2tpd-0.61 and 0.62 ) from the net and I have PPP- version 2.4 code. How I can integrate L2TP with PPP stack? Since I did not find any modification for L2TP on PPP code (version 2.4), do I need to modify the PPP code? if so, could you please tell me what I should modify. If anybody could suggest me operations including modifications in sequential order I would be more grateful. In short I would like to know the installation procedure of L2TP with PPP on linux. Thanks in Advance, Best regards, Boby |
|
From: Jeff M. <je...@ig...> - 2001-04-25 14:36:40
|
Also sprach Deja User >Yes. I want to bring up thousands of calls on a l2tp tunnel. That is >why I am thinking of these stuff. Hrmm...well...with thousands of tunnels I see where the linked lists and other optimizations that you're talking about might be useful. More useful, though, I think, would be kernel support for L2TP. I'm fairly convinced that context switching on the data path between kernel and user processes is what's really killing performance on this thing. At the very least, it effectively would accomplish a lot of the things that you're suggesting as well (basically the seperation of data switching which needs to be done very quickly, from the control functions which could be done at a rather more leisurely pace) -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Deja U. <ci...@my...> - 2001-04-25 04:42:22
|
Yes. I want to bring up thousands of calls on a l2tp tunnel. That is why I am thinking of these stuff. >Well...I think you may be getting into some premature optimizing here. >I tend to adhere to the Keep It Simple idea until something gets shown >to be a problem and needs to be optimized. > >Similar for the hashes instead of linked lists. You'd have to have a >*lot* of sessions active for the linked list to cause any problems. > >I will say, and this is an open "bug" on sourceforge, that the call >close functionality of the current code *sucks*, but it'll take some >major rearranging of code to fix that. ------------------------------------------------------------ --== Sent via Deja.com ==-- http://www.deja.com/ |
|
From: Jeff M. <je...@ig...> - 2001-04-24 18:15:26
|
Also sprach Deja User >In the file/function network.c:network_thread(), there is an infinite >for loop. Inside this for loop, there are 2 while loops and the first >thing they do is to see if any call/tunnel needs to be closed and if >so, close it. >Instead of having to do this check everytime and wasting quite a lot of >time, is it not better to handle it in some different way? >Eg: signal-catching? Or someone may have a still better way for this? Well...I think you may be getting into some premature optimizing here. I tend to adhere to the Keep It Simple idea until something gets shown to be a problem and needs to be optimized. Similar for the hashes instead of linked lists. You'd have to have a *lot* of sessions active for the linked list to cause any problems. I will say, and this is an open "bug" on sourceforge, that the call close functionality of the current code *sucks*, but it'll take some major rearranging of code to fix that. -- Jeff McAdams Email: je...@ig... Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 |
|
From: Deja U. <ci...@my...> - 2001-04-24 18:08:07
|
Hi, In the file/function network.c:network_thread(), there is an infinite for loop. Inside this for loop, there are 2 while loops and the first thing they do is to see if any call/tunnel needs to be closed and if so, close it. Instead of having to do this check everytime and wasting quite a lot of time, is it not better to handle it in some different way? Eg: signal-catching? Or someone may have a still better way for this? citl ------------------------------------------------------------ --== Sent via Deja.com ==-- http://www.deja.com/ |
21 messages has been excluded from this view by a project administrator.
