Re: git: 8338690a0a43 - main - ip_reass: provide sysctl MIB returning IP fragment TTL

> On 21. Aug 2022, at 04:18, Gleb Smirnoff <glebius@FreeBSD.org> wrote:
> 
> On Sun, Aug 21, 2022 at 12:07:39AM +0200, Michael Tuexen wrote:
> M> > commit 8338690a0a43c8b11a382e2160f8eedb9aeecf91
> M> > Author:     Gleb Smirnoff <glebius@FreeBSD.org>
> M> > AuthorDate: 2022-08-20 20:33:39 +0000
> M> > Commit:     Gleb Smirnoff <glebius@FreeBSD.org>
> M> > CommitDate: 2022-08-20 20:39:12 +0000
> M> > 
> M> >    ip_reass: provide sysctl MIB returning IP fragment TTL
> M> > 
> M> >    For now it is read-only, but eventually the cycle that goes over
> M> >    all fragments should be refactored and this MIB should also become
> M> >    read/write.
> M> > 
> M> >    This MIB will allow SNMP daemons to implement MIB-II ipReasmTimeout MIB
> M> >    straightfoward.  Right now net-snmp compilation is broken by 1922eb3e9c2.
> M> >    The base system bsnmpd is not broken just because it ignored PR_SLOWTIMO,
> M> >    and thus always returned incorrectly doubled value for ipReasmTimeout.
> M> > ---
> M> > sys/netinet/ip_reass.c | 4 ++++
> M> > 1 file changed, 4 insertions(+)
> M> > 
> M> > diff --git a/sys/netinet/ip_reass.c b/sys/netinet/ip_reass.c
> M> > index 0420091e0a2a..e581e2e622c7 100644
> M> > --- a/sys/netinet/ip_reass.c
> M> > +++ b/sys/netinet/ip_reass.c
> M> > @@ -167,6 +167,10 @@ SYSCTL_PROC(_net_inet_ip, OID_AUTO, maxfragbucketsize,
> M> >     sysctl_maxfragbucketsize, "I",
> M> >     "Maximum number of IPv4 fragment reassembly queue entries per bucket");
> M> > 
> M> > +static u_int ipfragttl = IPFRAGTTL / 2;
> M> > +SYSCTL_UINT(_net_inet_ip, OID_AUTO, fragttl, CTLFLAG_RD, &ipfragttl,
> M> > +    IPFRAGTTL / 2, "IP fragment life time on reassembly queue");
> M> What unit is used? seconds? milliseconds? You might want to state that.
> M> What us the semantic of IPFRAGTTL? What is the unit of that constant?
> 
> I'll add '(seconds)' to the sysctl description.
Perfect, thank you.
> 
> The semantic of IPFRAGTTL is ugly. It is number of timeouts, which are 0.5
> second. A legacy of PR_SLOWTIMO. This will go away, so is not worth documenting.
Not sure what goes away. IPFRAGTTL or PR_SLOWTIMO. If IPFRAGTTL goes away, everything
is fine. If not, you might change the unit of IPFRAGTTL to seconds an update the
code correspondingly.

Best regards
Michael
> 
> -- 
> Gleb Smirnoff