Цитата: Sadler от 21/07/2020, 19:41

Это просто информационные сообщения о завершении подключения, они не связаны с какими-то ошибками. Вот обсуждение на форуме nginx: https://forum.nginx.org/read.php?2,1680,1680

Цитата: AndryRV от 21/07/2020, 19:47

а почему именно в эти моменты у меня подключение по kerio обрывается?

Цитата: Sadler от 21/07/2020, 20:41

Конечно, если соединение обрывается, то сессии nginx тоже будут отваливаться, но сообщения такие могут появляться и при исправном соединении, так что сами по себе мало о чём говорят. "entered promiscuous mode" может быть связано с переходом на страницу "диагностика сети", в таком случае это тоже нормальное поведение.

Цитата: AndryRV от 21/07/2020, 21:35

Хорошо, а в каком направлении мне тогда копать, чтобы уменьшить обрывы. сегодня у меня 6 раз kerio обрывалось. у жены при таком же подключении, но она сидит ближе к роутеру, обрывов не было судя по логам, т.к. в них только мой ip.

[spoiler]

Jul 21 08:18:14 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=4 to 5GHz AP a8:6d:aa:7d:1f:cc, WNM supported, PMF connect (WPA2PSK/AES)
Jul 21 08:18:14 udhcpd[22796]: sending ACK to 192.168.1.13
Jul 21 08:30:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 08:40:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 08:47:16 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=5 to 5GHz AP a8:6d:aa:76:cc:e4, WNM supported, PMF connect (WPA2PSK/AES)
Jul 21 08:47:16 udhcpd[22796]: sending ACK to 192.168.1.86
Jul 21 08:50:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 09:00:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 09:30:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 09:40:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 10:30:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 10:50:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 10:52:57 kernel: device br0 entered promiscuous mode
Jul 21 10:53:01 kernel: device br0 left promiscuous mode
Jul 21 10:58:41 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 10:58:49 udhcpd[22796]: sending ACK to 192.168.1.93
Jul 21 11:23:00 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 11:27:38 udhcpd[22796]: sending ACK to 192.168.1.220
Jul 21 11:27:38 udhcpd[22796]: sending ACK to 192.168.1.54
Jul 21 11:27:41 udhcpd[22796]: sending ACK to 192.168.1.199
Jul 21 11:30:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 12:00:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 12:02:52 nginx: 2020/07/21 12:02:52 [info] 4444#0: *794 client 192.168.1.13 closed keepalive connection
Jul 21 12:02:52 nginx: 2020/07/21 12:02:52 [info] 4444#0: *795 client 192.168.1.13 closed keepalive connection
Jul 21 12:02:58 nginx: 2020/07/21 12:02:58 [info] 4444#0: *796 client 192.168.1.13 closed keepalive connection
Jul 21 12:02:58 nginx: 2020/07/21 12:02:58 [info] 4444#0: *798 client 192.168.1.13 closed keepalive connection
Jul 21 12:02:58 nginx: 2020/07/21 12:02:58 [info] 4444#0: *799 client 192.168.1.13 closed keepalive connection
Jul 21 12:02:58 nginx: 2020/07/21 12:02:58 [info] 4444#0: *800 client 192.168.1.13 closed keepalive connection
Jul 21 12:02:58 nginx: 2020/07/21 12:02:58 [info] 4444#0: *797 client 192.168.1.13 closed keepalive connection
Jul 21 12:03:25 nginx: 2020/07/21 12:03:25 [info] 4444#0: *801 client 192.168.1.13 closed keepalive connection
Jul 21 12:03:25 nginx: 2020/07/21 12:03:25 [info] 4444#0: *802 client 192.168.1.13 closed keepalive connection
Jul 21 12:03:25 nginx: 2020/07/21 12:03:25 [info] 4444#0: *803 client 192.168.1.13 closed keepalive connection
Jul 21 12:03:28 nginx: 2020/07/21 12:03:28 [info] 4444#0: *804 client 192.168.1.13 closed keepalive connection
Jul 21 12:03:28 nginx: 2020/07/21 12:03:28 [info] 4444#0: *805 client 192.168.1.13 closed keepalive connection
Jul 21 12:03:28 nginx: 2020/07/21 12:03:28 [info] 4444#0: *807 client 192.168.1.13 closed keepalive connection
Jul 21 12:03:28 nginx: 2020/07/21 12:03:28 [info] 4444#0: *806 client 192.168.1.13 closed keepalive connection
Jul 21 12:20:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 12:40:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 12:45:55 nginx: 2020/07/21 12:45:55 [info] 4444#0: *820 client 192.168.1.13 closed keepalive connection
Jul 21 12:45:55 nginx: 2020/07/21 12:45:55 [info] 4444#0: *821 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:00 kernel: device br0 entered promiscuous mode
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *822 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *823 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *824 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *825 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *826 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *827 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:04 kernel: device br0 left promiscuous mode
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *828 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *831 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *832 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *833 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *829 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *830 client 192.168.1.13 closed keepalive connection
Jul 21 13:20:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 13:24:52 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=3 to 5GHz AP 48:2c:a0:fb:03:ed, WNM supported (WPA2PSK/AES)
Jul 21 13:24:54 udhcpd[22796]: sending OFFER to 192.168.1.199
Jul 21 13:24:54 udhcpd[22796]: sending ACK to 192.168.1.199
Jul 21 13:33:14 kernel: 5GHz AP ageout 48:2c:a0:fb:03:ed after 480-sec silence
Jul 21 13:45:53 kernel: ASSOC - Assign VHT STA MODE=VHT, MCS=9, BW=80M, AID=3 to 5GHz AP 48:2c:a0:fb:03:ed, WNM supported (WPA2PSK/AES)
Jul 21 13:45:53 udhcpd[22796]: sending OFFER to 192.168.1.199
Jul 21 13:45:53 udhcpd[22796]: sending ACK to 192.168.1.199
Jul 21 13:50:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 13:52:28 kernel: device br0 entered promiscuous mode
Jul 21 13:52:32 kernel: device br0 left promiscuous mode
Jul 21 14:00:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 14:06:07 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 14:26:30 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 14:33:01 nginx: 2020/07/21 14:33:01 [info] 4444#0: *897 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:01 nginx: 2020/07/21 14:33:01 [info] 4444#0: *898 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:07 nginx: 2020/07/21 14:33:07 [info] 4444#0: *899 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:07 nginx: 2020/07/21 14:33:07 [info] 4444#0: *900 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:07 nginx: 2020/07/21 14:33:07 [info] 4444#0: *901 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:07 nginx: 2020/07/21 14:33:07 [info] 4444#0: *902 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:33 nginx: 2020/07/21 14:33:33 [info] 4444#0: *903 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:33 nginx: 2020/07/21 14:33:33 [info] 4444#0: *904 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:33 nginx: 2020/07/21 14:33:33 [info] 4444#0: *905 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:33 nginx: 2020/07/21 14:33:33 [info] 4444#0: *906 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:33 nginx: 2020/07/21 14:33:33 [info] 4444#0: *907 client 192.168.1.13 closed keepalive connection
Jul 21 14:33:33 nginx: 2020/07/21 14:33:33 [info] 4444#0: *908 client 192.168.1.13 closed keepalive connection
Jul 21 14:40:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 14:47:33 nginx: 2020/07/21 14:47:33 [info] 4444#0: *910 client 192.168.1.13 closed keepalive connection
Jul 21 14:47:33 nginx: 2020/07/21 14:47:33 [info] 4444#0: *917 client 192.168.1.13 closed keepalive connection
Jul 21 14:47:33 nginx: 2020/07/21 14:47:33 [info] 4444#0: *916 client 192.168.1.13 closed keepalive connection
Jul 21 14:47:39 nginx: 2020/07/21 14:47:39 [info] 4444#0: *918 client 192.168.1.13 closed keepalive connection
Jul 21 14:47:39 nginx: 2020/07/21 14:47:39 [info] 4444#0: *919 client 192.168.1.13 closed keepalive connection
Jul 21 14:47:39 nginx: 2020/07/21 14:47:39 [info] 4444#0: *920 client 192.168.1.13 closed keepalive connection
Jul 21 14:47:39 nginx: 2020/07/21 14:47:39 [info] 4444#0: *921 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:07 nginx: 2020/07/21 14:48:07 [info] 4444#0: *922 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:07 nginx: 2020/07/21 14:48:07 [info] 4444#0: *923 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:07 nginx: 2020/07/21 14:48:07 [info] 4444#0: *924 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:07 nginx: 2020/07/21 14:48:07 [info] 4444#0: *925 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:07 nginx: 2020/07/21 14:48:07 [info] 4444#0: *926 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:11 nginx: 2020/07/21 14:48:11 [info] 4444#0: *927 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:11 nginx: 2020/07/21 14:48:11 [info] 4444#0: *928 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:11 nginx: 2020/07/21 14:48:11 [info] 4444#0: *930 client 192.168.1.13 closed keepalive connection
Jul 21 14:48:11 nginx: 2020/07/21 14:48:11 [info] 4444#0: *929 client 192.168.1.13 closed keepalive connection
Jul 21 14:49:02 kernel: device br0 entered promiscuous mode
Jul 21 14:49:06 kernel: device br0 left promiscuous mode
Jul 21 14:57:37 nginx: 2020/07/21 14:57:37 [info] 4444#0: *936 client 192.168.1.13 closed keepalive connection
Jul 21 14:57:37 nginx: 2020/07/21 14:57:37 [info] 4444#0: *933 client 192.168.1.13 closed keepalive connection
Jul 21 14:57:43 nginx: 2020/07/21 14:57:43 [info] 4444#0: *937 client 192.168.1.13 closed keepalive connection
Jul 21 14:57:43 nginx: 2020/07/21 14:57:43 [info] 4444#0: *938 client 192.168.1.13 closed keepalive connection
Jul 21 14:57:43 nginx: 2020/07/21 14:57:43 [info] 4444#0: *939 client 192.168.1.13 closed keepalive connection
Jul 21 14:57:43 nginx: 2020/07/21 14:57:43 [info] 4444#0: *940 client 192.168.1.13 closed keepalive connection
Jul 21 14:57:43 nginx: 2020/07/21 14:57:43 [info] 4444#0: *941 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:10 nginx: 2020/07/21 14:58:10 [info] 4444#0: *942 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:10 nginx: 2020/07/21 14:58:10 [info] 4444#0: *943 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:10 nginx: 2020/07/21 14:58:10 [info] 4444#0: *944 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:10 nginx: 2020/07/21 14:58:10 [info] 4444#0: *945 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:10 nginx: 2020/07/21 14:58:10 [info] 4444#0: *946 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:13 nginx: 2020/07/21 14:58:13 [info] 4444#0: *948 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:13 nginx: 2020/07/21 14:58:13 [info] 4444#0: *949 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:13 nginx: 2020/07/21 14:58:13 [info] 4444#0: *950 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:13 nginx: 2020/07/21 14:58:13 [info] 4444#0: *951 client 192.168.1.13 closed keepalive connection
Jul 21 14:58:13 nginx: 2020/07/21 14:58:13 [info] 4444#0: *947 client 192.168.1.13 closed keepalive connection
Jul 21 15:10:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 15:20:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 15:40:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 16:00:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 16:14:00 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 16:30:53 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 16:39:10 nginx: 2020/07/21 16:39:10 [info] 4444#0: *980 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:10 nginx: 2020/07/21 16:39:10 [info] 4444#0: *981 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:16 nginx: 2020/07/21 16:39:16 [info] 4444#0: *982 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:16 nginx: 2020/07/21 16:39:16 [info] 4444#0: *983 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:16 nginx: 2020/07/21 16:39:16 [info] 4444#0: *984 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:16 nginx: 2020/07/21 16:39:16 [info] 4444#0: *985 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:16 nginx: 2020/07/21 16:39:16 [info] 4444#0: *987 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:16 nginx: 2020/07/21 16:39:16 [info] 4444#0: *986 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:23 nginx: 2020/07/21 16:39:23 [info] 4444#0: *988 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:23 nginx: 2020/07/21 16:39:23 [info] 4444#0: *990 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:23 nginx: 2020/07/21 16:39:23 [info] 4444#0: *989 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:27 nginx: 2020/07/21 16:39:27 [info] 4444#0: *991 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:27 nginx: 2020/07/21 16:39:27 [info] 4444#0: *992 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:27 nginx: 2020/07/21 16:39:27 [info] 4444#0: *993 client 192.168.1.13 closed keepalive connection
Jul 21 16:39:27 nginx: 2020/07/21 16:39:27 [info] 4444#0: *994 client 192.168.1.13 closed keepalive connection
Jul 21 17:06:51 kernel: device br0 entered promiscuous mode
Jul 21 17:06:52 nginx: 2020/07/21 17:06:52 [info] 4444#0: *1006 client 192.168.1.13 closed keepalive connection
Jul 21 17:06:55 kernel: device br0 left promiscuous mode
Jul 21 17:10:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 17:27:34 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=6 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 17:27:34 udhcpd[22796]: sending OFFER to 192.168.1.164
Jul 21 17:27:34 udhcpd[22796]: sending ACK to 192.168.1.164
Jul 21 17:39:13 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=6 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 17:39:33 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=6 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 17:39:34 udhcpd[22796]: sending OFFER to 192.168.1.164
Jul 21 17:39:34 udhcpd[22796]: sending ACK to 192.168.1.164
Jul 21 17:47:30 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=6 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 17:47:30 udhcpd[22796]: sending OFFER to 192.168.1.164
Jul 21 17:47:31 udhcpd[22796]: sending ACK to 192.168.1.164
Jul 21 17:50:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 17:52:06 kernel: device br0 entered promiscuous mode
Jul 21 17:52:10 kernel: device br0 left promiscuous mode
Jul 21 17:54:06 nginx: 2020/07/21 17:54:06 [info] 4444#0: *1028 client 192.168.1.13 closed keepalive connection
Jul 21 17:54:07 kernel: device br0 entered promiscuous mode
Jul 21 17:54:11 kernel: device br0 left promiscuous mode
Jul 21 17:54:18 nginx: 2020/07/21 17:54:18 [info] 4444#0: *1023 client 192.168.1.13 closed keepalive connection (131: Connection reset by peer)
Jul 21 17:54:22 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=6 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 17:54:22 udhcpd[22796]: sending OFFER to 192.168.1.164
Jul 21 17:54:22 udhcpd[22796]: sending ACK to 192.168.1.164
Jul 21 17:54:44 kernel: device br0 entered promiscuous mode
Jul 21 17:54:48 kernel: device br0 left promiscuous mode
Jul 21 18:02:28 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-9) from a8:6d:aa:76:cc:e4, reason=1
Jul 21 18:07:35 kernel: device br0 entered promiscuous mode
Jul 21 18:07:39 kernel: device br0 left promiscuous mode
Jul 21 18:10:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 18:30:54 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 18:51:57 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 18:53:40 dnsmasq[24316]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 21 18:53:47 kernel: 2.4GHz AP ageout e0:62:67:2c:13:cd after 480-sec silence
Jul 21 18:55:10 kernel: 5GHz AP ageout 00:0a:f5:44:6f:6c after 480-sec silence
Jul 21 18:55:41 kernel: 5GHz AP ageout 48:2c:a0:fb:03:ed after 480-sec silence
Jul 21 18:59:33 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=2 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 18:59:33 udhcpd[22796]: sending OFFER to 192.168.1.164
Jul 21 18:59:33 udhcpd[22796]: sending ACK to 192.168.1.164
Jul 21 19:18:01 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=2 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 19:18:12 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=20M, AID=2 to 2.4GHz AP e0:62:67:2c:13:cd, WNM supported (WPA2PSK/AES)
Jul 21 19:18:12 udhcpd[22796]: sending OFFER to 192.168.1.164
Jul 21 19:18:12 udhcpd[22796]: sending ACK to 192.168.1.164
Jul 21 19:19:47 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=40M, AID=3 to 5GHz AP 00:0a:f5:44:6f:6c, WNM supported (WPA2PSK/AES)
Jul 21 19:19:50 udhcpd[22796]: sending OFFER to 192.168.1.54
Jul 21 19:19:50 udhcpd[22796]: sending ACK to 192.168.1.54

