Thank you for the reply! I have been given permission to show a bit more about our setup. I snipped out some of the original message, and I'll post the additions at the bottom.
On Sat, Mar 06, 2021 at 07:45:03PM +0900, YASUOKA Masahiko wrote: > Hi, > > On Fri, 5 Mar 2021 19:07:45 +0000 > Ryan Freeman <ryan.free...@uniserveteam.com> wrote: > > Full disclosure: this took place over the course of about a month, and > > I've done my best to include the relevant info.. > > > > Unsure if this is really a bug, and I don't have a real diff for a fix, > > just a > > work-around, so misc it is. > > > > This is done with OpenBSD 6.8-stable, syspatch 001 through 012 installed. > > We considered trying -current, but noticed no activity in the npppd tree > > that might make a difference. > > > > 'old' and 'new' equipment types from upstream are both Juniper, though > > unsure of exact models. Old should be Juniper ERX of some type, new > > I only know this from packet capture: Juniper Networks/Unisphere(4874). > > > > I work for a small ISP and we are exploring the use of npppd(8) for > > termination of L2TP with incumbent for xDSL connections. > > > > Working with the provider, their 'old' equipment works fine[1], however, > > the 'new' network would always cause these errors upon receipt of Proxy AVP: > > > > Feb 5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 Received bad > > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 33 > 24 > > Feb 5 14:13:13 edge9 npppd[86416]: l2tpd ctrl=2359 call=2685 SendCDN > > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none > > > > Looking at RFC 2661, I can't actually figure where a limit of 24 is imposed, > > ...snip... > > Yes. The limit is come from MAX_CHALLENGE_LENGTH in ppp.h. > > 85 #define MAX_CHALLENGE_LENGTH 24 Thank you! > > In RFC 2661, > > This AVP MUST be present for Proxy Authen Types 2 and 5. The > Challenge field contains the CHAP challenge presented to the > client by the LAC. > > Proxy Authen Challenge AVP is for "Proxy Authen Types 2 and 5". > > Proxy Authen Type (ICCN) > (snip) > Defined Authen Type values are: > 0 - Reserved > 1 - Textual username/password exchange > 2 - PPP CHAP > 3 - PPP PAP > 4 - No Authentication > 5 - Microsoft CHAP Version 1 (MSCHAPv1) > > It's for CHAP or MSCHAPv1. If MD5 is selected for PPP CHAP, the > challenge length for CHAP is 16 octet. The challenge for MSCHAPv1 is > also 8 octet, but npppd doesn't support MSCHAv1 anyway. So 24 must be > enough for RFC 2661. > > I'd like to see the packet capture of ICCN from Juniper to see what is > happening. (what authen type is used.) I will contact you off-list about packet captures. > > ...snip... > > Ultimately we managed to get this working by simply omitting the size check > > as such: > > > > Index: l2tp/l2tp_call.c > > =================================================================== > > RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_call.c,v > > retrieving revision 1.19 > > diff -u -p -r1.19 l2tp_call.c > > --- l2tp/l2tp_call.c 5 Dec 2015 16:10:31 -0000 1.19 > > +++ l2tp/l2tp_call.c 5 Mar 2021 17:46:12 -0000 > > @@ -546,7 +546,8 @@ l2tp_call_recv_ICCN(l2tp_call *_this, u_ > > dpi->last_recv_lcp.ldata = avp_attr_length(avp); > > break; > > case L2TP_AVP_TYPE_PROXY_AUTHEN_CHALLENGE: > > - AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall)); > > + /* XXX: disable to try and skirt 'too long' errors */ > > + /* AVP_MAXLEN_CHECK(avp, sizeof(dpi->auth_chall)); */ > > memcpy(dpi->auth_chall, avp->attr_value, > > avp_attr_length(avp)); > > dpi->lauth_chall = avp_attr_length(avp); > > > > We've been running this modified npppd for a week now, our upstream is happy > > that they can continue phasing out their 'old' gear, and our endusers are > > Do you mean that the endusers can connect with the above diff? Absolutely. Prior to disabling that particular size check, endusers do not get past the RecvICCN stage due to "PROXY_AUTHEN_CHALLENGE too long" error. > diff --git a/usr.sbin/npppd/npppd/ppp.h b/usr.sbin/npppd/npppd/ppp.h > index 1bb8bfc6cf3..219b47c6172 100644 > --- a/usr.sbin/npppd/npppd/ppp.h > +++ b/usr.sbin/npppd/npppd/ppp.h > @@ -82,7 +82,7 @@ > > #define MAX_USERNAME_LENGTH 256 > #define MAX_PASSWORD_LENGTH 256 > -#define MAX_CHALLENGE_LENGTH 24 > +#define MAX_CHALLENGE_LENGTH 256 > > #define INADDR_IPCP_OBEY_REMOTE_REQ 0x00000000L > > is better if it works. Thank you! I will report back with results. > > I am thinking that we would want a maximum length set there still, but > > perhaps > > it can be pushed up? I've seen many of those error types, all seem to stay > > below 100: > > > > Feb 8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 Received bad > > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 40 > 24 > > Feb 8 11:42:53 edge9 npppd[86416]: l2tpd ctrl=5477 call=32713 SendCDN > > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none > > Feb 8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 Received bad > > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 62 > 24 > > Feb 8 11:42:54 edge9 npppd[86416]: l2tpd ctrl=5477 call=29504 SendCDN > > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none > > Feb 8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 Received bad > > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 46 > 24 > > Feb 8 11:43:01 edge9 npppd[86416]: l2tpd ctrl=5477 call=31527 SendCDN > > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none > > Feb 8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 Received bad > > ICCN: Attribute value is too long PROXY_AUTHEN_CHALLENGE 63 > 24 > > Feb 8 11:43:06 edge9 npppd[86416]: l2tpd ctrl=5477 call=1626 SendCDN > > result=ERROR_CODE/2 error=WRONG_LENGTH/2 messsage=none > > > > [1] at some point over the course of debugging, I did notice that this > > error would /sometimes/ print on the connections from the 'old' equipment, > > but would continue to work anyway: > > > > Mar 5 10:21:44 edge9 npppd[35209]: ppp id=4108 layer=chap proto=unknown > > "Proxy Authen Challenge" is too long. > > > > This now also prints on all the 'new equipment' successful connections since > > disabling the AVP_MAXLEN_CHECK. > > -- > YASUOKA Masahiko http://yasuoka.net/~yasuoka/ > mailto:yasu...@yasuoka.net mobile:090-8801-1637 Our general setup looks something like this fake representation with us being 'Downstream', and npppd(8) running on the Downstream LNS: <via internet> .......... __________ ________________ / \______________/ \ | Downstream ISP | | Upstream ISP | | | RADIUS | | RADIUS Proxy | | `--------.-------' `------.-------' | \_______________ ______|_______ ________|________ __________ | Downstream ISP|__| Upstream ISP |__| Upstream Juniper|__| ADSL CPE | | Network | | Network | | ERX | | w/ PPPoE | /`---------------' `--------------' `--------,--------' `----------' _______/________ | | Downstream ISP |..............<via NNI>.............../ | LNS | `----------------' I've cleaned up some log data showing sessions that do establish from upstream on their original equipment (two variations) and their new equipment. L2TP session with upstream 'old' equipment, no errors: Mar 7 14:08:44 edge9 npppd[35209]: l2tpd ctrl=4 call=17315 RecvICRQ session_id=20635 Mar 7 14:08:44 edge9 npppd[35209]: l2tpd ctrl=4 call=17315 SendICRP session_id=17315 Mar 7 14:08:45 edge9 npppd[35209]: l2tpd ctrl=4 call=17315 RecvICCN session_id=20635 calling_number=GigabitEthernet 5/0.12345:1-236 tx_conn_speed=1000000000 framing=sync Mar 7 14:08:45 edge9 npppd[35209]: l2tpd ctrl=4 call=17315 logtype=PPPBind ppp=5514 Mar 7 14:08:45 edge9 npppd[35209]: ppp id=5514 layer=lcp dialin-proxy user=xxxx...@pppoe.example.com auth-type=MD5-CHAP renegotiate=no Mar 7 14:08:45 edge9 npppd[35209]: ppp id=5514 layer=base logtype=Started tunnel=L2TP(1.2.3.4:1701) Mar 7 14:08:45 edge9 npppd[35209]: ppp id=5514 layer=lcp logtype=Opened mru=1460/1492 auth=MD5-CHAP magic=xxx32de1/xxx15636 Mar 7 14:08:45 edge9 npppd[35209]: l2tpd ctrl=4 call=17315 SendZLB Mar 7 14:08:45 edge9 npppd[35209]: ppp id=5514 layer=chap proto=chap logtype=Success username="xxxx...@pppoe.example.com" realm=DYNAMIC Mar 7 14:08:45 edge9 npppd[35209]: ppp id=5514 layer=ipcp IP Address peer=0.0.0.0 our=5.6.7.8 Mar 7 14:08:45 edge9 npppd[35209]: ppp id=5514 layer=ipcp logtype=Opened ip=5.6.7.8 assignType=dynamic Mar 7 14:08:45 edge9 npppd[35209]: ppp id=5514 layer=base logtype=TUNNELSTART user="xxxx...@pppoe.example.com" duration=0sec layer2=L2TP layer2from=1.2.3.4:1701 auth=MD5-CHAP ip=5.6.7.8 iface=pppac1 dialin_proxy=yes L2TP session with upstream 'old' equipment, "Proxy Authen Challenge" is too long error in layer=chap, but session works anyway: Mar 7 14:06:12 edge9 npppd[35209]: l2tpd ctrl=33 call=8471 RecvICRQ session_id=25752 Mar 7 14:06:12 edge9 npppd[35209]: l2tpd ctrl=33 call=8471 SendICRP session_id=8471 Mar 7 14:06:12 edge9 npppd[35209]: l2tpd ctrl=33 call=8471 RecvICCN session_id=25752 calling_number=GigabitEthernet 5/0.1234123456:20 tx_conn_speed=1000000000 framing=sync Mar 7 14:06:12 edge9 npppd[35209]: l2tpd ctrl=33 call=8471 logtype=PPPBind ppp=5513 Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=chap proto=unknown "Proxy Authen Challenge" is too long. Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=lcp dialin-proxy user=xxxx...@pppoe.example.com auth-type=MD5-CHAP renegotiate=no Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=base logtype=Started tunnel=L2TP(1.2.3.4:1701) Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=lcp logtype=Opened mru=1460/1492 auth=MD5-CHAP magic=xxx6f6c8/xxxad100 Mar 7 14:06:12 edge9 npppd[35209]: l2tpd ctrl=33 call=8471 SendZLB Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=chap proto=chap logtype=Success username="xxxx...@pppoe.example.com" realm=DYNAMIC Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=ipcp IP Address peer=0.0.0.0 our=5.6.7.8. Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=base unhandled protocol ipv6cp, 32855(8057) Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=ipcp logtype=Opened ip=5.6.7.8 assignType=dynamic Mar 7 14:06:12 edge9 npppd[35209]: ppp id=5513 layer=base logtype=TUNNELSTART user="xxxx...@pppoe.example.com" duration=0sec layer2=L2TP layer2from=1.2.3.4:1701 auth=MD5-CHAP ip=5.6.7.8 iface=pppac1 dialin_proxy=yes For this last example, without the patch, the session fails after RecvICCN due to the "PROXY_AUTH_CHALLENGE 33 > 24" type errors. L2TP session with upstream 'new' equipment, after commenting AVP_MAXLEN_CHECK from l2tp/l2tp_call.c; "Proxy Authen Challenge" is too long' error shows in layer=chap, but session works anyway: Mar 7 13:52:11 edge9 npppd[35209]: l2tpd ctrl=8 call=14842 RecvICRQ session_id=7982 Mar 7 13:52:11 edge9 npppd[35209]: l2tpd ctrl=8 call=14842 SendICRP session_id=14842 Mar 7 13:52:11 edge9 npppd[35209]: l2tpd ctrl=8 RecvZLB Mar 7 13:52:11 edge9 npppd[35209]: l2tpd ctrl=8 call=14842 RecvICCN session_id=7982 calling_number= tx_conn_speed=3000000000 framing=sync Mar 7 13:52:11 edge9 npppd[35209]: l2tpd ctrl=8 call=14842 logtype=PPPBind ppp=5509 Mar 7 13:52:11 edge9 npppd[35209]: ppp id=5509 layer=chap proto=unknown "Proxy Authen Challenge" is too long. Mar 7 13:52:11 edge9 npppd[35209]: ppp id=5509 layer=lcp dialin-proxy user=xxx...@pppoe.example.com auth-type=MD5-CHAP renegotiate=no Mar 7 13:52:11 edge9 npppd[35209]: ppp id=5509 layer=base logtype=Started tunnel=L2TP(1.2.3.4:1701) Mar 7 13:52:11 edge9 npppd[35209]: ppp id=5509 layer=lcp logtype=Opened mru=1460/1460 auth=MD5-CHAP magic=xxx35d9a/xxx3a687 Mar 7 13:52:11 edge9 npppd[35209]: l2tpd ctrl=8 call=14842 SendZLB Mar 7 13:52:11 edge9 npppd[35209]: l2tpd ctrl=40 RecvZLB Mar 7 13:52:14 edge9 npppd[35209]: ppp id=5509 layer=chap proto=chap Received challenge response has unknown id. Mar 7 13:52:14 edge9 npppd[35209]: ppp id=5509 layer=chap proto=chap logtype=Success username="xxxx...@pppoe.example.com" realm=DYNAMIC Mar 7 13:52:14 edge9 npppd[35209]: ppp id=5509 layer=ipcp IP Address peer=0.0.0.0 our=5.6.7.8. Mar 7 13:52:14 edge9 npppd[35209]: ppp id=5509 layer=ipcp logtype=Opened ip=5.6.7.8 assignType=dynamic Mar 7 13:52:14 edge9 npppd[35209]: ppp id=5509 layer=base logtype=TUNNELSTART user="xxxx...@pppoe.example.com" duration=3sec layer2=L2TP layer2from=1.2.3.4:1701 auth=MD5-CHAP ip=5.6.7.8 iface=pppac1 dialin_proxy=yes Mar 7 13:52:14 edge9 npppd[35209]: ppp id=5509 layer=base Using pipex=yes Our npppd.conf looks something like this: # $OpenBSD: npppd.conf,v 1.3 2020/01/23 03:01:22 dlg Exp $ authentication MGMT type radius { username-suffix mgmt.example.com authentication-server { address 192.168.10.10 port 1812 secret "verysecret" address 192.168.11.10 port 1812 secret "verysecret" } accounting-server { address 192.168.10.10 port 1813 secret "verysecret" address 192.168.11.10 port 1813 secret "verysecret" } } authentication DYNAMIC type radius { #username-suffix pppoe.example.com user-max-session 2 authentication-server { address 192.168.10.10 port 1812 secret "verysecret" address 192.168.11.10 port 1812 secret "verysecret" } accounting-server { address 192.168.10.10 port 1813 secret "verysecret" address 192.168.11.10 port 1813 secret "verysecret" } } tunnel L2TP protocol l2tp { listen on 123.123.123.123 authentication-method chap l2tp-hostname HOSTNAME l2tp-accept-dialin yes l2tp-lcp-renegotiation yes lcp-keepalive yes lcp-keepalive-interval 10 lcp-keepalive-retry-interval 5 lcp-keepalive-max-retries 3 mru 1460 tcp-mss-adjust yes l2tp-ctrl-in-pktdump yes #l2tp-ctrl-out-pktdump yes #debug-dump-pktin ip lcp ipcp #debug-dump-pktout ip lcp ipcp } ipcp mgmt { pool-address 192.168.1.2-192.168.1.255 dns-servers 1.1.1.1 } ipcp live { pool-address 10.2.3.2-10.2.3.255 pool-address 10.2.4.2-10.2.4.255 for static dns-servers 1.1.1.1 1.0.0.1 allow-user-selected-address no } interface pppac0 address 192.168.1.1 ipcp modem-mgmt interface pppac1 address 10.2.3.1 ipcp telus-pgs bind tunnel from L2TP authenticated by MGMT to pppac0 bind tunnel from L2TP authenticated by DYNAMIC to pppac1 Regards, -Ryan
