> On Oct. 6, 2014, 6:32 p.m., Timothy Chen wrote: > > 3rdparty/libprocess/src/process.cpp, line 1549 > > <https://reviews.apache.org/r/26253/diff/3/?file=714165#file714165line1549> > > > > Does this means the check for 127.0.0.1 never worked? > > > > I know it should since I remember I tested this when I was testing > > Docker bridge networking. > > > > Did you try verifying this actually works?
I've tested the ip value retrieved by getsockname with a small program and checked if it is 16777343 or not [1]. [1] http://pastebin.com/WR3FVCUT - Evelina ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/26253/#review55546 ----------------------------------------------------------- On Oct. 6, 2014, 6:27 p.m., Evelina Dumitrescu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/26253/ > ----------------------------------------------------------- > > (Updated Oct. 6, 2014, 6:27 p.m.) > > > Review request for mesos, Jay Buffington and Vinod Kone. > > > Bugs: MESOS-1835 > https://issues.apache.org/jira/browse/MESOS-1835 > > > Repository: mesos-git > > > Description > ------- > > Getsockname uses network byte order. In the code only the port number is > converted in host order: > > _ip_ = addr.sin_addr.s_addr; > _port_ = ntohs(addr.sin_port); > > So, it is necessary to replace the ip comparison value with 16777343 instead > of 2130706433. > > Doing getsockname after bind would make sense only in the case of __port__ = > 0(when one lets the kernel to choose the port). > > Therefore, the line __ip__ = addr.sin_addr.s_addr; should be removed. > > The __ip__ address can be 0.0.0.0 (for binding on all interfaces) or a > specific __ip__ address(taken from LIBPROCESS_IP and converted in network > order by inet_pton). > In both cases getsockname will retrieve the same __ip__ address as the one > requested fo the bind call. > > Actually, this issue has nothing to do with the machine's endianness. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > d30ed636ee24d0fe6e62f69a921307bde1f32765 > > Diff: https://reviews.apache.org/r/26253/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Evelina Dumitrescu > >
