Upgrade from 12/13 to 12/18 -> PPPoE dead…

_igor_ · Jan 18, 2011, 4:27 PM

With update from 01/18 i lost my PPPOE completely. Had more problems while updating packages. After a while of working state PPPOE was lost. And never came back. Nor a downgrade to 01/15 resolved the problem.
Tried that edit from interfaces.inc with no success.
Its an i386 install, XL0 is not assigned (its my WAN.) Only LAN, no opt nor other interfaces present. PPP-log only retries to connect. Only tries to connect show up at the logs. No errors so far, nor success.

Packages present: squid, squidguard, lightsquid, cron and OVPN-Exporter. Nothing more.

So at last i was caught too with this failure of PPPOE. :-(

clarknova · Jan 21, 2011, 4:10 PM

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)..

romainp · Jan 21, 2011, 4:33 PM

At least for me, the issue is still there from the latest yesterday's snap.

_igor_ · Jan 22, 2011, 1:47 PM

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.

clarknova · Jan 22, 2011, 1:49 PM

I just updated to last snap from 1/21 and still have to manually connect.

jlepthien · Jan 22, 2011, 3:26 PM

@_igor_:

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?

_igor_ · Jan 22, 2011, 3:34 PM

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!!!!!

jlepthien · Jan 22, 2011, 3:40 PM

I never had problems with PPPoE when I disabled the additional OPT…

_igor_ · Jan 22, 2011, 4:15 PM

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.

gnhb · Jan 23, 2011, 6:31 AM

@clarknova:

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

clarknova · Jan 23, 2011, 7:40 AM

OPT6-OPT13 (vlans on em0) – mlppp WAN + static (modem subnets)

@gnhb:

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.

_igor_ · Jan 23, 2011, 1:11 PM

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?

gnhb · Jan 23, 2011, 2:01 PM

@clarknova:

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

romainp · Jan 23, 2011, 5:40 PM

Seems better with the lastest snap from the 23th. I will test further.

romainp · Jan 24, 2011, 4:02 AM

Still working on 2.0-BETA5 (i386) built on Sun Jan 23 10:30:03 EST 2011.

clarknova · Jan 24, 2011, 12:57 PM

2.0-BETA5 (amd64)
built on Mon Jan 24 06:17:59 EST 2011

mlppp on vlans
vlans configured for modem access

No change here, still have to manually connect.

jimp · Jan 24, 2011, 1:10 PM

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.

clarknova · Jan 24, 2011, 1:14 PM

Yeah, I have

pppoe>OPTx>vlanx>em1

jlepthien · Jan 24, 2011, 5:15 PM

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!

gnhb · Jan 25, 2011, 2:22 AM

@jimp:

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