[/spoiler]

Цитата: sfstudio от 21/07/2020, 23:39

1. используйте вставку code для цитирования логов
2. у вас какая-то ерунда с фрагментацией твориться, судя по матам dnsmasq ipv6 через тонналь испольузте?

P.S. Конфиги прикладвать полезно + что там за соеидение с керио и какой оно протокол юзает поверьте знают не все. В т.ч. я не в курсе.

Цитата: AndryRV от 22/07/2020, 01:56

Приложил конфиг. Подключение к интернет у меня PPPoE.

Про Kerio - не в курсе особо. у меня рабочий ноутбук, на нем установлен Kerio VPN Client. (ГИП: 8.0.1.609, Служба: 8.0.1 build 609, Драйвер: 7.4.0.4517). Приложил сведения о подключении Kerio.  что еще можно сообщить?

Цитата: AndryRV от 22/07/2020, 19:28

За сегодня не было сообщений "client closed keepalive connection" , но в логе теперь много таких сообщений - это критично?

Jul 22 07:19:51 udhcpd[22796]: sending ACK to 192.168.1.54
Jul 22 08:02:43 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=4 to 5GHz AP a8:6d:aa:7d:1f:cc, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:02:43 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-3) from a8:6d:aa:7d:1f:cc, reason=1
Jul 22 08:02:44 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=4 to 5GHz AP a8:6d:aa:7d:1f:cc, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:02:44 udhcpd[22796]: sending ACK to 192.168.1.13
Jul 22 08:03:52 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-10) from a8:6d:aa:7d:1f:cc, reason=1
Jul 22 08:04:00 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=4 to 5GHz AP a8:6d:aa:7d:1f:cc, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:04:00 udhcpd[22796]: sending ACK to 192.168.1.13
Jul 22 08:46:35 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=5 to 5GHz AP a8:6d:aa:76:cc:e4, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:46:35 udhcpd[22796]: sending ACK to 192.168.1.86
Jul 22 10:01:12 udhcpd[22796]: sending ACK to 192.168.1.93
Jul 22 10:17:06 udhcpd[22796]: sending ACK to 192.168.1.199
Jul 22 10:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:24:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:25:45 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:27:34 udhcpd[22796]: sending ACK to 192.168.1.220
Jul 22 11:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:49:47 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 12:24:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 12:34:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 12:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 13:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 13:34:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 13:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:03:17 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:04:51 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:34:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:50:29 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:51:43 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:04:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:57:29 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 16:04:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 16:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 16:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 17:12:54 nginx: 2020/07/22 17:12:54 [info] 4444#0: *1097 Authentication successful: user=Admin , client: 192.168.1.13, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.1.1", referrer: "http://192.168.1.1/login.asp"
Jul 22 17:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280

 

