WAN PPPoE on Releases Since 3-23-2007
-
I have not been able to successfully use PPPoE since 1.01 snapshot 03-15-2007 although I have only verified the problem with 3-23-2007 and 3-27-2007. I revisited the issue with the release of 1.2-BETA-1 and neither it nor the 06-04-2007 or 06-06-2007 updates work for me either.
I tried completely new installs with a minimum of configuration using 1.01 and 1.2-BETA-1 with their updates and they all returned repeating system logs similar to the following:
Jun 9 00:01:50 mpd: MRU 1492
Jun 9 00:01:50 mpd: MAGICNUM e33c8cf9
Jun 9 00:01:50 mpd: MRU 1492
Jun 9 00:01:50 mpd: AUTHPROTO PAP
Jun 9 00:01:50 mpd: MAGICNUM 578d60c1
Jun 9 00:01:50 mpd: MRU 1492
Jun 9 00:01:50 mpd: AUTHPROTO PAP
Jun 9 00:01:50 mpd: MAGICNUM 578d60c1
Jun 9 00:01:50 mpd: MRU 1492
Jun 9 00:01:50 mpd: MAGICNUM e33c8cf9
Jun 9 00:01:51 mpd: IPADDR 0.0.0.0
Jun 9 00:01:51 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jun 9 00:01:51 mpd: PRIDNS 0.0.0.0
Jun 9 00:01:51 mpd: SECDNS 0.0.0.0
Jun 9 00:01:51 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jun 9 00:01:51 mpd: PRIDNS 0.0.0.0
Jun 9 00:01:51 mpd: SECDNS 0.0.0.0
Jun 9 00:01:51 mpd: IPADDR 0.0.0.0
Jun 9 00:01:51 mpd: IPADDR 151.164.182.114
Jun 9 00:01:51 mpd: 151.164.182.114 is OK
Jun 9 00:01:51 mpd: IPADDR 151.164.182.114
Jun 9 00:01:51 mpd: IPADDR 75.42.150.151
Jun 9 00:01:51 mpd: 75.42.150.151 is OK
Jun 9 00:01:51 mpd: 75.42.150.151 -> 151.164.182.114
Jun 9 00:01:52 php: : Informational: DHClient spawned /etc/rc.newwanip and the new ip is wan - .
Jun 9 00:01:52 php: : Creating rrd update script
Jun 9 00:01:52 php: : Configuring slbd
Jun 9 00:01:53 check_reload_status: reloading filter
Jun 9 00:01:55 check_reload_status: updating dyndns
Jun 9 00:01:58 mpd: MRU 1492
Jun 9 00:01:58 mpd: MAGICNUM 04ebb7e8
Jun 9 00:01:58 mpd: MRU 1492
Jun 9 00:01:58 mpd: AUTHPROTO PAP
Jun 9 00:01:58 mpd: MAGICNUM 680445fe
Jun 9 00:01:58 mpd: MRU 1492
Jun 9 00:01:58 mpd: AUTHPROTO PAP
Jun 9 00:01:58 mpd: MAGICNUM 680445fe
Jun 9 00:01:58 mpd: MRU 1492
Jun 9 00:01:58 mpd: MAGICNUM 04ebb7e8
Jun 9 00:01:58 mpd: IPADDR 0.0.0.0
Jun 9 00:01:58 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jun 9 00:01:58 mpd: PRIDNS 0.0.0.0
Jun 9 00:01:58 mpd: SECDNS 0.0.0.0
Jun 9 00:01:58 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Jun 9 00:01:58 mpd: PRIDNS 0.0.0.0
Jun 9 00:01:58 mpd: SECDNS 0.0.0.0
Jun 9 00:01:58 mpd: IPADDR 0.0.0.0
Jun 9 00:01:58 mpd: IPADDR 75.42.150.175
Jun 9 00:01:58 mpd: 75.42.150.175 is OK
Jun 9 00:01:58 mpd: IPADDR 151.164.182.114
Jun 9 00:01:58 mpd: 151.164.182.114 is OK
Jun 9 00:01:58 mpd: IPADDR 151.164.182.114
Jun 9 00:01:58 mpd: 75.42.150.175 -> 151.164.182.114
Jun 9 00:02:02 check_reload_status: rc.newwanip starting
Jun 9 00:02:04 php: : Informational: rc.newwanip is starting wan.
Jun 9 00:02:04 php: : rc.newwanip working with IP address wan ng0.
Jun 9 00:02:04 php: : WARNING! /etc/rc.newwanip could not deterimine the previous ip address ( wan ). -
Take /etc/rc.newwanip from a 1.0.1 (or working box) and move to the newer snapshot and test again.
-
Take /etc/rc.newwanip from a 1.0.1 (or working box) and move to the newer snapshot and test again.
Thanks for the suggestion. I just tried it and got the same result. :/
-
Interesting, looks like this might be getting closer to the cause of this:
http://cvstrac.pfsense.com/tktview?tn=1315,6the cause of which we have no clue at this point, as it works for the vast majority of people…
nothing helpful to add, just hope you'll be able to help us get to the bottom of this. ;D
-
As I originally posted, the problem goes back months for me but I never assigned it enough significance to post about it until 1.2-BETA-1 failed in the same way. I figured it was a transient problem that would be resolved in a more recent snapshot.
I read through that other thread a couple of days ago and tried the suggestions (including swapping an rl card for my fxp) but the failure was always the same. I will probably investigate mpd over the next couple of days.
-
It would be great if you could check out mpd. We can't replicate the problem so it's difficult for us to debug and fix it.
-
I managed to set mpd to use "log +all" and recovered the following logs which show that the problem is just after mpd negotiates the connection:
Working 1.0.1-SNAPSHOT-03-15-2007:
http://www.banishedsouls.org/c2df3757f1/mpd.log.working.txt
Broken 1.2-BETA-1-TESTING-SNAPSHOT-06-06-2007:
http://www.banishedsouls.org/c2df3757f1/mpd.log.broken.txt
There are significant differences just after "IFACE: Up event" but I am not clear about what the problem is yet.
-
After inspecting the changes in mpd.conf generated by interfaces.inc I found that removing "set ipcp enable req-sec-dns" allows PPPoE to work.
-
Download config.xml and add to the <pppoe>section:
<dnsnosec>true</dnsnosec>
So it should look something like
<pppoe><dnsnosec>true</dnsnosec>
…
...
...Also call your ISP and suggest that they give out 2 dns server addresses like most of the other ISP's do on the planet.</pppoe></pppoe>
-
Download config.xml and add to the <pppoe>section:
<dnsnosec>true</dnsnosec></pppoe>That works. Thanks.
I understood the php code enough to recognize the flag but did not know where it was set.
Also call your ISP and suggest that they give out 2 dns server addresses like most of the other ISP's do on the planet.
PPPoE is not my connection type of choice but it does have the distinction of being available here. I will send an email to Earthlink (also not my first choice) but I doubt they will be interested. I actually do not even use their DNS servers because of repeated reliability issues.
-
thats the resun that a isp gives you 2 dns servers
fails the first then the 2end will be asked