No IPv6 address assigned on WAN interface / Router Advertisement ignored

[marjohn56]

But the fix to rtsold, which you have just issued a commit for and I've tested also works and does exactly the same thing, whatever as long as it works I don't really care how it's done.

[glasi]

> As configuration type I use PPPoE for IPv4 and SLAAC for IPv6.

So the PPPoE is too slow to come up as we try to immediately start dhcp6c anyway. We cannot expect to keep all quirks for ISPs alive if we change code to accommodate other setups.

> The proposed patch works like a charm. Router solicitation messages are now send via correctly identified interface pppoe0.

It's not happening.


Cheers,
Franco

This is absolutely ridiculous.

Neither is PPPoE too slow to come up nor is any quirk for my ISP necessary. PPPoE is ready. The only part not being ready is OPNsense. Hence, OPNsense misses out on ISP's RA messages during startup.

And to be honest, I don't understand why you get in a huff now. We've a good reason raising an issue with codes changes made in 20.7.r. Because it's simply not working as intended. Code changes have been made without paying attention to rtsold man pages. That's sloppy work!

And it's IMHO completely irrelevant that these changes already made it to two production releases.

I'm really concerned how things develop here. The problem was clearly defined and named. Rtsold autoprobing does not work on point-to-point interfaces. Have you ask yourself why this limitation is in place? Rather than fixing the problem at the point where it arises, we are now tinkering with rtsold's source code.

That's insane!

[franco]

Time for you to pack your bags and take your energy elsewhere. Bye bye.

[schnipp]

So the PPPoE is too slow to come up as we try to immediately start dhcp6c anyway. We cannot expect to keep all quirks for ISPs alive if we change code to accommodate other setups.

Can you please clarify, what kind of quirks do you mean. Looking at the packet dump of pppoe dial-in looks like my provider acts correctly. But as already mentioned, I noticed similar problems with my opnsense box. So, I cannot see any quirks my ISP is doing.

Please consider, the whole problem needs to be divided into two parts.

• Opnsense ignores router advertisements sent by the ISP for period of time after boot-up and pppoe dial-in
• Opnsense does not send router solicit messages after pppoe dial-in

The first one occurs only directly after booting the opnsense box and performing pppoe dial-in. When insctructing the mpd daemon to re-establish the pppoe connection router advertisement messages are immediately accepted and the pppoe interface generates a new SLACC address.

The second should trigger IPSs to send router advertisement messages in case the ISP does not send gracious ones after dial-in. But, this trigger (sending router solicit messages) does not happen as already discussed above.   

[schnipp]

Time for you to pack your bags and take your energy elsewhere. Bye bye.

I am a little bit confused regarding the whole discussion. Emotions are hijacking this thread which helps nobody of us to solve the problem. This project can only survive if work will be honored. And systems analyst's work is equally valuable like the programmer's one.

So, what is the way you like to go?

[marjohn56]

@schnipp - it's dealt with. The patch of interfaces.inc has been deleted as we are going with the patch to rtsold itself. That will make through it in the next release, If you cannot wait then you can either compile the updated version yourself or I've attached the compiled version of rtsold here. Replace the existing /usr/sbin/rtsold with the attached version; make sure  the flags are correctly set to 0555. Kill the running rtsold instance and then restart a Wan interface, that should kick the new one into life.


Now lets just relax and enjoy life.

[glasi]

Time for you to pack your bags and take your energy elsewhere. Bye bye.

Why should I? I' ll just ignore your bullshit from now on.

[schnipp]

@schnipp - it's dealt with. The patch of interfaces.inc has been deleted as we are going with the patch to rtsold itself. That will make through it in the next release, If you cannot wait then you can either compile the updated version yourself or I've attached the compiled version of rtsold here. Replace the existing /usr/sbin/rtsold with the attached version; make sure  the flags are correctly set to 0555. Kill the running rtsold instance and then restart a Wan interface, that should kick the new one into life.

Thank's a lot.

Now lets just relax and enjoy life.

You're right :).

[marjohn56]

Time for you to pack your bags and take your energy elsewhere. Bye bye.

Why should I? I' ll just ignore your bullshit from now on.

Take it down @glasi. @Franco's new addition is probably teething.. :) He's not a bad bloke really.

[chemlud]

Wow... simply wow...

[marjohn56]

Ah.. a little flame now and then is good for the soul, just so long as we can move on and forget about it.

[glasi]

Exactly.

Nevertheless, I want to add another point.

It seems that with a more extensive setup dhcp6c is being started too late and misses out on my ISP's RA messages. In my case PPPoE link is already up for more than two minutes before dhcp6c starts.

A lot of other tasks are running in between. Time consumimg seem to be e. g.: unbound_configure_do, ipsec_starter.

An empty monitor address for IX0_WAN_SLAAC is also causing delays when I read the logs correctly.

[marjohn56]

dhcp6c doesn't use RA messages. dhcp6c sends out a multicast solicit and waits for a dhcpv6 unicast advertise response from the server, it then sends a request to the server.  RS/RA is SLAAC, dhcp6 is a different beast altogether. If sometimes fails if the ISP does not have the 'other configuration' flag set in the original chit chat. dhcp6c is actually started at roughly the same time as rtsold, I'm talking milliseconds. Unlike pfsense the dhcp6c daemon used by opnsense is effectively resident and we rarely shut it down completely, having modified it heavily to allow us to use sighup to add/remove interfaces or config parameters.

[schnipp]

For me it looks like there is a sequence of actions without proper synchronization during the dial-in procedure. But, currently it's ony a guess. I can try to investigate a little bit more and in case there is an issue raise an appropriate github ticket.

Can everybody live with it?  :)

Edit:
let's make the project a success story together...

[marjohn56]

All I can say is that I have run a PPPoE server on a VM serving to my test router and that logs in and gets prefixes without issues. Of course every ISP has a different way of doing things. Some require that an RS is sent before solicit and get upset if that doesn't happen; Sky UK used to be that way, they have now relaxed that but that could be an issue. Difficult to know without seeing all of the logs and a wireshark capture.