Upgrade from 12/13 to 12/18 -> PPPoE dead…
-
Is this still a problem? I'm still running a snap from the 12th, not planning to update unless there's hope for a change (for this or the panic problem)..
-
At least for me, the issue is still there from the latest yesterday's snap.
-
I could get rid of that problem:
Downgraded to snap from 01/15, there i had connect, from this snap i updated (as a test) to snap from 01/20. Still now (snap is from 01/21) its working. Lastly i don't know why, but it works. Strange. I'm happy so.
-
I just updated to last snap from 1/21 and still have to manually connect.
-
I could get rid of that problem:
Downgraded to snap from 01/15, there i had connect, from this snap i updated (as a test) to snap from 01/20. Still now (snap is from 01/21) its working. Lastly i don't know why, but it works. Strange. I'm happy so.
Also with your WAN as an additional OPT interface for modem access?
-
No. WAN was not and is not as additional Interface assigned.
Uh, now i see, the old snap to which i reverted was NOT 01/15, it was 01/07! Sorry for that wrong info!!!!!
-
I never had problems with PPPoE when I disabled the additional OPT…
-
i'll try with assigning the WAN as OPT and report back.
report:
I assigned my WAN-if as OPT, but nothing more. Didn't assign anything to that if.
rebooted pfSense.
After reboot my PPPOE connected as normal. No problems. Connection was made automatically.At advanced options of my PPPOE nothing is activated. So no "Dial on demand", no "idle tieout", nothing ticked.
My WAN-if is xl0, an old 3com in a dell home-pc. Its an onboard-card. Hope that helps. If you want some more testing from my side, tell me. What i see, the problems with PPPOE are in my case gone. -
I just updated to last snap from 1/21 and still have to manually connect.
Are you using OPTX interface(s) for modem management? I just committed an update that will prevent detachment of netgraph nodes on interfaces that are used by PPPoE and also configured as an OPTX interface (netgraph nodes are necessary on interfaces that are used by PPPoE/PPTP/L2TP/MLPPP)
The way the code is was written before, it would detach the netgraph node from the underlying interface if you assigned that same physical interface to OPTX.
Warning . . . my update is untested since I don't have access to my PPPoE link right now (I'm away from home). . .
@_igor_: the problem doesn't have anything to do with whether your WAN link is called WAN or OPTx, it's related to having PPPoE configured on a physical interface (e.g. em0) and having OPTx configured on the same physical interface (e.g. em0).
In future posts, everyone please state if you have configured the same physical interface for both PPPoE/MLPPP/PPTP/L2TP (WAN) and OPTx(static/dynamic) (e.g. for modem management.)
Thanks,
GB -
OPT6-OPT13 (vlans on em0) – mlppp WAN + static (modem subnets)
Are you using OPTX interface(s) for modem management?
Yes. I have no choice because said interfaces are vlan interfaces, and they aren't eligible for inclusion in the mlppp bundle without first assigning them IP info and activating them.
I just committed an update that will prevent detachment of netgraph nodes on interfaces that are used by PPPoE and also configured as an OPTX interface (netgraph nodes are necessary on interfaces that are used by PPPoE/PPTP/L2TP/MLPPP)
So if I understand you correctly your fix won't work for me because I'm using mlppp. Is that correct?
I'll try your fix if you think there's a chance of it working, or I can get you LAN access to this install if you want to investigate some. The biggest inconvenience there is that it would have to be between midnight and 7 am MST, as I have a lot of daytime users.
-
In future posts, everyone please state if you have configured the same physical interface for both PPPoE/MLPPP/PPTP/L2TP (WAN) and OPTx(static/dynamic) (e.g. for modem management.)
To clear it up:
XL0 is my PPPOE-interface.
So i assigned that same interface xl0 as OPT-interface. Thats what i was speaking about and what i understood which created the problem. If that is wrong, excuse me. Maybe i was not clear enough too.
Due to the fact that i don't use the same interface for other things as PPPOE may be that simple assigning is only the half of the problem. The other half could be an assigned vlan to the same physical interface, right? -
So if I understand you correctly your fix won't work for me because I'm using mlppp. Is that correct?
No, the fix should work for you and everyone else with this problem. :)
@_igor_: Okay, I mis-understood your last post . . .
GB
-
Seems better with the lastest snap from the 23th. I will test further.
-
Still working on 2.0-BETA5 (i386) built on Sun Jan 23 10:30:03 EST 2011.
-
2.0-BETA5 (amd64)
built on Mon Jan 24 06:17:59 EST 2011mlppp on vlans
vlans configured for modem accessNo change here, still have to manually connect.
-
I bet the code is still detaching netgraph from the parent interface of the VLANs in your case, and the current fixes just got it one level closer.
The code probably needs to take even more things into account, because in theory someone could have:
pppoe0 on lagg0_vlan1 on lagg0 on em0, etc, etc. It needs to walk all the way back until it hits a real physical interface.
-
Yeah, I have
pppoe>OPTx>vlanx>em1
-
Just updated to the latest snap and "my" problem of this thread is gone! Hooray ;-)
I have vr0 set as OPT for modem access and as a PPPoE interface.
Updated to latest snap, rebooted and everything worked fine. This includes all my package updates! Yeah! -
I bet the code is still detaching netgraph from the parent interface of the VLANs in your case, and the current fixes just got it one level closer.
pppoe0 on lagg0_vlan1 on lagg0 on em0, etc, etc. It needs to walk all the way back until it hits a real physical interface.
Your right on both counts. :) This is a pain IMO . . .
Maybe we should consider the reverse strategy, which is to allow netgraph to attach every node by default and detach ones where the node adversely effects interface performance. Is that feasible? Is there a way to identify such interfaces easily?
I'm curious about the motivation for the change to detaching the nodes. Did some customer or user experience some performance increase due to detaching the netgraph nodes?
GB
-
Ermal would be the one to know for sure. He says detaching netgraph from interfaces that don't need it improves performance a bit. I'm not sure if anyone has run the numbers, but the way it is now we've outpaced a $40k checkpoint firewall :-)
(Search the forum, someone posted benchmarks) -
New stuff committed to try to address clarknova's config. I think is might still use some work. As before, I can't test with PPPoE right now so it might not work.
GB
-
2.0-BETA5 (amd64)
built on Tue Jan 25 07:56:16 EST 2011Spontaneous connection! Thank you, and well done.
-
Nice! :)
-
I have no problem with my PPPoE DSL WAN link connecting, using the latest snapshots and having an OPTx interface configured for managing my DSL modem. Thank you! ;D
-
Oh boy this is soooo annoying. With the latest snap of today it is broken again. Box takes 'forever' to get connected via PPPoE…that is so lame and we are on RC status now. Why do things like this brake? I will stay on a 'stable' RC now and let some other guys do the testing. This is getting old...
-
I do not think anybody touched that code.
You sure its something you did or a pacakge did? -
It's the same behavior as before. After reboot there was no PPPoE connection. Now I installed one of my packages (nmap) and after that I get Error 500 - Internal Server Error again. Now I'll need to reboot, install avahi and then do another reboot before everything works again…sigh...
-
Now on the console the output is (exactly like in those days it was broken):
Mar 22 21:32:16 voldemort kernel: pid 5720 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 5814 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 6008 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 6324 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 6653 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 6885 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 6919 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 6974 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 7177 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 7278 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 7445 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 7538 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 7577 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 7762 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 7935 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 8109 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 8449 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 8491 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 8727 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 8744 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 8764 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 9075 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 9106 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 9216 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 9325 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 9585 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 9658 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 9949 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 10234 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 10566 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 10815 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 11116 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 11218 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 11469 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 11558 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 11820 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12052 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12153 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12291 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12351 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12494 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12547 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12626 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12752 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 12862 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 13136 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 13327 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 13463 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 13783 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 14096 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 14374 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 14379 (php), uid 0: exited on signal 11 Mar 22 21:32:16 voldemort kernel: pid 14656 (php), uid 0: exited on signal 1
Goes on and on and on…
-
It may have been Efonne's attempt to fix the ro/rw filesystem status at boot time, if you're on nanobsd and hitting this.
-
Yep, nanoBSD…
-
Try backing out either this:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/548be1fd6697ab115cbb29d61bc5507744488094
Or perhaps this:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/e4d40f41aafe00353c0069b457a0b1b0d6c20987
-
jlepthien, if its any help I have found this version to be stable with respect to pppoe,openvpn & avahi… I have been in that boat before with things working and then not working again... it is what it is....you just got to love development.... things will be good when its over... but give this one a try.
Jim
2.0-RC1 (i386)
built on Mon Feb 14 03:24:30 EST 2011 -
Try backing out either this:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/548be1fd6697ab115cbb29d61bc5507744488094
Or perhaps this:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/e4d40f41aafe00353c0069b457a0b1b0d6c20987
Ok, but then after an upgrade I would be screwed again, right?
-
Did an upgrade to the latest snapshot right now and after a reboot the PPPoE connection was up so that is great. But again the friggin packages make problems…That's what in my system.log
Mar 25 20:36:12 voldemort kernel: pid 28861 (php), uid 0: exited on signal 11
Mar 25 20:36:13 voldemort php: : Resyncing configuration for all packages.
Mar 25 20:36:13 voldemort php: : The Backup package is missing required dependencies and must be reinstalled.
Mar 25 20:36:13 voldemort php: : The Backup package is missing required dependencies and must be reinstalled.
Mar 25 20:36:14 voldemort php: : The Avahi package is missing required dependencies and must be reinstalled.
Mar 25 20:36:14 voldemort php: : The Avahi package is missing required dependencies and must be reinstalled.
Mar 25 20:36:14 voldemort php: : The Avahi package is missing required dependencies and must be reinstalled.
Mar 25 20:36:16 voldemort login: login on console as root
Mar 25 20:36:16 voldemort syslogd: Logging subprocess 37853 (exec /usr/local/sbin/sshlockout_pf 15) exited due to signal 11.
Mar 25 20:36:16 voldemort kernel: pid 37853 (sshlockout_pf), uid 0: exited on signal 11
Mar 25 20:36:17 voldemort kernel: pid 10569 (mpd5), uid 0: exited on signal 11 (core dumped)
Mar 25 20:37:02 voldemort kernel: pid 55382 (rrdtool), uid 0: exited on signal 11And after that, the GUI is not accessable. I'll reboot now and after that the old problem with the reinstallation of the packages begins again....sigh
-
Ok now after the reboot it took PPPoE forever to connect, but it did…
Also the packages were ok...What is the command for CLI o reinstall all packages?
-
Try to update to a current snapshot and see if it still happens. I backed out the change I suspected might be the cause and at least for my ALIX it doesn't crash/hang after the update like it had been doing on last week's code.
-
Did the update right now. The PPPoE connection did come up fine but not all packages were reinstalled….
Only backup - I had to manually reinstall avahi and rrd summary. nmap was shown as installed but the command was missing, so I had to remove it and install it again. Reinstalling nmap didn't do the trick...Edit: nmap still not running. Again I get 'nmap: Command not found.' when trying to start it from shell...
What happened there. It was working so fine and now all this package crap again...
-
While I was on vacation someone tried to fix an issue with conf_mount_ro/conf_mount_rw and in the process, broke some bootup processes on NanoBSD again that were fixed quite a while ago.
I had to reinstall some packages by hand the first time but on subsequent updates they all should stay again (I hope…) so you might wait for the next new snap to see if it makes a difference.
-
While I was on vacation someone tried to fix an issue with conf_mount_ro/conf_mount_rw and in the process, broke some bootup processes on NanoBSD again that were fixed quite a while ago.
I had to reinstall some packages by hand the first time but on subsequent updates they all should stay again (I hope…) so you might wait for the next new snap to see if it makes a difference.
I can try that jimp, but I can't install nmap anymore. Even manually removing it with pkg_remove doesn't help. Oh boy…
-
Weird. Did another update to the latest snap and now it worked, but there was one small problem. All packages got reinstalled but RRD Summary wasn't available. Had to reinstall that one…
Strange...