FYI: backend Exetel change breaks pppd (solved)
Exetel made some changes to their backend on Fri which screwed me. I investigated this morning and now have a fix, detailed below. pppd is pretty cargo-culty, so let me know if I'm missing any best practice options. * * * I believe this issue is now resolved. By explicitly disabling PAP authentication, I get a public address (58.96.65.206). Detailed analysis follows. On Tue Nov 13 16:08:25 2012 +1100, we changed our CHAP password to the new one you supplied. Prior to that, our PPP configuration was unchanged since 19 Jul 2012. The following logs show the last correct PPP negotiation, and the first incorrect negotiation. PLEASE NOTE in both cases AUTHENTICATION SUCCEEDS. 2012-11-09T17:19:08.008040+11:00 alpha pppd[6844]: Using interface ppp1 2012-11-09T17:19:08.008071+11:00 alpha pppd[6844]: Connect: ppp1 <--> 0.8.35 2012-11-09T17:19:11.089919+11:00 alpha pppd[6844]: CHAP authentication succeeded 2012-11-09T17:19:11.089947+11:00 alpha pppd[6844]: CHAP authentication succeeded 2012-11-09T17:19:11.167105+11:00 alpha pppd[6844]: Cannot determine ethernet address for proxy ARP 2012-11-09T17:19:11.167135+11:00 alpha pppd[6844]: local IP address 58.96.67.67 2012-11-09T17:19:11.167152+11:00 alpha pppd[6844]: remote IP address 58.96.2.202 2012-11-09T17:20:16.098565+11:00 alpha pppd[6844]: No response to 3 echo-requests 2012-11-09T17:20:16.098595+11:00 alpha pppd[6844]: Serial link appears to be disconnected. 2012-11-09T17:20:16.098643+11:00 alpha pppd[6844]: Connect time 1.1 minutes. 2012-11-09T17:20:16.098661+11:00 alpha pppd[6844]: Sent 420 bytes, received 420 bytes. 2012-11-09T17:20:22.119564+11:00 alpha pppd[6844]: Connection terminated. 2012-11-09T17:20:22.181547+11:00 alpha pppd[6844]: Modem hangup 2012-11-09T17:45:21.300013+11:00 alpha pppd[6844]: Using interface ppp1 2012-11-09T17:45:21.300043+11:00 alpha pppd[6844]: Connect: ppp1 <--> 0.8.35 2012-11-09T17:45:24.473407+11:00 alpha pppd[6844]: PAP authentication succeeded 2012-11-09T17:45:24.531114+11:00 alpha pppd[6844]: Cannot determine ethernet address for proxy ARP 2012-11-09T17:45:24.531144+11:00 alpha pppd[6844]: local IP address 10.35.14.66 2012-11-09T17:45:24.531161+11:00 alpha pppd[6844]: remote IP address 220.233.1.169 2012-11-09T18:45:24.515123+11:00 alpha pppd[6844]: LCP terminated by peer 2012-11-09T18:45:24.515185+11:00 alpha pppd[6844]: Connect time 60.0 minutes. 2012-11-09T18:45:24.515204+11:00 alpha pppd[6844]: Sent 0 bytes, received 0 bytes. 2012-11-09T18:45:27.532734+11:00 alpha pppd[6844]: Connection terminated. 2012-11-09T18:45:27.597564+11:00 alpha pppd[6844]: Modem hangup Our modem runs Ubuntu 10.04, with pppd 2.4.5~git20081126t100229-0ubuntu3. Our ppp configuration is as follows (password is elided). options:asyncmap 0 options:noauth options:crtscts options:lock options:hide-password options:modem options:proxyarp options:lcp-echo-interval 5 options:lcp-echo-failure 3 options:noipx peers/internode:user "UNPRINTABLE@internode.on.net" peers/internode:plugin pppoatm.so peers/internode:1.8.35 peers/internode:noipdefault peers/internode:persist peers/internode:maxfail 0 peers/internode:noauth peers/internode:nodeflate peers/internode:linkname internode peers/internode:nodetach peers/exetel:user "UNPRINTABLE@vic.exetel.com.au" peers/exetel:plugin pppoatm.so peers/exetel:0.8.35 peers/exetel:noipdefault peers/exetel:persist peers/exetel:maxfail 0 peers/exetel:noauth peers/exetel:nodeflate peers/exetel:linkname exetel peers/exetel:nodetach chap-secrets:UNPRINTABLE@vic.exetel.com.au * "UNPRINTABLE" * PLEASE NOTE that we have a password configured in chap-secrets, but not in pap-secrets. I speculate that the current issue is caused by a combination of the following: - our modem currently tries PAP before CHAP - you used to reject PAP, so we proceeded to CHAP which works. - you now accept PAP, but give a private IP. Possibly this is misconfiguration; possibly it's some kind of "captive portal"-style artefact to help users with misconfigured modems. Experimentally, I added "refuse-pap" to peers/exetel. After this, the point-to-point link has reasonable addresses: 2012-11-14T11:58:21.762615+11:00 alpha pppd[3208]: Using interface ppp1 2012-11-14T11:58:21.762784+11:00 alpha pppd[3208]: Connect: ppp1 <--> 0.8.35 2012-11-14T11:58:23.906234+11:00 alpha pppd[3208]: CHAP authentication succeeded 2012-11-14T11:58:23.906261+11:00 alpha pppd[3208]: CHAP authentication succeeded 2012-11-14T11:58:23.990924+11:00 alpha pppd[3208]: Cannot determine ethernet address for proxy ARP 2012-11-14T11:58:23.990954+11:00 alpha pppd[3208]: local IP address 58.96.65.206 2012-11-14T11:58:23.990972+11:00 alpha pppd[3208]: remote IP address 220.233.1.171
That's interesting.. I'm using exetel as well (at home), with pppoe to a pure-bridge adsl modem. According to my logs, the last time it reconnected was 10:12am on Nov 10th. (Saturday, so after the changes you mention to their backend) I didn't even notice, so it seems this didn't effect all clients. This is on Ubuntu 12.04 LTS, so maybe something changed in pppd? Nov 10 10:12:21 penfold pppd[1588]: Serial link appears to be disconnected. Nov 10 10:12:21 penfold pppd[1588]: Connect time 2786.4 minutes. Nov 10 10:12:21 penfold pppd[1588]: Sent 1706758826 bytes, received 2646704198 bytes. ... Nov 10 10:12:52 penfold pppd[1588]: CHAP authentication succeeded Nov 10 10:12:52 penfold pppd[1588]: peer from calling number 00:30:88:1A:D5:AC authorized Nov 10 10:12:52 penfold pppd[1588]: local IP address 58.96.97.xxx Nov 10 10:12:52 penfold pppd[1588]: remote IP address 58.96.2.210 My 'peers' file just contains: noipdefault usepeerdns defaultroute lcp-echo-interval 20 lcp-echo-failure 3 connect /bin/true noauth persist maxfail 0 mtu 1492 noaccomp default-asyncmap plugin rp-pppoe.so br0 user "xxxxxxxxx@vic.exetel.com.au" On 14/11/12 12:40, Trent W. Buck wrote:
Exetel made some changes to their backend on Fri which screwed me. I investigated this morning and now have a fix, detailed below. pppd is pretty cargo-culty, so let me know if I'm missing any best practice options.
* * *
I believe this issue is now resolved. By explicitly disabling PAP authentication, I get a public address (58.96.65.206).
Our modem runs Ubuntu 10.04, with pppd 2.4.5~git20081126t100229-0ubuntu3.
Toby Corkindale <toby.corkindale@strategicdata.com.au> writes:
That's interesting.. I'm using exetel as well (at home), with pppoe to a pure-bridge adsl modem.
According to my logs, the last time it reconnected was 10:12am on Nov 10th. (Saturday, so after the changes you mention to their backend)
AIUI exetel emailed customers who would be affected ("your upstream IP will change on $date"), though they didn't mention the symptoms I encountered, and the change didn't occur until about a week after they said it would.
I didn't even notice, so it seems this didn't effect all clients. This is on Ubuntu 12.04 LTS, so maybe something changed in pppd? Nov 10 10:12:52 penfold pppd[1588]: local IP address 58.96.97.xxx Nov 10 10:12:52 penfold pppd[1588]: remote IP address 58.96.2.210
Those IPs look like my pre-transition ones, so I'd say they just haven't wibbled your service yet. (I don't know if they plan to wibble all of them, or if it was a single batch, or what.)
On 14/11/12 13:59, Trent W. Buck wrote:
Toby Corkindale <toby.corkindale@strategicdata.com.au> writes:
That's interesting.. I'm using exetel as well (at home), with pppoe to a pure-bridge adsl modem.
According to my logs, the last time it reconnected was 10:12am on Nov 10th. (Saturday, so after the changes you mention to their backend)
AIUI exetel emailed customers who would be affected ("your upstream IP will change on $date"), though they didn't mention the symptoms I encountered, and the change didn't occur until about a week after they said it would.
Ah, interesting to know then. I'll watch out for such an email. Thanks for the heads-up.
participants (2)
-
Toby Corkindale -
trentbuck＠gmail.com