Discussion:
[uknof] SonicWALL PPPoE Issues over Talk-Talk WFTTC Circuits
Gareth Phillips
2017-01-28 15:12:22 UTC
Permalink
Hello all,

We're an ISP re-selling Talk-Talk wholesale LLU DSL and Wholesale FTTC circuits to a UK national customer base.

Within the last couple of weeks we've started noticing that our customers that are using a SonicWALL firewall / BT Openreach modem combination on FTTC circuits (authenticating over PPPoE) have started to disconnect and simply will not come back online again. This has only affected our customers using these SonicWALLs on FTTC so far - nobody else.

These same devices worked flawlessly on the BT WBMC network for several years without any issues and have recently worked flawlessly on the Talk Talk network for roughly one year until now.

Talk-Talk have been carrying out a series of software / network upgrades this month and we suspect that it's probably related to one of those. We've been in touch with Talk Talk Support and they are investigating the issue but they don't seem to be having much luck at this stage.

I was hoping that somebody out there may have experienced / noticed the same thing. I realise that this issue is quite specific, so unless you're using this kit in this configuration with this provider, then you may have not.

The only thing that seems to resolve this at the moment is a complete hardware replacement with a Billion router, which is what we use at a number of our other customer sites. The Openreach modem remains in place so we know it's not an issue with that. The connection then comes back up without issue.

Things we have tried so far...


* Changing the MTU on the SonicWALL WAN taking it right down from 1500 in increments to below 1300.

* We've tried a RADIUS Filter-ID of "l" (lower case L) to stop MRU renegotiation and a similar hard coded setting on the L2TP LNS tunnel for those particular circuits.

* We've tried configuring a fixed MTU on the L2TP LNS tunnel for those particular circuits.

* We've tried disabling IPv6 on the SonicWALL WAN interface doing the PPPoE authentication / negotiation.

* We've tried switching both the SonicWALL and modem off for over half an hour to kill any potential stale sessions.

Thank you.

Kind Regards,

Gareth Phillips.

Disclaimer: Views or opinions presented are solely those of the author and do not necessarily represent those of Clearstream Technology Ltd or Clearstream Technology Group Ltd (Clearstream). Confidentiality: This email and any attached files are confidential and intended solely for the use of the individual(s) to whom it is addressed. If you are not the intended recipient, you have received this email in error and any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please contact the sender. Security: This e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us. Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by Clearstream or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof.
Neil J. McRae
2017-01-28 15:57:08 UTC
Permalink
Suggest you do a wire shark between the OR modem and this box. It will show what's going on.

Neil

Sent from my iPhone

On 28 Jan 2017, at 15:34, Gareth Phillips <***@clearstreamgroup.co.uk<mailto:***@clearstreamgroup.co.uk>> wrote:

Hello all,

We're an ISP re-selling Talk-Talk wholesale LLU DSL and Wholesale FTTC circuits to a UK national customer base.

Within the last couple of weeks we've started noticing that our customers that are using a SonicWALL firewall / BT Openreach modem combination on FTTC circuits (authenticating over PPPoE) have started to disconnect and simply will not come back online again. This has only affected our customers using these SonicWALLs on FTTC so far - nobody else.

These same devices worked flawlessly on the BT WBMC network for several years without any issues and have recently worked flawlessly on the Talk Talk network for roughly one year until now.

Talk-Talk have been carrying out a series of software / network upgrades this month and we suspect that it's probably related to one of those. We've been in touch with Talk Talk Support and they are investigating the issue but they don't seem to be having much luck at this stage.

I was hoping that somebody out there may have experienced / noticed the same thing. I realise that this issue is quite specific, so unless you're using this kit in this configuration with this provider, then you may have not.

The only thing that seems to resolve this at the moment is a complete hardware replacement with a Billion router, which is what we use at a number of our other customer sites. The Openreach modem remains in place so we know it's not an issue with that. The connection then comes back up without issue.

Things we have tried so far...


