gzclient does not start unless the GAZEBO_IP env variable is set to 127.0.0.1 when a non-running interface is present in the machine

[traversaro]

Describe the bug
gzclient does not start correctly unless the GAZEBO_IP env variable is set to 127.0.0.1 for both gzserver and gzclient.

To Reproduce
I tried to launch https://ms-iot.github.io/ROSOnWindows/Turtlebot/Turtlebot3.html using the the roslaunch turtlebot3_gazebo turtlebot3_gazebo_cartographer_demo.launch command, and the gzclient was opening but instead of the rendererede 3D scene of Gazebo, I only get a white rectangle, as shown in the attached screenshot:

If I call set GAZEBO_IP=127.0.0.1 before calling roslaunch, the Gzclient windows is working correctly:

Expected behavior
I expect that everything works as described in the tutorial without the need to set GAZEBO_IP manually.

Environment information:

• OS version: winver
  Microsoft Windows Version 1709 (OS Build 16299.129)
• Chocolatey Versions: choco list --local-only

C:\Users\STraversaro\source>choco list --local-only
Chocolatey v0.10.11
assimp 4.0.1.1809242322
boost 1.66.0.1809242326
bullet3 2.87.0.1809242326
bzip2 1.0.6.1809242322
cairo 1.15.12.1810221716
ceres 1.14.0.1812111905
chocolatey 0.10.11
clapack 3.2.1.1811082319
console_bridge 0.4.0.1809242322
cppunit 1.12.1.1809242322
cppzmq 4.2.2.1811162207
dlfcn-win32 1.1.1.1811162226
eigen 3.3.4.1809242322
freeglut 3.0.0.1809242322
freeimage 3.17.0.1811160037
gazebo9 9.4.1.1812181926
gflags 2.2.1.1811082321
glog 0.3.5.1811082321
google-mock 1.8.0.1809242326
google-test 1.8.0.1809242322
gtk2 2.22.1.1809242322
hg 4.6.1
ilmbase 2.2.1.1811210800
jasper 2.0.14.1811210919
jxrlib 1.1.0.1811210809
lcms 2.8.0.1811210903
libcurl 7.58.0.1809242322
libflann 1.9.1.1809090720
libgraphviz 2.41.0.1810022039
libjpeg-turbo 1.5.3.1809242322
liblzma 5.2.4.1811210837
libogg 1.3.3.1809090720
libopencv 3.4.1.1809242322
libpcl 1.8.1.1809090720
libpng 1.6.35.1809242322
libraw 0.19.0.1811210804
libtbb-dev 2018.6.0.1812011750
libtheora 1.1.1.1809090720
libwebp 0.6.1.1811210731
log4cxx 0.10.0.1809242322
lua 5.3.4.1810221716
lz4 1.8.1.1809242322
metis 5.1.0.1811082350
ogre 1.10.11.1809100020
openblas 0.2.20.1811082312
openexr 2.2.1.1811210832
openjpeg 2.3.0.1811210736
openssl 1.1.1.1809242322
pkg-config 0.29.2.1809242322
poco 1.8.1.1809242322
protobuf 3.6.1.1811130545
pyqt5 5.10.1.1809242322
pyside2 5.10.1.1809242322
qt5-sdk 5.10.1.1810112239
qwt 6.1.3.1811212304
ros-catkin-tools 0.0.1.1811160029
ros-cmake 3.11.4.1809242322
ros-melodic-cartographer_ros 20181220.1
ros-melodic-desktop 20181220.2
ros-melodic-desktop_full 20181220.2
ros-python2 2.7.15.1809242354
sbcl 0.0.0.1809242326
sdl 1.2.15.1809242322
sdl_image 1.2.12.1809242322
sip 4.19.8.1809242322
suitesparse 1.4.0.1811082321
tiff 4.0.9.1811210742
tinyxml 2.6.2.1809242322
tinyxml2 6.1.0.1809242322
urdfdom 1.0.0.1809242322
urdfdom_headers 1.0.0.1809242322
vcpython27 9.0.30729.1809090720
yaml-cpp 0.5.3.1809242322
zeromq 4.2.5.1811162203
zlib 1.2.11.1809242322
75 packages installed.

C:\Users\STraversaro\source>

Possible fix
See #47 (comment) for a possible fix.

[traversaro]

To investigate a bit the issue, I launched gzserver --verbose running C:\opt\rosdeps\x64\share\gazebo-9\setup.bat after C:\opt\ros\melodic\x64\setup.bat, without setting GAZEBO_IP. The output that I get is:

C:\Users\STraversaro\source>gzserver --verbose
Gazebo multi-robot simulator, version 9.5.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 169.254.220.186

Note that 169.254.220.186 is not a valid IP for any network interface of my laptop, at least according to the ipconfig output:

C:\Users\STraversaro\source>ipconfig

Windows IP Configuration


Wireless LAN adapter Local Area Connection* 11:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : homenet.telecomitalia.it
   Link-local IPv6 Address . . . . . : fe80::4fc:3eae:97f2:440a%2
   IPv4 Address. . . . . . . . . . . : 192.168.1.44
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

Ethernet adapter Bluetooth Network Connection 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . :
   IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:79fd:1833:23e5:b0e1:d102
   Link-local IPv6 Address . . . . . : fe80::1833:23e5:b0e1:d102%5
   Default Gateway . . . . . . . . . : ::

C:\Users\STraversaro\source>

