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