Toke Høiland-Jørgensen <[email protected]> writes:
> "Jason A. Donenfeld" <[email protected]> writes:
>
>> On Thu, Mar 8, 2018 at 6:50 PM, Toke Høiland-Jørgensen <[email protected]> wrote:
>>> Well, I do generally setup routing in a somewhat unusual manner.
>>>
>>> I can try to capture some packet dumps tomorrow to poke into it a bit more.
>>> Anything in particular I should look for?
>>
>> One thing to examine is when WireGuard calls
>> `socket_clear_peer_endpoint_src'. This makes wireguard forget the
>> source address that it should be using and fall back to the default.
>> You could add a pr_info(...) call in this function. I have an inkling
>> that I make calls to this function too zealously and in potentially
>> unneeded places, such as on handshake transmission retries.
>>
>> I'm headed out of town super soon, so likely debugging this will have
>> to wait until I'm back, but do let me know what you find, and we'll
>> get this fixed up upon return.
>
> Well, completely failed to reproduce it; everything works as its
> supposed to now (wireguard correctly picks the public IP as its source
> address when replying to the client).
>
> Not sure if I have changed something in my setup or what is going on;
> but at least I can roam now, so I'm happy ;)
Scratch that, it's still happening; just not straight away upon roaming.
It is definitely a timeout thing; installed a kprobe on the function you
mentioned and got this strack trace when it switches IP:
TIME(s) FUNCTION
104.999884129 socket_clear_peer_endpoint_src
socket_clear_peer_endpoint_src
expired_new_handshake
call_timer_fn
run_timer_softirq
__do_softirq
irq_exit
smp_apic_timer_interrupt
__irqentry_text_start
cpuidle_enter_state
do_idle
cpu_startup_entry
start_secondary
secondary_startup_64
Think it may be related to powersave on the phone or something? Doesn't
seem to happen with my laptop at least...
-Toke
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
