User Details
- User Since
- Jun 4 2014, 7:25 AM (599 w, 9 h)
Mon, Nov 24
Tue, Nov 18
Wed, Nov 12
Oct 27 2025
Oct 26 2025
Oct 25 2025
Oct 22 2025
It seems to have affected MLDv6: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407
Oct 18 2025
Oct 17 2025
Oct 15 2025
Oct 14 2025
Yes, I think they were replaced with handlers from ipfw_sopt_handler.
Oct 13 2025
Oct 8 2025
Oct 7 2025
Oct 3 2025
Oct 1 2025
Sep 23 2025
Sep 16 2025
Sep 8 2025
Sep 2 2025
LGTM.
Aug 3 2025
Jul 23 2025
Jul 22 2025
Jul 14 2025
LGTM.
Jun 5 2025
Jun 3 2025
Jun 2 2025
May 24 2025
May 21 2025
May 14 2025
Apr 18 2025
Apr 2 2025
Mar 25 2025
Mar 23 2025
Mar 19 2025
I think adding MPASS is better than removing. There is no locking, and it is still possible, that the code you are modifying will first get ifp pointer and then this ifp will be unlinked and marked as DYING :)
Mar 18 2025
Mar 13 2025
Mar 7 2025
Mar 6 2025
Mar 5 2025
Mar 4 2025
Mar 3 2025
- Add example of comapt layer.
Mar 2 2025
- Rebase
- Document some features, also reduce the diff.
- Fix skipto/call arguments parsing.
- Fix mismerged reass/return opcodes
- Fix ipfw32 opcode version for NAT44 opcodes.
- ipfw: rework call action to drop packets on errors
Feb 28 2025
It looks a bit confusing when you set net.inet.ipsec.random_id=1 and it does not work because default value of net.inet.random_id is 0.
It should be documented in ipsec(4).
Maybe just make ip_fillid_ex as ip_fillid_ex(struct ip *, bool do_randomid) and set net.inet.ipsec.random_id=0 by default?
Feb 21 2025
Feb 19 2025
> Do you think a IN_IS_ADDR_MULTICAST akin to IN6_IS_ADDR_MULTICAST is valuable ?
