In attempting to troubleshoot a failed ping from the Windows host to the IP address of one Linux guest virtual machine (, I did a traceroute:

$ traceroute
traceroute to (, 30 hops max, 60 byte packets
 1  Samsung.station (  3132.517 ms !H  3132.491 ms !H  3132.489 ms !H

$ ping
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable

$ ping hostname
PING hostname ( 56(84) bytes of data.
From Samsung.station ( icmp_seq=1 Destination Host Unreachable
From Samsung.station ( icmp_seq=2 Destination Host Unreachable

I can ping the host IP ( from the guest. The thing is, I know what I have on my network, but I have no idea what this Samsung.station machine is supposed to be. I've logged onto the Wi-Fi router and cannot identify any device with a "" IP address. I have turned off or disconnected the Wi-Fi of all the few Samsung devices on the network, but I still get the same result.

My end goal is to get the ping working both ways, but now I also would like to know if there is anything I can do to identify this mysterious device! I've seen a related question but I am not yet trying to block devices, I first want to learn what would be the best next step here, before I reboot the router. If someone can confidently say that there are no Linux tools that can help me solve this or gain further information, that is also a valid answer. Thank you.


The host machine is running Windows 10, connected to the network on the built-in Wi-Fi interface.

The virtual machine is on VirtualBox. I have chosen a "Bridged Adapter" intentionally, to get a dedicated DHCP IP address, which makes it easy and convenient to access its local webserver. This setup was working fine on a previous Ubuntu VM, but the VM in question here is a new Debian 11 minimal (no desktop) install.

I have also rebooted the Wi-Fi router, so some things have changed:

  • The Windows host is now at but it shows up on the Wi-Fi router with the "hostname" of the VM! This was likely the same as before the reboot, I probably had just missed the fact that the hostname for the Windows host was not on the list of devices.
  • The VM still reports an IP of But now it also fails to ping the host IP (.16) and traceroute to just shows * * * for all 30 hops.
  • Doing traceroute from the host to the reported guest IP still shows the mysterious hop to the dot 17 IP, but it no longer has the Samsung.station hostname next to it, don't know where that came from before. Here it is:
    $ traceroute
    traceroute to (, 30 hops max, 60 byte packets
     1 (  3121.263 ms !H  3121.242 ms !H  3121.239 ms !H

I would paste the output of ip address from the VM but I don't have clipboard integration working, and even the shared folder which was easy on the previous VM is not visible on this one, so I can't redirect output to a file either.

It's now evident that the root of the connectivity issue seems to be that the bridged adapter failed to get its own DHCP IP from the router's DHCP server, which I likely missed before the reboot due to the VM hostname appearing on the list of Wi-Fi devices on the router.

This turned out to be more of a VirtualBox troubleshooting than anything, apologies for that. I'll probably just assign a fixed IP to the VM. Any tips on the mystery of the unexpected hop would still be interesting.

Second Update

Just remembered that I can use tcpdump to get more information. It's been one of my favorite network troubleshooting tool for years! Will post an update or an answer depending on what I find. Also, I have not restarted Windows yet. Other suggestions are still welcome.

  • It's the first device in the data path. What's the virtualization solution? Is the VM NIC bridged? What does traceroute from the VM show? How exactly is your Win system connecting to the router - using internal Wi-Fi or a dongle? Can you please add the output of ipconfig /all? Please don't answer in a comment, edit your question instead. Oct 5, 2021 at 16:44

2 Answers 2

1 does not exist. is telling you it does not exist. As it is on the same subnet and is the first hop, that suggests that, samsung.station, is the system you are running the traceroute & ping on. Or is acting as proxy and any unknown hostnames will be referred to it. In other words, there is nothing to see here.

  • That's correct, dot19 does not exist on the network, the VM is not telling the truth with ip a. I am wondering where the extra hop is coming from though. I still don't know what dot17 is, it is not the host machine, since it has different IP. Thanks.
    – Nagev
    Oct 5, 2021 at 19:45

TL;DR: The network issue was caused by manually running dockerd on the WSL. Using ip address on the same terminal and tcpdump provided greater clarity.


Things have become clear enough, so I'm sharing my troubleshooting steps, for what it's worth. The accepted answer is absolutely correct, the ping was coming from I had a Windows terminal open and was thinking of the source IP from the Powershell tab, even though I was running the ping from the Ubuntu WSL tab, so that was my mistake. If I do ip a on the WSL terminal I can see an interesting entry:

6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:0b:14:ce:50 brd ff:ff:ff:ff:ff:ff
    inet brd scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:bff:fe14:ce50/64 scope link
       valid_lft forever preferred_lft forever

Note the mystery I've probably seen it before but ignored it because the interface was down and all the noise from all the other interfaces. Indeed I have docker installed on the WSL (with apt, not the Windows version) and I am not sure how it is interacting with the network, but it seems to have given the apparent hop. As for the hostname displayed next to dot17, I've now seen different names shown, so it's clearly some cached name that should be ignored because it's misleading.

It's easier to see the operation in a PCAP file in Wireshark, which I captured with:

sudo tcpdump -i any icmp -w traceroute.pcap

The first packet:

1   0.000000    ICMP    104 Destination unreachable (Host unreachable)

And within ICMP:

Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 1 (Host unreachable)
    Checksum: 0x7313 [correct]
    [Checksum Status: Good]
    Unused: 00000000
    Internet Protocol Version 4, Src:, Dst:
        0100 .... = Version: 4
        .... 0101 = Header Length: 20 bytes (5)
        Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        Total Length: 60
        Identification: 0xa55a (42330)
        Flags: 0x00
        Fragment Offset: 0
        Time to Live: 1
        Protocol: UDP (17)
        Header Checksum: 0x90e3 [validation disabled]
        [Header checksum status: Unverified]
        Source Address:
        Destination Address:
    User Datagram Protocol, Src Port: 36470, Dst Port: 33434

So there is no extra hop. I also noticed that I could ping the target from the Powershell tab, but not from the WSL tab. So I restarted the WSL:

> wsl --list -v
  NAME            STATE           VERSION
* Ubuntu-20.04    Running         2
  Debian          Stopped         2

> wsl --shutdown Ubuntu-20.04

> wsl -d Ubuntu-20.04

Now if I do ip a on the newly started WSL shell, the last entry is:

5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit brd

The docker interface is gone. I can ping from the WSL shell again. Then it hit me: I had started the docker daemon manually with sudo dockerd &, that's when the connectivity broke down! Another point of interest is that the VM is using a bridged interface, and although it has its own IP address and can ping all other devices on the network, it cannot ping the IP of the host machine.

The good news is, I now have docker running on the VM and I can SSH to it from the WSL, or even better, straight from PowerShell, and it all works fine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .