Upgrade to 2.4.1 cant connect to pppoe wan over vlan
-
That's what I have planned for tomorrow.
What is the best way to roll back? Do a clean install and use the config backup of 2.4.0 version?
-
TBH, douche move to do this in a maintenance release. Broke PPP. Rolled back via VM Snapshot…
I didn't read the release notes fully, but it's a maint release shortly after a major release. The below came in the newsletter - so basically I expected a KRACK patch and stability fix. Not to have the PPP stack entirely borked, which was found in tested and pushed out anyway.
PPP might not be all that widely used, but I expected things to break in 2.4.0 and planned accordingly, as would the people who did the upgrade to 2.4.0 and found the VLAN problems. I didn't expect the same from 2.4.1
pfSense software version 2.4.1 release
We are excited to announce the release of pfSense software version 2.4.1, now available for new installations and upgrades!
pfSense software version 2.4.1 is a maintenance release bringing security patches and stability fixes for issues discovered in pfSense 2.4.0-RELEASE, including a patch for the recently announced WPA-2 KRACK vulnerability.
pfSense 2.4.1-RELEASE updates and installation images are available now!
-
It was allegedly done because of some ARM nonsense where some genius decided to name the interface mvneta and they found that it was too long after beginning to sell hardware with those.
I suggest you fix your attitude.
Those are the SG3100 units than can be recycled as paperweight once your one year support has ended and you need to reinstall, since there are no public ARM images available.
This is incorrect. You can always reinstall your SG-1000 using its image that's available on portal.pfsense.org. After 1 year, portal access, not support as no support is bundled with the device, is locked out BUT you can still use SG-1000, continue to update it or reinstall it using the image. Please refrain from making such wrong conclusions.
-
TBH, douche move to do this in a maintenance release. Broke PPP. Rolled back via VM Snapshot…
I didn't read the release notes fully, but it's a maint release shortly after a major release.
Then start reading the release notes or at least the announcement blog post. "douche move" remark is not nice.
-
for now i had to rename all igb.20 to igb1_20 to make it connect, why would they release it with such a bug
It was allegedly done because of some ARM nonsense where some genius decided to name the interface mvneta and they found that it was too long after beginning to sell hardware with those. (Those are the SG3100 units than can be recycled as paperweight once your one year support has ended and you need to reinstall, since there are no public ARM images available.)
Renaming interfaces is about the most critical thing you can mess with on a networking gear such as firewall. So, of course a minor bugfix release is an excellent opportunity to change those, completely untested and after 2.4 has been tested for ~1 year. Sigh.
Once again, reading the release notes is important: https://www.netgate.com/blog/pfsense-2-4-1-release-now-available.html
https://redmine.pfsense.org/issues/7981
Yeah, once again, noone sane makes and expects such changes at this time point.
Doktornotor,
Point in-fact the "too long" was due to some work done (by people who are now gone) to use "interfacename<unit>_vlan<number>" in pfSense.
What we did is to repair the pfSenes code to use the FreeBSD standard "interfacename<unit>. <number>where <number here="" is="" the="" vlan="" tag".<br="">As you should be well-aware, choices made over the last decade mean that pfSense can be quite difficult to maintain.
This did not occur "after beginning to sell hardware" as you assert. You are 100% wrong on this point, and you need to retract. 2.4.0-RELEASE occurred prior to SG-3100 entering a shipping state, and, in fact, the earliest release of pfSense for the SG-3100 is 2.4.1-RELEASE.
This "mvneta" name did not come from us, it came from Semihalf, via FreeBSD.
Many people are misinformed about being able to get reload images for Netgate platforms. You perpetuate the myth, and I think only to gain advantage.You've made several false statements in the above, and denigrated members of the team.
We've been here before. Back down the rhetoric, and retract the above, or go somewhere else.
You have zero more chances, and I am 100% serious on this point. Criticism is fine, but lying is not.</number></number></unit></number></unit>
-
I've upgraded my SG-4860 to 2.4.1 and lost my internet connection.
I tried to modify my config, renaming all
igb1.11toigb1_11but this results in the system not coming up at all anymore. I had to factory reset and reload the original config to connect again.What else can I do to get my connection running again?
-
While its running run on console "ifconfig igb1.11 name igb1_11" then from webgui edit the pppoe interface to select the right interface to run on. That should afaik allow for internet access. Until reboot that is..
Should probably be possible to upgrade to 2.4.2development which should fix the pppoe+vlan issue, though i am not 100% sure if it wont complain during boot then yet again.. due to the changed config for a then not existing interface with that name.. -
While its running run on console "ifconfig igb1.11 name igb1_11" then from webgui edit the pppoe interface to select the right interface to run on. That should afaik allow for internet access. Until reboot that is..
That did the trick, thank you very much!!!
-
@jwt:
This "mvneta" name did not come from us, it came from Semihalf, via FreeBSD.
Many people are misinformed about being able to get reload images for Netgate platforms. You perpetuate the myth, and I think only to gain advantage.I perpetuate nothing. I responded to your email, sadly no response to that. So let me restate this in public - noone gives a horse shit about who's responsible for the interface naming brainfart. You are breaking stable releases because of this nonsense. 2.4.0 RC, 2.4.1, the 2.4.2 snapshots…
WTH you keep threatening contributors to this project What kind of advantage am I supposed to gain from this? Being threatened here, being threatened via email, as a reward for contributing tens of thousand LOCs to the project?
Go see a shrink doctor, ASAP. This paranoia is pathologic.
-
That's it, your continuous abuse ends now. You were warned many times.
-
Just did a fresh install of 2.4.0 and restored my backup config… all up and running now.. waiting for 2.4.2 for now, or maybe 2.5.x ...
still damn unhappy about how this all went down... such change in an Minor upgrade.. unbelievable
-
My solution workflow that got our 2.4.1 box with this issue back online…....
a) Had upgraded from 2.4.0 to 2.4.1
b) System came back up fine after the upgrade reboot, but no internet connection anymore with existing VLAN/PPPoE configuration.
c) Logged into WebGUI
d) Went to Diagnotstics --> Edit File --> Browse. Choose "Conf" folder. Choose Config.xml file.
e) Place cursor in text window. Go to the Web browser's menu to choose the "find" content facility. Search for each occurrence of "interfacename.vlannumber" in config.xml and change the . to _ then save the edited config.xml file. For example igb0.900 to igb0_900
f) Reboot PfSense.
g) System came back up without issue and connected the PPPoE connection immediately. Job done. 15 minutes work max.Hope that helps as another interim solution option. I had to do this remotely (200+ Km away), with the keyboard assistance of an inexperienced person at the system's site. The pfSense system was installed at a Radiology practice, so the situation was business critical.
It was an inconvenience yes, but not a show stopper.
The bottom line in all this, is that I failed to appreciated the release notes content regarding the VLAN/PPPoE issue, in as much as I forgot that this problem configuration existed on the system I upgraded. So I have no one else to blame but myself. I see that some people are rather disguntled by the circumstances of their own demise with this issue. Yes one could sook that the upgrade was released broken I suppose, but it gets a bit rich to complain about this, when the release notes forewarn of the issue for a specific configuration and then that warning is not heeded.
Cheers
-
@MAW: if I follow that advise, pfSense will have troubles assigning it's vlans (on that appliance: vtnet0., vtnet0_ respectively) to logical interfaces (OPT*) at reboot. If I only change that within the vlan and pppoe sessions, assignments still work, but pppoe still fails.
-
@MAW:
… I had to do this remotely (200+ Km away) ... at a Radiology practice, so the situation was business critical ... It was an inconvenience yes, but not a show stopper.
What?
A point release that kills functionality IS a show stopper. Period.
Work in the live entertainment industry like I do and you'll get this pretty soon. Or get fired before you even know why. -
I upgraded to 2.4.1 and lost my PPPOE WAN connection too. Whoever implemented this system breaking change smoked far too much crack.
-
this is a known issue, will be fixed in 2.4.2.
I dont know if its fixed in the current 2.4.2 dev branch.
Thank you for the information
-
The biggest pain in the ass comes when you update remotely the box, through a VPN connecting via the PPPoE connection. You won't be able to fix anything until you go there physically. Which can cause severe downtime…
-
The biggest pain in the ass comes when you update remotely the box, through a VPN connecting via the PPPoE connection. You won't be able to fix anything until you go there physically. Which can cause severe downtime…
directly upgrade to 2.4.2 dev from 2.4 and it will be fine, just skip the 2.4.1 update
-
directly upgrade to 2.4.2 dev …
Stuntman is your main profession or just a hobby? 8)
Honestly, you don't update a remote machine some serious distance away to a dev snapshot. May I remind you that dev stands for development and may contain glitches and quirks.
And which snapshot timestamp are you talking about? There's probably a newer one already built while we post. Is that fine as well, did you test that on my infrastructure?You can do so at home if you like but surely not in a remote session to a critical system not within walking reach.
If you are sane, that is. ;) -
I think he meant for this specific case only.
This is the only reasonable thing to do. Better 2.4.2 which is more stable than 2.4.1 at least IMO.
