<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">connect-hostname sounds good to me. As an alternative, I was thinking about "bind-hostname".</span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 5:29 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Dec 3, 2014, at 3:28 PM, Oleksiy Vyalov <<a href="mailto:ovyalov@google.com">ovyalov@google.com</a>> wrote:<br>
><br>
> Thank you for suggestions  - let me think this path through.<br>
><br>
> How do you think does it make sense to use value of hostname property as a part of qHostInfo response (instead of real hostname)?<br>
<br>
</span>Yes. Anything that will be doing and reverse connections will need to use this. Not sure if "hostname" is a good name? "connect-hostname"? "reverse-hostname"?<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
> On Wed, Dec 3, 2014 at 10:41 AM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
> We should probably make a global setting in LLDB in Debugger.cpp line 131 where we add a new setting named "hostname" or something else that makes sense. It defaults to not being set, or we can try to populate it with the result of HostInfo::GetHostname(...). Then you can change this if needed to allow reverse connections to succeed.<br>
><br>
> By default, it should do what it does now but it should use the "hostname" (or whatever name we want to name it) setting instead of HostInfo::GetHostname(). If the user changes the setting, then it would get picked up and used.<br>
><br>
> Greg<br>
><br>
> > On Dec 2, 2014, at 5:34 PM, Oleksiy Vyalov <<a href="mailto:ovyalov@google.com">ovyalov@google.com</a>> wrote:<br>
> ><br>
> > Hello,<br>
> ><br>
> > I was playing with LLDB remote debugging and stumbled upon a few network issues. Presumably, such issues may prevent lldb from connecting to debugserver:<br>
> ><br>
> > 1. qLaunchGDBServer takes host's local hostname (like $qLaunchGDBServer;host:ovyalov-linux...;#..), so lldb-platform may pass this hostname to debugserver via command line. As I can see, debugserver uses this hostname for authentication purposes - only incoming connection from this host is allowed. There are a few possible problems here:<br>
> >       • Host's hostname may be just a local network name and in case of debugging over the Internet target cannot resolve it.<br>
> >       • If host has multiple IPs there is no way to figure out which IP will be chosen by host to connect to debugserver (unless lldb has option to specify a local bind address). So, there is a likelihood that such connection will be rejected by debugserver.<br>
> >       • As a variation of previous issue - host and target are on the same machine and connected via remote-* platform as "connect://localhost:some_port". If host binds a socket to any local address excluding 127.0.0.1 - connection is rejected by debugserver.<br>
> >       • If host cannot get his own host name(<a href="https://github.com/llvm-mirror/lldb/blob/ba1d944f0e761c277e6caba23a818b9d2083c40b/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L2838" target="_blank">https://github.com/llvm-mirror/lldb/blob/ba1d944f0e761c277e6caba23a818b9d2083c40b/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L2838</a>) LLDB allows any inbound connection to debugserver. This affects debugging security allowing anybody to connect  debugserver and maybe even broken right now - when platform parses "$qLaunchGDBServer;host:*;"  it treats * as a beginning of RLE sequence and eventually starts debugserver allowing only connections from localhost.<br>
> > Potentially, we may use hash authentication instead of using IP address:<br>
> >  - lldb may generate a random hash which will be sent along with qLaunchGDBServer (instead of host parameter).<br>
> >  - lldb-platform passes auth hash to debugserver via command line.<br>
> >  - debugserver expects to receive new packet with auth hash and verifies that received hash matches the hash provided by platform.<br>
> > Such change will definitely complicates interaction between lldb and debugserver but on other hand will make LLDB networking more robust.<br>
> ><br>
> > As an easier workaround lldb can take local IP address (as a setting option or command line flag) which will be used for outgoing TCP connections (i.e. Socket::TcpConnect will bind to it) and will be sent as a host option of qLaunchGDBServer request. It's still not perfect and won't work in case of debugging over Internet, since most likely remote target will get incoming connection from host's gateway/NAT IP.<br>
> ><br>
> > 2. Another problem that I found that once qLaunchGDBServer succeeded, lldb tries to establish connection to debugserver, but instead of platform connect address a target's host name is used - <a href="https://github.com/llvm-mirror/lldb/blob/f06d448a750ebf88851791237077bb2a665f9784/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp#L486" target="_blank">https://github.com/llvm-mirror/lldb/blob/f06d448a750ebf88851791237077bb2a665f9784/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp#L486</a>. In case of debugging over the Internet, this may not work and it might be a safer option to re-use the platform's address when connecting to debugserver.<br>
> ><br>
> > Please let me know your opinion and whether it sounds reasonable to you.<br>
> ><br>
> > Thank you.<br>
> ><br>
> ><br>
> > --<br>
> > Oleksiy Vyalov | Software Engineer | <a href="mailto:ovyalov@google.com">ovyalov@google.com</a><br>
> > _______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Oleksiy Vyalov | Software Engineer | <a href="mailto:ovyalov@google.com">ovyalov@google.com</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="color:rgb(85,85,85);font-family:sans-serif;line-height:20px;background-color:rgb(255,255,255);border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Oleksiy Vyalov |</span><span style="color:rgb(85,85,85);font-family:sans-serif;line-height:20px;background-color:rgb(255,255,255);border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Software Engineer |</span><span style="color:rgb(85,85,85);font-family:sans-serif;line-height:20px;background-color:rgb(255,255,255);border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:ovyalov@google.com" target="_blank">ovyalov<font color="#1155cc">@google.com</font></a></span></div></div>
</div>