PPPoE over an unassigned VLAN no longer connects after upgrading to 26.7.3

[fanski]

No I did it in that order:

1. download the patch with opnsense-patch -d 3384e551f3
2. copied the patch to /root/3384e551f3.patch
3. checked if the patch is working with  patch -d /usr/local -p2 --dry-run < /root/3384e551f3.patch
4. upgraded to 26.7.6_3
5. PPPoE was not working so i used this command patch -d /usr/local -p2 < /root/3384e551f3.patch
6. did a reboot
7. PPPoE was still not working so I checked /usr/local/etc/inc/interfaces.inc if the lines written in the patch are in there. They were there so I guessed the patch was working
8. did a second reboot and reloaded the ONT to be sure it's not another problem, but that didn't help

Maybe I did something wrong or need to activate something additionally?
But back in 26.7.1 the lines aren't in the interfaces.inc anymore so I'm pretty sure it was at least updated.
Is there something else I can check if to see if the patch is correctly installed?

Regards,

Fanski

[franco]

Hi Franski,

Okay, just wanted to double check.  Let me try to come up with debug output for your case.  The patch not working would indicate the VLAN is up when it is supposed to wait for it to come up... which is silly because it will be down a split second later?  It's not easy to work around this when the kernel lives on its own schedule.

Maybe you can try to increase the sleep to 5 seconds in order to catch the down window?


Cheers,
Franco

[fanski]

Hi Franco,

so I tried with 5, 10 and 15 seconds but no success.
I changed this (log message was just for me to be sure where this happens and if it works :) ):

Code Select Expand

/* wait for functional parent (only the first) */
    $max = 10;
    $i = 0;
    while ($i < $max) {

        sleep(15);
        log_msg("sleeping", LOG_WARNING);
        if (does_interface_exist($ports[0], 'up')) {
            break;
        }
        $i++;
    }

I'm just curious, do you think this could be hardware related? I use an old firewall for my setup. It was for free so for my home config it was good enough.I thought maybe the old hardware is not working properly with the new firmware/something in the modern architecture is causing this issue with my old hardware.

Regards,

Fanski

[franco]

That means the VLAN us up while the parent is down, which is even more inconvenient.  Yes, this is definitely a driver issue.

I added

https://github.com/opnsense/core/commit/d2ad94b38b48

and

https://github.com/opnsense/core/commit/212185a8be

which tries to look at the up state of the parent, not the port itself.  Your case at least already proves that this is likely not waiting for anything in most cases, but it might fix the issue you're seeing now.

If not there's a problem with the lookup, a) not waiting for the right device which would be my fault or b) the kernel driver for igb takes it down after we pass the wait test (worst case).

If you have trouble applying these patches I can try to make a proper backport for 26.7.6_3.


Cheers,
Franco

[franco]

PS: I've were honing in on "igb" being the culprit we can easily limit the wait code to that interface name to minimize impact for others.

[fanski]

Hi Franco,

still not coming up :(

So I upgraded again to 26.7.6_3, installed patch 3384e551f3 and reboot, then patch d2ad94b38b48 and reboot and then patch 212185a8be and reboot but unfortunately it's still the same behavior.

Maybe just a short question:
In 26.7.1 the vlan0.35 was not the first VLAN to be created. In the following versions it is always is the first one/vlan0, all the other VLANs created later seem to work without a problem. Is there a possibility switch the order again (maybe it's just the first one which is created which has problems)? Or is this a mandatory behavior that the VLAN attached to the WAN interface always needs to be the first to be created?

Regards,

Fanski

[franco]

Hi fanski,

> In 26.7.1 the vlan0.35 was not the first VLAN to be created.

Previously the VLANs were created in a batch before interfaces were brought up, but that changed in .3 with the support of VLANs on top of bridges.

We haven't seen many oddities, but there were a few.  Some hidden in the old code and some apparently in drivers.  I need to recheck the code I gave you, but it feels like the kernel is lying to us here.

At the moment I need to release 26.7.7 though so I'll try to get back to this later this week.


Cheers,
Franco

[fbantgat7]

I wonder if my problem is related to the behaviour reported by fanski.

Something changed with 26.7.x in the way IPv6 is obtained over PPPoE.

My WAN interface used to receive an IPv6 address/128 from the ISP via DHCPv6 IA-NA solicitation which up until now used to be shown as the router's IPv6 WAN address.  The ISP also allocates via DHCPv6 Prefix Delegation a /48 block and within this a /64 block.  For clarity I'll call this the 'home' prefix.  I have configured statically an address from the /64 block on the LAN interface.

For historical reasons I also have been allocated by the ISP a /64 block with a different to the above /48 prefix, which I have set up statically on a second interface on the router.  I'll call this the 'work' prefix.  At present there are no VLANs configured.

If I ever need additional /64 prefixes I'll allocate them out of the /48 block.  I do not have access to additional /64 prefixes from the 'work' address space.

Hosts connected either to the LAN or to the second interface happily obtain IPv6 leases with their respective delegated prefixes from allocated KEA pools and continue to do so.

However, the table showing the Kea DHCPv6 leases comes up with all local hosts grouped under the WAN interface, while previously they were listed under LAN and OPT1 respectively.

What seems to have changed recently is the order the router obtains its WAN IPv6 address from the ISP.  It still obtains its /128 address, but it shows up third on the list under the home/64 and work/64 addresses in the router's ifconfig and GUI.  The home/64 and work/64 addresses shown on the WAN are both created using the WAN's interface MAC address as their least-significant 64-bits.

I am trying to understand if I have misconfigured the router, but then again it was working fine with previous OPNsense releases.  What am I missing here?

(Please move this to a new thread if you think this is not relevant to the OP)

[franco]

@fbantgat7 Your issue is likely not related to PPPoE since that part is fine, but on top negotiation changed in DHCPv6 as it seems.  This could be a provider change.  I'm not aware of regressions in DHCPv6 connectivity in 26.7.x.


Cheers,
Franco

[fbantgat7]

Right, I don't have the same problem like the OP experienced, because I do get addresses fine.  The only apparent issue is with the router no longer presenting the /128 address as its WAN address.

Is the matter of KEA leases for my hosts listed under a WAN group, rather than under LAN & OPT1 as it used to be, of any functional rather than presentational significance?