* Changing the MTU on the SonicWALL WAN taking it right down from 1500 in increments to below 1300.

* We've tried a RADIUS Filter-ID of "l" (lower case L) to stop MRU renegotiation and a similar hard coded setting on the L2TP LNS tunnel for those particular circuits.

* We've tried configuring a fixed MTU on the L2TP LNS tunnel for those particular circuits.

* We've tried disabling IPv6 on the SonicWALL WAN interface doing the PPPoE authentication / negotiation.

* We've tried switching both the SonicWALL and modem off for over half an hour to kill any potential stale sessions.

Thank you.

Kind Regards,

Gareth Phillips.

Disclaimer: Views or opinions presented are solely those of the author and do not necessarily represent those of Clearstream Technology Ltd or Clearstream Technology Group Ltd (Clearstream). Confidentiality: This email and any attached files are confidential and intended solely for the use of the individual(s) to whom it is addressed. If you are not the intended recipient, you have received this email in error and any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please contact the sender. Security: This e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us. Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by Clearstream or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof.
Bjoern A. Zeeb
2017-01-28 20:34:53 UTC
Permalink
Post by Neil J. McRae
Suggest you do a wire shark between the OR modem and this box. It will
show what's going on.
yes or even simply, does the SonicWall logs say anything about what they
are attempting to do (might reveal at which stage things are failing,
PPPoE discovery, PPP, Auth, ..) and make (remote) debugging a lot easier
narrowing down the search). I am always extremely surprised when people
don’t mention the obvious in problem reports.

Gareth, given you seem to be trying to change RADIUS that means you are
seeing RADIUS requests for these customers? Because that alone already
tells you what to rule out early on. Can you be a bit more precise in
what you got?

/bz
Post by Neil J. McRae
On 28 Jan 2017, at 15:34, Gareth Phillips
Hello all,
We're an ISP re-selling Talk-Talk wholesale LLU DSL and Wholesale FTTC
circuits to a UK national customer base.
Within the last couple of weeks we've started noticing that our
customers that are using a SonicWALL firewall / BT Openreach modem
combination on FTTC circuits (authenticating over PPPoE) have started
to disconnect and simply will not come back online again. This has
only affected our customers using these SonicWALLs on FTTC so far -
nobody else.
These same devices worked flawlessly on the BT WBMC network for
several years without any issues and have recently worked flawlessly
on the Talk Talk network for roughly one year until now.
Talk-Talk have been carrying out a series of software / network
upgrades this month and we suspect that it's probably related to one
of those. We've been in touch with Talk Talk Support and they are
investigating the issue but they don't seem to be having much luck at
this stage.
I was hoping that somebody out there may have experienced / noticed
the same thing. I realise that this issue is quite specific, so
unless you're using this kit in this configuration with this provider,
then you may have not.
The only thing that seems to resolve this at the moment is a complete
hardware replacement with a Billion router, which is what we use at a
number of our other customer sites. The Openreach modem remains in
place so we know it's not an issue with that. The connection then
comes back up without issue.
Things we have tried so far...
* Changing the MTU on the SonicWALL WAN taking it right down
from 1500 in increments to below 1300.
* We've tried a RADIUS Filter-ID of "l" (lower case L) to stop
MRU renegotiation and a similar hard coded setting on the L2TP LNS
tunnel for those particular circuits.
* We've tried configuring a fixed MTU on the L2TP LNS tunnel
for those particular circuits.
* We've tried disabling IPv6 on the SonicWALL WAN interface
doing the PPPoE authentication / negotiation.
* We've tried switching both the SonicWALL and modem off for
over half an hour to kill any potential stale sessions.
Thank you.
Kind Regards,
Gareth Phillips.
Gareth Phillips
2017-01-28 19:48:01 UTC
Permalink
Thanks Neil. Fortunately I still have access to this most recent SonicWALL box remotely via the backup ADSL interface. I've attached a .pcap trace file from the PPPoE WAN interface that connects to the OR modem and I've also attached some PPPoE debug logs from the SonicWALL. Please let me know if you have any trouble receiving them.

