Jason A. Donenfeld <[email protected]> 于2020年5月5日周二 上午6:28写道： > Can you send full networking configuration in enough detail that I'll be > able to reliably reproduce this problem? If I can't reproduce it, it's > unlikely I'll be able to fix it.
I will send full networking configuration to you privately. The configuration works and the problem occured only once. > > Meanwhile, it really really looks from your stacktrace that you have one > wireguard interface going over another wireguard interface: > > [27929.506367] wg_packet_send_staged_packets+0x320/0x5d0 [wireguard] > [27929.506426] wg_xmit+0x324/0x490 [wireguard] > [27929.506469] dev_hard_start_xmit+0x8d/0x1e0 > [27929.506508] __dev_queue_xmit+0x721/0x8e0 > [27929.506549] ip_finish_output2+0x19b/0x590 > [27929.506604] ? nf_confirm+0xcb/0xf0 [nf_conntrack] > [27929.506648] ip_output+0x76/0xf0 > [27929.506681] ? __ip_finish_output+0x1c0/0x1c0 > [27929.506720] iptunnel_xmit+0x174/0x210 > [27929.506761] send4+0x120/0x390 [wireguard] > [27929.506806] wg_socket_send_skb_to_peer+0x98/0xb0 [wireguard] > [27929.506860] wg_packet_tx_worker+0xa9/0x210 [wireguard] > > Here, a wireguard encrypted udp packet is being sent to an endpoint that > then is being routed to a wireguard interface. What in your network > config would make that possible? Maybe some erroneous ip route/rule magic that I don't notice.