Цитата: AndryRV от 24/07/2020, 12:10

Извините за назойливость. просмотрел логи Kerio с ошибками,  c 17.07 когда поставил роутер появилось больше ошибок, до этого был Keenetic, ошибки были, но не так часто. что мне можно настроить для более стабильного соединения.

Цитата: sfstudio от 24/07/2020, 14:00

Обратитесь в ТП керио, я по их логам не понимаю что именно ему не нравиться и кто виноват. И врятли роутер. Вижу что он долбится до DNS и регулярно не может что-то отрезолвить.

Проблема может быть где угодно в т.ч. в провайдерских DNS или вообще на стороне DNS вашего VPN сервера куда он ломится.

Но судя по логам с роутера керио генерит кривые запросы к DNS и dnsmasq в роутере их дропает.

В любом случае это вопрос к керио, а не к нам.

Цитата: AndryRV от 24/07/2020, 14:54

Т.е. keenetic'y нравились запросы kerio, а вашему перестали нравится. с такого провайдера не я один сижу, у других пользователей обрывов не бывает. к kerio подключены около 100 пользователей с разных провайдеров, а обрывы стабильные только у меня после смены роутера.

Цитата: sfstudio от 24/07/2020, 15:21

Запросто. А ещё запросто так же завтра кинетику перестанут нравиться эти запросы т.к. обновят например DNSMASQ и получат ту же валидацию.

