- User Since
- Sep 26 2019, 9:24 AM (192 w, 6 d)
Feb 20 2022
Similar to ng_bridge, but there was hope that if_bridge could avoid such problems.
Feb 6 2022
Feb 3 2022
Feb 1 2022
All the solutions do not address the underlying problem: Do we know, that the payload is correctly assigned or not?
If we know, that we should use
alignas(int32_t) void * pstart = &up[p->ip_hl]; struct udphdr *u = pstart;
Jan 4 2022
Thank you for reviewing, @pauamma_gundo.com
- Fix man page grammar
Jan 3 2022
It's not possible to remove a hook while creating it.
Find a better solution.
Thank you. The bug is simple:
Dec 31 2021
Dec 28 2021
Dec 27 2021
This is the first approach to implement the reattach process.
It does compile. I did not test anything yet.
Only alias_nbt.c may return any negative result. Even if no handler is suitable, the returned value from alias_mod.c would be positive (2). Every other handler always returns zero.
Rebase to main.
Nov 11 2021
Thank you for including the fib.
Nov 10 2021
If I understand correctly, the requirement is to align the IP header unconditional.
So there is no need for an extra message, but all other nodes might be urged to add this, too.
Nov 9 2021
The reason for the change of the interface might be located in the pfil_run_hooks.
May be @kp can tell something more about the magic there.
Others call this "host model" instead of "end system", hence I was confused without reading the documentation.
I welcome this extension to other architectures. Thank you.
Nov 3 2021
Nov 1 2021
Because both types are "int", the calculation does work.
Oct 25 2021
Thank you for taking care of this.
Oct 22 2021
Thank you for simplifying the code without dropping the functionality.
Oct 21 2021
Oh, I'm impressed that this fixes the "intended break" triggered by the netgraph test.
Please go ahead!
Oct 20 2021
The motivation behind the check can be understood from the viewpoint of a working system. It is an early dropout for a disconnected system.
But the PR253166 highlights, that this assumption is not valid during the early boot phase. So yes, remove this check.
Oct 19 2021
For the performance aspect, the following code path is involved:
A complete different approach would be to call ether_reassign from if_ethersubr.c
Oct 18 2021
This proposed message is specific to the ng_ether node. There is no need to clobber the global message space with such a specialized message.
Oct 8 2021
Sep 23 2021
Sep 17 2021
Sep 14 2021
Which architecture causes this problem?
Sep 10 2021
The rules of pf does not replicate exactly the same logic as the ipfw ones.
This might be insignificant how, but causes extra headache, if the test fails in an interesting way ...
okay or the ipfw part
May this cause an unwanted effect on automatic module loading?
So may somebody depend on this dependency in the local setup?
Sep 8 2021
Sep 7 2021
The current situation is good enough.
Aug 26 2021
Aug 25 2021
Same procedure as last test.
Same game as if_vlan
Aug 24 2021
Aug 12 2021
Aug 11 2021
The whole netgraph code predates any epoch, so the interactions are interesting.
Jul 27 2021
Because this is an incompatible change to current behavior, it should be mentioned in the RELNOTES or UPDATEING
Jul 25 2021
Jul 23 2021
Jul 22 2021
Do I understand correctly, that this is the first bpf-option to alter the packet in transit?
Usually I'd solve this problem by adding a simple netgraph network to the outgoing interface.
Jul 14 2021
Jul 10 2021
Jul 8 2021
Jul 7 2021
Depends on D30959
Good work! But hard to review.