tunneldigger
tunneldigger copied to clipboard
wlanslovenija
tunneldigger dies somtimes
Original bug report from @Sunz3r under https://github.com/freifunk-gluon/gluon/issues/1188
If internet lost connection (like reboot of router or plug off lan-cable) then the tunneldigger sometime dies.After strace the tunneldigger i found that a assert is triggered: https://github.com/wlanslovenija/tunneldigger/blob/master/client/asyncns.c#L884https://pastebin.com/R6CQmGXr
I was not able to report this bug on there site ...
this bug happens when dns-resolution failed and despite sending data through a socket:
td-client: Failed to send() control packet (errno=89, type=1)!
when dns-resolution suddenly works in this situation then the tunneldigger will crash.
I think there is a bug in the broker selection. The selector should wait for successful address-resolution.
To workaround this bug you can use ip's instead of names.
Have you verified this is still the issue with latest tunneldigger? Because many things around broker selection were improved.
But yes, I think this code path with DNS resolution is less tested because we are not using it ourselves, we have hard-coded IPs.
We are using DNS names and I have not seen this yet. But the issue is not fully reproducible anyway if I understand the report correctly?
Btw, there is an error in the links in the first post, it seems there are two links directly stuck to each other.
I think there is a bug in the broker selection. The selector should wait for successful address-resolution.
I don't follow. Of course it does that, the selector cannot contact a server before address resolution completed.
Isn't this a bug in libasyncns? This is an internal assertion of that library: https://github.com/wlanslovenija/tunneldigger/blob/master/client/libasyncns/asyncns.c#L884
@mitar
Have you verified this is still the issue with latest tunneldigger? Because many things around broker selection were improved.
IIRC Gluon is using the 0.3.0 client. I don't think there were significant changes since then?