pfSense

I am having the same issue when trying to dial PPPoE through a VLAN with the new dotted naming convention:

[em0.120] Cannot send a netgraph message: em0.120:: Invalid argument
kernel          ng_ether_attach: can't name node em0_120
ppp             [wan_link0] PPPoE: Error creating ng_pppoe node on em0.120:
ppp             [wan_link0] PPPoE node for link is not initialized

Can you please try again when a new snapshot is available? mpd-5.8_3 contains a fix for that

Renato Botelho wrote:

Can you please try again when a new snapshot is available? mpd-5.8_3 contains a fix for that

        Multi-link PPP daemon for FreeBSD
Oct 23 18:31:18 ppp             process 15326 started, version 5.8 (nobody@pfSense_master_amd64-pfSense_devel-job-02 16:31 21-Oct-2017)
Oct 23 18:31:18 ppp             web: web is not running
Oct 23 18:31:18 ppp             [wan] Bundle: Interface ng0 created
Oct 23 18:31:18 ppp             [wan_link0] Link: OPEN event
Oct 23 18:31:18 kernel          ng0: changing name to 'pppoe1'
Oct 23 18:31:18 ppp             [wan_link0] LCP: Open event
Oct 23 18:31:18 ppp             [wan_link0] LCP: state change Initial --> Starting
Oct 23 18:31:18 ppp             [wan_link0] LCP: LayerStart
Oct 23 18:31:18 ppp             [wan_link0] PPPoE: Connecting to ''
Oct 23 18:31:18 kernel          ng_ether_attach: can't name node em0_120
Oct 23 18:31:27 ppp             [wan_link0] PPPoE connection timeout after 9 seconds
Oct 23 18:31:27 ppp             [wan_link0] Link: DOWN event
Oct 23 18:31:27 ppp             [wan_link0] LCP: Down event
Oct 23 18:31:27 ppp             [wan_link0] Link: reconnection attempt 1 in 1 seconds

Thanks Renato, still can't dial PPPoE through a VLAN unfortunately

Having the exact same issue, my ISP provides internet over PPPoE on VLAN 6, worked perfectly until I upgraded to 2.4.1-RC yesterday.

Oct 23 15:24:37    ppp        [wan] Bundle: Interface ng0 created
Oct 23 15:24:37    ppp        [wan_link0] Link: OPEN event
Oct 23 15:24:37    kernel        ng0: changing name to 'pppoe0'
Oct 23 15:24:37    ppp        [wan_link0] LCP: Open event
Oct 23 15:24:37    ppp        [wan_link0] LCP: state change Initial --> Starting
Oct 23 15:24:37    ppp        [wan_link0] LCP: LayerStart
Oct 23 15:24:37    ppp        [wan_link0] PPPoE: Connecting to ''
Oct 23 15:24:37    kernel        ng_ether_attach: can't name node igb0_6
Oct 23 15:24:46    ppp        [wan_link0] PPPoE connection timeout after 9 seconds
Oct 23 15:24:46    ppp        [wan_link0] Link: DOWN event
Oct 23 15:24:46    ppp        [wan_link0] LCP: Down event
Oct 23 15:24:46    ppp        [wan_link0] Link: reconnection attempt 1 in 1 seconds
Oct 23 15:24:47    ppp        [wan_link0] Link: reconnection attempt 1
Oct 23 15:24:47    ppp        [wan_link0] PPPoE: Connecting to ''
Oct 23 15:24:56    ppp        [wan_link0] PPPoE connection timeout after 9 seconds

On latest snapshot: 2.4.1-RC (amd64) built on Sun Oct 22 12:08:54 CDT 2017 FreeBSD 11.1-RELEASE-p2

Had to dust off the old ISP provided router to get back online...

This doesn't work and frankly this is an absolutely horrible change to dump on people in between maintenance versions. You had about a year for testing, what's the hurry with this here? There must be at least 0.00001% of users using QinQ hitting the interface name length limit.

The VLAN name change was done because NIC drivers with 6 letter names, like mvneta, would break with VLANs >=1000, which impacted more people than this particular regression.

We'll be fixing this in 2.4.2, current ETA is ~2 weeks so if you're affected, just hold off and wait for 2.4.2.

