https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283426
Bjoern A. Zeeb <b...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|wireless@FreeBSD.org |n...@freebsd.org
Summary|panic in |panic in
|sbappendaddr_locked() |sbappendaddr_locked() -
| |if_ovpn related?
CC| |k...@freebsd.org
--- Comment #12 from Bjoern A. Zeeb <b...@freebsd.org> ---
(In reply to Robin Haberkorn from comment #11)
Yes I understand why the question was for the original one; I just wanted to
understand as the "copy" should have it too then and when manually going up the
stack I couldn't spot where it might be cleared.
I wonder what Dan Epure's report looked like, Glebius? Do you have a backtrace
from that? Same code paths? Also UDP? Also ovpn loaded?
I don't know how the openvpn kernel module is hooking into the input path; if
it's using u_tun_func then that at least would explain why we do not see it in
the backtrace. And then Takahiro Kurosawa's analysis from #c7 sounds fairly
valid if m_unshare can lose the PKTHDR on the copy. OpenVPN doesn't have to be
active; it seems if there's an interface the filtering function will be hooked
up. And then it's not a regression in iwm or the network stack; then it's
imply the feature.
Adding Kristof and bouncing this back to net@.
--
You are receiving this mail because:
You are the assignee for the bug.
