NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/60071: The kernel stop sending ARP/NS packets on ping/ping6



The following reply was made to PR kern/60071; it has been noted by GNATS.

From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/60071: The kernel stop sending ARP/NS packets on ping/ping6
Date: Thu, 19 Mar 2026 14:34:11 +0900

 On Thu, Mar 12, 2026 at 1:20=E2=80=AFPM ozaki-r%iij.ad.jp@localhost via gnats
 <gnats-admin%netbsd.org@localhost> wrote:
 >
 > >Number:         60071
 > >Category:       kern
 > >Synopsis:       The kernel stop sending ARP/NS packets on ping/ping6
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Thu Mar 12 04:20:00 +0000 2026
 > >Originator:     Ryota Ozaki
 > >Release:        current, 11, 10
 > >Organization:
 > IIJ
 > >Environment:
 > NetBSD kvm 11.99.5 NetBSD 11.99.5 (KVM) #32: Thu Mar 12 11:48:45 JST 2026=
   (hidden) amd64
 > >Description:
 > ping(8) with no option sends ICMP echo requests periodically.  If a targe=
 t host is not available, the kernel keeps sending ARP packets per the ICMP =
 packets.  This is probably the typical and expected behavior.  NetBSD 9, Ne=
 tBSD 8, FreeBSD 11 and Linux 6.0 acts like so.
 >
 > However, recent NetBSD kernels (10~) stop sending ARP packets at most net=
 .inet.arp.nd_bmaxtries times.
 >
 > ping6 (IPv6 NS) is the same situation.
 > >How-To-Repeat:
 > Run tcpdump on a host (or another host in the same network) and ping to a=
  nonexistence host from the host, and see tcpdump's outputs.
 > >Fix:
 > One possible fix:
 >
 > @@ -361,10 +361,6 @@ nd_resolve(struct llentry *ln, const struct rtentry =
 *rt, struct mbuf *m,
 >          * does not exceed maxqueuelen.  When it exceeds maxqueuelen,
 >          * the oldest packet in the queue will be removed.
 >          */
 > -       if (ln->ln_state =3D=3D ND_LLINFO_NOSTATE ||
 > -           ln->ln_state =3D=3D ND_LLINFO_WAITDELETE)
 > -               ln->ln_state =3D ND_LLINFO_INCOMPLETE;
 > -
 >  #ifdef MBUFTRACE
 >         m_claimm(m, ln->lle_tbl->llt_mowner);
 >  #endif
 > @@ -406,6 +402,12 @@ nd_resolve(struct llentry *ln, const struct rtentry =
 *rt, struct mbuf *m,
 >         else
 >                 error =3D EWOULDBLOCK;
 >
 > +       if (ln->ln_state =3D=3D ND_LLINFO_NOSTATE ||
 > +           ln->ln_state =3D=3D ND_LLINFO_WAITDELETE) {
 > +               ln->ln_asked =3D 0;
 > +               ln->ln_state =3D ND_LLINFO_INCOMPLETE;
 > +       }
 > +
 >         /*
 >          * If there has been no NS for the neighbor after entering the
 >          * INCOMPLETE state, send the first solicitation.
 >
 
 I've updated the possible fix:
 https://www.netbsd.org/~ozaki-r/fix-nd_resolve.diff
 The new diff is even closer to the old behavior; if unresolved, an error is
 constantly returned to the caller.
 
   ozaki-r
 



Home | Main Index | Thread Index | Old Index