I have a remote system connected via WiFi to the network. The wifi connection is established correctly and I can ping the gateway. The maintainer of the gateway (3rd party, not accessible for me) confirms this. The device is connected, got an IP, firewall is not active for my MAC.

Yet I do not have internet connection. I tested it with ping -I wlan0 and curl --interface wlan0 -XGET http://example.org both resulting in timeouts. I monitored the traffic on wlan0 with tcpdump -i wlan0 and noticed, that up to 100% of the packages are dropped by interface. Clarification: I can see the packets in the tcpdump output, yet ping states 100% packet loss.

My two questions are: Is this the cause for my missing connection? And how can I fix this?

A firewall (iptables / ufw) is not active.

My uname -a output is Linux machine 3.10.104-126 #1 SMP PREEMPT Tue Nov 29 22:24:16 UTC 2016 armv7l armv7l armv7l GNU/Linux

My WiFi interface is a Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter with device ID 0bda:8176


@Lenniey I'm not sure I follow. The connection to the network itself is successful (as I get an IP, DHCP configures gateway dns etc and I can ping the gateway successfully). My device is at (wlan0) and (eth0). I already did a traceroute, it looks like this:

root@device:~# traceroute -i wlan0
traceroute to (, 30 hops max, 60 byte packets
 1 ( 7.069 ms 6.961 ms 6.888 ms
 2 ***
 3 ***
(this continues until traceroute gives up)
30 ***

My routing table is as follows:

root@device:~# route --verbose
Kernel IP routing table
Destination    Gateway          Genmask        Flags  Metric  Ref  Use  Iface
default        UG     100     0    0    eth0
default        UG     600     0    0    wlan0
link-local     *          U      1000    0    0    eth0    *        U      100     0    0    eth0  *        U      600     0    0    wlan0

@Dennis Nolte I assumed the packages are dropped by the interface because tcpdump said so at after stopping the monitoring. The output was like (random numbers due to bad memory)

59 packages captured
59 packages received by filter
 0 packages dropped by kernel
40 packages dropped by interface

The packages dropped by interface ranged between zero and all packages. Kernel never dropped packages in my tests. A wireshark screenshot is not possible as it is a device without a screen attached and I'm not even in the same country as the device. So all my attempts to fix the issue are made via SSH over LAN. But the LAN connection is only temporary for maintenance work, the prod connection will be WiFi.

  • I have to ask...how do you connect to your remote system if the packets are dropped? But for your problem: try a traceroute and have a look at where it's getting killed. I assume it's an error on your provider's gateway (no NAT, wrong routes, or similar). But check you routing table nonetheless, maybe it's wrong. – Lenniey Feb 13 '18 at 15:36
  • how do you know the packets are dropped by the interface? did you actually check f.e. ifconfig for the TX/RX dropped packages? wireshark screenshot might help clarify what you think are packages dropped from the interface. other than that: routing as Lenniey already wrote is a good guess. – Dennis Nolte Feb 13 '18 at 16:05
  • @Lenniey Thanks for your input, I updated the question with traceroute and routing table – DBX12 Feb 14 '18 at 7:22
  • @DennisNolte Thank you for your input too. I updated the question with traceroute and routing table as requested. (I made this second similar comment to notify you as Serverfault only lets me notify one user per comment) – DBX12 Feb 14 '18 at 7:23
  • Well, it looks like the wifi gateway isn't routing your traffic. Either that, or the NAT is broken, or there is a firewall (even if they say there isn't). Some probable causes. – Lenniey Feb 14 '18 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.