sfstudio Опубликовано 24 марта, 2017 · Жалоба 1) допустимый диапазон питающих напряжений 5-14В постоянки. Ток БП должен держать не меньше ампера 2) ну сдох бывает, брак,если железка новая заменят без проблем, БП нынче не торт ;( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 5 апреля, 2017 · Жалоба При обновлении с 5.0.19 на 5.2.13 в настройках WiFi пропал сканер эфира. Это какой-то баг, или специально убрали? (фича мегаудобная, позволяющая саппорту оперативно проверить радиообстановку у клиента, при жалобах "интернет на ноутбуке тормозит") Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirill Vasilyev Опубликовано 5 апреля, 2017 · Жалоба Сканер не доступен только в режиме автовыбора канала, проверьте не выбран ли у вас автовыбор Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 5 апреля, 2017 · Жалоба Действительно, стоит автовыбор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 5 апреля, 2017 · Жалоба Сканер не доступен только в режиме автовыбора канала, проверьте не выбран ли у вас автовыбор И это не верно. Нет никакого смысла скрывать сканер даже если стоит авто. Надо убрать привязку. (фича мегаудобная, позволяющая саппорту оперативно проверить радиообстановку у клиента, при жалобах "интернет на ноутбуке тормозит") Увы но результаты сканирование зачастую не говорят ни о чём т.к. в результатах только 802.11 устройства, тогда как очень часто проблема деградации скорости в совсем других устройствах так же работающих в 2.4ГГц которые сканер не увидит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 6 апреля, 2017 · Жалоба Увы но результаты сканирование зачастую не говорят ни о чём т.к. в результатах только 802.11 устройства, тогда как очень часто проблема деградации скорости в совсем других устройствах так же работающих в 2.4ГГц которые сканер не увидит. По опыту эксплуатации >1000 устройств, самая главная причина деградации скорости это когда один канал обсели несколько десятков AP-шек. Встроенный сканер просто глотком воздуха оказался, помогая саппорту оперативно разрулить ситуацию без необходимости выезда на адрес сотрудника. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 6 апреля, 2017 · Жалоба Да да. Поставьте рядом 2 АП, разнесите по каналам ну пусть 1 и 6. Запустите на одной iperf в 16 потоков, затем параллельно на другой. Убедитесь что всё сдохло почти до уровня GPRS. Теперь проделайте тоже самое выставив один и тот же канал. Вы будете сильно удивлены результату. =) Самая главная причина деградации скорости в 2.4 это его сверхзагаженность. Потому повторюсь, дуалбэнд и только дуалбэнд для таких инсталляций. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 12 апреля, 2017 · Жалоба Добрый день. Пробую поднять L2TP Server для доступа в Lan из Wan. System Platform - MT7620 2T2R 2.4GHz, 100FDX Firmware Version - 5.0.19.RU.09022017 Services - L2TP Server - Включен по умолчанию, плюс Allow debug. Пароль test - test. System Log: Feb 13 02:49:12 vpn-server: One or more users need be configured. Stop. Feb 13 02:49:12 kernel: ASSOC Assign 11n HT STA - AID=1 14:bb:6e:7c:e0:a5 Feb 13 02:49:12 kernel: ASSOC - Update AP OperaionMode=2 , fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=1 Feb 13 02:49:12 udhcpd[28929]: sending ACK to 192.168.1.151 Feb 13 02:49:13 udhcpd[28929]: sending ACK to 192.168.1.202 Feb 13 02:49:14 udhcpd[28929]: sending ACK to 192.168.1.236 Feb 13 02:49:16 kernel: br0: port 1(eth2.1) entered forwarding state Feb 13 02:49:17 kernel: br0: port 2(ra0) entered forwarding state Feb 13 02:50:29 iptables: Add netfiler rules Feb 13 02:50:29 iptables: Allow established/related in input Feb 13 02:50:29 iptables: Service limit set Feb 13 02:50:29 iptables: DHCP server allow Feb 13 02:50:29 iptables: Dnsproxy allow to connect Feb 13 02:50:29 iptables: Add vpnfilter rules for L2TP Feb 13 02:50:29 iptables: Remote managment web limit Feb 13 02:50:29 iptables: Remote managment ssh limit Feb 13 02:50:29 iptables: Remote managment telnet limit Feb 13 02:50:29 iptables: Allow rate limited ping from all interfaces. Feb 13 02:50:29 iptables: Set forward rules Feb 13 02:50:29 iptables: Add forward chain for vpnserver Feb 13 02:50:29 iptables: Allow forward from LAN to any Feb 13 02:50:29 iptables: Add SNAT from 192.168.1.1/255.255.255.0 to 185.0.0.0 at eth2.2. Feb 13 02:50:29 iptables: Allow established/related in forward Feb 13 02:50:30 vpn-server: Start l2tp vpn server Feb 13 02:50:35 xl2tpd[29354]: Using l2tp kernel support. Feb 13 02:50:35 xl2tpd[29356]: xl2tpd version xl2tpd-1.3.8 started on Wive-NG-MT PID:29356 Feb 13 02:52:04 dropbear[29361]: Child connection from 192.168.1.151:53213 Feb 13 02:52:12 dropbear[29361]: Password auth succeeded for 'Admin' from 192.168.1.151:53213 Feb 13 02:53:06 kernel: ESW: Link Status Changed - Port2 Link Down Feb 13 02:53:50 dropbear[29361]: Exit (Admin): Error reading: Connection timed out Feb 13 02:56:50 kernel: ESW: Link Status Changed - Port2 Link Up Feb 13 02:56:50 udhcpd[28929]: sending ACK to 192.168.1.151 Feb 13 02:57:16 iptables: Add netfiler rules Feb 13 02:57:16 iptables: Allow established/related in input Feb 13 02:57:16 iptables: Service limit set Feb 13 02:57:16 iptables: DHCP server allow Feb 13 02:57:16 iptables: Dnsproxy allow to connect Feb 13 02:57:16 iptables: Add vpnfilter rules for L2TP Feb 13 02:57:16 iptables: Remote managment web limit Feb 13 02:57:16 iptables: Remote managment ssh limit Feb 13 02:57:16 iptables: Remote managment telnet limit Feb 13 02:57:17 iptables: Allow rate limited ping from all interfaces. Feb 13 02:57:17 iptables: Set forward rules Feb 13 02:57:17 iptables: Add forward chain for vpnserver Feb 13 02:57:17 iptables: Allow forward from LAN to any Feb 13 02:57:17 iptables: Add SNAT from 192.168.1.1/255.255.255.0 to 185.0.0.0 at eth2.2. Feb 13 02:57:17 iptables: Allow established/related in forward Feb 13 02:57:17 vpn-server: Stop l2tp vpn server Feb 13 02:57:17 xl2tpd[29356]: death_handler: Fatal signal 15 received Feb 13 02:57:18 vpn-server: Start l2tp vpn server Feb 13 02:57:23 xl2tpd[29532]: Using l2tp kernel support. Feb 13 02:57:23 xl2tpd[29532]: xl2tpd version xl2tpd-1.3.8 started on Wive-NG-MT PID:29532 [Wive-NG-MT@/]# netstat -au Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 0.0.0.0:domain 0.0.0.0:* udp 0 0 0.0.0.0:bootps 0.0.0.0:* udp 0 0 0.0.0.0:l2f 0.0.0.0:* udp 0 0 :::domain :::* [Wive-NG-MT@/]# iptables -L -n -v Chain INPUT (policy DROP 176 packets, 17105 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 2154 166K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 445 33600 servicelimit all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 708 484K l2tpsrvfwd all -- * * 0.0.0.0/0 0.0.0.0/0 348 20056 ACCEPT all -- br0 * 192.168.1.0/24 0.0.0.0/0 360 464K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT 3915 packets, 777K bytes) pkts bytes target prot opt in out source destination Chain l2tpsrvfwd (1 references) pkts bytes target prot opt in out source destination Chain servicelimit (1 references) pkts bytes target prot opt in out source destination 1 334 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 127 7389 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53 4 1648 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:500 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 500,1701,4500 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 500,1701,4500 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 #conn src/32 > 16 reject-with icmp-port-unreachable 136 7072 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 #conn src/32 > 4 reject-with icmp-port-unreachable 1 52 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:23 #conn src/32 > 4 reject-with icmp-port-unreachable 0 0 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:23 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 10/sec burst 5 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp !type 8 Как не пробовал настроить клиента на Windows, по дебагу чисто, как будто даже нет попыток подключится. Подскажите пожалуйста куда копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 12 апреля, 2017 · Жалоба 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 500,1701,4500 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 500,1701,4500 А их и нет (попыток), счётчики пустые. Т.е. ниодого пакета на 1701 порт не пришло в принципе. Так что выясняйте у провайдеров посередине кто дропает udp на 1701 порт (читай блокирует l2tp) ну или винда ваша и не пытается соедениться... P.S. И в 100й раз. Перед тем как писать всегда обновляйте ПО до текущей актуальной версии. С софтом даже месячной давности никто разбираться не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 12 апреля, 2017 · Жалоба ну или винда ваша и не пытается соедениться... Так и есть. Имея другие, зашифрованные IPSec, L2TP подключения на компьютере, ни в какую не подключится к серверу на роутере. Попробовал с соседнего компьютера, с такой же Windows 7, и всё заработало без танцев с бубном. Решение оказалось на поверхности, отключаем проверку подлинности ЦС при подключении - "ProhibitIpSec"=dword:00000001 "AllowL2TPWeakCrypto"=dword:00000001 Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 15 апреля, 2017 · Жалоба Добрый день. Установили роутер абоненту, увидели интересную картину на графиках доступности устройства. На канале проблем нет, потери пакетов тоже. Как кажется, такая картина может быть вызвана - # allow ratelimit ping request iptables -A servicelimit -p icmp --icmp-type echo-request -m limit --limit 10/s -j ACCEPT iptables -A servicelimit -p icmp --icmp-type echo-request -j DROP Если так, то какой лимит выставить? П.С. Мониторинг Cacti - Advanced Ping. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 апреля, 2017 · Жалоба Ну да в лимит влетаете видимо. Я не очень понимаю в чём тайный смысл постоянно дрючить клиента icmp echo. Увеличивайте интервал опроса пингом устройства. Я не в курсе как именно Cacti - Advanced Ping реализует опрос. Сериями через интервал или равномерно и постоянно по таймеру тикают. Но интервал для icmp echo должен быть больше десятой доли секунды (при опросе). По дефолту у ping (у самой обычной консольной команды) интервал 1 icmp echo в секунду т.е. лимит достаточно высок что бы не вносить проблем. Как там у какти ХЗ. Я бы (если бы стояла цель мониторить доступность) вообще бы слал бы раз в минуту или даже больше серию из 10тка пакетов большого размера с интервалом в 1s. Надо понимать какая цель ставиться. Если проверить доступность устройства то это хотя бы один ответ пинга можно считать устройство уже доступно. Кстати тоже не факт. Запросто может колом всё встать, но ядро будет усиленно отвечать пингами, или наоборот канал будет забит пользовательскими данными которые аппаратно нащёлкал блок PPE, а ответы на icmp echo банально будут постоянно висеть в софт очереди и умирать не долетая до вопрошающего. Т.е. такой опрос почти ни о чём не говорит. Если стоит цель тестировать трассу, то наверное имеет смысл мониторить потери до вашей конечной точки ответственности (домовой свитч) и только по необходимости (если проблемы до домового коммутатора нет, а у юзверя есть, при этом линк в норме и ошибок на портах коммутатора не наблюдается, взрывной рост которых зачастую гораздо более информативен чем пинание CPE). ИМХО не очень хорошая идея создавать шум в сторону пользователя icmp-echo. Эти данные почти ничего не дают относительно тех данных которые можно снять с порта коммутатора. Но это всё вопросы уже из другой темы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 15 апреля, 2017 · Жалоба ИМХО не очень хорошая идея создавать шум в сторону пользователя icmp-echo. Эти данные почти ничего не дают относительно тех данных которые можно снять с порта коммутатора. В текущий момент цель отслеживание качества линка, там на пути радимост, скоро поставим на объект свою активку и не будем "теранить" роутер. Попробую, временно, поиграться со значением --limit. Без fs save - ребут роутера спасёт от возможных ошибок? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 апреля, 2017 · Жалоба В текущий момент цель отслеживание качества линка, там на пути радимост, скоро поставим на объект свою активку и не будем "теранить" роутер. А... Вот оно что. Попробую, временно, поиграться со значением --limit. Да добавьте тогда правило что бы с адреса пинговалки отвечал без лимита перед лимит правилом. Ну раз один фиг решение временное. iptables -A servicelimit -s адрес_пинговалки -p icmp --icmp-type echo-request -j ACCEPT Без fs save - ребут роутера спасёт от возможных ошибок? Не очень понял от каких ошибок спасёт? =) Для экспериментов можете менять правила на лету и применять их по service iptables restart или вообще непосредственно руками через iptables крутить. Изменения не будут сохраняться пока fs save не скажете, т.е. после ребута rwfs будет снова загружена с флэша, где если не сказать fs save, будет версия до правок. Т.е. ваших изменений не будет. Однако будьте аккуратны. Совсем не сложно правя логику инита поставить устройво раком вплоть до необходимости подключения консоли для восстановления. Что бы избежать таких казусов в части работы с iptables сделаны хуки https://sourceforge.net/p/wive-ng/wive-ng-mt/ci/master/tree/README Т.е. возможность исполнения пользовательских скриптов с вызовом из опредёленных мест и даже если в них будет ошибка то это не приведёт к остановке загрузки и в крайнем случае для восстановления работы достаточно будет нажать резет. Ну и плюс это решает проблему когда я правлю что-то в скриптовой логике, а потом вам приходиться уже в другом месте что-то править. P.S. Для проверки лимит ли виноват или что-то ещё достаточно вообще просто сказать iptables -I servicelimit -p icmp --icmp-type echo-request -j ACCEPT Т.е. добавить разрешающее правило без всяких лимитов в самое начало таблицы servicelimit. PP.S. Кроме лимита на уровне нетфильтра, ядро само лимитирует icmp, настройки меняются через sysctl (сделать постоянными можно добавив опции в /etc/sysctl.conf). Текущие настройки лимита для icmp в ядре: net.ipv4.icmp_ratelimit = 1000 net.ipv4.icmp_ratemask = 6168 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 апреля, 2017 · Жалоба цель отслеживание качества линка Вот тут кстати может быть ещё одна засада. В радио сейчас модно стало использовать TxOP. Т.е. на уровне драйвера классифицируют трафик и исходя из этого крутят модуляции, параметры tx retry и т.д. per packet. В итоге icmp зачастую, как и для ManagmentFrames бегают на самых низких доступных модуляциях. Т.е. то что icmp бегает и бегает без потерь никак не говорит, что линк работает нормально и что потерь на том же UDP/TCP не будет, или что оно вообще как-то будет ходить. ;) Но это опять таки уже вопрос совсем другой темы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 15 апреля, 2017 · Жалоба Не очень понял от каких ошибок спасёт? =) Как говорится, ковыряние в удалённом фаерволе - к дальней дороге. А тут ещё момент, что жезезка за 15 км от меня. Вот тут кстати может быть ещё одна засада. С радио там всё нормально, всё снимается по SNMP, тут задача простая как "бревно". На составном канале, местами не подконтрольном, мониторить наличие связи. П.С. Спасибо за помощь, разобрался, кстати ровно 20 пакетов в секунду - действительно всё удобно. Забываем, что это "сохо роутер", общаемся просто с Lin машиной. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 апреля, 2017 · Жалоба П.С. Спасибо за помощь, разобрался, кстати ровно 20 пакетов в секунду - действительно всё удобно. Забываем, что это "сохо роутер", общаемся просто с Lin машиной. Могу по дефолту увеличить в софте тогда лимит. 10 или 20 для решения задачи защиты от зафлуживания разницы нет. Т.е. можно несколько увеличить дефолт. Наверное так и сделаю. Забываем, что это "сохо роутер", общаемся просто с Lin машиной. Ну собсно да, именно так и есть, маленький Linux ноги у которого ооооооооочень давно выросли из uClinux (правда от него в чистом виде ничего не осталось). И инит скриптовый тоже не спроста тяну в то время как даже на больших системах во всю шизофрения со всякими systemd. Как бы задача дать чловеку с мозгом свободу делать, что он захочет при этом оставить web в максимально лаконичном виде что бы и блондинка могла настроить. P.S. Увеличил дефолт до 25/s (36кбит флуда 1500байт пакетами не страшно). C 5.3.7 будет в сборках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 апреля, 2017 · Жалоба Как говорится, ковыряние в удалённом фаерволе - к дальней дороге. А тут ещё момент, что жезезка за 15 км от меня. Ну эт да =) С радио там всё нормально, всё снимается по SNMP, тут задача простая как "бревно". Ну я не грю что ненормально. Но вот такие подвыверты могут сильно осложнить мониторинг на основе icmp echo. Т.к. по пингам например будет всё ОК. А по факту... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlbertBUG Опубликовано 18 мая, 2017 · Жалоба Подскажите если можно, vpn не получается поднять между CPE-MD1 и CPE-W4N-MT. Нужно заставить W4N ходить в инет через MD1. Прошивка на обоих последняя на текущий момент от 28.04. ppp0 в кач-ве основного шлюза постоянно отваливается, и в VPN Client состояние из Online переходит в Connecting.. Логи в текстовике приложил. vpn.txt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 18 мая, 2017 · Жалоба С роутами беда. Пропишите статик роут до VPN сервера через DGW по WAN который выдаётся через DHCP затем настраивайте туннель. Иначе у вас сейчас поднимается туннель и в него перекидывается DGW после чего всё умирает. Он просто незнает куда слать и откда принимать пакеты. Для большинтсва случаев оно само всё что надо добавляет, но... Глядя в лог ничего другого в голову не приходит навскидку. Может где-то подсети пересекаются. Или клиент и сервер в одной подсети но при этом должны ходить один фиг через DGW. Такие случае прошивка сама не в силах задетектить. Тут ИИ нужен. =) P.S. Для проверки догадки можно убрать галку DGW в настройках клиента, если обрывы прекратятся то копаем в эту сторону дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DinarD Опубликовано 19 мая, 2017 (изменено) · Жалоба Давайте уже в профильный раздел с описанием схемы тестирования, описанием устройств, со скринами рожи и т.д. А то разговоры про обычный порошок и другие роутеры не дадут нужного результата как ни крути. Тот же ноут, но роутер другой (Кинетик гига 3) на md1 сеть wifi Wive-NG-MT,на другом OfficeUN. Изменено 19 мая, 2017 пользователем DinarD Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Artemiy Опубликовано 19 мая, 2017 · Жалоба Роутер SNR-CPE-W4N Версия ПО 4.3.14.RU.17052016 Платформа MT7620 2T2R 2.4GHz, 100FDX Настроен в режиме роутера. Реквизиты статикой(один IP), в остальном настройки роутера не изменялись. Сеть из себя представляет: роутер SNR-CPE-W4N, включен wifi (максимум 3 девайса). В LAN порт роутера включен 8-ми портовый dlink (должен быть неуправляемый). В dlink стянуты парочка ПК и принтер. ------- Проблема: Каждые 5 минут пропадает связь из LAN до внешней сети. Пингплоттер (ПК по кабелю в LAN) показывает отсутствие потерь до LAN-интерфейса (192.168.1.1) и наличие потерь до всех внешних IP. Пинги из LAN. Скрины пингплоттера: https://vk.com/photo74628755_456239271 https://vk.com/photo74628755_456239272 Потерь из внешних сетей до WAN-интерфейса нет. Отсюда делаю вывод, что какая-то проблема на роутере с перекладкой трафика из LAN в WAN, возможно, что-то с NAT. В логах в момент проблемы чисто. Снять дампы трафика за роутером(с WAN) проблематично, т.к. оператор связи не расторопный. Может кто-то сталкивался с проблемой, что можете посоветовать? Вопрос на опережение: при обновлении прошивки конфиг слетит(планирую обновиться удалённо)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
megahertz Опубликовано 19 мая, 2017 · Жалоба думаю что однозначно обновляться, резетить и конфигурить заново руками, потом повторно снимать лог. И тут же вроде видно что потери на экстриме. Что трэйс до других узлов говорит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Artemiy Опубликовано 19 мая, 2017 · Жалоба Второй хоп 91.229.235.193 - это AS57003 91.229.234.0/23 PortalTeleNet LLC - там и включен роутер. Потери не на экстриме, а в том провайдере, к которому подключен. Иначе говоря сразу за WAN-интерфейсом роутера. Трейс до других хостов аналогичен, потери за роутером. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 19 мая, 2017 · Жалоба Второй хоп 91.229.235.193 - это AS57003 91.229.234.0/23 PortalTeleNet LLC - там и включен роутер. Потери не на экстриме, а в том провайдере, к которому подключен. Иначе говоря сразу за WAN-интерфейсом роутера. Трейс до других хостов аналогичен, потери за роутером. Ну дык и разбирайтесь с тем что выше WAN роутера. Шнурки и т.д... Может длинк прёт и т.д. С чего вывод что проблема в роутере? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...