This happens with a whole range of different SonicWALL models, from TZ100 / 200's to TZ105's and even the newest SOHO devices. Our LNS that these sessions are hosted on is a Firebrick FB6202 Running FB6202 Nestor+ (V1.35.019 2015-02-11T17:21:55) firmware. The logs off of that for this particular FTTC PPPoE session from this SonicWALL are as follows. We have checked and double-checked our RADIUS servers and the username / password combos are definitely correct, so there's no issue there. Thanks.

28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 request lts001.hex NMCIHW eth 0/1/17:***@FTTC1264195
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 incoming NMCIHW eth 0/1/17:***@FTTC1264195
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Init Rx C021:LCP 01 01 000E ConfReq 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Last Rx C021:LCP 01 01 000E ConfReq 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Last Tx C021:LCP 01 01 000F ConfReq 03:AUTH 05 c2:23:05 05:MAGIC 06 0a:d4:9c:d4 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Auth name 6d:63:6d:66:6d:74:32:40:63:6f:6e:6e:65:63:74:2e:63:6c:65:61:72:73:74:72:65:61:6d:67:72:6f:75:70:2e:63:6f:2e:75:6b [***@connect.username]
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Auth chal 15 57:7d:f2:7f:ea:06:6c:ff:f8:a8:3c:7d:f9:6f:59:a6
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Auth response 8c:8c:b0:d3:76:4e:b4:5c:de:60:76:80:83:9c:78:cf
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 connect ***@connect.username 39956000/9999000bps mtu1492
28 Jan 2017 19:24:22 radius-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C223:CHAP 03 15 0004 ***@connect.username
28 Jan 2017 19:24:22 radius-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C021:LCP 01 01 000E ConfReq 05:MAGIC 06 0a:d4:9c:d4 01:MRU 04 1472 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 8021:IPCP 01 01 0016 ConfReq 03:IP 06 0.0.0.0 81:DNS1 06 0.0.0.0 83:DNS2 06 0.0.0.0 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx 8021:IPCP 03 01 0016 ConfNak 03:IP 06 46.17.214.185 81:DNS1 06 185.23.52.131 83:DNS2 06 185.23.52.132 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 8057:IPV6CP 01 01 000E ConfReq 01:I/F 0A c2:ea:e4:ff:fe:7a:16:e6 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C021:LCP 08 01 0014 ProtoRej 8057 01 01 000E ConfReq 01:I/F 0A c2:ea:e4:ff:fe:7a:16:e6 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 C021:LCP 01 02 000E ConfReq 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx C021:LCP 02 02 000E ConfAck 01:MRU 04 1492 05:MAGIC 06 29:97:fe:3b ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Rx FF03 C021:LCP 02 01 000E ConfAck 05:MAGIC 06 0a:d4:9c:d4 01:MRU 04 1472 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S24816-43992 PPP Rx FF03 C021:LCP 08 B1 0040 ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00 00 08 04 00 00 00 71 q 72 r 73 s 74 t FD 12 A5 AD BA 38 8 8E BD FB 55 U 50 P 18 10 00 F8 E0 00 00 17 03 03 00 50 P D6 07 80 20 81 D2 6F o 57 W B8 CC 9C 2E . 0F
28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S43511-28544 PPP Rx FF03 C021:LCP 08 E9 001C ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00 00 08 04 00 00 00 71 q 72 r 73 s 74 t

Regards,

Gareth.

From: Neil J. McRae [mailto:***@domino.org]
Sent: 28 January 2017 15:57
To: Gareth Phillips <***@clearstreamgroup.co.uk>
Cc: ***@lists.uknof.org.uk
Subject: Re: [uknof] SonicWALL PPPoE Issues over Talk-Talk WFTTC Circuits

Suggest you do a wire shark between the OR modem and this box. It will show what's going on.

Neil

Sent from my iPhone

