Исправили, как я понял, в r7454Quote:
Originally Posted by starter
Printable View
Исправили, как я понял, в r7454Quote:
Originally Posted by starter
Добрый день.
Дорогие форумчане подскажите, пожалуйста, после обновления до прошивки: 1.9.2.7-rtn-r7440M-g736a62c, постоянно стала выскакивать вот такая фигня:
May 23 13:39:25 dnsmasq-dhcp[217]: DHCPACK(br0) 192.168.1.11 7c:2f:80:62:3a:c3 C610A-IP
May 23 13:40:02 dnsmasq-dhcp[217]: DHCPINFORM(br0) 192.168.1.11 7c:2f:80:62:3a:c3
May 23 13:40:02 dnsmasq-dhcp[217]: DHCPACK(br0) 192.168.1.11 7c:2f:80:62:3a:c3 C610A-IP
May 23 13:40:07 dnsmasq-dhcp[217]: DHCPINFORM(br0) 192.168.1.11 7c:2f:80:62:3a:c3
May 23 13:40:07 dnsmasq-dhcp[217]: DHCPACK(br0) 192.168.1.11 7c:2f:80:62:3a:c3 C610A-IP
May 23 13:40:33 dnsmasq-dhcp[217]: DHCPINFORM(br0) 192.168.1.11 7c:2f:80:62:3a:c3
May 23 13:40:33 dnsmasq-dhcp[217]: DHCPACK(br0) 192.168.1.11 7c:2f:80:62:3a:c3 C610A-IP
На данном IP находится ip телефон.
Где ошибка? Куда копать?
Вроде не первый день на форуме, данные для анализа можно было бы предоставить сразу :confused:. Видно же что не "фигня", а сообщения от dnsmasq!Quote:
Originally Posted by kostyal
Старая версия какая? Какое настроено время жизни IP-адреса по DHCP в LAN?
Похоже что телефон не ужился с новой версией dnsmasq 2.76, надо поднимать уровень логгирования ключиком --log-dhcp
Тогда можно будет попробовать увидеть что пошло не так.
Большое спасибо за быстрый отклик по моему вопросу.Quote:
Originally Posted by lly
Проблема решилась, один из свичей стал выходить из строя и перезапускался постоянно. Заменил, ошибка пропала.
И снова простите за беспокойство.
Вылез какой то косяк после установки новой прошивки:
Сам поковырялся, но проблема осталась.Code:May 24 14:55:16 miniupnpd[345]: addmasqueraderule() : chain UPNP-POSTROUTING not found
May 24 14:55:16 miniupnpd[345]: add_redirect_rule2(): addmasqueraderule returned -1
May 24 14:55:16 miniupnpd[345]: addmasqueraderule() : chain UPNP-POSTROUTING not found
May 24 14:55:16 miniupnpd[345]: add_redirect_rule2(): addmasqueraderule returned -1
May 24 15:06:39 miniupnpd[345]: addmasqueraderule() : chain UPNP-POSTROUTING not found
May 24 15:06:39 miniupnpd[345]: add_redirect_rule2(): addmasqueraderule returned -1
May 24 15:06:39 miniupnpd[345]: Failed to add NAT-PMP 51795 tcp->192.168.1.2:51795 'NAT-PMP 51795 tcp'
May 24 15:06:39 miniupnpd[345]: addmasqueraderule() : chain UPNP-POSTROUTING not found
May 24 15:06:39 miniupnpd[345]: add_redirect_rule2(): addmasqueraderule returned -1
May 24 15:06:39 miniupnpd[345]: Failed to add NAT-PMP 51795 udp->192.168.1.2:51795 'NAT-PMP 51795 udp'
May 24 15:20:14 miniupnpd[345]: addmasqueraderule() : chain UPNP-POSTROUTING not found
May 24 15:20:14 miniupnpd[345]: add_redirect_rule2(): addmasqueraderule returned -1
May 24 15:22:27 miniupnpd[345]: remove port mapping 12340 TCP because it has expired
May 24 15:48:40 miniupnpd[345]: addmasqueraderule() : chain UPNP-POSTROUTING not found
May 24 15:48:40 miniupnpd[345]: add_redirect_rule2(): addmasqueraderule returned -1
May 24 15:48:40 miniupnpd[345]: Failed to add NAT-PMP 51795 tcp->192.168.1.2:51795 'NAT-PMP 51795 tcp'
May 24 15:48:40 miniupnpd[345]: addmasqueraderule() : chain UPNP-POSTROUTING not found
May 24 15:48:40 miniupnpd[345]: add_redirect_rule2(): addmasqueraderule returned -1
May 24 15:48:40 miniupnpd[345]: Failed to add NAT-PMP 51795 udp->192.168.1.2:51795 'NAT-PMP 51795 udp'
Ни кто не знает в чем может быть проблема?
День добрый! Такая проблема непомню уже с какой версии вашей прошивки появилась,последнюю пробовал 1.9.2.7-rtn-r7459M-g2f6d2a0-стоит на минут пять отключить устройства от вайфая как потом невозможно подключиться,как будто засыпает вайфай модуль-по лан-портам интернет нормально раздается в это время,помогает перезапуск вайфай модуля или перезагруз роутера.Если активно юзается вайфай то хоть целый день сиди-все нормально работает,а как только отключишься от сети так потом только перезапуск модуля спасает-ненаходят устройства моей вайфай сети.Роутер ASUS rt-n15u.Может где в настройках какой нить автослип выключается-сам ненашёл,помогите пожалуйста.С родной асусовской прошивкой все работает норм, с вашей побыстрее :)
Он у вас точно засыпает? У меня была похожая проблема, при запуске ноута по wifi (выход из спящего режима) ОЧЕНЬ долго происходил поиск точки. Все решилось переустановкой дров на более старые. Данный эксперимент проводил на разных ноутах, везде приходилось откатывать дрова на старые (новые какие то кривые)Quote:
Originally Posted by netbuk
Становится невидно моей созданной вайфай сети-ни смартфоны,ни планшет и ноутбук пишут что сеть моя не найдена.перезапускаю вайфай модуль и все опять работаетQuote:
Originally Posted by kostyal
Исправлено начиная с r7454Quote:
Originally Posted by kostyal
Там нечего "ковыряться" если известно что такое iptables. ВыводQuote:
Сам поковырялся, но проблема осталась.
в студию!Code:iptables -t nat -L
Очень интересно как это вы перезапускете вайфай модуль.Quote:
Originally Posted by netbuk
Более похоже на аппаратную проблему, блоб wl.ko не менялся несколько лет.
С веб морды захожу и там Status & Log-WiFi-Disable потом Enable. На родной асусовской прошивке все работает нормально так что врятли аппаратное что нить.Может логи какие скинуть?Quote:
Originally Posted by lly
Прошу прощения за панику ,Методом тыка :) сам нашел в чем причина, Wireless-Advanced-и там включена была опция Enable Frame Bursting,отключил и теперь нормально все.раньше с ней работалоQuote:
Originally Posted by netbuk
Недавно theMIRon'ом был обновлен dnsmasq до 2.76 :)Quote:
Originally Posted by lly
https://github.com/wl500g/wl500g/commits/master
https://bitbucket.org/padavan/rt-n56u/commits/master
Можно еще будет включить там и поддержку скриптов ;)
http://wl500g.info/showthread.php?28...618#post269618
Спасибо за помощь. Проставил последнюю версию прошивки, все ОК.Quote:
Originally Posted by lly
хм, я правильно понимаю, что сейчас изменилась "работа с usb"
раньше было /dev/discs/disca/part1, а сейчас usb как-то по другому обзываются ибо все отвалилось :-(
прошивка r7470M rt-n16
а не, "мой" косяк. оказывается при обновлении прошивки "что-то пошло не так" и она виделась, но не монтировалась
из-за (вроде) неудачной синхронизации при последнем размонтировании, уже не помню, вчера разбирался...
вынул флешку, натравил fsck, теперь норм.
Прошу помощи у коллективного разума. Имеем RT-N16 и сырцы r7487M, плюс LZO 2.09, zlib 1.2.8, openssl 1.0.2h, openvpn 2.3.11
Интегрировал все в прошивку, собрал тулчейном, которым собирается сама прошивка, openvpn на роутере в качестве клиента запускается, поднимается tun интерфейс, в логах все ОК, и с роутера я серверный IP пингую, но в обратную сторону с сервера клиентский IP не пингуется, более того кроме пингов больше ничего не работает, к примеру wget с роутера на сервер даже подключаться не хочет
и так и висит. При этом видно что сервер пакеты шлет, а роутер их как-будто не видит, хотя tcpdump все видит. Так же и с пингами, на роутерном tun0 видно что запросы приходят, а роутер тупо не отвечает. В iptables все в ACCEPT.Code:[router@router root]$ wget -O /dev/null http://10.8.0.1/test.zip
Connecting to 10.8.0.1 (10.8.0.1:80)
Друзья, подскажите куда копать?Code:$ tcpdump -vvvv -ni tun0
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
04:24:31.980467 IP (tos 0x0, ttl 64, id 26770, offset 0, flags [DF], proto TCP (6), length 60)
10.8.0.1.80 > 10.8.0.6.51115: Flags [S.], cksum 0x6217 (correct), seq 1784613188, ack 3269737748, win 65535, options [mss 1368,nop,wscale 9,nop,nop,TS val 1784424562 ecr 329394], length 0
04:25:25.856684 IP (tos 0x0, ttl 64, id 45779, offset 0, flags [none], proto ICMP (1), length 84)
10.8.0.1 > 10.8.0.6: ICMP echo request, id 27722, seq 0, length 64
04:25:26.859579 IP (tos 0x0, ttl 64, id 46908, offset 0, flags [none], proto ICMP (1), length 84)
10.8.0.1 > 10.8.0.6: ICMP echo request, id 27722, seq 1, length 64
04:25:27.869594 IP (tos 0x0, ttl 64, id 48238, offset 0, flags [none], proto ICMP (1), length 84)
10.8.0.1 > 10.8.0.6: ICMP echo request, id 27722, seq 2, length 64
--
Пересобрал все без своих пакетов, поставил openvpn из entware-ng и вижу такое же поведение. Значит дело в чем-то другом.
---
Похоже я столкнулся с уже известным описанным багом: https://github.com/wl500g/wl500g/issues/451
и действительно на r5066 все работает, на любой другой выше - фиг. Теперь найти бы эту регрессию. Еще одна неприятность в том что после переноса сырцов из code.google на githab svn версии не соответствуют тому что лежит на гитхабе. Теперь только по коментам к патчам догадываться какой это был релиз. Может у кого-то есть svn репозиторий тот, с гуглокода?
Я хочу вас поддержать. Ссылка на мой пост http://wl500g.info/showthread.php?30...636#post269636Quote:
Originally Posted by dvg_lab
Уважаемые разработчики посмотрите, пожалуйста, проблема легко эмулируется и воспроизводится. Роутер через туннель пингуется, а связи с ним нет. Для простоты можно обращаться к тому же udpxy, его страничка статуса не открывается. Оно не зависит является роутер клинетом или сервером. Я уже давно и активно использую OpenVPN на N16 с вашей прошивкой, переодически всё переставляю и помню переход на новые версии, когда оно работать перестало. Сейчас использую http://asus.vectormm.net/rtn/7487/RT...M-g4164297.trx За всё это время (несколько лет) вышло уже очень много прошивок, несколько раз сменился репозиторий и даже сам openvpn обновлялся и поведение не менялось. Т.е. корень зла давно живёт в этой прошивке.
Может это поможет, но кроме недоступности устройств через vpn, с чем я всё это время как то мирился, есть ещё проблемы нестабильной его работы, которые очень заметно появились аккурат после того события смены. И не проходят. Например, при попытках обращения к роутеру через туннель вся связь через роутер пропадает, а потом сама восстнавливается. Пример, пингуем роутер через туннель (я ещё вёл sip телефонный разговор через туннель и смотрел rtp трафик) и одновременно заходим на роутер смотреть ТВ по udpxy через туннель. В результате связь прекращается (пинги и rtp трафик), а потом (до минуты) сама восстанавливается. Роутер не перезагружается, нагрузки цпу в нём большой нет.
А ещё при перезагрузке сервера, особенно при смене им push маршрутов, иногда отваливаются туннели у клиентов, они заваливают лог сообщениями "kernel: unregister_netdevice: waiting for tap0 to become free. Usage count = 1", я об этом писал по ссылке выше. Уменьшает эту проблему (а не исправляет использование persist-key и persist-tun) и иногда явно видно, что у запущенного openvpn'а проблемы удалить и прикрутить новые маршруты.
Если нужна какая то от меня помощь, что то снять или протестировать, готов поучавствовать и помочь. Я пытался сам что то обнаружить, но с сетевой частью всё вроде нормально. Использую tap L2 туннель, даже мультикасты по нему ходят. Если не обращаться через туннель к самому роутеру (напомню, пинги работают) оно нормально пропускает и маршрутизирует трафик.