Оно не просто так ругается именно на kerio и ни на что больше. Так что завтра проблему могут получить все у кого сейчас всё нормально, просто по мере обновления dnsmasq другими вендорами.

Цитата: sfstudio от 24/07/2020, 15:25

Точнее тут даже не так.

Судя по:

reducing DNS packet size for nameserver 95.66.188.11 to 1280

На стороне этого сервера проблемы с фрагментацией пакетов (режим медиума ON) поэтому встроенный у нас DNSMASQ после кучи попыток уменьшает размер пакета до 1280 и тогда что-то проходит.

Это на правах куцих логов проприретарщины от керио и сопоставление с руганью dnsmasq в логе роутера.

И разбираться тут надо не на стороне роутера. Хотя можно и на стороне роутера накостылить попробовав уменьшив MTU. Но судя по ругани только на этот сервер проблема на его стороне. В керио или ещё в чём я ХЗ. Может на транзите где-то.

Это всё сильно выходит за рамки ТП роутера (разборы со сторонними сервисами).

Цитата: AndryRV от 25/07/2020, 01:25

95.66.188.11, я так понимаю, это dns сервер провайдера, попробую им написать. 

мои знания не позволяют вести с вами разговор на одном уровне. сегодня было всего 2 разрыва связи, с этим можно жить.