On 28 Jan 2017, at 15:34, Gareth Phillips <***@clearstreamgroup.co.uk<mailto:***@clearstreamgroup.co.uk>> wrote:
Hello all,

We're an ISP re-selling Talk-Talk wholesale LLU DSL and Wholesale FTTC circuits to a UK national customer base.

Within the last couple of weeks we've started noticing that our customers that are using a SonicWALL firewall / BT Openreach modem combination on FTTC circuits (authenticating over PPPoE) have started to disconnect and simply will not come back online again. This has only affected our customers using these SonicWALLs on FTTC so far - nobody else.

These same devices worked flawlessly on the BT WBMC network for several years without any issues and have recently worked flawlessly on the Talk Talk network for roughly one year until now.

Talk-Talk have been carrying out a series of software / network upgrades this month and we suspect that it's probably related to one of those. We've been in touch with Talk Talk Support and they are investigating the issue but they don't seem to be having much luck at this stage.

I was hoping that somebody out there may have experienced / noticed the same thing. I realise that this issue is quite specific, so unless you're using this kit in this configuration with this provider, then you may have not.

The only thing that seems to resolve this at the moment is a complete hardware replacement with a Billion router, which is what we use at a number of our other customer sites. The Openreach modem remains in place so we know it's not an issue with that. The connection then comes back up without issue.

Things we have tried so far...


* Changing the MTU on the SonicWALL WAN taking it right down from 1500 in increments to below 1300.

* We've tried a RADIUS Filter-ID of "l" (lower case L) to stop MRU renegotiation and a similar hard coded setting on the L2TP LNS tunnel for those particular circuits.

* We've tried configuring a fixed MTU on the L2TP LNS tunnel for those particular circuits.

* We've tried disabling IPv6 on the SonicWALL WAN interface doing the PPPoE authentication / negotiation.

* We've tried switching both the SonicWALL and modem off for over half an hour to kill any potential stale sessions.

Thank you.

Kind Regards,

Gareth Phillips.

Disclaimer: Views or opinions presented are solely those of the author and do not necessarily represent those of Clearstream Technology Ltd or Clearstream Technology Group Ltd (Clearstream). Confidentiality: This email and any attached files are confidential and intended solely for the use of the individual(s) to whom it is addressed. If you are not the intended recipient, you have received this email in error and any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please contact the sender. Security: This e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when e-mailing us. Although this email and any attachments are believed to be free of any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by Clearstream or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof.
Gareth Phillips
2017-01-29 00:31:17 UTC
Permalink
Thanks for the input Bjoern. No, neither the CPE's or our LNS's have had any recent software updates / configuration changes at all. Our provider on the other hand has been rolling out some major software upgrades across their network. We suspect that something in one of those updates no longer agrees with the way that the SonicWALLs negotiate their PPPoE sessions.

It's like the SonicWALL is stuck waiting for something that it no longer receives and so it sends a termination request and things start all over again. I've scanned through some other LNS logs and it does look like IPCP packets are being sent once every second from the LNS yes.

29 Jan 2017 00:06:35 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:36 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:37 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:38 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:39 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:40 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:41 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:42 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:43 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:44 l2tp-poll T13111-30001-62.24.203.99 S19863-17367 PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98 ***@connect.username
29 Jan 2017 00:06:44 l2tp-rx T13111-30001-62.24.203.99 S19863-17367 PPP Rx FF03 C021:LCP 05 04 0004 TermReq ***@connect.username


