Drop packets in ifconfig

Installing and Using OpenWrt
1

Hello, and thanks for your time. Recently I used the "ifconfig" command and noticed something unusual, many dropped packets on wan interface, but, I am using PPPoE, so, the WAN is the physical interface and PPPoE-WAN is the tunnel one:


pppoe-wan Link encap:Point-to-Point Protocol
          inet addr:79.113.xxx.xxx  P-t-P:10.0.0.1  Mask:255.255.255.255
          inet6 addr: 2a02:2f07:94ff:fxxx::4xxx:xxxx/128 Scope:Global
          inet6 addr: fe80::4f71:713e/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:44818274 errors:0 dropped:38 overruns:0 frame:0
          TX packets:22335690 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:46134551672 (42.9 GiB)  TX bytes:3621200306 (3.3 GiB)

wan       Link encap:Ethernet  HWaddr 10:27:F5:CD:F5:81
          inet6 addr: fe80::1227:f5ff:fecd:f581/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:45417844 errors:0 dropped:598744 overruns:0 frame:0
          TX packets:22336525 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:46532465901 (43.3 GiB)  TX bytes:4112612535 (3.8 GiB)

As you can see, PPPoE has 38 dropped packets, but, WAN has 598744, is this normal or I have problems with cables/hardware? I have FTTH, so Fibre Cable -> Provider Optical Terminal -> UTP Cable -> Router.
What does "drop packets" actually means? I have 0 erros on both intefaces, so, is this alright and the dropped ones are just normal?

2

Try to turn off sw/hw offload or adjust mtu size for wan (for me it looks correct here!). Maybe enable "MSS clamping" to avoid issues. I cannot see this option in firewall settings. But I'm sure it was there in the past. I don't know (I don't use pppoe anymore, so I cannot verify if the option is available for pppoe enabled devices only).

As there are so many reasons for dropped packets you could use tcpdump to investigate further.

Beside that: I have dropped packets here also. They are comming from my ISP's modem searching constantly for smart home devices. In particular here Fritz!Box is searching for those devices supported by the Box itself at a pretty high rate and constantly hitting any device in my network. My routers are just dropping them. You cannot do anything about. No option to disable this behaviour on any Fritz!Box afaik.

3

Thank you for the answer. I already have MSS-Clamping enabled on WAN Zone in firewall, the MTU size is the right one, directly from the ISP when PPPoE session is established as the PPP logs says:

rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x2ce181f2>]

MRU value reported is 1492, so, MTU is the same. Forgot to mention, about two weeks ago I had some problems with the MTU and MTU Path because, for some time, the ISP filtered ICMP packets, as I find out, it was a config error on their servers, it's been solved and now it's working. So, that dropped packets are not errors? Like loss, I tested ping to google.com for 12hrs and in the final I had 0 % packet loss, all packets send were received back. On PPPoE interface, tunnel, I only have 38 dropped, nothing changed, only on the physical one, WAN, it keeps growing.

4

Well, you have to install tcpdump and look into the traffic:

e. g. tcpdump -i not port 22

It is very difficult to track down this as you don't even have any issues. My bet would have been either any smart device search by the ISP modem (what you do not have it seems as I saw after 2nd reading) or a switch in between with e. g. igmp snooping activated.

I would start with tcpdump and let everything idle for like an hour (make sure you don't have any traffic (close browser/apps, choose a linux to watch, windows is causing a lot of traffic)). Then compare drops before and after. If there is a change you have to look into the packets captured. Maybe sth. is catching your eyes. If there is no increase I would try a speedtest with and without SQM to look for issues from the line/provider itself.

You could also question your UTP cable choice. I would have choosen S/FTP at least for such a connection. Smartphones can cause interference.

5

Dropped packets seen with the ifconfig command have been resolved by overflowing the rx buffer with the ethtool command, but the network nic in question must support it.