Цитата: sfstudio от 25/07/2020, 13:32

Сделайте следующее, в настройках VPN уменьшите MTU до 1280 или чуть ниже. Возможно проблема вообще не в DNS и не в kerio а в настройках браса провайдера. Я правда уже лет 10ть не видел что бы брас отдавал неверное значение MTU при подъёме PPPOE. Но чую вот что-то где-то оно тут зарыто. Потому часть запросов жирных к DNS от kerio по просту не пролазиет.

Надеюсь это не DSL ? А то там потери наплывами могут быть из-за ошибок на DSL интерфейсе. Даже от дождика в итоге будет зависеть сколько их и проблемы абсолютно непредсказуемо могут возникать.

А что бы говорить со мной на одном языке достаточно предоставлять всю инфу от того кто провайдер, как именно подключены и т.д. и т.п.

В данном случае по сути играем в угадайку. Керио ругается что не может отрезолвить адреса какие-то, dnsmasq ругается что ему пришлось ограничить размер пакетов в сторону одного из серверов.

Не ну можно в настройках DNS в Upstream DNS Servers забить например гугловские 8.8.8.8 и 8.8.4.4 и посмотреть что будет. Если глючит один из провайдерских DNS проблема тоже уйдёт.

Однако остаётся таки вариант, что это керио что-то левое формирует такое что dnsmasq или провайдерский dns сервер переварить не может. Вот тоже запросто.

