Re: NPPPD with intermediate LTS
Hi, On Mon, 13 May 2013 15:28:38 +0100 Joe Holden li...@rewt.org.uk wrote: YASUOKA Masahiko wrote: On Wed, 08 May 2013 12:32:16 +0100 Joe Holden li...@rewt.org.uk wrote: YASUOKA Masahiko wrote: On Tue, 07 May 2013 22:38:46 +0100 Joe Holden li...@rewt.org.uk wrote: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the dialin-proxy message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 Those AVPs don't seem to be requested by the LAC. 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The LAC seems to be starting CHAP without LCP. The problem seems to be come from the LAC. If mpd has settings about proxy LCP and authentication, I would like you to try them. mpd doesn't have the ability to generate Proxy auth AVPs, I currently use both mpd and others without proxied avps, afaic it isn't breaking rfc to restart lcp at every point (which is how I work things currently) npppd itself is in Link Establishment Phase. As RFC 1661 section 3.4., | Any non-LCP packets received during this phase MUST be silently | discarded. so discarding CHAP packets from mpd should not be a problem. But npppd doesn't start LCP actively. I think this causes the problem in this case. The peer is in Authentication Phase, it must be able to receive the LCP packets from npppd. I attached the diff which makes npppd start LCP actively. Could you try the diff? How difficult would it be to add a config option to always restart lcp, or maybe just if proxied avps aren't there? If my understanding is correct and the diff will fix the problem, it's easy. --yasuoka Index: usr.sbin/npppd/npppd/lcp.c === RCS file: /cvs/openbsd/src/usr.sbin/npppd/npppd/lcp.c,v retrieving revision 1.8 diff -u -p -r1.8 lcp.c --- usr.sbin/npppd/npppd/lcp.c 18 Sep 2012 13:14:08 - 1.8 +++ usr.sbin/npppd/npppd/lcp.c 15 May 2013 02:46:28 - @@ -122,7 +122,9 @@ lcp_init(lcp *_this, npppd_ppp *ppp) _this-fsm.ppp = ppp; _this-fsm.callbacks = lcp_callbacks; _this-fsm.protocol = PPP_PROTO_LCP; + /* _this-fsm.flags |= OPT_SILENT; +*/ _this-timerctx.ctx = _this; _this-recv_ress = 0;
Re: NPPPD with intermediate LTS
YASUOKA Masahiko wrote: Hi, On Mon, 13 May 2013 15:28:38 +0100 Joe Holden li...@rewt.org.uk wrote: YASUOKA Masahiko wrote: On Wed, 08 May 2013 12:32:16 +0100 Joe Holden li...@rewt.org.uk wrote: YASUOKA Masahiko wrote: On Tue, 07 May 2013 22:38:46 +0100 Joe Holden li...@rewt.org.uk wrote: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the dialin-proxy message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 Those AVPs don't seem to be requested by the LAC. 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The LAC seems to be starting CHAP without LCP. The problem seems to be come from the LAC. If mpd has settings about proxy LCP and authentication, I would like you to try them. mpd doesn't have the ability to generate Proxy auth AVPs, I currently use both mpd and others without proxied avps, afaic it isn't breaking rfc to restart lcp at every point (which is how I work things currently) npppd itself is in Link Establishment Phase. As RFC 1661 section 3.4., | Any non-LCP packets received during this phase MUST be silently | discarded. so discarding CHAP packets from mpd should not be a problem. But npppd doesn't start LCP actively. I think this causes the problem in this case. The peer is in Authentication Phase, it must be able to receive the LCP packets from npppd. I attached the diff which makes npppd start LCP actively. Could you try the diff? How difficult would it be to add a config option to always restart lcp, or maybe just if proxied avps aren't there? If my understanding is correct and the diff will fix the problem, it's easy. Perfect! See initial chap not started message, but then negotiation occurs as expected. Thanks --yasuoka Index: usr.sbin/npppd/npppd/lcp.c === RCS file: /cvs/openbsd/src/usr.sbin/npppd/npppd/lcp.c,v retrieving revision 1.8 diff -u -p -r1.8 lcp.c --- usr.sbin/npppd/npppd/lcp.c 18 Sep 2012 13:14:08 - 1.8 +++ usr.sbin/npppd/npppd/lcp.c 15 May 2013 02:46:28 - @@ -122,7 +122,9 @@ lcp_init(lcp *_this, npppd_ppp *ppp) _this-fsm.ppp = ppp; _this-fsm.callbacks = lcp_callbacks; _this-fsm.protocol = PPP_PROTO_LCP; + /* _this-fsm.flags |= OPT_SILENT; +*/ _this-timerctx.ctx = _this; _this-recv_ress = 0;
Re: NPPPD with intermediate LTS
YASUOKA Masahiko wrote: On Wed, 08 May 2013 12:32:16 +0100 Joe Holden li...@rewt.org.uk wrote: YASUOKA Masahiko wrote: On Tue, 07 May 2013 22:38:46 +0100 Joe Holden li...@rewt.org.uk wrote: I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: In this case, npppd assumes the LAC is using Proxy LCP and Authentication AVP in RFC 2661. Is it possible to force npppd to treat it as a non-dialin tunnel? 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the dialin-proxy message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 Those AVPs don't seem to be requested by the LAC. 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The LAC seems to be starting CHAP without LCP. The problem seems to be come from the LAC. If mpd has settings about proxy LCP and authentication, I would like you to try them. mpd doesn't have the ability to generate Proxy auth AVPs, I currently use both mpd and others without proxied avps, afaic it isn't breaking rfc to restart lcp at every point (which is how I work things currently) How difficult would it be to add a config option to always restart lcp, or maybe just if proxied avps aren't there? --yasuoka Thanks, Joe
Re: NPPPD with intermediate LTS
On Wed, 08 May 2013 12:32:16 +0100 Joe Holden li...@rewt.org.uk wrote: YASUOKA Masahiko wrote: On Tue, 07 May 2013 22:38:46 +0100 Joe Holden li...@rewt.org.uk wrote: I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: In this case, npppd assumes the LAC is using Proxy LCP and Authentication AVP in RFC 2661. 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the dialin-proxy message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 Those AVPs don't seem to be requested by the LAC. 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The LAC seems to be starting CHAP without LCP. The problem seems to be come from the LAC. If mpd has settings about proxy LCP and authentication, I would like you to try them. --yasuoka
Re: NPPPD with intermediate LTS
Hi, YASUOKA Masahiko wrote: Hi, On Tue, 07 May 2013 22:38:46 +0100 Joe Holden li...@rewt.org.uk wrote: I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the dialin-proxy message before these messages? If you have, I would like to see it. The only message ppp related prior to those is: 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 RecvICCN session_id=5644 calling_number= tx_conn_speed=1000 framing=sync 2013-05-08 12:21:07:NOTICE: l2tpd ctrl=1 call=3490 logtype=PPPBind ppp=0 2013-05-08 12:21:07:INFO: ppp id=0 layer=base logtype=Started tunnel=L2TP_ipv4(172.16.10.57:54189) 2013-05-08 12:21:07:INFO: l2tpd ctrl=1 call=3490 SendZLB 2013-05-08 12:21:08:INFO: ppp id=0 layer=base ppp_recv_packet: Rcvd broken frame. ACFC is not accepted, but received ppp frame that has no address. 2013-05-08 12:21:08:INFO: ppp id=0 layer=chap proto=unknown Received chap packet. But chap is not started The ACFC message appears when blindly forwarded also, but then the next message is the expected one: 2013-05-08 12:24:04:INFO: ppp id=0 layer=lcp logtype=Opened mru=1400/1480 auth=MS-CHAP-V2 magic=9d8d641c/77831e4b This is on a test setup currently, but mirrors the behaviour as it would see on a real network. If I blindly switch to npppd all is well, I've got l2tp-lcp-reneg enabled but it doesn't seem to make any difference, likewise with force. Is this known behaviour or am I missing something? Does the config l2tp-accept-dialin yes line in the `tunnel' config? I've got that in the config yes: listen on 0.0.0.0 tcp-mss-adjust yes pipex yes authentication-method pap chap mschapv2 l2tp-lcp-renegotiation yes l2tp-force-lcp-renegotiation yes l2tp-accept-dialin yes --yasuoka Thanks
NPPPD with intermediate LTS
Hi all, I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started This is on a test setup currently, but mirrors the behaviour as it would see on a real network. If I blindly switch to npppd all is well, I've got l2tp-lcp-reneg enabled but it doesn't seem to make any difference, likewise with force. Is this known behaviour or am I missing something? Cheers.
Re: NPPPD with intermediate LTS
Hi, On Tue, 07 May 2013 22:38:46 +0100 Joe Holden li...@rewt.org.uk wrote: I'm testing out npppd as a termination device which is being fed from existing LACs (in this particular setup, mpd on FreeBSD) - if the LAC begins LCP to challenge the client for it's username in order to lookup the destination LNS, npppd just repeats the following until it gives up: 2013-05-07 22:29:03:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started 2013-05-07 22:29:05:INFO: ppp id=1 layer=chap proto=unknown Received chap packet. But chap is not started Do you have the dialin-proxy message before these messages? If you have, I would like to see it. This is on a test setup currently, but mirrors the behaviour as it would see on a real network. If I blindly switch to npppd all is well, I've got l2tp-lcp-reneg enabled but it doesn't seem to make any difference, likewise with force. Is this known behaviour or am I missing something? Does the config l2tp-accept-dialin yes line in the `tunnel' config? --yasuoka
