"Recent posts
#61
General Discussion / Re: Why I am retiring from con...
Last post by meyergru - March 31, 2026, 11:09:19 AMAt least we cannot be sure of that. From time to time we stumble upon another piece of the puzzle.
And for the record: This was a (small) security problem that had been fixed in the other BSD project and ported to FreeBSD, but only in parts (that seemed to matter). It was never clearly communicated which parts where fixed, because the fixes were done incrementally and augmented via several bug reports. Some of those were simply disregarded, because they were not reported on "pure" FreeBSD, but on OpnSense, laying the burden of proof on users.
So, to answer your question, you would have to take the initial fix and compare it across all over the place in FreeBSD. Would you like to volunteer?
All we know is that there were documented missing parts of specific ICMPv6 handling that were left out and led to the exact bug sighting that were to be expected from it, all sidelined with pure denial of these facts and pointing how this must be done - with each of the missing parts tracked down according to the FreeBSD process.
And for the record: This was a (small) security problem that had been fixed in the other BSD project and ported to FreeBSD, but only in parts (that seemed to matter). It was never clearly communicated which parts where fixed, because the fixes were done incrementally and augmented via several bug reports. Some of those were simply disregarded, because they were not reported on "pure" FreeBSD, but on OpnSense, laying the burden of proof on users.
So, to answer your question, you would have to take the initial fix and compare it across all over the place in FreeBSD. Would you like to volunteer?
All we know is that there were documented missing parts of specific ICMPv6 handling that were left out and led to the exact bug sighting that were to be expected from it, all sidelined with pure denial of these facts and pointing how this must be done - with each of the missing parts tracked down according to the FreeBSD process.
#62
General Discussion / Re: Which trigger for new IPv6...
Last post by meyergru - March 31, 2026, 10:53:52 AMAFAIK, OpnSense itself uses no privacy extensions for its own outbound connections. With IA_NA, it just cannot, because that would be a /128 and even with IA_PD, it does not, which has been criticised in the past.
Thus, I suspect you try to achieve something different? Dynamic DNS is out of the question, because you would rely on the redundant EUI-64 based parts for that, so what is your intention?
Thus, I suspect you try to achieve something different? Dynamic DNS is out of the question, because you would rely on the redundant EUI-64 based parts for that, so what is your intention?
#63
Tutorials and FAQs / Re: IPv6 Control Plane with FQ...
Last post by meyergru - March 31, 2026, 10:40:08 AMYou are correct about that there is a certain relation between up- and downstream that must be met in order to allow traffic at all. That is because the ACK stream takes up upstream bandwidth.
However, I measured during the downstream part of the Waveform test and got these results:
You cannot view this attachment.
This shows 4 GByte downstream data and ~130 MByte Upstream, of which 80% was TCP ACKs, so roughly a 3.25% of the downstream needed for upstream. AFAIR, that is about to be expected at a theoretical worst case of ~4% and a more practical 2% (RFC 1122).
AFAIK, that should also explain your rate of 1000/35 Mbps: Your ISP wants you to have full 1000 Mbps downstream, but only the mere neccessity for the upstream with nothing left for server applications. There are some more providers which offer only a small downstream even if there is no technical neccessity to do so, like with DOCSIS.
So, in theory, you should be able to use the full 1000 Mbps downstream, not only 600?
I can imagine two things that may shift the results:
1. With TCP ACKs, you can have pure ACKs and SACKs, so the number of packets used can be severly lower than the number of data packets. That is obviously the case in my test. You did not show the downstream part of your test, you we cannot know if SACK was used, which would be dependend on the client.
2. Regardless of the net data being transferred, pure ACK packets are way shorter than data packets, so they incur a larger overhead, so the net data results may not mirror the real bandwitdhs used.
However, I measured during the downstream part of the Waveform test and got these results:
You cannot view this attachment.
This shows 4 GByte downstream data and ~130 MByte Upstream, of which 80% was TCP ACKs, so roughly a 3.25% of the downstream needed for upstream. AFAIR, that is about to be expected at a theoretical worst case of ~4% and a more practical 2% (RFC 1122).
AFAIK, that should also explain your rate of 1000/35 Mbps: Your ISP wants you to have full 1000 Mbps downstream, but only the mere neccessity for the upstream with nothing left for server applications. There are some more providers which offer only a small downstream even if there is no technical neccessity to do so, like with DOCSIS.
So, in theory, you should be able to use the full 1000 Mbps downstream, not only 600?
I can imagine two things that may shift the results:
1. With TCP ACKs, you can have pure ACKs and SACKs, so the number of packets used can be severly lower than the number of data packets. That is obviously the case in my test. You did not show the downstream part of your test, you we cannot know if SACK was used, which would be dependend on the client.
2. Regardless of the net data being transferred, pure ACK packets are way shorter than data packets, so they incur a larger overhead, so the net data results may not mirror the real bandwitdhs used.
#64
26.1 Series / Re: New IPv6 address assignmen...
Last post by meyergru - March 31, 2026, 09:53:34 AMIDK. If you feel that is a bug, create a bug request on Github.
#65
General Discussion / Re: Which trigger for new IPv6...
Last post by JamesFrisch - March 31, 2026, 09:52:48 AMQuote from: drosophila on March 31, 2026, 12:00:53 AMI need to react to both these events.Why? Maybe we can help you better if you tell us why that should matter.
IMHO a changing PE IPv6 should never matter. And AFIK, OPNsense does not get a PE IPv6 on the WAN interface, even when SLAAC is used.
#66
26.1 Series / Re: After the Migration of Fir...
Last post by Patrick M. Hausen - March 31, 2026, 09:32:18 AMQuote from: NorbertK on March 31, 2026, 09:22:22 AMI conclude that I can delete all entries in the OLD lists then ? This would help too.
That should be the last step in the migration assistant. Weren't you offered that option?
#67
26.1 Series / Re: After the Migration of Fir...
Last post by NorbertK - March 31, 2026, 09:22:22 AMThanks a lot fr the fast reply. I conclude that I can delete all entries in the OLD lists then ? This would help too.
#68
General Discussion / Re: Why I am retiring from con...
Last post by chrcoluk - March 31, 2026, 08:42:25 AMI can offer my 5 pence on that long bug report conversation. I apologise if anyone is offended by it.
First, my view is that the nature of the bug is pretty scary, we have had issues over the years with weird IPv6 behaviours, weird PF issues, which can be very frustrating for people operating misbehaving networks, if it also affected ICMP packet too big stuff, then it is especially nasty, and I think its clear regression testing is inadequate on FreeBSD.
Second I can see the asks's to back out the original security patch, as a end user I definitely see the logic in the request, but I very rarely see developers back out code, they usually die on that hill. I agree with dok's comment that the issues the patch was causing are far more serious than a vague low risk security bug.
Third, I think the idea to use a vanilla FreeBSD kernel on OPNsense to get the bug moving again was sound and should have been done right away after it was suggested. It doesnt matter if its felt it was wrong, just do it to satisfy all parties for democratic reasons.
Fourth was some bickering which was not a good luck on anyone.
Fifth the entire bug report makes FreeBSD look pretty bad in many areas, which its lask of regression testing as well as urgency in getting the issue fixed, even if it means backing out.
Is this still not properly fixed in FreeBSD upstream?
First, my view is that the nature of the bug is pretty scary, we have had issues over the years with weird IPv6 behaviours, weird PF issues, which can be very frustrating for people operating misbehaving networks, if it also affected ICMP packet too big stuff, then it is especially nasty, and I think its clear regression testing is inadequate on FreeBSD.
Second I can see the asks's to back out the original security patch, as a end user I definitely see the logic in the request, but I very rarely see developers back out code, they usually die on that hill. I agree with dok's comment that the issues the patch was causing are far more serious than a vague low risk security bug.
Third, I think the idea to use a vanilla FreeBSD kernel on OPNsense to get the bug moving again was sound and should have been done right away after it was suggested. It doesnt matter if its felt it was wrong, just do it to satisfy all parties for democratic reasons.
Fourth was some bickering which was not a good luck on anyone.
Fifth the entire bug report makes FreeBSD look pretty bad in many areas, which its lask of regression testing as well as urgency in getting the issue fixed, even if it means backing out.
Is this still not properly fixed in FreeBSD upstream?
#69
German - Deutsch / Re: download einer bestimmten ...
Last post by stulpinger - March 31, 2026, 08:37:56 AMAlles klar
Danke Dir
LG
C
Danke Dir
LG
C
#70
26.1 Series / Re: New IPv6 address assignmen...
Last post by melectronics - March 31, 2026, 08:22:04 AMHi, thanks for the answer :)
This is a OPNsense in my lab and it gets a /60 from a higher router.
So there should be enough room for 16x /64 prefixes.
I looked at the WAN interface and I set it to request a /61 prefix, but get a /60. In this situation the OPNsense assigns /63 to any interface where I activate the IA. When I turn it to request a /60 prefix it works fine.
Why this behavior is there? That shouldn´t be like this I think.😅
This is a OPNsense in my lab and it gets a /60 from a higher router.
So there should be enough room for 16x /64 prefixes.
I looked at the WAN interface and I set it to request a /61 prefix, but get a /60. In this situation the OPNsense assigns /63 to any interface where I activate the IA. When I turn it to request a /60 prefix it works fine.
Why this behavior is there? That shouldn´t be like this I think.😅
