we can't recover why would we ever have identical 4-tuples in the hash
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, Jan 23
Sun, Jan 22
Wed, Jan 18
Tue, Jan 17
Tue, Jan 10
Dec 20 2022
Nov 28 2022
Nov 17 2022
Nov 10 2022
Oct 6 2022
Sep 21 2022
Sep 16 2022
I'll try to read the patch more carefully this weekend.
Sep 13 2022
Thanks, the patch is correct.
But I think we need rework the code to avoid such problem in future, or maybe add some comment, or add inline function like this:
Aug 22 2022
Can you take a look at the errata for 82599 that does report checksum error when card receives IPv4 UDP packets with zero checksum?
I found several discussion (on Opensense and FreeBSD forums) about this problem that appeared visible after this commit. Also, I found this PR. In our case we see noticeable RX errors on machines that handle SNMP traps.
Aug 17 2022
Aug 15 2022
Do you plan add similar support for IPv6? There is ICMP6_PACKET_TOO_BIG with the same meaning. But actually it is not unreach message, thus I'm not sure we should do it.
Jul 14 2022
Jul 7 2022
Good explanation. It would be nice to have something similar somewhere in comments.
Jun 9 2022
Superseded by D30398.
Jun 4 2022
May 19 2022
Apr 18 2022
Apr 11 2022
Apr 6 2022
Apr 4 2022
Apr 1 2022
Mar 2 2022
There are several comments that don't match our style. Those, that are like:
Feb 18 2022
Jan 24 2022
I think you can go through using of some sysctl/tunable first.
I.e. by default system will use old behavior, but you can change it for your system.
Dec 14 2021
In D33227#755751, @bz wrote:Because otherwise your listen socket cannot have protected and unprotected connections; 5 BGP speakers do MD5, 7 don't.
The socket option is the "turn the feature on", the SADB is your policy to whom you do MD5 and to whom you don't.
I have no objection. Just a question. What is the reason behind the accepting of non-signed packets on the socket that we explicitly marked that it must use signatures?
I think this will lead to hiding misconfigurations from the user.
Dec 13 2021
I think the patch needs to be updated to reflect epoch related changes in the vlan code.
We use this patch. But I did not checked is it applicable to recent CURRENT or not.
Dec 2 2021
Nov 24 2021
This looks like leftover from D31271.
Nov 13 2021
Nov 12 2021
Nov 3 2021
In D32810#740413, @bz wrote:This leads to a lot of questions:
(a) can we check for the NULL pointer and gracefully handle it? Or at least add a KASSERT to document it?
Nov 2 2021
Oct 29 2021
It isn't write only variable. At line 501 original IP header can be changed, this variable keeps its copy.
Oct 20 2021
In D32563#735219, @bz wrote:Has anyone checked what this was before the epoch work came in?
Oct 1 2021
Sep 21 2021
LGTM.
Sep 17 2021
Sep 10 2021
Sep 6 2021
Sep 3 2021
Sep 2 2021
Ah, sorry, I committed the fix already..
Aug 26 2021
Aug 25 2021
Aug 24 2021
Aug 17 2021
Aug 13 2021
Aug 6 2021
Aug 5 2021
Jul 16 2021
Jul 15 2021
Jul 5 2021
Jun 28 2021
I have no objection.
Jun 16 2021
In D30764#691856, @markj wrote:p is a union of struct mbuf ** and void *. So wouldn't setting *p.m do the wrong thing if the packet is passed with PFIL_MEMPTR?
Jun 15 2021
I think we can set *p.m unconditionally, like we do in ipfw_check_packet().
Jun 11 2021
The intent of this review was show how we can reduce vlan handling call path. It is not targeted to be included in main stream.