On 08/13/2018 12:55 AM, Vieri Di Paola via Shorewall-users wrote: > > On Saturday, August 11, 2018, 8:07:36 PM GMT+2, Tom Eastep > <teas...@shorewall.net> wrote: > >> My suggestion for debugging this further is to use a packet sniffer to >> see what is happening on the wire during the period of loss: >> >> a) Are the echo-request packets being sent? >> b) If not, is there unsuccessful ARPing occurring? > > The echo requests are being sent as seen below. > > # tcpdump -i enp9s6 host 8.8.8.8 > dropped privs to tcpdump > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on enp9s6, link-type EN10MB (Ethernet), capture size 262144 bytes > 08:12:18.603636 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 1, length 64 > 08:12:19.642887 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 2, length 64 > 08:12:20.682810 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 3, length 64 > 08:12:21.721237 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 4, length 64 > 08:12:22.762528 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 5, length 64 > 08:12:23.802597 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 6, length 64 > 08:12:24.841126 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 7, length 64 > 08:12:25.881195 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 8, length 64 > 08:12:26.922607 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 9, length 64 > 08:12:27.962655 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 10, length 64 > 08:12:29.001091 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 11, length 64 > 08:12:30.042569 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 12, length 64 > 08:12:31.082581 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 13, length 64 > 08:12:32.122591 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 14, length 64 > 08:12:33.162544 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 15, length 64 > 08:12:33.177647 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 15, length 64 > 08:12:34.171027 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 16, length 64 > 08:12:34.186632 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 16, length 64 > 08:12:35.180972 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 17, length 64 > 08:12:35.196782 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 17, length 64 > 08:12:36.191086 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 18, length 64 > 08:12:36.206656 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 18, length 64 > 08:12:37.201017 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 19, length 64 > 08:12:37.216632 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 19, length 64 > 08:12:38.210990 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 20, length 64 > 08:12:38.226712 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 20, length 64 > 08:12:39.219069 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 21, length 64 > 08:12:39.234713 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 21, length 64 > 08:12:40.229018 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 22, length 64 > 08:12:40.244660 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 22, length 64 > 08:12:41.230962 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo > request, id 4825, seq 23, length 64 > 08:12:41.246677 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo > reply, id 4825, seq 23, length 64 > > The pattern of echo replies failing to arrive is variable. At times, there's > no packet loss, but I frequently get a 10-20-40% packet loss (sometimes even > as high as 65%). > I also noticed (but it's just an impression) that right after rebooting the > modem/router I get no packet loss whatsoever for several hours. > > The shorewall gateway's enp9s6 interface is 100Mbps full duplex, and is > connected to the modem/router which has a built-in 4-port Gbps switch with an > ethernet cable. If I connect a test laptop to that mini switch while I'm > experiencing the packet loss issues on the shorewall box, I can see the same > problems there too. Disconnecting the shorewall gateway ethernet cable from > that 4-port switch, hence making my test laptop the only client device in > the network makes the packet loss issue vanish. Reconnecting the Shorewall > gateway restores the network issues. Again, I'd like to point out that > rebooting the modem/router solves everything for SEVERAL hours (basically > until the next day), no matter what I connect to that 4-port switch. > > I'm wondering if there's a host within Shorewall's LAN that's generating some > sort of traffic that could be directly or indirectly causing this issue > (maybe it does so only on a daily basis and only at night, which would > explain why rebooting the modem/router in the morning fixes my issue for > about 24 hours). > > A full tcpdump was taken on enp9s6 (no filters) while I was pinging 8.8.8.8 > (and noticed missing reply packets even though there were requests). It can > be found here: > > https://drive.google.com/open?id=1TVqiNmlaL4Hu5-I3IDiJpX66vPofHpd9 > > I'd appreciate it if you could let me know if you see anything odd in that > trace. >
The only thing that I see is heavy upload traffic to port 80 at IP address 31.216.144.11. There are no ARP packets in the entire pcap file, so it isn't a problem of the upstream router not being able to determine the L2 address of your gateway. Given that the echo-request packets are being sent, that is about the only thing that your gateway could be involved in that would result in dropped incoming echo-reply packets. There are also some retransmissions of TCP packets going on, but that isn't all that unusual. I think that the next step I would take would be to pick a destination "closer" to your gateway; use 'traceroute' to determine the IP address of the router that is a couple of hops from your gateway and ping that. If you don't see packet loss in those pings, then the problem is likely beyond that router. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
