Upgrade from 12/13 to 12/18 -> PPPoE dead…
-
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?)
-
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.
Hey jimp. Which manual fix are you talking about? Is there one working with a current snap which I should try? Otherwise I can disable that secondary interfaces, but I guess that this should be working…
-
Hey jimp. Which manual fix are you talking about? Is there one working with a current snap which I should try? Otherwise I can disable that secondary interfaces, but I guess that this should be working…
I was referring to pressing save on the WAN page to connect being the manual fix.
-
Hey jimp. Which manual fix are you talking about? Is there one working with a current snap which I should try? Otherwise I can disable that secondary interfaces, but I guess that this should be working…
I was referring to pressing save on the WAN page to connect being the manual fix.
Ah okay. That one. But that one isn't necessary anymore. It is working, it just takes up to three minutes in order to complete my PPPoE connection….
