PPPoE reconenction fix - mpd fix ($100)
-
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
-
After suffering from very similar logs and lots of googling I found a cure (well a cause) for me anyway.
If the router came up after pfSense (if it was powered off then on again), pfSense would not connect to it no matter what unless you power cycled it again or yanked the cable. What I found was happening was when the link first came up pfSense would grab the ip address from the router using DHCP and start sending its pppoe requests to it (producing the same logs about connecting posted earlier), it would never log in. Pulling the cable, waiting a bit then plugging it back in would then log in straight away.
What was happening was the first ip address it obtained from the router was a local 'admin' address (in my case 192.168.2.10), the router would then connect to whatever destination and sync, it would then change it's ip address to the correct WAN IP (In my case 217.155..), but as the link status stayed as 'up' pfSense would not grab the new ip address and keep sending it's pppoe junk to the original 192.168.2.10 address. No amount of ifconfig up/down would shift it.
The solution to my problem was just to disable the DHCP server in the router as it isn't required anyway (admin access can be got using a static ip). Now I can power on/off router or pull/reconnect cable and pfSense picks up the status and the correct ip address straight away with no rebooting or anything.
I hope this is of use to someone as googling this issue picks this post as the top one.
the above was posted by another user but he managed to login into his isp modem i guess but in my case i cant do that, its not giving me access in anyway nor is dhcp enabled on the modem so i dont suffer that issue