Upgrade from 12/13 to 12/18 -> PPPoE dead…
-
Still a pain here with snap 01/05…
This is what I do on EVERY update! :-(- Update
- Reboot
- 500 - Internal Server Error
- Reboot
- Diagnostics->Interfaces->Connect on PPPoE
- Packages->none are installed anymore
- Install avahi
- 500 - Internal Server Error
- Reboot
- Diagnostics->Interfaces->Connect on PPPoE doesn't work anymore, interfaces goes up and right after that down again. Need to use save button on WAN!
- Install nmap->error in system.log: Jan 5 15:12:18 voldemort kernel: pid 28656 (php), uid 0: exited on signal 11 (goes on forever)
- 500 - Internal Server Error
- Reboot
- Diagnostics->Interfaces->Connect on PPPoE doesn't work anymore, interfaces goes up and right after that down again. Need to use save button on WAN!
- Install Backup, Ubound and Shellcmd with no problem
-
jlepthein, what browser are you using to access the GUI and what is the version of that browser?
Several months back I noticed some versions of FireFox (I think in the 3.5 range) would send two button clicks when I only clicked once on the "Connect" button in Status -> Interfaces, causing the connection to come up and then down again.Also, try going back to an image from Dec 16th or earlier. I'm running an image from the 14th. What happens when you do that?
If that (16th or earlier) image doesn't behave correctly try adding these patches to it.
diff –git a/etc/inc/interfaces.inc b/etc/inc/interfaces.inc
index d0ff066..de95433 100644
--- a/etc/inc/interfaces.inc
+++ b/etc/inc/interfaces.inc
@@ -2459,7 +2459,6 @@ function interface_configure($interface = "wan", $reloadall = false, $linkupeven
case 'l2tp':
case 'pptp':
case 'ppp':- interface_bring_down($interface, true);
break;
default:
interface_bring_down($interface);
diff --git a/etc/inc/interfaces.inc b/etc/inc/interfaces.inc
index 0a5e00a..d0ff066 100644
--- a/etc/inc/interfaces.inc
+++ b/etc/inc/interfaces.inc
@@ -917,13 +917,15 @@ function interface_bring_down($interface = "wan", $destroy = false) {
if (is_array($config['ppps']['ppp']) && count($config['ppps']['ppp'])) {
foreach ($config['ppps']['ppp'] as $pppid => $ppp) {
if ($realif == $ppp['if']) {- if (isset($ppp['ondemand']) && !$destroy){
- send_event("interface reconfigure {$interface}");
- break;
- }
if (file_exists("{$g['varrun_path']}/{$ppp['type']}{$interface}.pid")) {
killbypid("{$g['varrun_path']}/{$ppp['type']}{$interface}.pid");
- sleep(5);
- sleep(2);
}
unlink_if_exists("{$g['varetc_path']}/mpd_{$interface}.conf");
- if (isset($ppp['ondemand']) && !$destroy)
- send_event("interface reconfigure {$interface}");
break;
}
}
- interface_bring_down($interface, true);
-
Go back to an older image and test it with Dial on Demand enabled (and disabled too for that matter.) Report those results.
Then apply the patches I posted and test again with Dial on Demand enabled (and disabled) and report those results.
Those patches prevent pfSense from calling mpd twice in rapid succession when "Dial on Demand" is enabled.GB
P.S. I also changed the description of "Dial on Demand" in the PPPs configuration page. See if it makes more sense now that you DON'T want that ticked if you want your line/link to be always on.
OR . . .
If you have time to test this out, you can stay on the image from Jan 4 or Jan 5 and use the mpd binary from before Dec. 16. I'll try to attach one from the 14th with a .txt file extension. Ok, the attach didn't work (file too big). So get one from an older image.
Plus, you must apply this patch (to the new Jan 4/5 images.)
diff –git a/etc/inc/interfaces.inc b/etc/inc/interfaces.inc
index 2d16927..c0b629c 100644
--- a/etc/inc/interfaces.inc
+++ b/etc/inc/interfaces.inc
@@ -1175,7 +1175,6 @@ function interface_ppps_configure($interface) {
case "pppoe":
/* Bring the parent interface up */
interfaces_bring_up($port);
- pfSense_ngctl_attach(".", $port);
break;
case "pptp":
case "l2tp": -
With 2.0-BETA5 (i386) built on Fri Jan 7 15:25:33 EST 2011.
I no longer have the issue!
-
2.0-BETA5 (amd64)
built on Sat Jan 8 00:47:04 EST 2011Still broken here.
-
I also have to manually connect my WAN PPPoE link when using build 2.0-BETA5 (i386) built on Fri Jan 7 15:25:33 EST 2011.
I am using a single bridged DSL modem for my WAN connection, with pfSense providing the PPPoE client, and I have OPT2 configured on the same Ethernet interface as the bridged modem (for modem configuration):
-
LAN = em0
-
WAN = PPPOE0 (em1)
-
OPT1 = em2
-
OPT2 = em1
I don't have any packages installed.
Curiously, if I disable OPT2 and reboot, the WAN PPPoE link connects normally (i.e. without intervention). If I then enable OPT2, the WAN PPPoE link drops immediately and and requires a manual connect.
-
-
With snap from 1/8 my PPPoE came up on its own…
-
I have similar results as SteveB on the latest snap/git.
When I have an opt interface on my WAN interface on which PPPoE is running. I have to manually connect the PPPoE after boot. When there is no opt interface, it connects automatically.
Also, my second PPP interface (PPTP client on top of the PPPoE WAN interface) never connects automatically. I'll try to debug this and give some more information a bit later. -
Well, I'm no longer sure the failure of my PPTP client to connect is a related issue.
Whenever I boot with my system with the PPTP client enabled (which connects via the PPPoE WAN), and the WAN comes up properly (ie there is no OPT interface on the interface the WAN connects to the modem with), the system locks up completely when the startup scripts reach the stage where it attempts to bring the PPTP client up. I can't kill the startup scripts with Control-C (like you normally can), and the system rarely responds to pings (although if I try for long enough, one or two will respond indicating its not a total kernel panic/system crash). I have to hard reboot/reset my system. I'm using a full i386 install. -
I checked again today by updating to the latest snap. It still takes some time to connect so the problem still persists. But if you wait long enough (1-2 minutes) it connects by itself…
Still some work to do I guess...
-
I have the issue again with the 8th release but it works with the 7th
-
It still works with 2.0-BETA5 (i386) built on Sun Jan 9 17:53:34 EST 2011
-
It still works with 2.0-BETA5 (i386) built on Sun Jan 9 17:53:34 EST 2011
It works or it doesn't? Because you have written 'still'…
-
Arg, sorry for my bad english….
it works with with 2.0-BETA5 (i386) built on Sun Jan 9 17:53:34 EST 2011
It wasn't with latest build of the 8th but the first of 8th worked for me.Hope this is clearer this time ;-)
-
There weren't any changes on the 8th that would have impacted that, so it's odd that it would have worked on one and not the other. But I suppose as long as it continues to work, that's what matters. :-)
-
I'm agree.
Well let's forget about the 8th build and see what happens with the next one. -
Updated to 1/10 but still having the same old problem. But it connects on its own, so no need to do anything besides wait for 2-3min…
Although the package reinstall doesn't work that way because it takes too long to connect... -
I have similar results as SteveB on the latest snap/git.
When I have an opt interface on my WAN interface on which PPPoE is running. I have to manually connect the PPPoE after boot. When there is no opt interface, it connects automatically.
Also, my second PPP interface (PPTP client on top of the PPPoE WAN interface) never connects automatically. I'll try to debug this and give some more information a bit later.I can confirm having this issue as well. Should be looked into with higher priority since this can cause unnecessarily prolonged outages.
-
I can confirm having this issue as well. Should be looked into with higher priority since this can cause unnecessarily prolonged outages.
So far the only people having confirmed the issue in this thread also have their physical interface assigned to access the modem for convenience. If you are hitting this bug and can't deal with the manual fix, just don't assign the physical interface until others confirm the issue is fixed.
-
I can confirm having this issue as well. Should be looked into with higher priority since this can cause unnecessarily prolonged outages.
So far the only people having confirmed the issue in this thread also have their physical interface assigned to access the modem for convenience. If you are hitting this bug and can't deal with the manual fix, just don't assign the physical interface until others confirm the issue is fixed.
Without having spent any real time debugging the code, I would be willing to bet that the issues are one in the same (some kind of lock on the interface?)
