User Details
- User Since
- Jun 4 2014, 7:25 AM (576 w, 3 d)
Thu, Jun 5
Tue, Jun 3
Mon, Jun 2
Sat, May 24
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 ?
Feb 17 2025
Feb 11 2025
Feb 10 2025
Feb 4 2025
Jan 24 2025
Jan 23 2025
IMHO, we need to fix this behaviour. First PINNED route should have priority and second attempt to add the same route on $if2 should fail with EEXIST. But then the test will fail, because after address deletion from $if1 there will not be any PINNED routes.
Jan 21 2025
Jan 11 2025
Dec 24 2024
Dec 23 2024
Dec 13 2024
I didn't test the patch, so if it is works for you I have no objection. :-)
I think this patch should do what you need.
Dec 12 2024
Dec 11 2024
Dec 4 2024
Dec 3 2024
IMHO when we already have an interface route, we should fail on trying to add the same route on different interface. And I think this should fail even before adding route, when an IP address will be configured.
If you want to test the case that was fixed in D47534 you need to add some static route, then configure interface route that will replace this static route, because interface route has higher priority.
I just tested these commands from PR:
ifconfig tun0 create ifconfig tun0 10.10.10.10 20.20.20.20 route -n delete -host 20.20.20.20 -interface tun0
with this patch:
--- a/sys/netlink/route/rt.c +++ b/sys/netlink/route/rt.c @@ -1010,8 +1010,9 @@ rtnl_handle_delroute(struct nlmsghdr *hdr, struct nlpcb *nlp, return (EINVAL); }
I don't like the idea that you can easily remove PINNED route, but it seems it always worked before.
However as I see, route(8) should pass RTF_PINNED flag to netlink via attrs.rta_rtflags. At least we should reduce use of RTM_F_FORCE only for case when RTF_PINNED was sent from userland.
Dec 2 2024
Nov 26 2024
Nov 25 2024
Nov 23 2024
Nov 13 2024
Sep 26 2024
You probably can directly call similar to bpf_ifdetach() function from if_vmove(). It is called from ioctl context, so you can make detaching synchronously.
Sep 25 2024
Sep 5 2024
Sep 4 2024
Probably for network related code ENOBUFS is better than ENOMEM.
I think you need to modify IFF_CANTCHANGE in sys/net/if.h
Aug 1 2024
- Document some features, also reduce the diff.
- Fix bug in mac:radix table: lookup addr doesn't work due to wrong args order in memcpy
Jul 30 2024
- Document some features, also reduce the diff.
Jul 3 2024
Maybe it would be better implement such feature via named flag, like ignore_source is implemented? Also if_gre(4) has the same problem.
Jul 2 2024
Jun 28 2024
I think it is firewall problem when it can not handle some unexpected data. Pfil hook expects that mbus has M_PKTHDR and m->m_pkthdr.len in this case should not be 0, even when m_len is 0. Thus, I think if doesn't work properly, it should be fixed in firewall.
May 20 2024
Mar 5 2024
Probably you can simplify some similar checks in in6_src.c too, e.g. IP6PO_VALID_PKTINFO and IP6PO_VALID_NHINFO. Not sure how it impacts your cache misses measurements.
Feb 26 2024
Probably we should increase esps_notdb or esps_invalid counter here.
Feb 19 2024
Dec 15 2023
I think https://reviews.freebsd.org/D32811, https://reviews.freebsd.org/D33064 also are related.