I changed the route after it was incorrectly changed by net/bind6 and got panic: [emz@taiga:~]# route change -inet6 2001:470:1f09:14c0::/120 -iface vlan22 change net 2001:470:1f09:14c0::/120: gateway vlan22 [emz@taiga:~]# Write failed: Broken pipe panic: sin_family 18 cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 in6_lltable_lookup() at in6_lltable_lookup+0x44d nd6_output_lle() at nd6_output_lle+0x349 nd6_output() at nd6_output+0x18 ip6_output() at ip6_output+0x122f nd6_na_output_fib() at nd6_na_output_fib+0x4fa nd6_ns_input() at nd6_ns_input+0x992 icmp6_input() at icmp6_input+0xb06 ip6_input() at ip6_input+0x8f4 netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x17d ether_nh_input() at ether_nh_input+0x20e netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x86 ether_nh_input() at ether_nh_input+0x20e netisr_dispatch_src() at netisr_dispatch_src+0x152 bce_intr() at bce_intr+0x46a intr_event_execute_handlers() at intr_event_execute_handlers+0x6a ithread_loop() at ithread_loop+0xb4 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff811a901cf0, rbp = 0 --- Uptime: 19d0h34m11s Dumping 1472 out of 4079 MB:panic: Bad tailq NEXT(0xfffffe0002a74160->tqh_last) != NULL cpuid = 2 Uptime: 19d0h34m11s aac0: shutting down controller.... Got a routing table snapshot just before the route was changed: Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2001:470:1f08:14c0::1 UGS gif0 ::1 link#10 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:470:1f08:14c0::1 link#30 UH gif0 2001:470:1f08:14c0::2 link#30 UHS lo0 2001:470:1f09:14c0::/120 fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 2001:470:1f09:14c0::1 link#20 UHS lo0 fd00::/120 fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 fd00::300/120 link#11 U vlan1 fd00::301 link#31 UHS lo0 fd00::316 link#11 UHS lo0 fd00::700/120 link#18 U vlan15 fd00::701 link#32 UHS lo0 fd00::702 link#18 UHS lo0 fd00::d00/120 fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 fd00::b400/120 fe80::21a:64ff:fe21:8e80%vlan1 UG1 vlan1 fd00::b401 fe80::21a:64ff:fe21:8e80%vlan1 UGH1 vlan1 fd00::b40a fe80::21a:64ff:fe21:8e80%vlan1 UGH1 vlan1 fe80::/10 ::1 UGRS lo0 fe80::%bce0/64 link#1 U bce0 fe80::21a:64ff:fec6:a87c%bce0 link#1 UHS lo0 fe80::%lo0/64 link#10 U lo0 fe80::1%lo0 link#10 UHS lo0 fe80::%vlan1/64 link#11 U vlan1 fe80::21a:64ff:fec6:a87c%vlan1 link#11 UHS lo0 fe80::%vlan2/64 link#12 U vlan2 fe80::21a:64ff:fec6:a87c%vlan2 link#12 UHS lo0 fe80::%vlan5/64 link#13 U vlan5 fe80::21a:64ff:fec6:a87c%vlan5 link#13 UHS lo0 fe80::%vlan9/64 link#14 U vlan9 fe80::21a:64ff:fec6:a87c%vlan9 link#14 UHS lo0 fe80::%vlan10/64 link#15 U vlan10 fe80::21a:64ff:fec6:a87c%vlan10 link#15 UHS lo0 fe80::%vlan11/64 link#16 U vlan11 fe80::21a:64ff:fec6:a87c%vlan11 link#16 UHS lo0 fe80::%vlan12/64 link#17 U vlan12 fe80::21a:64ff:fec6:a87c%vlan12 link#17 UHS lo0 fe80::%vlan15/64 link#18 U vlan15 fe80::21a:64ff:fec6:a87c%vlan15 link#18 UHS lo0 fe80::%vlan21/64 link#19 U vlan21 fe80::21a:64ff:fec6:a87c%vlan21 link#19 UHS lo0 fe80::%vlan22/64 link#20 U vlan22 fe80::21a:64ff:fec6:a87c%vlan22 link#20 UHS lo0 fe80::%vlan23/64 link#21 U vlan23 fe80::21a:64ff:fec6:a87c%vlan23 link#21 UHS lo0 fe80::%vlan104/64 link#22 U vlan104 fe80::21a:64ff:fec6:a87c%vlan104 link#22 UHS lo0 fe80::%vlan818/64 link#23 U vlan818 fe80::21a:64ff:fec6:a87c%vlan818 link#23 UHS lo0 fe80::%gif0/64 link#30 U gif0 fe80::21a:64ff:fec6:a87c%gif0 link#30 UHS lo0 fe80::%ng0/64 link#33 U ng0 fe80::21a:64ff:fec6:a87c%ng0 link#33 UHS lo0 fe80::%ng1/64 link#34 U ng1 fe80::21a:64ff:fec6:a87c%ng1 link#34 UHS lo0 ff01::%bce0/32 fe80::21a:64ff:fec6:a87c%bce0 U bce0 ff01::%lo0/32 ::1 U lo0 ff01::%vlan1/32 fe80::21a:64ff:fec6:a87c%vlan1 U vlan1 ff01::%vlan2/32 fe80::21a:64ff:fec6:a87c%vlan2 U vlan2 ff01::%vlan5/32 fe80::21a:64ff:fec6:a87c%vlan5 U vlan5 ff01::%vlan9/32 fe80::21a:64ff:fec6:a87c%vlan9 U vlan9 ff01::%vlan10/32 fe80::21a:64ff:fec6:a87c%vlan10 U vlan10 ff01::%vlan11/32 fe80::21a:64ff:fec6:a87c%vlan11 U vlan11 ff01::%vlan12/32 fe80::21a:64ff:fec6:a87c%vlan12 U vlan12 ff01::%vlan15/32 fe80::21a:64ff:fec6:a87c%vlan15 U vlan15 ff01::%vlan21/32 fe80::21a:64ff:fec6:a87c%vlan21 U vlan21 ff01::%vlan22/32 2001:470:1f09:14c0::1 U vlan22 ff01::%vlan23/32 fe80::21a:64ff:fec6:a87c%vlan23 U vlan23 ff01::%vlan104/32 fe80::21a:64ff:fec6:a87c%vlan104 U vlan104 ff01::%vlan818/32 fe80::21a:64ff:fec6:a87c%vlan818 U vlan818 ff01::%gif0/32 2001:470:1f08:14c0::2 U gif0 ff01::%ng0/32 fe80::21a:64ff:fec6:a87c%ng0 U ng0 ff01::%ng1/32 fe80::21a:64ff:fec6:a87c%ng1 U ng1 ff02::/16 ::1 UGRS lo0 ff02::%bce0/32 fe80::21a:64ff:fec6:a87c%bce0 U bce0 ff02::%lo0/32 ::1 U lo0 ff02::%vlan1/32 fe80::21a:64ff:fec6:a87c%vlan1 U vlan1 ff02::%vlan2/32 fe80::21a:64ff:fec6:a87c%vlan2 U vlan2 ff02::%vlan5/32 fe80::21a:64ff:fec6:a87c%vlan5 U vlan5 ff02::%vlan9/32 fe80::21a:64ff:fec6:a87c%vlan9 U vlan9 ff02::%vlan10/32 fe80::21a:64ff:fec6:a87c%vlan10 U vlan10 ff02::%vlan11/32 fe80::21a:64ff:fec6:a87c%vlan11 U vlan11 ff02::%vlan12/32 fe80::21a:64ff:fec6:a87c%vlan12 U vlan12 ff02::%vlan15/32 fe80::21a:64ff:fec6:a87c%vlan15 U vlan15 ff02::%vlan21/32 fe80::21a:64ff:fec6:a87c%vlan21 U vlan21 ff02::%vlan22/32 2001:470:1f09:14c0::1 U vlan22 ff02::%vlan23/32 fe80::21a:64ff:fec6:a87c%vlan23 U vlan23 ff02::%vlan104/32 fe80::21a:64ff:fec6:a87c%vlan104 U vlan104 ff02::%vlan818/32 fe80::21a:64ff:fec6:a87c%vlan818 U vlan818 ff02::%gif0/32 2001:470:1f08:14c0::2 U gif0 ff02::%ng0/32 fe80::21a:64ff:fec6:a87c%ng0 U ng0 ff02::%ng1/32 fe80::21a:64ff:fec6:a87c%ng1 U ng1 How-To-Repeat: Don't know if it's repeatable.
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
Actually it's repeatable. There's a bug in net/bird6 (and net/bird), both aren't directly related to this bug, but bird for some reason doesn't honor on-interface routes and can delete them, so I have to add a filter so it won't do it again and then restore the on-interface route by hand. And in this moment FreeBSD panics. One more panic: panic: sin_family 18 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 in6_lltable_lookup() at in6_lltable_lookup+0x44d nd6_output_lle() at nd6_output_lle+0x349 nd6_output() at nd6_output+0x18 ip6_output() at ip6_output+0x122f tcp_output() at tcp_output+0x12c7 tcp_usr_shutdown() at tcp_usr_shutdown+0xf8 sys_shutdown() at sys_shutdown+0x75 amd64_syscall() at amd64_syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (134, FreeBSD ELF64, sys_shutdown), rip = 0x801fee65c, rsp = 0x7fffffffd728, rbp = 0x7fffffffd970 --- Uptime: 43m28s Dumping 545 out of 4079 MB:panic: Bad tailq NEXT(0xfffffe0002a74160->tqh_last) != NULL cpuid = 1 Uptime: 43m28s aac0: shutting down controller...
Responsible Changed From-To: freebsd-net->ae Take it.
Hi, Eugene, it seems I found how this KASSERT can be triggered. The ip6_output function has this part of code: routefound: if (rt && !IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) { if (opt && opt->ip6po_nextroute.ro_rt) { /* * The nexthop is explicitly specified by the * application. We assume the next hop is an IPv6 * address. */ dst = (struct sockaddr_in6 *)opt->ip6po_nexthop; } else if ((rt->rt_flags & RTF_GATEWAY)) dst = (struct sockaddr_in6 *)rt->rt_gateway; } There a dst pointer can be changed to the rt->rt_gateway, that in your case has non IPv6 address. Then, the nd6_output_lle() does lla_lookup() for this address and it triggers KASSERT when INVARIANTS is enabled. Not sure that this is a correct fix, but I think, it should work like when INVARIANTS is disabled. You can try attached patch. -- WBR, Andrey V. Elsukov
Hi, it seems the previous patch is wrong and this KASSERT will be triggered again via the nd6_storelladdr() function. So, can you please try this patch? -- WBR, Andrey V. Elsukov
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped