PPPoE reconenction fix - mpd fix ($100)
-
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
-
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 …
it would be helpful if some1 could get me a proper mpd developer contact
- 7 days later
-
I am having this same problem. I am going to purchase another device to mange my ppp connection and pass that interface forward.
-
sooner or later more ppl will have this issue once isp switch to unisphere BRAS or they upgrade its software or they implement one session per id restrictions
bytheway i have posted this on mpd forum as well but just one reply where i was asked for logs
http://sourceforge.net/projects/mpd/forums/forum/44692/topic/6720934 -
there was some progress on this matter with the mpd developers and one way they showed to delay sending the PADT when modem is down was by setting set link keep-alive to a higher number and i did that and before mpd could renegotiate a new connection that modem came up but still the connection wouldn't continue and this gives me a strong feeling its the interface drivers but for time being still coordinating with mpd developers
-
the other ppl having this issue or had this issue in the past, can u confirm ur using a alix box as well?
-
Its not an mpd issue it is a netgraph issue.
I told you that my priorities are set and will come back to this when i can.For the mpd developers tell them that seems ng_ether has this issues with attaching/detaching interfaces or ng_iface.
Though there are some patches specifc to pfSense that might be needed to be tested as well. -
ok fine, no1 was replying so i thought it was forgotten completely.
bytheway few suggestions on the mpd forum helped a bit,regarding PADT packet which used to be sent when modem was down so they said to increase set link keep-alive value and so i did but if alix was connected to modem directly it wouldnt help but if connected through a switch then mpd would continue connection once modem was up again and i also tried setting the standard value of 60 for it and in that case also it would connect but after some time and had to goto interface and hit connect in which case mpd was killed and a fresh instance started. i have generated log for both and will keep with me till required.
meanwhile ill reply on mpd forum about it not being a mpd issue
-
bytheway mpd developers replied this
And what those pfSense-specific patches are? I personally run mpd as PPPoE client using stock FreeBSD 8.3-STABLE and vr1 interface at home and have no netgraph-related problems with it
-
they mentioned this as well
Ethernet card driver vr(4) is known to have major problems with traffic restoration after physical link down/up. This problem have nothing to do with mpd/netgraph. You need to contact FreeBSD developers or replace your hardware to get other type of NIC. Also, read this:
http://lists.freebsd.org/pipermail/freebsd-net/2012-August/033127.html
- about a month later
-
How I fixed it:
Changed my USB Ethernet adapter for a different chipset, PCI Ethernet adapter. Voila!Zentyal, ClearOS and even pfSense failed to reconnect while using a Linksys USB200M, but I've had this same problem using another USB adapter (Intellinet, different chipset… I don't remember which). Maybe it's tied to USB adapters?
- 2 months later
-
I just installed pfsense (2.1-BETA1-4g-i386-nanobsd-20130507-1652.img.gz) on my Alix2d3 and I'm experiencing the same issue. Any news on a fix or workaround?
- 3 months later
-
Ummm OK, here is my experience…
Yesterday my box crashed and burned :) So I build a new one from an old PC...It has 2 NICs. 1 realtek (vr0) and one Intel (em0).
Now, if WAN is on Realtek card it will never reconnect. But if on Intel card (em0) it will reconnect with no problem at all...
Before that I had 4 Intel 100 cards (fxp). It also worked like a charm.So my suggestion for pppoe user is, use Intel NIC for WAN and you should be just fine.
I do believe this is NOT mpd bug but driver bug.My 2 cents…
- 9 days later
-
so considering a driver bug, how much would it cost to fix it or do the drivers need to be fixed from chipset manufacturer or freebsd?
-
Considering the multitude of Alix boards here not having any such problem, cannot see how's this a generic Realtek issue.
-
Considering the multitude of Alix boards here not having any such problem, cannot see how's this a generic Realtek issue.
Don't Alix boards have VIA NICs (not Realtek)?
-
yes they use VIA and im desperately ready to pay to get this fixed
-
Errr… let me try again since the message apparently got lost:
It has 2 NICs. 1 realtek (vr0) and one Intel (em0).
Now, if WAN is on Realtek card it will never reconnect. But if on Intel card (em0) it will reconnect with no problem at all…So, which is it?
-
Errr… let me try again since the message apparently got lost:
It has 2 NICs. 1 realtek (vr0) and one Intel (em0).
Now, if WAN is on Realtek card it will never reconnect. But if on Intel card (em0) it will reconnect with no problem at all…So, which is it?
alix boxes dont have realtek or intel nics at all, all r VIA chipset
-
via show as vr and realtek show as rl i guess
-
Yep, so… I'd wager Realtek really had nothing to do with the issue for that guy at least.
-
For whatever reason it only seems to be certain specific combinations of vr NICs + specific ISP/DSLAM equipment. Most people have no problems, but those that do seem to be isolated to vr NICs in that situation. We've had others report that in those cases adding a USB NIC, or swapping the NIC if it's not ALIX, has fixed it.
The ticket is still open here:
http://redmine.pfsense.org/issues/1943 -
realtek work fine for me always on same isp but this vr is an issue with almsot 4 different isps i have tested in 2 countries
-
realtek work fine for me always on same isp but this vr is an issue with almsot 4 different isps i have tested in 2 countries
It works with a switch in between?
-
ys because that way the port never goes down, the issue is when its connected to the isp fiber optic modem and that power offs which results in the port going completely down or some wierd state after which when on the packets from mpd never reach the isp at all inspite of port being on again
-
Sounds like a $5 solution….
-
switch solves the issue but isnt the proper solution.
its like some1 saying adding a switch to a switch to make a network connection for a PC but all u end up with is unnecessary switches when the PC can connect to the first switch directly or a better eg would be like adding a switch to connect 2 cat5 cables when u can simply plug in a coupler
-
It might not be a proper solution, however, lets be realistic here. This probably will not ever get solved. Assumes a whole LOT more detail on the HW involved plus - I'm afraid - involves getting developers to get their hands on that very HW/ISP connectivity for testing/debugging. So, however harsh that may sound - certainly not a question of a $100 bounty.
-
the reason this thread is still active because the developer has the redmine ticket still open as well as ermal last time said he would come back to this issue so was just checking as that post was quiet some time ago.
if its never going to be fixed then they might simply close this bounty as well as the redmine ticket once and for all
-
It's worth leaving open yet, there is a chance it may work again once we get 2.2 snapshots going on FreeBSD 10.x, newer driver set an all.
-
any eta on when thats going to happen?
the weird thing about this issue is that even the most crappiest routers in the market dont suffer this issue so it all cant be blamed on the DSLAM, if it was that then most other routers would also suffer that
-
No ETA on usable 10.x images. Could be months.
And the problem is a combination of factors - Specific Modem/ISP/DSLAM + Specific driver
-
to what i noticed is its just VIA drivers because it works fine with realtek, the isp modem i tested were 3 different types, zhone, huawei and cisco and it was same on all three, via chipset causing it, dslam which i tested was unisphere and the other was some unknown brand so the dslam, modem changed in all situations but alix was common so it suffered, i have 2 other pfsense full installs on the same isp using realtek and they work fine and always connect everytime
-
Wow, I missed this thread :)
Sorry for late reply…
Yes, vr0 had problems, DSLAM is UNISPHERE...
Dlink, realtek, intel and broadcom nics all worked great...
VIA on-motherboard NICs failed to connect...I tested all possibilities, from power outages to just cable disconnect and vr0 failed every time and others worked just fine EVERY time...
Regards,
Greg -
cant we take the vr drivers from FreeBSD 10.x and test it on current pfsense to see if it will actually fix this issue or no rather than wait for months for this to resolve coz its already over 2 years now
-
Well, I replaced my nics with Intel ones and that was it….
I needed stable system and Intel gave me that... -
cant we take the vr drivers from FreeBSD 10.x and test it on current pfsense to see if it will actually fix this issue
Possible but might not be trivial: FreeBSD internal interfaces and data structures might have changed significantly requiring considerable work to backport those changes as well or rewrite the vr changes from FreeBSD 8.3 to 10.x to work in FreeBSD 8.3 context.
Best case (assuming familiarity with FreeBSD kernel build procedures): maybe an hour or two to import the 10.x source into a 8.3 build system, recompile and run some basic tests.
Worst case: maybe up to a few months to figure out what changes in FreeBSD internals to backport and do them.
-
how about just check the drivers code and see the changes and cherry pick them which possibly might solve this network port stuck in a limbo state
-
Given how widespread the Alix install base is - pleeease, no. No backporting of vr drivers from FreeBSD 10.x to 2.1. While I can understand that it sucks for affected people
- this can apparently be extremely easily worked around by putting a switch between the pfsense box and the modem,
- this clearly affects a tiny percentage of users with specific NIC/modem/DSLAM combo on PPPoE specifically.
=> certainly not worth the risk of breaking everyone else
-
lets just leave it to the developers to decide, what they can do is provide the drivers separately to install so every1 dont need to use this