PPPoE reconenction fix - mpd fix ($100)
-
Are you saying that the modem, in bridge mode, is remembering an active session and preventing a new one? If that's the case, why does rebooting pfsense re-establish the connection? There is a switch between my modems and pfsense, so the modem will never see the link as down.
the port on the isp modem needs to be brought down by unplugging the cable to make it send a link down to its remote pppoe server then when its brought up again with a replug, then pfsense renegotiates a new connection successfully.
the part about how its able to reconnect on pfsense boot i seriously don't understand how that happens now, there definitely is some difference in the way mpd connects on boot and on link loss
-
key to connection on boot and link loss is with the state of the vr1 port etc and if that is studied then we could come to a conclusion of the issue first
-
so you have the very same issue with the RAS client under windows and the test with the old mpd/fw release was 2 months ago. That doesn't sound like a mpd/pfsense issue to me then…
You will not be aware of configurations changes on the Service Provider side.
What happens if you just disconnect and reconnect the ethernet cable after some seconds between pfsense and modem, when the reconnect loop is occuring?
-
im still sure if i configure a old pfsense box it will work just fine.
if i disconnect and reconenct cable when a reconnect loop is occuring during a fresh reboot of pfsense then it conencts fine but if the system was running for a period and then the link was brought down by the modem reset then the reconnect loop that time unplugging cable and replugging dont help provided the cable runs direct and not through a switch
-
if im not the only one with this issue means something is definitely changed in mpd 5 compared to mpd 4 and it cant be a isp fault also coz 2 isp don't make the same mistake.
the mystery still remains on whats different when connecting on boot and reconnecting on link loss, y does mpd connect perfectly fine when rebooting?
-
Have a look at this http://serverfault.com/questions/163811/pfsense-possible-to-traffic-capture-the-actual-wan-port
-
they guy on serverfault talks about a 'faulty ATM switch with MAC 00:90:1a:a0:a1:f4 (Unisphere Solutions)', but:
- an ATM switch has no MAC address, as it has nothing to do with Ethernet
- Unisphere Solutions produces (or produced) BRAS technology, which in this case terminates the PPPoE session
Both the serverfault guy and xbipin's PPPoE sessions are terminated on an Unisphere BRAS, as we can clearly see from the traces. It may be that there is a common software defect on that BRAS.
I still don't believe in a mpd defect, as the same issue is seen on the Windows box.
-
i guess a way around this is if its possible to bring vr1 interface down and up again with software rather than pulling the plug in between reconnect attempts, similar to how we disable an interface in windows and then enable it, this would replicate a plug pulling and a solution atleast.
-
can clarknova test the same using the older pfsense with the older mpd which will prove whose fault it is, mpd, freebsd or BRAS
-
out of desperation, i shut down my alix and re flashed pfsense 1.2.3 an quickly setup the wan and lan connections to see how it behaved, first thing i noticed was as soon as my isp mode was reset, pfsense triggered a vr1 - DOWN and when the modem came up again it triggered vr1 - UP, now this doesn't happen in this new pfsense 2.0, it considers the port to be alive for some reason, bear in mind there is no switch between pfsense and the modem.
as soon as the modem came up and vr1 showed as UP it didnt connect but nor did it show any reconenction attempts so i guess in a hurry i forgot to set that dial on demand stuff, but if i went to interfaces and clicked disconnect and then connect again then it would connect perfectly fine, also if i went to the wan page and clicked save then also it would reconnect fine so i guess it works fine compared to newer mpd.
cable unplug and replug also works fine, except due to dial on demand mis config, i had to go to interfaces and click disconnect or if it disconnected automatically then would just need to click connect and wan would be up again.
i tried multiple scenarios and all i can say i didnt have to reboot pfsense to make it reconnect which usually i have to do in pfsense 2 with the newer mpd.
so i guess that vr1 down and vr1 up during modem reset or switch off and on was key to this, i usually try reset only coz chances of a switch off and on are almost nil, in worst case it would reset itself or if there was a firmware update then it would reboot which was something like a reset only but triggered from the isp end automatically and thats when pfsense needs to be able to reconnect again once modem is up.
i wasnt able to take traces or even put a switch on the wan side because i had to get the device up asap.
-
so you have the very same issue with the RAS client under windows and the test with the old mpd/fw release was 2 months ago. That doesn't sound like a mpd/pfsense issue to me then…
You will not be aware of configurations changes on the Service Provider side.
What happens if you just disconnect and reconnect the ethernet cable after some seconds between pfsense and modem, when the reconnect loop is occuring?
its true it happens with the RAS client but if i unplug and replug or simply disable and enable the interface and reattempt it would connect just fine
-
My pppoe0 interface is mlppp with 6 vlan members. After disconnecting then reconnecting the cable to the interface that is parent to these vlans, I disabled all 6 parent vlans in the GUI, hit Apply, then re-enabled all 6 parent vlans in the GUI and hit Apply. pppoe0 did not reconnect, and I had to reboot pfsense to get the WAN back.
-
the isp modem needs to detect a link down along with pfsense to be able to kill the zombie connection on the isp end also that pfsense doesnt try to renegotiate the same again but starts a fresh negotiation of a new connection
-
the isp modem needs to detect a link down
That's going to be a problem then, as I don't see that as a realistic scenario for me.
Actually, the most realistic scenario for me (and it has happened) is that the power goes out. My equipement is on UPS, but the ADSL provider's equipment apparently is not, so the modems lose sync but they don't lose power, and the ethernet interface doesn't go down, but pfsense loses its PPPoE connection.
This is the problem that I really need fixed, and although I'm no PPPoE expert, it seems silly to me that pfsense can't seem to deal with this.
-
mayb if u invest some in this then some1 could take it more seriously and i think there r more such ppl like us suffering from the same and i think it might have to do with FreeBSD coz in the older pfsense, when the modem looses sync, the pppoe connection used to go down as well as the power or so on the interface and FreeBSD used to report a link down but this newer pfsense and FreeBSD doesn't for some reason.
i will be out of town after a month or so and i desperately need this fixed asap as i need to keep my internet connection running while im away thousands of miles
-
would it be possible to send a pppoe termination packet based on previous active session before initiating a new pppoe connection?
it would require patches to mpd i guess
-
It has been over a month since any of the pfsense developers have posted in this thread.
Have you considered posting in freebsd-net list http://lists.freebsd.org/mailman/listinfo/freebsd-net and/or mpd's developers at http://sourceforge.net/projects/mpd/ ?
-
posted in mpd on sourceforge just now
-
pfsense 2.0 uses mpd5 but the current version is 5.5, any1 care to test it out manually?
-
pfsense 2.0 uses mpd5 but the current version is 5.5, any1 care to test it out manually?
pfsense's mpd5 is actually mpd v5.5 (you can check via "mpd5 -v")