PPPoA client problem behind Draytek Vigor 120 modem in PPPoA pass-through
-
I have pfsense 1.2.3, no extra packages installed.
I'm having issues with regular ppp dropouts. The modem maintains rock solid sync lasting several weeks but the ppp connection dropouts occur frequently. In the pfsense log i receive the message LCP down and it fails to reconnect for several minutes sometimes hours! I have had the same setup for well over a year and have always had this problem, sometimes it goes weeks without disconnecting but recently this occurs several times a day causing several hours of down time (usually at the weekend).
My ISP have tried changing RAS cards and giving me different pppoa login details none of which have helped. I have also tried with a netgear dg834gt/pfsense and have the same problem. Restarting pfsense and the modem usually speeds up the reconnection process.
Has anyone else had similar issues or got any ideas?
Thanks in advance
-
Has anyone else had similar issues or got any ideas?
I moved my pfSense to a 2.0 snapshot build and afterwards change my WAN link to pppoe so I have not had similar issues and I don't know the details of ppp on pfSense 1.2.3.
I'm sure it would be helpful to have more information about what is going on. Any ppp reports in the system log other than "LCP down"? What does the ppp log (if any) report?
When the WAN link goes down what does a packet trace on the WAN interface show?
Is the firmware in your modem up to date?
-
Thanks for the quick response. How is the latest build of pfsense? Is it stable and reliable enough in its current beta stage?
I recently upgraded from 1.2.2 to 1.2.3 but still have the same issues. My modem firmware is currently up-to-date. Here is the system log from when i rebooted the system yesterday:
May 3 14:17:14 dnsmasq[540]: using nameserver 94.30.127.100#53 May 3 14:17:14 dnsmasq[540]: using nameserver 89.145.254.78#53 May 3 14:17:14 dnsmasq[540]: reading /etc/resolv.conf May 3 13:59:20 check_reload_status: updating dyndns May 3 13:59:17 check_reload_status: reloading filter May 3 13:59:17 php: : Configuring slbd May 3 13:59:16 php: : Creating rrd update script May 3 13:59:16 php: : Informational: DHClient spawned /etc/rc.newwanip and the new ip is wan - 94.xx.xx.xx. May 3 13:59:11 php: : rc.newwanip working with (IP address: 94.xx.xx.xx) (interface: wan) (interface real: ng0). May 3 13:59:11 php: : Informational: rc.newwanip is starting wan. May 3 13:59:07 check_reload_status: rc.newwanip starting May 3 13:59:06 mpd: 94.xx.xx.xx (my ip) -> 94.30.127.73 (gateway) May 3 13:59:06 mpd: SECDNS 89.145.254.78 May 3 13:59:06 mpd: PRIDNS 94.30.127.100 May 3 13:59:06 mpd: IPADDR 94.xx.xx.xx (my ip) May 3 13:59:06 mpd: SECDNS 89.145.254.78 May 3 13:59:06 mpd: PRIDNS 94.30.127.100 May 3 13:59:06 mpd: IPADDR 94.xx.xx.xx (my ip) May 3 13:59:06 mpd: SECDNS 89.145.254.78 May 3 13:59:06 mpd: PRIDNS 94.30.127.100 May 3 13:59:06 mpd: 94.xx.xx.xx (my ip) is OK May 3 13:59:06 mpd: IPADDR 94.xx.xx.xx (my ip) May 3 13:59:06 mpd: SECDNS 0.0.0.0 May 3 13:59:06 mpd: PRIDNS 0.0.0.0 May 3 13:59:06 mpd: IPADDR 0.0.0.0 May 3 13:59:06 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid May 3 13:59:06 mpd: SECDNS 0.0.0.0 May 3 13:59:06 mpd: PRIDNS 0.0.0.0 May 3 13:59:06 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid May 3 13:59:06 mpd: IPADDR 0.0.0.0 May 3 13:59:06 mpd: IPADDR 94.30.127.73 May 3 13:59:06 mpd: 94.30.127.73 is OK May 3 13:59:06 mpd: IPADDR 94.30.127.73 May 3 13:59:04 mpd: SECDNS 0.0.0.0 May 3 13:59:04 mpd: PRIDNS 0.0.0.0 May 3 13:59:04 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid May 3 13:59:04 mpd: IPADDR 0.0.0.0 May 3 13:59:04 mpd: Using authname "myuser@accessdsl" May 3 13:59:04 mpd: Name: "lns2.uan.the.uk.murphx.net" May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MAGICNUM b196e82d May 3 13:58:54 mpd: AUTHPROTO CHAP MD5 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MAGICNUM b196e82d May 3 13:58:54 mpd: AUTHPROTO CHAP MD5 May 3 13:58:54 mpd: Using authname "myuser@accessdsl" May 3 13:58:54 mpd: Name: "lts1.sdn.the.uk.murphx.net" May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MRU 1492 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MRU 1492 May 3 13:58:54 mpd: MRU 1500 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MRU 1492 May 3 13:58:54 mpd: MRU 1500 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MRU 1492 May 3 13:58:54 mpd: MRU 1500 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MRU 1492 May 3 13:58:54 mpd: MRU 1500 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MRU 1492 May 3 13:58:54 mpd: MRU 1500 May 3 13:58:54 mpd: MAGICNUM 828c99e5 May 3 13:58:54 mpd: AUTHPROTO CHAP MD5 May 3 13:58:54 mpd: MAGICNUM 35e11518 May 3 13:58:54 mpd: MRU 1492 May 3 13:58:54 mpd: MAGICNUM 828c99e5 May 3 13:58:54 mpd: AUTHPROTO CHAP MD5 May 3 13:58:53 mpd: Using authname "myuser@accessdsl" May 3 13:58:53 mpd: Name: "sqy-lts-001" May 3 13:58:53 mpd: Using authname "myuser@accessdsl" May 3 13:58:53 mpd: Name: "bsh-bng-012" May 3 13:58:53 mpd: MAGICNUM 35e11518 May 3 13:58:53 mpd: MRU 1492 May 3 13:58:53 mpd: MAGICNUM 0e99638f May 3 13:58:53 mpd: AUTHPROTO CHAP MD5 May 3 13:58:53 mpd: MAGICNUM 0e99638f May 3 13:58:53 mpd: AUTHPROTO CHAP MD5 May 3 13:58:52 mpd: MAGICNUM 35e11518 May 3 13:58:52 mpd: MRU 1492 May 3 12:30:01 check_reload_status: check_reload_status is starting May 3 12:00:00 check_reload_status: check_reload_status is starting May 3 01:00:01 check_reload_status: check_reload_status is starting May 2 20:17:11 dnsmasq[540]: using nameserver 89.145.254.78#53 May 2 20:17:11 dnsmasq[540]: using nameserver 94.30.127.100#53 May 2 20:17:11 dnsmasq[540]: reading /etc/resolv.conf
I will post another log with more information next time it drops. Do you mean run a traceroute when the WAN link goes down? I'll give it a go if it goes down tonight whilst i'm using it, although i expect it will timeout.
-
I will post another log with more information next time it drops. Do you mean run a traceroute when the WAN link goes down?
No, I don't mean a traceroute because that won't get very far if the link is down. I meant packet capture, for example, pfsense shell command: # tcpdump -i vr0 (replace vr0 by the physical name of your WAN interface) to see what is happening when you expect your WAN link to be recovering.