В любом случае тут дебаг должен быть не на стороне роутера, у него всё хорошо, а на стороне провайдера или kerio и разбираться что происходит. Я тут кроме как карты раскинуть (см выше) предложить особо ничего не смогу.

Сидеть дебажить керио или вместо спецов вашего провайдера разбирать дампы обращений к их DNS в моменте затыка, ну наверное всё же не моя работа.

Цитата: AndryRV от 26/07/2020, 14:49

Провайдер местный, Район называется. не думаю, что это как-то поможет. В поддержке провайдера сказали не обращать внимание на такие сообщения. в настройках dns вбил гугловские сервера. сообщения не пропали

Jul 25 17:06:24 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 17:52:58 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 18:22:58 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 19:23:04 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=40M, AID=3 to 5GHz AP 00:0a:f5:44:6f:6c, WNM supported (WPA2PSK/AES)
Jul 25 19:23:05 udhcpd[2997]: sending OFFER to 192.168.1.54
Jul 25 19:23:05 udhcpd[2997]: sending ACK to 192.168.1.54
Jul 25 19:44:08 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 20:02:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 20:12:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 20:39:31 udhcpd[2997]: sending ACK to 192.168.1.93
Jul 25 21:02:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 21:08:17 udhcpd[2997]: sending ACK to 192.168.1.220
Jul 25 21:09:08 udhcpd[2997]: sending ACK to 192.168.1.13
Jul 25 21:16:20 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 21:42:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 21:52:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 22:22:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 23:20:42 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-50) from a8:6d:aa:7d:1f:cc, reason=1

Уменьшил mtu до 1280. разрывы с kerio каждые 10-15 минут стали. в 12-06 установил этот параметр.

Jul 26 12:06:56 dnsserver: Starting DNSMASQ.
Jul 26 12:06:56 adblock: Next adblock update after 24h.
Jul 26 12:06:56 dnsmasq[6718]: started, version 2.81 cachesize 4096
Jul 26 12:06:56 dnsmasq[6718]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN no-DHCP no-scripts no-TFTP no-conntrack no-ipset no-auth DNSSEC loop-detect inotify no-dumpfile
Jul 26 12:06:56 dnsmasq[6718]: warning: ignoring resolv-file flag because no-resolv is set
Jul 26 12:06:56 dnsmasq[6718]: using nameserver 8.8.4.4#53
Jul 26 12:06:56 dnsmasq[6718]: using nameserver 8.8.8.8#53
Jul 26 12:06:56 dnsmasq[6718]: read /etc/hosts - 5 addresses
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *29 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *30 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *31 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *32 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *34 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *33 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:12 nginx: 2020/07/26 12:07:12 [info] 4707#0: *35 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *36 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *37 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *38 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *39 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *40 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *41 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *42 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *43 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *44 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *45 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *46 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *47 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *48 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *49 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *50 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *52 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *51 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *53 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *60 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *61 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *62 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *63 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *64 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *65 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *66 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *71 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *70 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *67 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *68 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *69 client 192.168.1.13 closed keepalive connection
Jul 26 12:45:38 nginx: 2020/07/26 12:45:38 [info] 4707#0: *76 client 192.168.1.13 closed keepalive connection
Jul 26 12:45:45 nginx: 2020/07/26 12:45:45 [info] 4707#0: *78 client 192.168.1.13 closed keepalive connection

какой то замкнутый круг получился. попробую еще наших IT поспрашивать про настройки kerio.

Цитата: sfstudio от 26/07/2020, 16:33

Уменьшил mtu до 1280. разрывы с kerio каждые 10-15 минут стали. в 12-06 установил этот параметр.

Однако ругань из логов пропала. Т.е. таки какие-то проблемы с MTU имеют место быть.

