On Tue, Jul 04, 2017 at 02:25:25PM +0900, Kengo NAKAHARA wrote:
> Hi,
>
> Thank you for your quick and detailed reply.
>
> On 2017/07/03 12:30, Dominik Bialy wrote:
> > On Sun, Jul 02, 2017 at 11:35:01PM +0000, Kengo NAKAHARA wrote:
> >> The following reply was made to PR kern/52353; it has been noted by GNATS.
> >>
> >> From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
> >> To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
> >> netbsd-bugs%netbsd.org@localhost
> >> Cc:
> >> Subject: Re: kern/52353: [netbsd-8] A crash in icmpv6 code (?)
> >> Date: Mon, 3 Jul 2017 08:33:32 +0900
> >>
> >> Hi,
> >>
> >> On 2017/07/01 22:40, dmb%yenn.ulegend.net@localhost wrote:
> >> > System: NetBSD yenn 8.0_BETA NetBSD 8.0_BETA (YENN) #6: Mon Jun 26 08:49:07 UTC 2017 builds@yenn:/var/obj/sys/arch/amd64/compile/YENN amd64
> >>
> >> It seems you use other than GENERIC kernel config.Could you show your
> >> kernel config?
> >>
> > It is almost GENERIC with: GATEWAY, and altq* options added. The setup
> > is somewhat unusual, since I'm using ipf+pf+the old altq
> >
> > Here's the config:
> >
> > http://yenn.ulegend.net/~dmb/YENN
> >
> > Here's dmesg.boot:
> >
> > http://yenn.ulegend.net/~dmb/dmesg.boot
> >
> > (The panic in this dmesg is probably unrelated.)
> >
> > In altq I'm using WFQ over a 0.75 Mbps uplink.
> >
> >> > Architecture: x86_64
> >> > Machine: amd64
> >> >> Description:
> >> > yenn# crash -M netbsd.3.core -N netbsd.3
> >> > Crash version 8.0_BETA, image version 8.0_BETA.
> >> > System panicked: in6_cksum: mbuf too short for IPv6 header
> >> > Backtrace from time of crash is available.
> >> > crash> bt
> >> > _KERNEL_OPT_NARCNET() at 0
> >> > ?() at fffffe80a11bcc00
> >> > vpanic() at vpanic+0x149
> >> > snprintf() at snprintf
> >> > in6_cksum() at in6_cksum+0x1a2
> >> > _icmp6_input() at _icmp6_input+0xb4
> >> > wqinput_work() at wqinput_work+0x88
> >> > workqueue_worker() at workqueue_worker+0xbc
> >> >
> >> > yes, IPv6 is via gif(4), but _before_ the patch for MP-fy
> >> >> How-To-Repeat:
> >> > possibly ping the machine for some time (?) with IPv6 on a gif(4) (?)
> >>
> >> Which do you use IPv6 over IPv6 or IPv6 over IPv4?
> >>
> > IPv6 over IPv4 -- he.net tunnelbroker
>
> Hmm, I guess there may be the issue in combination ALTQ and gif(4).
> So, I try to reproduce it in my simple environment. That is,
> - use two NetBSD-8 machine and connect directly their ethernet ports
> - create IPv6 over IPv4 gif(4) between the two machines
> - apply below WFQ to the gif(4) psrc, pdst ethernet
> ====================
> interface wm2 bandwidth 750000 wfq
> ====================
> - ping6 over gif(4) each other
> However, I cannot reproduce it yet...
>
> By the way, ozaki-r@n.o help me to research this issue. He also implements
> a patch. Could you try below patch?
> ====================
> diff --git a/sys/netinet6/icmp6.c b/sys/netinet6/icmp6.c
> index f740932036d..3b45ba8d785 100644
> --- a/sys/netinet6/icmp6.c
> +++ b/sys/netinet6/icmp6.c
> @@ -494,6 +494,15 @@ _icmp6_input(struct mbuf *m, int off, int proto)
> goto freeit;
> }
>
> + if (m->m_len < sizeof(struct ip6_hdr)) {
> + m = m_pullup(m, sizeof(struct ip6_hdr));
> + if (m == NULL) {
> + ICMP6_STATINC(ICMP6_STAT_TOOSHORT);
> + icmp6_ifstat_inc(rcvif, ifs6_in_error);
> + goto freeit;
> + }
> + }
> +
> ip6 = mtod(m, struct ip6_hdr *);
> IP6_EXTHDR_GET(icmp6, struct icmp6_hdr *, m, off, sizeof(*icmp6));
> if (icmp6 == NULL) {
> ====================
>
> If the issue is reproduced after applying above patch, could you tell
> me your detailed network configuration and ipf/pf setting?
> Of course, within the range you can show with no problem.
>
OK, then I applied the patch, and I'm pinging the machine
for quite some time. The uptime is almost 2 days.
Close the PR? When it'd be needed it could be reopened again, no?
Dominik
Attachment:
signature.asc
Description: PGP signature