Bug #13353
closedDHCPv6 (still) doesn't work properly with multiple interfaces
0%
Description
Another release, another stupid IPv6 bug that could have been detected with basic testing. I'm sure the users of the free community edition will appreciate that the customers of pfSense Plus are basically doing beta testing so that the community edition will be released in a much more stable state, that's definitely how it should be....
Anyways, this bug is particularly "beautiful": When setting up multiple DHCPv6 WAN Interfaces (so pfSense as Client that is) the config in /var/etc/dhcp6c.conf is created for both. However, the previous config is overwritten. That means the file first looks like this:
interface eth0 { send ia-na 0; send ia-pd 0; send rapid-commit; script "/var/etc/dhcp6c_opt1_dhcp6withoutra_script.sh"; }; id-assoc na 0 { }; id-assoc pd 0 { prefix ::/56 infinity; };
and a second later like this
interface eth1 { send ia-na 1; send ia-pd 1; send rapid-commit; script "/var/etc/dhcp6c_opt2_dhcp6withoutra_script.sh"; }; id-assoc na 1 { }; id-assoc pd 1 { prefix ::/56 infinity; };
Of course that doesn't work properly at all. Also the Webinterface is allowing invalid configurations or at least isn't complaining and instead just selecting and deselecting random options, that makes configuring this even more fun (try to set the same id-assoc for multiple interfaces, to just name one example). Also apparently nobody spent time to think a second if the "override config file"-option in the webinterface makes sense in the current scenario (hint: it doesn't), there is a single dhcpv6-client-process but you can specify a different config override for each interface....
That is on the latest pfSense plus version.
Related issues
Updated by Jim Pingle over 2 years ago
- Status changed from New to Duplicate
Duplicate of #6880 -- it does work on Plus 22.05 and 2.7.0 snapshots.
Updated by Jim Pingle over 2 years ago
- Is duplicate of Bug #6880: Multiple DHCP6 WAN connections leads to multiple dhcp6c clients added
Updated by Flole Systems over 2 years ago
No it's not! I clearly wrote:
That is on the latest pfSense plus version.¶
above which shouldn't leave any room for interpretation, so don't tell me it's fixed when I am literally just experiencing that issue. Anyways, I'm over this. Fix it or leave it broken, I don't care anymore, I will switch to a different firewall solution and if another customer reads this report they should do the same. You turned pfSense from open source software into a product (which is not necessarily a bad thing), so I can and will expect the quality of a commercial product. That includes that bug reports are read fully and that at least basic testing is done so that bugs that render the product useless are found before releases. I have never seen so many regressions in a product, the previous release was complete junk and I needed no less than 10 patches to have it in a partially working state, but this one is even worse, I don't have time to have a multiple hour downtime and go bug hunting everytime I upgrade this product. I'm just glad we bought our appliance through a reseller here in the european union, that thing will go back tomorrow as I am so done with this.
That "fix" for #6880 is causing exactly these issues by the way. You basically "fixed" multiple clients starting, that's great but that doesn't mean it's working, especially if you just delete the config midway while writing to it.....
By the way: I have found and fixed this issue already and I can tell you that basic testing would have found it aswell.
Updated by Jim Pingle over 2 years ago
I am actively using it on 22.05. It works, and does not behave as you describe.
: cat /var/etc/dhcp6c.conf interface ix3 { send ia-na 0; # request stateful address send ia-pd 0; # request prefix delegation request domain-name-servers; request domain-name; script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please }; id-assoc na 0 { }; id-assoc pd 0 { prefix-interface igc0 { sla-id 0; sla-len 4; }; prefix-interface igc1 { sla-id 1; sla-len 4; }; prefix-interface igc2 { sla-id 2; sla-len 4; }; }; interface ix2 { send ia-na 1; # request stateful address send ia-pd 1; # 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 1 { }; id-assoc pd 1 { prefix-interface igc3 { sla-id 4; sla-len 4; }; };
Furthermore I have LANs tracked from both WANs:
LAN1 (lan) -> igc0 -> v4: 10.17.0.1/24 v6/t6: 2001:db8:1:eed0:208:a2ff:fe12:169e/64 LAN2 (opt4) -> igc1 -> v4: 10.17.1.1/24 v6/t6: 2001:db8:1:eed1:208:a2ff:fe12:169f/64 LAN3 (opt5) -> igc2 -> v4: 10.17.2.1/24 v6/t6: 2001:db8:1:eed2:208:a2ff:fe12:16a0/64 LAN4 (opt6) -> igc3 -> v4: 10.17.3.1/24 v6/t6: 2001:db8:2:ee34:208:a2ff:fe12:16a1/64
So either there is something wrong with your install and isn't isn't running 22.05, or there is something else wrong with your setup/environment -- either way, take it to the forum. It's working for me and others.
Updated by Flole Systems over 2 years ago
I know exactly why it's working for you (and for some others aswell, not for all though), but it's not my job to fix your product if you lack basic regression testing before releases. So I suggest you start setting up some test scenarios and figure out where the bug is, or start staring at the code (which works aswell). Or since I was kind enough to post my config you can also try to figure out what's needed to create that config and then you will reproduce this.
I can tell you that basic unit/regression testing would have found this bug, which is why I am so upset about this. Usually I would provide the solution as I've done it in the past aswell but I rather get the impression that such free work is exactly what you want so you don't put any effort into testing anymore as users will report bugs and provide solutions. That's acceptable for open source software but not for a commercial product. Show me your effort and what you have done (and a single configuration is not sufficient, there are many configuration options, testing just one of them is not enough and you haven't even tested what I mentioned in the bug report....) then I will be glad to help and maybe even reconsider my decision to switch to a different manufacturer, but not like this.
Updated by Jim Pingle over 2 years ago
Unit tests are a concept that is easy to suggest but not at all easy to implement. It's something we are working toward but it's a long road.
If you have more information you should provide it instead of giving hints and suggestions and being vague. Even better, a pull request with a suggested fix.
It works for what most users would do in practice, there are always likely to be edge cases not covered by the GUI.
To reiterate: The issue stated in the title and the bulk of the description here is demonstrably false. If there is some other requirement (e.g. override configurations) then that should be the subject and lede, not an afterthought that wasn't even stated as being definitively part of the configuration.
If you want to make a new, and more accurate, bug report with just the facts and without the colorful language, then we might be able to find and fix potential problems.
Updated by Flole Systems over 2 years ago
If you would do proper testing (which means that at least multiple options that the GUI offers are tested, not just this works-for-me-attitude where a single test-case passing basically means it's working) then implementing unit tests would be a major relief. Of course if there's no testing or the test being "runs on a machine in the lab - works!" implementing unit test seems like a huge effort, but compared to proper manual testing it's a huge relief as it saves a lot of time. You don't seem to understand that your testing is not enough, you released 2 versions of a commercial product in a row that contain major issues, that's pretty much game over.
As I said: This appliance will be returned to the reseller which is luckily in the EU so we'll get a full refund for it, I gave more than enough pointers in the right direction (I even posted the config created, as you might have noticed yours looks different) but since I am not getting paid for this (in fact I had to pay for the hardware with the pfSense plus license) I am not going to provide the solution, especially since I get the impression that this is somehow part of your business model. If you want to fix this you can either search the bug yourself, hope that someone else finds it and does the work for you for free or negotiate some kind of contract with me so that I get paid for the work I am doing to fix a product that should be working in the first place. I'm not going to work for free (or even worse: pay for a product so I can fix it and provide those fixes for free) as that's clearly what you want and are expecting. Again: You turned this into a product, so I am expecting the quality of a product. Others might have different views on that and if they want to spend money to buy pfSense plus and then spent time to make it usable they can certainly do that, I rather buy a product from a different manufacturer though.
If you found a fix and want to compare it to my fix:
# sha256sum /etc/inc/interfaces.inc b2e61aaf097e4ee4e343cb6c48c1db05cb1a61ed4df5feb34f7ed9a1b872b266 /etc/inc/interfaces.inc
and if you figured out that the same mistake was made somewhere else aswell and you fixed both
# sha256sum /etc/inc/interfaces.inc 6490a3b262045a16cb291bf47566c1ae15fc3cbce691e48f9c37707eb4ec62fd /etc/inc/interfaces.inc <pre>
Updated by Jim Pingle over 2 years ago
We do test a variety of configurations but testing every possible iteration is not possible. Even with unit testing there is a limit to how many combinations can be tested.
We have to rely on cooperation from customers and the community to give us meaningful feedback so we can address bugs. If we get incomplete or vague information there is only so much we can do.
Updated by Jim Pingle almost 2 years ago
- Related to Bug #13462: Advanced DHCP6 client settings only work for a single interface added