Jim Pingle wrote:

NIC drivers with 6 letter names, like mvneta, would break with VLANs >=1000

The ARM thing? Perhaps it'd be a good idea to limit the messing to the publicly unavailable ARM factory images. (How many people need >1000 VLANs there given the platform performance would be another question.)

It wasn't over 1000 VLANs, it was VLAN IDs >1000 (four digit VLAN ID numbers). So if someone used VLAN 1001, 1002, as their main VLANs it would fail. Not everyone starts at 1 or counts by 10, and some people need VLANs in the 4000 range for various transport reasons. Also there are other drivers with six letters besides mvneta.

The alternatives were to change the interface name size (which blew up the 2.4.0 RC images, as you well know) or to change driver names, which means maintaining even more technical debt in changes against FreeBSD. FreeBSD now uses the interfacename.vlanid format so we felt it was best to follow them. We've already imported a patch to MPD which was supposed to fix this, but it apparently doesn't work all the way.

The PPPoE Discovery message comes back from the server but MPD never receives it.

honestly that was not cool to change in a minor update. And to release this bug with 2.4.1 since that obviously already existed in the snapshots.
Had to rewire network/switching and reconfigure pppoe binding to 1 physical interface to get pppoe back online.

Why couldnt you have waited for this to be tested and fixed before releasing public?

Luiz Souza wrote:

Fixed in the last 2.4.2 snapshot.

I can confirm it is working here, thanks for your effort.

Zach Nedwich wrote:

Luiz Souza wrote:

Fixed in the last 2.4.2 snapshot.

I can confirm it is working here, thanks for your effort.

Same here, working again with the latest snapshot.

Luiz Souza wrote:

Fixed in the last 2.4.2 snapshot.

I've been using dual-wan PPP connection, and one is working fine with the last build but another is still in Unknown state. Am I missing something?

Diego Henrique Pagani wrote:

Luiz Souza wrote:

Fixed in the last 2.4.2 snapshot.

I've been using dual-wan PPP connection, and one is working fine with the last build but another is still in Unknown state. Am I missing something?

Can you post more details of your setup ? Maybe some log outputs too...

Luiz Souza wrote:

Diego Henrique Pagani wrote:

Luiz Souza wrote:

Fixed in the last 2.4.2 snapshot.

I've been using dual-wan PPP connection, and one is working fine with the last build but another is still in Unknown state. Am I missing something?

Can you post more details of your setup ? Maybe some log outputs too...

I have triple-wan configured using vlan and load balancing: VIVO, CERTTO, NET. The NET network it's configured to use DHCP and the other two PPPoE. After upgrade to 2.4.1, the VIVO and CERTTO stopped working. After some research and found out this issue, upgraded to 2.4.2 snapshot and VIVO started to work again, but CERTTO not. I can't found in the log any evidence of the problem, even 'ng_ether_attach: can't name node xxx' that is posted above (maybe because some configuration, I don't know). I have to shutdown the main router and put the backup one, witch is on 2.3.4, where everything is working fine.

Version 2.3 and newer
In 2.3 and newer versions, the update system is pkg-based, changing the available update methods. Upgrades are performed either under System > Update in the webGUI, or option 13 at the console. Manual updates are no longer available, and systems must be Internet-connected to update.

I upgraded to 2.4.1 this morning without knowing about this PPPoE + VLAN issue. I no longer have internet access at home.
Looking into upgrading to 2.4.2. Is there anyway to update using the ISO and not loose my configuration?
Thanks for the help.

Marc-Andre Robert wrote:

Looking into upgrading to 2.4.2. Is there anyway to update using the ISO and not loose my configuration?

Sure, you can follow the instructions on the wiki to recover config.xml during the install process: https://doc.pfsense.org/index.php/Automatically_Restore_During_Install#Recover_config.xml - It will result in a fresh 2.4.x install using your existing settings. If you use a 2.4.2 snapshot you should be back up and running in a few minutes.

If you have more questions, follow up on the forum/reddit/etc.

with

2.4.2-DEVELOPMENT (amd64)
built on Mon Nov 06 10:40:15 CST 2017

I confirm there is no more problem with pppoe & vlan.

Thanks