Another roaming problem

Toke Høiland-Jørgensen toke at
Fri Mar 9 15:32:20 CET 2018

Toke Høiland-Jørgensen <toke at> writes:

> "Jason A. Donenfeld" <Jason at> writes:
>> On Thu, Mar 8, 2018 at 6:50 PM, Toke Høiland-Jørgensen <toke at> 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

Think it may be related to powersave on the phone or something? Doesn't
seem to happen with my laptop at least...


More information about the WireGuard mailing list