Messages

OK. I'm going to install 20.1.7 and do what you did, see where it takes me.

Thanks. I have just run

Code Select Expand


opnsense-update -t opnsense

and am now back on 20.1.7.

I'll also remove the files /var/etc/dhcp6c.conf, /var/dhcpd/etc/dhcpdv6.conf and related to start fresh and redo the procedure.

Indeed, something triggered my attention from the man pages of opnsense-patch:

Code Select Expand

opnsense-patch - OPNsense patch utility
[...]
Patches can also be reversed by reapplying them
[...]

which means since I tried several times, the patches may have been reverted.

I meant what revision you were on, I assume 20.1.7?

I was indeed on 20.1.7, but followed the procedure I described above, and then it showed OPNsense 20.7.b_178-amd64

Also, if you know what is the procedure to go back to stock, let me now. That way, I can restart from scratch. :)

what does your version info say, 20.?

It says: OPNsense 20.7.b_178-amd64

I'll try and recreate what you did, but I need to know where to start.

Where to start? Simply follow what I did from there.

Code Select Expand

opnsense-update -t opnsense-devel
cd /usr
opnsense-code core
make upgrade

cd /usr
git clone https://github.com/opnsense/dhcp6c.git
cd dhcp6c
./configure
make
killall -TERM dhcp6c
make install

opnsense-patch c76a729
opnsense-patch 88bb423
opnsense-patch fa8b4c7

reboot

that would suggest not everything is in place.

What do you suggest to do then? The procedure I followed and adapted from yours is described here.

Would you mind checking whether the steps I followed are correct?

Work has not yet been done on a single LAN with multiple WAN dhcp6, however dhcp6c should still do its thing. Can you post your /var/etc/dhcp6c.conf and /var/dhcpd/etc/dhcpdv6.conf files.

Yes, I know work on single LAN for multi WAN has not been done yet. The problem I have been describing was related to have several dhcp6c :)

Here are the files requested. Some sensible content has been redacted with X.

/var/etc/dhcp6c.conf:

Quite normal this is not working, the file doesn't have config for ibg2. :/ I don't understand why the config is missing though.

Code Select Expand

interface igb1 {
  send ia-na 2; # request stateful address
  send ia-pd 2; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_opt1_script.sh"; # we'd like some nameservers please
};
id-assoc na 2 { };
id-assoc pd 2 {
  prefix-interface igb0 {
    sla-id 0;
    sla-len 0;
  };
};

/var/dhcpd/etc/dhcpdv6.conf:

Code Select Expand

option dhcp6.domain-search "home.XXXX.XX";

default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
one-lease-per-client true;
deny duplicates;
ping-check true;
update-conflict-detection false;
authoritative;

subnet6 2a02:2788:XXX:XXX::/64 {
  range6 2a02:2788:XXX:XXX::1000 2a02:2788:XXX:XXX::2000;
  option dhcp6.name-servers 2a02:2788:XXX:XXX:XXX:XXX:XXXX:XXXX;
  prefix6 2a02:2788:XXX:8000:: 2a02:2788:XXX:ff00::/60;
}

ddns-update-style none;

[Situation]

Ok. So I have tested the whole thing.

@marjohn56, I discarded the patches IDs you have sent to me in DM since the ones provided here above are more up to date.

Situation

PC Engines apu2c4 (apu2c4 = 3 i210AT LAN / AMD GX-412TC CPU / 4 GB DRAM)

1 LAN on opt0

2 WANs dual stack:
- Cable DOCSIS based connection (VOO Belgium 125/6.5Mbps) on opt1
- xDSL based connection (Proximus 35/10Mbps) (IPv6 tech info) on opt2

Instructions

My OPNsense was never put in devel mode, so I had to adapt your commands a bit.

Code Select Expand

opnsense-update -t opnsense-devel
cd /usr
opnsense-code core
make upgrade

cd /usr
git clone https://github.com/opnsense/dhcp6c.git
cd dhcp6c
./configure
make
killall -TERM dhcp6c
make install

opnsense-patch c76a729
opnsense-patch 88bb423
opnsense-patch fa8b4c7

reboot

Observations

- On the dashboard, the DHCPv6 server is exactly like before in red. Trying to restart it is not working.
- If I enable the xDSL IPv6 as DHCPv6, the modem cable connection cannot get an IPv6
- As soon I disable IPv6 on the xDSL and I reboot, the modem cable connection gets an IPv6
- Compared to the production 20.1 OPNsense version, the LAN now receives an additional IPv6 /128 scope global 2a02:[xxxx] address. LAN machines are still receiving a global unicast /64 like before.

What kind of log do you need to debug? I'm using radvdump extensively =)

It appears that you can add multiple GUAs to an interface, the issue there is that you can only have one dhcpv6 server, RADVD may be able to handle it, but this is a long road and it's not going to get implemented overnight, lots more work to do.

" but this is a long road and it's not going to get implemented overnight," yes, much things to have in mind indeed :)

OK, some success. @wget I'll PM you with what you need to do, but you must be running the dev path, can you confirm that before i send you anything.

I'm a primarily a full stack dev and only a network enthusiast, so I'm ok with the dev path. :)

Since my OPNsense current apu1c4 is used for production, I'll just visualize one on KVM VM hosted on my Proxmox machine. :)

My xDSL and modem cable both being in bridge mode, my ISPs are allowing a second direct connection on them, shouldn't be a problem :)

I'll pick this up and aim for 20.7...


Going to need some testers, they'll need dual WAN ISPs using dhcp6.

Then, if you need testing, I'm your man :)

Btw, since I'm still figuring out how the fallback method is working I wonder how LAN devices tracking the IPv6 PD address range prefix from WAN1 (Global Unicast IPv6 address i.e. 2a02::/8) will fallback to WAN2 (the backup WAN) when WAN1 is down.

And how to address the issue of DNS? Since the prefix will change when WAN1 is down, LAN devices (some of them are servers) will get a new prefix...

It will be there when I have time, or someone else is welcome to do it.  8)

Does this restriction still apply with OPNsense 20.1?

You can also make you own opinion by reading this page: https://pcengines.github.io/ which is a bit more complete than the Markdown file hosted on their github page: https://github.com/pcengines/release_manifests/blob/coreboot-4.6.x/CHANGELOG.md

Hi smawuascht.

I was in the same situation as you and read a lot about this topic. From my understanding, here are the pieces of info I have been able to gather:

- Back in the days, when they launched the APU boards, PCEngines forked the coreboot project and modified it in order to support their APU board (CPU, ACPI tables, etc.)
- They submitted a patch upstream, to the coreboot project, in order to have their changes integrated in the coreboot project directly.
- Their patch has been integrated around version coreboot 4.5.1.
- But in the meanwhile, they still supported their old forked version. The coreboot firmware has payloads (SeaBIOS, memtest, etc.) that are continuously upgraded by PCEngines (cf. version 4.0.16 released just yesterday).

So from my understanding, as of 2018, there is no reason to upgrade to the 4.6 branch (and onward). The board is stable enough with this 4.0.X versions an the payload are up to date. Changes in coreboot mainly concerns adding support for new boards and refactoring the coreboot code to support new board additions, nothing much. And I think if modifications concerning or impacting explicitly APU2 were to happen in the coreboot official branch, PCEngines would be more than happy to backport them to their own 4.0.X version, if this doesn't require too much work/hassle for them.

Regards,