Interestingly, a similar issue was analyized by @jbohren-hbr when tryng to run Gazebo on WSL, see microsoft/WSL#3368 (comment) and microsoft/WSL#3368 (comment). Based on his analysis, I guess something is going wrong for some reason around this call to GetAdaptersAddresses in https://bitbucket.org/seanyen-msft/gazebo/src/7eb033b4c8f891a9385fe2e50ba2db0310077fe9/gazebo/transport/Connection.cc?at=gazebo9_9.5.0_windows&fileviewer=file-view-default#Connection.cc-810 .

[traversaro]

If I understand correctly from a quick internet search (I am not 100% sure), apparently 169.254.*.* addresses are actualy part of APIPA support in Windows ( https://wiki.wireshark.org/APIPA and http://packetlife.net/blog/2008/sep/24/169-254-0-0-addresses-explained/ ), and so they are assigned to adapters that are listed as "Media disconnected" in ipconfig. So the problem is just in Gazebo logic to find the IP of the adapter, and so it is affecting in the same way regular Windows and WSL.

[traversaro]

and so they are assigned to adapters that are listed as "Media disconnected" in ipconfig.

I am not completly sure on that, to be honest. I saw around ( http://www.tomshardware.co.uk/answers/id-3420985/media-disconnected-problem.html ) output of ipconfig in which a network adapter assigned to a 169.254.*.* address is explicitly listed, so probably my assumption that "Media disconnected" adapter have a 169.254.*.* address was false.

[traversaro]

As correctly pointed out in the WSL issue, we probably need a fix similar to https://bitbucket.org/osrf/gazebo/pull-requests/3009/adding-check-to-make-sure-automatic/diff but for the Windows part of the code.

[traversaro]

Based on the similar code contained in ignition-transport (https://bitbucket.org/ignitionrobotics/ign-transport/src/f6f581a6852b0eccc8d9e27c398def9f174ca33a/src/NetUtils.cc#lines-292), I guess we should add

        // The interface is not running.
        if (curr->OperStatus != IfOperStatusUp)
          continue;

before this line https://bitbucket.org/seanyen-msft/gazebo/src/7eb033b4c8f891a9385fe2e50ba2db0310077fe9/gazebo/transport/Connection.cc?at=gazebo9_9.5.0_windows&fileviewer=file-view-default#lines-824 .

Related ign-transport commit: https://bitbucket.org/ignitionrobotics/ign-transport/commits/3d7c03da63806fc39c40547175d4069d1f57a693 .

[seanyen]

@traversaro That's an interesting issue. Did you try to use ipconfig /all to see if 169.254.*.* from any adapters?

I am not able to repro this issue on my end, so I cannot verify the fix. But I rebuilt with your suggested change and published the updated Gazebo9 package. You can do choco upgrade gazebo9 -y to refresh the new bits (9.4.1.1901022119). Let me know if it helps.

[traversaro]

@traversaro That's an interesting issue. Did you try to use ipconfig /all to see if 169.254.. from any adapters?

PS C:\Users\STraversaro> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : IITICUBLAP102
   Primary Dns Suffix  . . . . . . . : iit.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : iit.local
                                       lan

Wireless LAN adapter Local Area Connection* 11:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
   Physical Address. . . . . . . . . : 9E-B6-D0-F1-44-D7
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : lan
   Description . . . . . . . . . . . : Killer Wireless-n/a/ac 1535 Wireless Network Adapter
   Physical Address. . . . . . . . . : 9C-B6-D0-F1-44-D7
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:b07:a96:7ebc:4fc:3eae:97f2:440a(Preferred)
   Temporary IPv6 Address. . . . . . : 2001:b07:a96:7ebc:d5e1:db5c:820b:7a21(Preferred)
   Link-local IPv6 Address . . . . . : fe80::4fc:3eae:97f2:440a%2(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.59(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, January 2, 2019 9:02:40 PM
   Lease Expires . . . . . . . . . . : Thursday, January 3, 2019 10:02:39 PM
   Default Gateway . . . . . . . . . : fe80::a691:b1ff:fe82:18f%2
                                       192.168.1.254
   DHCP Server . . . . . . . . . . . : 192.168.1.254
   DHCPv6 IAID . . . . . . . . . . . : 429700816
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-F3-A8-67-74-DA-38-4A-0B-72
   DNS Servers . . . . . . . . . . . : 2001:b07:a96:7ebc::1
                                       192.168.1.254
   NetBIOS over Tcpip. . . . . . . . : Enabled
   Connection-specific DNS Suffix Search List :
                                       lan

Ethernet adapter Bluetooth Network Connection 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network) #2
   Physical Address. . . . . . . . . : 9C-B6-D0-F1-44-D8
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:79fd:103a:128f:a2d5:e7f9(Preferred)
   Link-local IPv6 Address . . . . . : fe80::103a:128f:a2d5:e7f9%5(Preferred)
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 603979776
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-F3-A8-67-74-DA-38-4A-0B-72
   NetBIOS over Tcpip. . . . . . . . : Disabled
PS C:\Users\STraversaro>

No trace of 169.254.*.*, but to be honest I am connected to a different Wi-Fi network w.r.t. to two days ago.

I am not able to repro this issue on my end, so I cannot verify the fix. But I rebuilt with your suggested change and published the updated Gazebo9 package. You can do choco upgrade gazebo9 -y to refresh the new bits (9.4.1.1901022119). Let me know if it helps.

The updated binary is working fine (no need to set GAZEBO_IP) and the issue seems to be solved, thanks a lot!

[traversaro]

Upstream Gazebo PR: https://bitbucket.org/osrf/gazebo/pull-requests/3079/in-windows-ignore-disabled-interfaces-in/diff .