какой то замкнутый круг получился. попробую еще наших IT поспрашивать про настройки kerio.

Как последняя мысль. Если керио впн использует UDP то возможно тот редкий случай когда себя проявила древняя болячка PPE. Увы полноценно она не лечиться, правда и вариант наступить на неё один на миллион.

В качестве проверки догадки можно в Services->Miscellaneous->NAT offload mode выставить в Hardware (для PPPOE/IPOE софт оффлоад бесполезен практически всё равно). Там же UDP hardware nat offload в disable.

Если я прально помню у кинетиков UDP оффлоад по дефолту вырублен.

Ну и крайне рекомендую взять (win)mtr  и натравить его на адрес сервера kerio и dns сервера и пусть он щёлкает. После отвала глянуть не было ли потерь. Сразу до кучи будет видно где потери.

Цитата: sfstudio от 26/07/2020, 16:37

Ругань та же самая до гугловских DNS (и отсутствие оной при уменьшении MTU туннеля руками) прямой и жирный намёк на таки проблемы с MTU у провайдера. По нормальному MTU/MRU для PPPOE равен 1492 т.к. 8 байт уходит на инкапсуляцию в PPPOE. Если используется другое значение на стороне браса то брас его должен корректно отдать в LCP на стадии подключения. Иначе придётся задавать руками.

Другое дело, что это могут быть и не связанные между собой проблемы.

Цитата: AndryRV от 29/07/2020, 01:33

Цитата: sfstudio от 26/07/2020, 16:33

В качестве проверки догадки можно в Services->Miscellaneous->NAT offload mode выставить в Hardware (для PPPOE/IPOE софт оффлоад бесполезен практически всё равно). Там же UDP hardware nat offload в disable.

Если я прально помню у кинетиков UDP оффлоад по дефолту вырублен.

после этих настроек разрывов kerio два дня вообще не было. огромное спасибо.

в логах роутера всё теже сообщения остались, но обрывы пропали.

Цитата: sfstudio от 29/07/2020, 07:48

1. раз в логах есть записи то стоит таки уменьшить mtu, т.е. у вас 2 проблемы в итоге. Не ну можете и так жить если ретрансмиты жирных пакетов и лишние задержки не напрягают.
2. теперь по правильному стоит написать товарищам из kerio что их vpn работающий по UDP триггерит аппаратную проблему в блоке оффлоада и у всех Ralink/MTK. А т.к. на большинстве роутеров его отлючить не реально (особенно отдельно оффлоад UDP) то было бы не плохо если бы они пофиксили это дело на своей стороне.

Крайне рекомендую выполнить оба пункта. Т.к. первый ведёт к подземным стукам, второй  к необходимости отключения UDP offload т.е. заметным увеличением нагрузки на cpu роутера при использовании например торрентов с uTP да и производительность UDP туннелей так же будет ограничена CPU роутера т.к. такой трафик будет обрабатываться полностью программно.

Благо керио vpn единственная бяка на которой на текущий момент проблема всё ещё повторяется (ну как выяснилось), остальные из встреченных мной и зарепорченных пофиксили на своей стороне.

С нашей стороны поправить тут увы особо не чего, ибо проблема в реализации самого PPE в железной логике, не в софте. ;(

Цитата: AndryRV от 29/07/2020, 22:58

Уменьшил mtu до 1200, а в логах сообщения так и остались. или я не там уменьшил?

Jul 29 20:45:40 dnsmasq[14267]: reducing DNS packet size for nameserver 8.8.8.8 to 1280

 

Цитата: sfstudio от 30/07/2020, 06:26

Странный коро у вас провайдер, что-то он по пути с пакетами такое делает. Для PPPOE выставьте 1492 от греха по дальше и пусть живёт раз проблем нет. Надо глубже разбираться чего там провайдер творит что dnsmasq ругается раз не в MTU дело... Хотя странно.

Цитата: CHIPSET от 31/07/2020, 20:47

Месяц назад перешёл с ME1 на DUO-G и сейчас заглянув в лог также увидел сообщения от dnsmasq. MTU уже лет 5 как зафиксировано в 1500(IPoE, InterZet). Просто на всякий случай сообщаю. Потом ещё у товарища гляну.

Цитата: sfstudio от 01/08/2020, 13:55

Я записал в туду глянуть эту логику в dnsmasq, возможно что-то там поменялось и оно стало срабатывать когда не надо, или же наоборот стало срабатывать когда надо. =)

В любом случае автору оного виднее.

Цитата: AndryRV от 02/08/2020, 00:01

