My setup is as follows:
$ ping 192.168.1.251 PING 192.168.1.251 (192.168.1.251) 56(84) bytes of data. From 192.168.1.22 icmp_seq=1 Destination Host Unreachable From 192.168.1.22 icmp_seq=2 Destination Host Unreachable From 192.168.1.22 icmp_seq=3 Destination Host Unreachable ^C --- 192.168.1.251 ping statistics --- 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 80ms pipe 4
Both under Windows 10 and Debian 10, are the interfaces configured in the same way, i.e. they both have the same static IP Address (192.168.1.22) and the same Subnet Mask (255.255.255.0).
ARP can see that the device ( with the IP Address 192.168.1.251) is there as well.
$ sudo arp-scan 192.168.1.251 Interface: enp0s25, datalink type: EN10MB (Ethernet) Starting arp-scan 1.9.5 with 1 hosts (https://github.com/royhills/arp-scan) 0 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.9.5: 1 hosts scanned in 2.538 seconds (0.39 hosts/sec). 0 responded
And if I connect and disconnect the cable, I can see that indeed on this interface on which I am trying to ping the device from, the "link connected" turns to "yes" and "no".
$ sudo ethtool enp0s25 Settings for enp0s25: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes
Question: So why could it be that I cannot ping the device from Debian 10, but from Windows 10 I can hassle free? I have been fighting with this for over 3~4 hours now testing all possible permutations and combinations that I could think of.
p.s. I can even ping the device successfully from a Linux VM running on the Windows 10 host (just saying, in case if that adds any info) but not from the Linux installed directly on the bare-metal.
UPDATE/EDIT:
As per the feedback from the comments, I did the following tests:
$ traceroute -UL 192.168.1.251
traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets
1 192.168.1.252 (192.168.1.252) 3070.385 ms !H 3070.330 ms !H 3070.314 ms !H
It succeeded ... ultimately. It took ~3 sec (meh! why?).
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s25
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s25
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
$ ping -r 192.168.1.251
PING 192.168.1.251 (192.168.1.251) 56(84) bytes of data.
From 192.168.1.252 icmp_seq=1 Destination Host Unreachable
From 192.168.1.252 icmp_seq=2 Destination Host Unreachable
From 192.168.1.252 icmp_seq=3 Destination Host Unreachable
From 192.168.1.252 icmp_seq=4 Destination Host Unreachable
From 192.168.1.252 icmp_seq=5 Destination Host Unreachable
From 192.168.1.252 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.251 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 147ms
pipe 4
Then I proceeded to rebooting the laptop into Windows 10 and starting the Ubuntu 18.04 LTS Virtual Machine.
# ping 192.168.1.251
Pinging 192.168.1.251 with 32 bytes of data:
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Reply from 192.168.1.251: bytes=32 time<1ms TTL=255
Ping statistics for 192.168.1.251:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
$ ping 192.168.1.251
PING 192.168.1.251 (192.168.1.251) 56(84) bytes of data.
64 bytes from 192.168.1.251: icmp_seq=1 ttl=255 time=0.459 ms
64 bytes from 192.168.1.251: icmp_seq=2 ttl=255 time=0.561 ms
64 bytes from 192.168.1.251: icmp_seq=3 ttl=255 time=0.385 ms
64 bytes from 192.168.1.251: icmp_seq=4 ttl=255 time=0.428 ms
^C
--- 192.168.1.251 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3066ms
rtt min/avg/max/mdev = 0.385/0.458/0.561/0.066 ms
$ traceroute -UL 192.168.1.251
traceroute to 192.168.1.251 (192.168.1.251), 30 hops max, 60 byte packets
1 192.168.1.251 (192.168.1.251) 0.594 ms !P 0.527 ms !P 0.497 ms !P
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.3.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 virbr0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s9
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
Last word: I have not setup any special firewalls or iptable rules on the Debian 10 installed on the laptop. This is a standard/default installation with of course other user packages installed as required (but no special network configuration done.)
EDIT 2: So, after the recent comments, I followed this and this to disable any "firewall" or iptable rules, that might be blocking the pings (Actually ping is just one of the symptoms. There is a server on the PC side which also cannot communicate with the network device, which was my original problem.)
Here is what I tried, and here is what are the results:
ufw
or nftables
or firewalld
are not installed. Also I have no host.deny
file.$ sudo ufw status
sudo: ufw: command not found
$ sudo nftables
sudo: nftables: command not found
$ cat /etc/host.deny
cat: /etc/host.deny: No such file or directory
$ sudo systemctl disable firewalld
Failed to disable unit: Unit file firewalld.service does not exist.
$ sudo firewall-cmd --state
sudo: firewall-cmd: command not found
iptables
we look. Interesting to find all these entries for iptable:$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:67
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
Chain DOCKER (1 references)
target prot opt source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
We see some rules, some for Docker and some in general. I have no idea what those rules and settings are doing, but let's just nuke them away and disable all controls (just for test purposes - to see if something works). In order to achieve that, I took the following steps (literally copied from one of the links mentioned above):
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
This resulted in some nice looking iptable
configuration as shown below.
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ping
still fails and traceroute
still takes ~3000+ milliseconds.I am starting to suspect the network-manager
service on debian 10 is somehow responsible as that is the only thing different between the bare-metal installation of the debian 10 on the laptop and the ubuntu 18.04 virtual machine running on windows 10 from which I had no problem pinging the device.)
Bonus info: I have another Virtual Machine with Debian 6 running on top of Windows 10 and even that can ping the network device.
Edit 3:
nmap can find the host.
nmap -Pns 192.168.1.200/32
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-21 14:42 CET
Nmap scan report for 192.168.1.200
Host is up (0.062s latency).
All 1000 scanned ports on 192.168.1.200 are filtered
Nmap done: 1 IP address (1 host up) scanned in 5.90 seconds
So after almost a year of not following up on this, I ended up trying a dozen different things today, and scouring the different linux distro forums, I finally struck gold here.
After doing the following, I could successfully ping (keeping my fingers crossed that it stays that way, but for the moment things look good).
From here, I tried this.
sudo lshw -C network
Which showed me what hardware I have for that ethernet port.
*-network
description: Ethernet interface
product: Ethernet Connection I217-LM
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: enp0s25
version: 04
serial: 70:5a:df:b9:a7:47
size: 100Mbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=0.13-4 ip=192.168.1.34 latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
resources: irq:31 memory:d2100000-d211ffff memory:d213a000-d213afff ioport:6040(size=32)
I downloaded the latest driver from intel.
cp e1000e-3.0.4.tar.gz /usr/local/src/
cd /usr/local/src/
tar xzvf e1000e-3.0.4.tar.gz
rmmod e1000e
apt-get install linux-headers-amd64
cd e1000e-3.0.4/src/
make install
Rebooted and bam! pings and all work! Sometimes to get things to work, you just have to do them yourself.
The idea that put me on this track is that, I could ping and do nearly everything over the other ethernet port (which is not a real ethernet port really. It's a USB Dongle, but that's besides the point.) but on the ethernet port itself, nothing worked (except somehow the traceroute and nmap got through I don't know how).
It may have been that 3~4 years ago when I installed debian on this laptop (next to Windows 10), "Fast Boot" was maybe active in BIOS and maybe the ethernet drivers did not get installed or something. Maybe!
FEEDBACK/UPDATE AFTER A COUPLE OF WEEKS:
After observing this for a couple of weeks now, this works only intermittently for some reason. It worked but then it stopped working. And then today it has started working again. It could be that the real problem lies somewhere else. One thing I did do today differently was I turned of "Automatically Connect" from the Network Manager. Maybe that makes a difference?
User contributions licensed under CC BY-SA 3.0