-----Original Message-----
From: Bjoern A. Zeeb [mailto:bzeeb-***@lists.zabbadoz.net]
Sent: 28 January 2017 23:41
To: Gareth Phillips <***@clearstreamgroup.co.uk>
Cc: ***@lists.uknof.org.uk
Subject: Re: [uknof] SonicWALL PPPoE Issues over Talk-Talk WFTTC Circuits
Post by Gareth Phillips
Thanks Neil. Fortunately I still have access to this most recent
SonicWALL box remotely via the backup ADSL interface. I've attached a
.pcap trace file from the PPPoE WAN interface that connects to the OR
modem and I've also attached some PPPoE debug logs from the SonicWALL.
Please let me know if you have any trouble receiving them.
This happens with a whole range of different SonicWALL models, from
TZ100 / 200's to TZ105's and even the newest SOHO devices. Our LNS
that these sessions are hosted on is a Firebrick FB6202 Running FB6202
Nestor+ (V1.35.019 2015-02-11T17:21:55) firmware. The logs off of
that for this particular FTTC PPPoE session from this SonicWALL are as
follows. We have checked and double-checked our RADIUS servers and
the username / password combos are definitely correct, so there's no
issue there.
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Init Rx C021:LCP 01 01 000E ConfReq 01:MRU 04 1492 05:MAGIC 06
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Last Rx C021:LCP 01 01 000E ConfReq 01:MRU 04 1492 05:MAGIC 06
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Last Tx C021:LCP 01 01 000F ConfReq 03:AUTH 05 c2:23:05 05:MAGIC
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Auth name
6d:63:6d:66:6d:74:32:40:63:6f:6e:6e:65:63:74:2e:63:6c:65:61:72:73:74:7
2:65:61:6d:67:72:6f:75:70:2e:63:6f:2e:75:6b
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Auth chal 15 57:7d:f2:7f:ea:06:6c:ff:f8:a8:3c:7d:f9:6f:59:a6
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Auth response 8c:8c:b0:d3:76:4e:b4:5c:de:60:76:80:83:9c:78:cf
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
28 Jan 2017 19:24:22 radius-rx T13092-51756-62.24.203.227 S17150-9461
PPP Auth done.

The CPE log (unfortunately timestamps are not in synch) is a bit weird with regards to the CHAP Success message.
Post by Gareth Phillips
28 Jan 2017 19:24:22 radius-rx T13092-51756-62.24.203.227 S17150-9461
PPP Tx C021:LCP 01 01 000E ConfReq 05:MAGIC 06 0a:d4:9c:d4 01:MRU 04
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Rx FF03 8021:IPCP 01 01 0016 ConfReq 03:IP 06 0.0.0.0 81:DNS1 06
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Tx 8021:IPCP 03 01 0016 ConfNak 03:IP 06 46.17.214.185 81:DNS1 06
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Rx FF03 8057:IPV6CP 01 01 000E ConfReq 01:I/F 0A
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Tx C021:LCP 08 01 0014 ProtoRej 8057 01 01 000E ConfReq 01:I/F 0A
You reject IPV6CP. That’s fine. CPE stops on IPV6CP.
Post by Gareth Phillips
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Rx FF03 C021:LCP 01 02 000E ConfReq 01:MRU 04 1492 05:MAGIC 06
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Tx C021:LCP 02 02 000E ConfAck 01:MRU 04 1492 05:MAGIC 06
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Rx FF03 C021:LCP 02 01 000E ConfAck 05:MAGIC 06 0a:d4:9c:d4 01:MRU
LCP seems done. Not seen any missing packets. CPE ACKs the last bit
from your early request, so CPE should be happy as well with LCP UP.
Post by Gareth Phillips
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Tx 8021:IPCP 01 00 000A ConfReq 03:IP 06 62.24.191.98
You tell CPE your IP address.
The pcap on the other end shows this being received way too often,
re-send once a second; this end doesn’t show this.
But the CPE never ACKs.
And the CPE also doesn’t send you a request for its local IP address
end.