Цитата: sfstudio от 26/07/2020, 16:33

Ну и крайне рекомендую взять (win)mtr  и натравить его на адрес сервера kerio и dns сервера и пусть он щёлкает. После отвала глянуть не было ли потерь. Сразу до кучи будет видно где потери.

Не знаю правильно ли сделал. в Host прописал 8.8.8.8 , т.к. у меня сейчас dns гугла в настройках роутера. получил такую картину. я, честно говоря, не знаю как ее понимать, потери 24% и 56%, как я понял, это сервера гугла. в логах роутера в это время так было.

Aug  1 16:28:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 16:38:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *349 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *350 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *351 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *352 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *353 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *354 client 192.168.1.13 closed keepalive connection
Aug  1 17:08:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 17:38:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 17:52:06 kernel: 5GHz AP ageout 00:0a:f5:44:6f:6c after 480-sec silence
Aug  1 18:46:10 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=40M, AID=3 to 5GHz AP 00:0a:f5:44:6f:6c, WNM supported (WPA2PSK/AES)
Aug  1 18:46:11 udhcpd[9334]: sending OFFER to 192.168.1.54
Aug  1 18:46:11 udhcpd[9334]: sending ACK to 192.168.1.54
Aug  1 19:18:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 19:28:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *357 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *360 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *355 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *356 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *359 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *358 client 192.168.1.13 closed keepalive connection
Aug  1 20:14:48 udhcpd[9334]: sending ACK to 192.168.1.199
Aug  1 20:18:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 20:38:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 20:54:41 udhcpd[9334]: sending ACK to 192.168.1.13
Aug  1 21:08:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 21:10:51 udhcpd[9334]: sending ACK to 192.168.1.220
Aug  1 21:25:58 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 21:38:09 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 21:57:42 udhcpd[9334]: sending ACK to 192.168.1.93
Aug  1 21:58:09 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280

 

Цитата: sfstudio от 02/08/2020, 00:24

С такми потерями будет Ж... И это мелкими пакетами. Ругань ДНС маскарада понятна.

Почитайте как читать репорты MTR например тут и до своего VPN сервера проверьте. Потери >5% это не норма. В идеале их быть вообще не должно тем более на мелких пакетах.

Цитата: AndryRV от 02/08/2020, 14:41

Сделал до VPN сервера. На работе интернет от такого-же провайдера, что и у меня дома, поэтому всё внутри сети провайдера проходит, как я понял.

а по поводу вчерашней картинки с потерями - это мне к поддержке провайдера обращаться?

Цитата: sfstudio от 02/08/2020, 14:47

Это за какой интервал времени? Потери <=1% как бы не криминал. Однако вижу что теряются прям до роутера в т.ч. Кабель отходит? Помехи? Т.е. вот это место бы я бы проверил.

Иногда (на например сетёвках от RTL) при включенных в настройках их драйверов оффлоадах время от времени лезут потери. Жить обычно не мешает т.к. процент потерь несущественный, но кого напрягает отключают оффлоады в настройках драйверов.

Как бы какого-то прям криминала тут нет.

Для полноты картинки неплохо бы сделать обратную трассировку с VPN сервера до вас таким же макаром и посмотреть что будет.

Цитата: AndryRV от 02/08/2020, 15:17

Цитата: sfstudio от 02/08/2020, 14:47

Это за какой интервал времени? Потери <=1% как бы не криминал. Однако вижу что теряются прям до роутера в т.ч. Кабель отходит? Помехи? Т.е. вот это место бы я бы проверил.

Т.к. опрос раз в секунду идет, то значит 1ч 40мин примерно. но я с ноута по wi-fi, качество сигнала далеко от 100%, может из-за этого потери до роутера?

Цитата: sfstudio от 02/08/2020, 17:01

Ну тады точно криминала не вижу.

Цитата: AndryRV от 03/08/2020, 01:14

я ping'ом прогнал 8.8.8.8, отобразилось 0% потерь. почему winmtr так много потерь показывало? или это разные вещи?

Цитата: sfstudio от 04/08/2020, 11:20

Ну вообще да и вещи разные и даже разные протоколы могут быть использованы для пинга и трассировки. Что конкретно у WINmtr по дефолту настроено я фиг знает, винды нет под рукой.

По ругани dnsmasq глянул (заодно обновил до текущего стэйбла), оно терь таким образом будет ругаться на любые потери пакетов до DNS. Т.е. как бы не смертельно (ну сделает резолв ещё раз), но вообще потери до ключевых сервисов нужных для функционирования сети эт не гуд.