lose the WAN connection
-
Dear all,
Every so often I lose the WAN connection.
Can you please help me?Best regards,
MiguelHere’s some information:
#Gateways log
Jul 31 09:37:53 dpinger WAN_DHCP 8.8.8.8: Clear latency 17426us stddev 293us loss 14%
Jul 31 09:40:55 dpinger WAN_DHCP 8.8.8.8: Alarm latency 17541us stddev 189us loss 21%
Jul 31 09:45:19 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm
Jul 31 09:45:21 dpinger WAN_DHCP 8.8.8.8: Alarm latency 0us stddev 0us loss 100%#My system
Pfsense 2.4.5-RELEASE-p1 (amd64)
AMD Athlon(tm) 7750 Dual-Core Processor
fiber WAN 1000baseT <full-duplex
Memory, CPU and disk usage is ok
ISP modem/router in bridge mode#Packet capture
10:16:17.469909 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3145, length 9
10:16:17.487456 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3145, length 9
10:16:17.995388 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3146, length 9
10:16:18.013037 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3146, length 9
10:16:18.497254 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3147, length 9
10:16:18.514627 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3147, length 9
10:16:19.009140 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3148, length 9
10:16:19.026589 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3148, length 9
10:16:19.539134 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3149, length 9
10:16:19.556667 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3149, length 9
10:16:20.071394 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3150, length 9
10:16:20.088743 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3150, length 9
10:16:20.599140 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3151, length 9
10:16:20.616822 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3151, length 9
10:16:21.058432 IP 109.51.46.194.26946 > 162.208.119.38.53: UDP, length 49
10:16:21.060892 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 78
10:16:21.060899 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 39
10:16:21.060905 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 92
10:16:21.077313 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
10:16:21.077331 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
10:16:21.077437 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
10:16:21.077812 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 39
10:16:21.103174 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 66
10:16:21.103181 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 118
10:16:21.103297 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 31
10:16:21.103303 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 39
10:16:21.103611 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
10:16:21.103617 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
10:16:21.104865 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 39
10:16:21.126288 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
10:16:21.126309 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3152, length 9
10:16:21.143899 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3152, length 9
10:16:21.173512 IP 162.208.119.38.53 > 109.51.46.194.26946: UDP, length 105
10:16:21.173640 IP 109.51.46.194.48542 > 208.123.73.80.53: UDP, length 44
10:16:21.214104 IP 109.51.46.194.23339 > 162.208.119.38.53: UDP, length 44
10:16:21.322800 IP 208.123.73.80.53 > 109.51.46.194.48542: UDP, length 101
10:16:21.322867 IP 109.51.46.194.5942 > 162.208.119.38.53: UDP, length 50
10:16:21.327798 IP 162.208.119.38.53 > 109.51.46.194.23339: UDP, length 101
10:16:21.327874 IP 109.51.46.194.49450 > 162.208.119.38.53: UDP, length 50
10:16:21.437989 IP 162.208.119.38.53 > 109.51.46.194.5942: UDP, length 82
10:16:21.439561 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
10:16:21.440180 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
10:16:21.440984 IP 162.208.119.38.53 > 109.51.46.194.49450: UDP, length 82
10:16:21.441042 IP 109.51.46.194.39754 > 162.208.119.38.53: UDP, length 50
10:16:21.551172 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 0
10:16:21.551612 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
10:16:21.551985 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 517
10:16:21.554170 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 0
10:16:21.554483 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
10:16:21.554983 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 517
10:16:21.555669 IP 162.208.119.38.53 > 109.51.46.194.39754: UDP, length 82
10:16:21.658578 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3153, length 9
10:16:21.666485 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
10:16:21.666607 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
10:16:21.666614 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1345
10:16:21.667296 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
10:16:21.670668 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 126
10:16:21.671168 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 681
10:16:21.672479 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 1460
10:16:21.672603 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 1460
10:16:21.672610 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 1345
10:16:21.673292 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
10:16:21.675036 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 126
10:16:21.675977 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3153, length 9
10:16:21.782043 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 51
10:16:21.783168 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 515
10:16:21.783981 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
10:16:21.788602 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 78
10:16:21.788608 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 93
10:16:21.789663 IP 162.208.119.41.443 > 109.51.46.194.63611: tcp 51
10:16:21.789726 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 682
10:16:21.805032 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
10:16:21.805154 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
10:16:21.830141 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 66
10:16:21.830148 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 120
10:16:21.830265 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 31
10:16:21.830390 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 39
10:16:21.830453 IP 109.51.46.194.63611 > 162.208.119.41.443: tcp 0
10:16:21.830577 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
10:16:21.830701 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 0
10:16:21.831946 IP 109.51.46.194.47651 > 172.217.16.238.443: tcp 39
10:16:21.853251 IP 172.217.16.238.443 > 109.51.46.194.47651: tcp 0
10:16:21.904727 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
10:16:21.904737 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
10:16:21.904743 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 188
10:16:21.905905 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
10:16:21.947391 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
10:16:22.143154 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 552
10:16:22.143388 IP 109.51.46.194.123 > 195.22.17.7.123: UDP, length 48
10:16:22.153584 IP 195.22.17.7.123 > 109.51.46.194.123: UDP, length 48
10:16:22.190830 IP 109.51.46.194 > 8.8.8.8: ICMP echo request, id 29005, seq 3154, length 9
10:16:22.208555 IP 8.8.8.8 > 109.51.46.194: ICMP echo reply, id 29005, seq 3154, length 9
10:16:22.254776 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 1460
10:16:22.254785 IP 162.208.119.41.443 > 109.51.46.194.42355: tcp 320
10:16:22.256092 IP 109.51.46.194.42355 > 162.208.119.41.443: tcp 0
10:16:22.327804 IP 109.51.46.194.10328 > 13.225.247.219.443: tcp 71
10:16:22.327811 IP 109.51.46.194.10328 > 13.225.247.219.443: tcp 46
10:16:22.337355 IP 13.225.247.219.443 > 109.51.46.194.10328: tcp 0
10:16:22.337480 IP 13.225.247.219.443 > 109.51.46.194.10328: tcp 0
10:16:22.337730 IP 13.225.247.219.443 > 109.51.46.194.10328: tcp 46 -
@LMM said in lose the WAN connection:
Can you please help me?
Yeah.
You are aware what the process 'dpinger' does ? What happens when the IP, where it sends ICMP packets to, isn't answering any more ? dpinger deducts that the connection is bad, and pulls the plug = resetting the WAN interface.You already know what "8.8.8.8" is, and guess what : replying to ping isn't it's main purpose. When "8.8.8.8" gets overworked, it will start to dropping non significant traffic, like the millions of ICMP (ping) request/replies.
The resultant will be : your WAN goes down for a reason that has nothing to do with your connection.
My advise is : use a more close to you IP to test against, typically an upstream gateway.
Note : still, if something goes bas on your direct uplink connection, then you will see the same ICMP packets from Google not coming back neither. That 's why you should choose an IP 'to ping' as close as possible.
Also, your ISP maintain your uplink and the quality of it. You, as a client, can't do nothing more as "notifying" them.
-
Thank you very much for your clear explanation.
If I understand well, I must change my WAN Monitor IP to a closer one to me.
So, in "Monitor IP Interface WAN_DHCP Gateway" , I change the IP address to 109.51.0.1Let me see how it behaves.
Thank you very much again.
Best regards,
Miguel -
The result, after 2 hours
Aug 2 11:37:04 dpinger WAN_DHCP 109.51.0.1: Alarm latency 9593us stddev 249us loss 21%
Aug 2 11:38:33 dpinger WAN_DHCP 109.51.0.1: Clear latency 9628us stddev 264us loss 9%
-
You saw the monitor graph called Quality - select the WAN interface ?
It's probably your direct uplink, which mans : only your ISP can help you.
-
Thank you for your support.
I will check the wan quality graph and report to my ISP.
Do you know why the router provided by them, don't lose the connection? Is their equipment prepared to accept the "bad" connection quality?Best regards