Seems the state machine on the CPE side is stuck?
Also can you confirm that your LNS is actually re-sending the IPCP
packet <n> times every second?
Post by Gareth Phillips
28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S24816-43992 PPP
Rx FF03 C021:LCP 08 B1 0040 ProtoRej AAAA 03 00 00 00 08 06 00 13 08
00 00 00 00 08 04 00 00 00 71 q 72 r 73 s 74 t FD 12 A5 AD BA 38 8 8E
BD FB 55 U 50 P 18 10 00 F8 E0 00 00 17 03 03 00 50 P D6 07 80 20 81
D2 6F o 57 W B8 CC 9C 2E . 0F
28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S43511-28544 PPP
Rx FF03 C021:LCP 08 E9 001C ProtoRej AAAA 03 00 00 00 08 06 00 13 08
00 00 00 00 08 04 00 00 00 71 q 72 r 73 s 74 t
Whatever those are I am confused about; Someone cleverly prints the
ASCII parts along with the hex values it seems. If T/Sxxxx-xxxxx is
the tunnel/session ID from L2TP this is a different session anyway?

The CPE on the remote end at best logs Auth done (even though it is
seems grumpy about it), LCP up, but never logs anything about IPCP
(whatever they’d call it). Not sure if we see the same
“conversation” there though.

Did the
James Bensley
2017-01-29 18:10:04 UTC
Permalink
On 28 January 2017 at 23:41, Bjoern A. Zeeb
Post by Gareth Phillips
Post by Gareth Phillips
28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461 PPP Tx
You tell CPE your IP address.
Which seems to be a TalkTalk IP?!
Post by Gareth Phillips
But the CPE never ACKs.
And the CPE also doesn’t send you a request for its local IP address end.
It does, here I believe:

28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Rx FF03 8021:IPCP 01 01 0016 ConfReq 03:IP 06 0.0.0.0 81:DNS1 06
0.0.0.0 83:DNS2 06 0.0.0.0 ***@connect.username

28 Jan 2017 19:24:22 l2tp-rx T13092-51756-62.24.203.227 S17150-9461
PPP Tx 8021:IPCP 03 01 0016 ConfNak 03:IP 06 46.17.214.185 81:DNS1 06
Post by Gareth Phillips
Post by Gareth Phillips
28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S24816-43992 PPP Rx
FF03 C021:LCP 08 B1 0040 ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00
00 08 04 00 00 00 71 q 72 r 73 s 74 t FD 12 A5 AD BA 38 8 8E BD FB 55 U 50 P
18 10 00 F8 E0 00 00 17 03 03 00 50 P D6 07 80 20 81 D2 6F o 57 W B8 CC 9C
2E . 0F
28 Jan 2017 19:24:22 l2tp-rx T10838-3606-62.24.203.91 S43511-28544 PPP Rx
FF03 C021:LCP 08 E9 001C ProtoRej AAAA 03 00 00 00 08 06 00 13 08 00 00 00
00 08 04 00 00 00 71 q 72 r 73 s 74 t
Whatever those are I am confused about;
That CPE is trying to make some sort of AAAA query I think.
Post by Gareth Phillips
Seems the state machine on the CPE side is stuck?
Yeah it looks a bit flaky.



On 28 January 2017 at 15:12, Gareth Phillips
Post by Gareth Phillips
· We’ve tried a RADIUS Filter-ID of "l" (lower case L) to stop MRU
renegotiation and a similar hard coded setting on the L2TP LNS tunnel for
those particular circuits.
Why have you done that? We are an LLU provider but also take wholesale
BT and TalkTalk connectivity to ensure total coverage. We force MRU
renegotiation for those wholesale circuits, particularly for BT where
their BRAS nodes seem to interfere; going through the whole PPP state
machine life cycle (including LCP, NCP, IPCP etc) part of the process
is performed between CPE and BRAS, then the L2TP tunnel is built, and
the later part is performed between CPE and LNS. Due to NOT having
performed the entire process with the BRAS we sometimes see side
effects so we always force MRU renegotiation to start most of the
process again with the CPE talking directly to the LNS.

What happens if you try this?

Also what do you see in your RADIUS log? Does the LNS report to RADIUS
that the authentication has been successful? From your output and
Bjoren's output it looks like auth is OK then negotiation fails near
the end of LCP.

Have you considered upgrading the firmware on you CPE and LNS devices?
Test it in the lab?

Cheers,
James.

Loading...