PPPoE reconenction fix - mpd fix ($100)
-
ermal, is this log fine?
-
Yeah its ok i am dealing with that but been side tracked by other things.
-
others have reported this as some driver problem but the main concern is y is it affecting ppl from different regions using different isp using different hardware?
-
plz show some love here, its pending since long
-
plz show some love here, its pending since long
i second that… i need love here too... no proper reconnect is a k.o. criteria (sry, but every cheap bs gateway can do it)
-
mayb other needs to add up their amounts as well to get this bounty a little higher to get it noticed and worked on so plz pitch in
-
im increasing bounty amount to $150 if some1 can seriously take up this task and finish it by 7th February 2013
cant find the button to edit title
-
what i noticed is one reason y it doesn't reconnect is some timeout occurring but no idea y does it timeout, probably mpd is not sending the correct connection packet or mayb its sending to wrong mac id of pppoe server based on cached results from earlier connection, one fix could be to make mpd forget about any previous successful connection with server and start from scratch
-
bytheway do we use mpd5 or mpd5.5 in pfsense 2.1?
-
bytheway do we use mpd5 or mpd5.5 in pfsense 2.1?
2.1-BETA1 (amd64), built on Thu Jan 24 07:40:32 EST 2013
mpd5 -v
Version 5.6 (root@snapshots-8_3-amd64.builders.pfsense.org 10:48 14-Jan-2013) -
So the mpd daemon implementation on pfsense is broken for a year and it has never been fixed?
Is this all ppp connections?
-
So the mpd daemon implementation on pfsense is broken for a year and it has never been fixed?
Is this all ppp connections?
Of course not. It's a 1 in tens of thousands kind of thing that none of us could ever replicate.
-
its not totally broken but there r some issues with certain isp hardware from unisphere and now juniper and many new isp r using that, mostly Asian countries, so the chances of pfsense being used by ppl on those isp connections is almost negligible thats y the cases r less.
developers will never be able to replicate untill they connect to such an isp but more over no1 is willing to debug a live device connected to such an isp to fix it
-
can setting the below line solve this or it comes in affect only after connection is successful?
lcp-echo-interval 0
-
further analysis shows it could be a freebsd issue coz when the isp modem is reset or rebooted, the link between pfsense and isp modem is in a half dead state so inspite of mpd saying its trying to reconnect, those packets never reach the isp modem thats y the connection never recovers, only bringing down the complete interface on the pfsense box and then back up again makes those mpd packets reach the isp modem. in half dead state its like the interface is up but nothing flows between end points, so some1 needs to figure out what causes this half dead state, could it be the interface drivers or something else
-
further analysis shows it could be a freebsd issue coz when the isp modem is reset or rebooted, the link between pfsense and isp modem is in a half dead state so inspite of mpd saying its trying to reconnect, those packets never reach the isp modem thats y the connection never recovers, only bringing down the complete interface on the pfsense box and then back up again makes those mpd packets reach the isp modem. in half dead state its like the interface is up but nothing flows between end points, so some1 needs to figure out what causes this half dead state, could it be the interface drivers or something else
Well, those who experience this issue should then provide a more detailed report of hardware (which driver e.g. em/vr/rl/etc, which DSL modem in bridge mode, which provider DSLAM -if known-) and pfsense/FreeBSD software used when replicating the issue …
It's quite fortunate that mpd is being actively developed, and if this issue is somehow related to mpd, we can expect a quick fix.
-
im using the alix 2d3, the FTTH modem is by Zhone technologies (ZNID-GPON-2520), also tried with huawei DSL and cisco cable connection devices, the DSLAM is provided by unisphere for all the isp i had this issue with, pfsense is the nanobsd 1g 2nd feb 2013 snap
-
will $200 be good to fix this?
-
im using the alix 2d3, the FTTH modem is by Zhone technologies (ZNID-GPON-2520), also tried with huawei DSL and cisco cable connection devices, the DSLAM is provided by unisphere for all the isp i had this issue with, pfsense is the nanobsd 1g 2nd feb 2013 snap
Well, could you check the very same setup with a different pfsense NIC (e.g. Intel) or running pfsense in a VM, to see if you can replicate the issue ?
But if it's some odd interaction between mpd and Unisphere DSLAM, I think your best bet would be the mpd developers …
-
the issue remains when trying windows dialup connection using a realtek nic to ftth modem by isp.
i have tried contacting mpd developers a few times recently also but no reply.
the only working fix as of now is bringing down the interface and then back up again and this was provided by wow a few pages back but it works in delayed fashion but probably some1 from pfsense can add this to pfsense in a more reliable manner so when pppoe disconnected, then kill mpd, bring down interface, wait few seconds, then bring back itnerface, wait few seconds and then launch mpd