Вы должны войти в систему для того, чтобы создавать сообщения и темы.

Ошибки/шероховатости в WEBUI

Описываем общие проблемы интерфейса Wive-NG-MT.
Обязательно приложить, конфиг, логи, указать точные версии браузеров на которых воспроизводиться проблема и так как обсуждается UI то его снимок.

Просьба описывать внятно, без дополнений аля (просто интересуюсь и подобных). Вместо этих дополнений просьба развёрнуто описать почему вам кажется, что должно быть иначе и т.д. Чем точнее опишите и больше полезной информации дадите - тем больше шансов на правку, в т.ч. вне очереди.

Есть небольшая недоработка на вкладке Administration/Management.

Выбран английский интерфейс, но кнопки и надписи некоторые на русском:

Загруженные файлы:
  • wive2.png

Это тулкит рисует, в FF на GTK будет обзор =) Короче оно само локализуется на язык системы т.к. это штатный стандартный кноп выбора файла.

Кстати, при отключении контроля потока, когда нажимаю на Применить, всплывает диалог о перезагрузке. И если нажать в нём Отмена, то всё-равно происходит применение настроек в течении пяти секунд и они выставляются(в nvram?).

К этому ещё прибавлю "Undefined" синими буквами вместо заголовка меню L2-туннелей.

Цитата: CHIPSET от 02/09/2018, 03:54

Кстати, при отключении контроля потока, когда нажимаю на Применить, всплывает диалог о перезагрузке. И если нажать в нём Отмена, то всё-равно происходит применение настроек в течении пяти секунд и они выставляются(в nvram?).

К этому ещё прибавлю "Undefined" синими буквами вместо заголовка меню L2-туннелей и

Подключил вебера к теме. Будет разбираться.

Ещё один момент обнаружил в этом месте: при изменении настроек коммутатора извне(а возможно и других, где требуется перезагрузка), после отсчёта происходит перенаправление на внутренний адрес. Т.е. вместо внешнего адреса меня отправляет на 192.168.1.1, хотя я снаружи. Возможно лучше сделать не перенаправление на конкретный адрес, а просто обновление страницы, как при изменении остальных настроек.

Версия? Вроде правили в последнем срезе это уже? Для LAN точно для коммутатора не помню. Обновитесь для проверки.

Обновил до последней. Поправлен только "undefined", остальное также. Прошивку кстати тоже извне обновлял и почему-то после того, как отсчёт доходит до нуля ещё минуту с лишним Хром висит на этом(не удаётся достучаться до веб-сервера, пробовал даже в соседней вкладке).

Ок. Вебер читает этот топик, пусть разбирается. Всё это последствия переезда на nginx, очень многое нужно было переделать, потому уши по сей день всплывают. Бум фиксить.

Ну а при обновлении из вне фиг его знает сколько понадобиться времени на переподъём соединения и прочие. Так что тут с таймерами не угадать особо. Хотя можно подумать и увечиличивать их вдвое при работе с WAN.

Небольшая опечатка, должно быть: /etc/ppp/resolv.conf

Загруженные файлы:
  • opechatka.png

пофиксил

Не первый раз натыкаюсь на неприятную особенность страницы "Main Wireless Settings" - с мобильного телефона (LG M320 на MTK6750), браузер Chrome (v.69.0.3497.100) при запуске скана сети для просмотра "состояния эфира" ничего не сканится, тупо вращается круг ожидания до бесконечности. В логе при этом вот такие строки:

Sep 21 19:12:03 nginx: 2018/09/21 19:12:03 [info] 3711#0: *31 recv() failed (145: Unknown error) while keepalive, client: 192.168.74.112, server: 0.0.0.0:80
Sep 21 19:14:13 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-1309) from b4:f7:a1:79:b9:78, reason=7
Sep 21 19:14:14 kernel: ASSOC - Assign AID=1 to 2.4GHz STA b4:f7:a1:79:b9:78
Sep 21 19:14:14 kernel: ASSOC - HT support STA. Update AP OperaionMode=3, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=1
Sep 21 19:14:15 udhcpd[10478]: sending ACK to 192.168.74.112
Sep 21 19:14:18 nginx: 2018/09/21 19:14:18 [info] 3711#0: *33 client 192.168.74.112 closed keepalive connection (131: Connection reset by peer)
Sep 21 19:15:05 kernel: ASSOC - Assign AID=1 to 2.4GHz STA b4:f7:a1:79:b9:78
Sep 21 19:15:05 kernel: ASSOC - HT support STA. Update AP OperaionMode=3, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=1
Sep 21 19:15:05 udhcpd[10478]: sending ACK to 192.168.74.112
Sep 21 19:15:06 nginx: 2018/09/21 19:15:06 [info] 3711#0: *34 client 192.168.74.112 closed keepalive connection (131: Connection reset by peer)
Sep 21 19:15:23 nginx: 2018/09/21 19:15:23 [info] 3711#0: *35 Authentication successful: user=Admin , client: 192.168.74.112, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.74.1", referrer: "http://192.168.74.1/login.asp"
Sep 21 19:15:36 nginx: 2018/09/21 19:15:36 [info] 3711#0: *40 client closed connection while waiting for request, client: 192.168.74.112, server: 0.0.0.0:80

В конце лога - это я перелогинился на роутер через вэбку, потому что страницу с настройками вайфай после нескольких попыток нажать на "Scan" глюкануло не по-детски и вывалило на показ дефолтную страницу с настройками аж двух диапазонов с дефолтными значениями, хотя роутер с одним диапазоном - 2.4ГГц.

После нескольких переходов по разным страницам настроек иногда скан срабатывает, иногда нет.

На телефоне заметил, что после нажатия на "Scan" на секунду пропадает  сигнал вайфай.

Со стационарного компа добиться "неработающего" скана (при подключении по проводу) пока не получилось. Если получится заскринить на мобилке этого"жука", то выложу скриншот.

PS. Получилось повторить "трюк" с дефолтной страницей настроек вайфай, последовательность действий такая:

1. Идём с телефона через браузер на главную страницу настроек вайфай и нажимаем скан

2. Если скан не срабатывает и крутится кольцо ожидания, то жмём на смену канала и выбираем любой канал, отличный от текущего канала. Жмём Apply.

3. Выпадает окно с отсчётом секунд, потом браузер немного задумывается и... вываливает на экран мобильного вот такую картину, как на приложенных скринах.

4. Реально канал вайфай меняется на тот, который выбирали, но почему то вэб-сервер отображает страницу с дефолтами, а не с настройками.

PPS. Описание сумбурное, но как-то так.

 

Загруженные файлы:
  • screenshot_2018-09-21-19-40-57.png
  • screenshot_2018-09-21-19-41-12.png

Механизм возникновения проблемы понятен: дело в том, что Ваш телефон подключен к веб-интерфейсу через тот же радиомодуль роутера, который сканирует эфир и не может одновременно взаимодействовать с Вашим телефоном, соединение с сервером обрывается, и интерфейс не может загрузить необходимые данные. Я подумаю, как обеспечить корректную работу интерфейса в этом случае.

Провёл небольшое исследование этой "проблемы", походу виноват полусвежий Андроид (7.0) на моём мобильном и сам мобильный аппарат.

Ни с компа через вайфайный адаптер (через браузеры хром и огнелис), ни с планшета на Андроиде 5.1 через родной андроидовский и yandex-броузер я не смог повторить "неработающий" скан. Оба варианта пропажи вайфай при скане сети как будто и не замечают.

Дальше продолжил со своим мобильным и выяснил, что самый отстойный вариант - это хром, далее по глюкавости идёт Samsung Internet browser (перекрашенный хром) и замыкает тройку - Yandex браузер. С последним эффект "неработы" кнопки скан проявляется в редких случаях.

В ходе экспериментов возникло ощущение, что проще всего повторить "баг", если после логина через вэбку сразу идти в настройки вайфай и жать "скан", если же немного побродить по менюхам вайфай и только после этого нажать "скан", то поймать багу практически нереально. Такое ощущение, что в первый раз браузер кэширует страницу и потом её ему проще отрисовать и показать результаты сканирования. ИМХО.

PS. В логе вот такое творится:

Sep 21 20:48:43 kernel: ASSOC - Assign AID=1 to 2.4GHz STA 28:cc:01:cd:66:7b
Sep 21 20:48:43 kernel: ASSOC - HT support STA. Update AP OperaionMode=2, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=1
Sep 21 20:48:47 udhcpd[19102]: sending OFFER of 192.168.74.123
Sep 21 20:48:47 udhcpd[19102]: sending ACK to 192.168.74.123
Sep 21 20:49:15 nginx: 2018/09/21 20:49:15 [info] 3711#0: *108 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:33 nginx: 2018/09/21 20:49:33 [info] 3711#0: *109 Authentication successful: user=Admin , client: 192.168.74.123, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.74.1", referrer: "http://192.168.74.1/login.asp"
Sep 21 20:49:35 nginx: 2018/09/21 20:49:35 [info] 3711#0: *110 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *111 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *109 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *120 client closed connection while waiting for request, client: 192.168.74.123, server: 0.0.0.0:80
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *119 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *113 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *112 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *115 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *116 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *117 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:37 nginx: 2018/09/21 20:49:37 [info] 3711#0: *118 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:42 nginx: 2018/09/21 20:49:42 [info] 3711#0: *121 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *123 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *131 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *122 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *130 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *124 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *127 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *128 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:44 nginx: 2018/09/21 20:49:44 [info] 3711#0: *129 client 192.168.74.123 closed keepalive connection
Sep 21 20:49:54 nginx: 2018/09/21 20:49:54 [info] 3711#0: *132 client 192.168.74.123 closed keepalive connection
Sep 21 20:50:08 nginx: 2018/09/21 20:50:08 [info] 3711#0: *133 client 192.168.74.123 closed keepalive connection
Sep 21 20:50:20 nginx: 2018/09/21 20:50:20 [info] 3711#0: *134 client 192.168.74.123 closed keepalive connection
Sep 21 20:51:17 nginx: 2018/09/21 20:51:17 [info] 3711#0: *136 client closed connection while waiting for request, client: 192.168.74.123, server: 0.0.0.0:80
Sep 21 20:51:17 nginx: 2018/09/21 20:51:17 [info] 3711#0: *135 Authentication successful: user=Admin , client: 192.168.74.123, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.74.1", referrer: "http://192.168.74.1/login.asp"
Sep 21 20:51:47 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA 28:cc:01:cd:66:7b
Sep 21 20:51:47 kernel: ReASSOC - HT support STA. Update AP OperaionMode=2, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=1
Sep 21 20:52:19 nginx: 2018/09/21 20:52:19 [info] 3711#0: *137 client 192.168.74.123 closed keepalive connection
Sep 21 20:52:19 nginx: 2018/09/21 20:52:19 [info] 3711#0: *135 client 192.168.74.123 closed keepalive connection
Sep 21 20:52:19 nginx: 2018/09/21 20:52:19 [info] 3711#0: *138 client 192.168.74.123 closed keepalive connection
Sep 21 20:52:19 nginx: 2018/09/21 20:52:19 [info] 3711#0: *139 client 192.168.74.123 closed keepalive connection
Sep 21 20:52:19 nginx: 2018/09/21 20:52:19 [info] 3711#0: *140 client 192.168.74.123 closed keepalive connection
Sep 21 20:52:31 kernel: 2.4GHz AP ASSOC - receive DIS-ASSOC(seq-517) request from 28:cc:01:cd:66:7b, reason=8
Sep 21 20:52:43 kernel: ASSOC - Assign AID=1 to 2.4GHz STA b4:f7:a1:79:b9:78
Sep 21 20:52:43 kernel: ASSOC - HT support STA. Update AP OperaionMode=2, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=0
Sep 21 20:52:43 udhcpd[19102]: sending ACK to 192.168.74.112
Sep 21 20:53:04 nginx: 2018/09/21 20:53:04 [info] 3711#0: *142 Authentication successful: user=Admin , client: 192.168.74.112, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.74.1", referrer: "http://192.168.74.1/login.asp"
Sep 21 20:53:21 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-2903) from b4:f7:a1:79:b9:78, reason=7
Sep 21 20:53:24 kernel: ASSOC - Assign AID=1 to 2.4GHz STA b4:f7:a1:79:b9:78
Sep 21 20:53:24 kernel: ASSOC - HT support STA. Update AP OperaionMode=2, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=0
Sep 21 20:53:24 udhcpd[19102]: sending ACK to 192.168.74.112
Sep 21 20:53:27 nginx: 2018/09/21 20:53:27 [info] 3711#0: *146 recv() failed (145: Unknown error) while keepalive, client: 192.168.74.112, server: 0.0.0.0:80
Sep 21 20:53:53 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-3059) from b4:f7:a1:79:b9:78, reason=7
Sep 21 20:53:55 kernel: ASSOC - Assign AID=1 to 2.4GHz STA b4:f7:a1:79:b9:78
Sep 21 20:53:55 kernel: ASSOC - HT support STA. Update AP OperaionMode=2, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=0
Sep 21 20:53:56 udhcpd[19102]: sending ACK to 192.168.74.112
Sep 21 20:53:56 nginx: 2018/09/21 20:53:56 [info] 3711#0: *148 client 192.168.74.112 closed keepalive connection (131: Connection reset by peer)
Sep 21 20:56:21 nginx: 2018/09/21 20:56:21 [info] 3711#0: *151 client closed connection while waiting for request, client: 192.168.74.112, server: 0.0.0.0:80
Sep 21 20:56:21 nginx: 2018/09/21 20:56:21 [info] 3711#0: *150 Authentication successful: user=Admin , client: 192.168.74.112, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.74.1", referrer: "http://192.168.74.1/login.asp"
Sep 21 20:56:56 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-3248) from b4:f7:a1:79:b9:78, reason=7
Sep 21 20:56:58 kernel: ASSOC - Assign AID=1 to 2.4GHz STA b4:f7:a1:79:b9:78
Sep 21 20:56:58 kernel: ASSOC - HT support STA. Update AP OperaionMode=2, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=0
Sep 21 20:56:58 udhcpd[19102]: sending ACK to 192.168.74.112
Sep 21 20:57:00 nginx: 2018/09/21 20:57:00 [info] 3711#0: *154 client 192.168.74.112 closed keepalive connection (131: Connection reset by peer)
Sep 21 20:58:19 nginx: 2018/09/21 20:58:19 [info] 3711#0: *157 client 192.168.74.112 closed keepalive connection
Sep 21 20:58:19 nginx: 2018/09/21 20:58:19 [info] 3711#0: *159 client 192.168.74.112 closed keepalive connection
Sep 21 20:58:19 nginx: 2018/09/21 20:58:19 [info] 3711#0: *158 client 192.168.74.112 closed keepalive connection
Sep 21 20:58:19 nginx: 2018/09/21 20:58:19 [info] 3711#0: *162 client 192.168.74.112 closed keepalive connection
Sep 21 20:58:19 nginx: 2018/09/21 20:58:19 [info] 3711#0: *160 client 192.168.74.112 closed keepalive connection
Sep 21 20:58:19 nginx: 2018/09/21 20:58:19 [info] 3711#0: *161 client 192.168.74.112 closed keepalive connection
Sep 21 20:59:07 nginx: 2018/09/21 20:59:07 [info] 3711#0: *164 client closed connection while waiting for request, client: 192.168.74.112, server: 0.0.0.0:80
Sep 21 20:59:07 nginx: 2018/09/21 20:59:07 [info] 3711#0: *163 Authentication successful: user=Admin , client: 192.168.74.112, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.74.1", referrer: "http://192.168.74.1/login.asp"
Sep 21 21:00:59 nginx: 2018/09/21 21:00:59 [info] 3711#0: *163 client 192.168.74.112 closed keepalive connection
Sep 21 21:00:59 nginx: 2018/09/21 21:00:59 [info] 3711#0: *168 client 192.168.74.112 closed keepalive connection
Sep 21 21:00:59 nginx: 2018/09/21 21:00:59 [info] 3711#0: *165 client 192.168.74.112 closed keepalive connection
Sep 21 21:00:59 nginx: 2018/09/21 21:00:59 [info] 3711#0: *166 client 192.168.74.112 closed keepalive connection
Sep 21 21:00:59 nginx: 2018/09/21 21:00:59 [info] 3711#0: *169 client 192.168.74.112 closed keepalive connection
Sep 21 21:14:51 nginx: 2018/09/21 21:14:51 [info] 3711#0: *170 Authentication successful: user=Admin , client: 192.168.74.106, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.74.1", referrer: "http://192.168.74.1/login.asp"

Это пара тестов с компа, пара с планшета и остальное в конце с моего мобильного.

PPS. Рассмотрел логи, походу комп вообще сюда не вошёл.. Странно, странно...

Единственная строчка в логе о компе, чуть выше того куска, что привёл и выглядит вот так:

Sep 21 20:36:27 kernel: 2.4GHz AP ASSOC - receive DIS-ASSOC(seq-1191) request from c8:3a:35:ca:9f:c3, reason=8

Больше никаких упоминай (возможно потому что комп из гибернации стартовал)

Пока у себя на андроиде 8.1 ничего подобного отловить не смог: даже если связь пропадает, таймаут у браузера весьма большой, и он успевает "дождаться" переподключения. Разве что ткнуть Scan подряд раз 10, чтобы роутер ещё какое-то время пытался всё это исполнить, и после этого сразу Apply. Видимо, нужно блокировать кнопку Scan, пока предыдущее сканирование не завершено.

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

Пока ничего не меняйте, я отпишусь о результатах.

Есть смысл растащить кнопку на 2. Скан и скан результ. Во первых это позволит смотреть последние результаты + результаты автоматических RRM сканирований, во вторых позволит не релоадить всё и вся а лишь подгружать результаты, а при скане ничего не рефрешить.

С одной стороны казалось бы не очень удобно. С другой стороны решает проблему + одновременно добавляет функционал позволяющий видеть результаты последнего скана или автоматизированных сканирований для RRM.

ИМХО это лучший вариант.

P.S. Последние результаты сканирования всегда хранятся в драйвере в виде массива scantab и доступны для вывода. Так сейчас можно в cli сказать wl scan result и получить их в полном объёме.

PP.S. Версию с фиксами редиректа заливаю на sf.net.

По поводу кнопки Scan и мобильников LG - всё же склоняюсь к мысли, что лжишники чего-то намудрили в сетевом стеке на своих мобилах, по крайней мере в бюджетниках на МТК. Проверил на трёх аппаратах LG, везде страница со сканом вайфай не хочет нормально отображать результат сканирования. Либо обрывает соединение с вэб-сервером, либо повисает на вечном круге ожидания.

Так что можно ничего не править, раз на других клиентах работает.

PS. Но думаю, было бы удобнее, если основную страницу настроек вайфай разделить на несколько, хотя бы на пару: основные настройки и типа продвинутые (роуминг и различные доп. крутилки).

PS. Но думаю, было бы удобнее, если основную страницу настроек вайфай разделить на несколько, хотя бы на пару: основные настройки и типа продвинутые (роуминг и различные доп. крутилки).

Надо сказать, раньше так и было. Однако, большое число вкладок вгоняло некоторых пользователь в дискомфорт (как с точки зрения визуализации, так и с точки зрения необходимости переходить между разделами меню в процессе настройки). Поэтому, решено было "схлопнуть" Basic & Advanced в Main . И поделить страницу на блоки, каждый из которых, кроме "необходимых и достаточных" , по умолчанию свернут.

Цитата: RoxsAndy от 08/10/2018, 18:19

По поводу кнопки Scan и мобильников LG - всё же склоняюсь к мысли, что лжишники чего-то намудрили в сетевом стеке на своих мобилах, по крайней мере в бюджетниках на МТК.

Да вот нет не проблема это LG. Суть проблемы проста и понятна. Да и всё равно надо делать возможность просмотра авто ррм сканирований. Так что разобъём на 2 кнопки и делу с концом. Сразу обе проблемы решатся.

 

Цитата: rgn_sss от 09/10/2018, 00:32

Надо сказать, раньше так и было. Однако, большое число вкладок вгоняло некоторых пользователь в дискомфорт (как с точки зрения визуализации, так и с точки зрения необходимости переходить между разделами меню в процессе настройки). Поэтому, решено было "схлопнуть" Basic & Advanced в Main.

Ну значит я не застал те времена. Раз это уже переделывали, уже не стоит.

Просто там ИМХО немного нелогично например с доп.каналом для 2T2R устройств получается. Основной настраивается в самом верху страницы, а доп.канал упрятан в спойлере, где-то ближе к низу. Может для кого-то это и удобно, но с мобильного, однозначно, для меня - нет. Опять же ИМХО.

По доп. каналу уже тоже обсуждали, согласен, что это не слишком удобно, но на тот момент вверху было не очень много свободного места, чтобы органично уместить туда дополнительный канал. Под мобильные у нас интерфейс пока вообще не очень заточен: заранее с прицелом на мобильные была написана разве что форма логина. Все остальные страницы нужно дорабатывать в соответствии с гайдлайнами для тача.

После правок Web-морды (не последних, а каких-то из предыдущих) вылезла одна бага при моей конфигурации (static - WAN, PPPoE - VPN, IPv6 - отключено).

Суть в следующем: статик соединение настроено полностью вручную (см.скриншот). Провайдер для местной сети даёт IP, маску, шлюз и ОДИН dns-сервер.

При поднятии VPN (PPPoE) для глобальной сети получаю ещё один dns для внешних ресурсов (вернее их получаю два, но они дублируются). Так вот этот второй dns начинает показываться во вкладке WAN вместе со статическим, что как бы не совсем правильно. Ладно бы просто отображался, но при изменении настроек на этой странице он прописывается в nvram в wan_secondary_dns. Причём если при изменении настроек взять и стереть это значение из поля  Secondary DNS Server, то это ни на что не повлияет, в nvram всё равно запишется dns от VPN.

Да и на вкладке Status отображение DNS серверов не совсем корректное. По хорошему там бы как-нибудь разделить типы подключения WAN/VPN  и соответствующие адреса, а то всё в одну кучу и не совсем логично. Но это моё личное мнение, не претендующее на истину.

Загруженные файлы:
  • dns3.png
  • dns4.png

Не помню что бы в логике настройки WAN DNS бы брались откуда-то кроме nvram. Sadler глянь, странно это. Как бы не прибабах браузера с автоподстановкой какой.

 

Дело не в браузере: значение статиков действительно зачем-то берётся из /etc/resolv.conf, а не из nvram. Я догадываюсь, что эта функция была написана для Administration / Status, чтобы иметь актуальные данные, а потом её просто заюзали в dns.

Ну значит надо выправить это дело. Видать кто-то запарился когда-то.

fixed

Немного запарился и ещё не собирал последний срез. Вечером попробую и отпишусь.

Ой да ладно не горит. Но  за репорты пасиб.

Вот по представлению DNS тут всё интереснее, на самом деле они в конечном итоге все попадут в resolv.conf и нет разницы откуда они прилетели. Думаю пока не будем это дело выделять отдельно. Как бы после окончания функциональных правок один фиг визуализация будет потихоньку переписываться, тогда уже будем решать как лучше распарисить и вывести resolv.conf в рожу. Пока просто смысла немного т.к. другой работы вагон, а этот момент чистая косметика.

Проверил 7.6.9. Отображение статики DNS на вкладке WAN поправленно. Подтверждаю! :)

По выводу на странице "Status", в принципе, не критично. Как решите, так и делайте. ИМХО, я бы просто отделил отображение wan-соединение с провом от vpn-соединения с глобалкой. А в случае отсутствия vpn - скрывал бы этот раздел. Простенько и со вкусом.

Но вот с парсингом dns-серверов действительно будут заморочки. Как вариант - запоминать их в глобальных переменных: для статики - подтягиваем из nvram, для vpn берём по peerdns.

Здравствуйте!

Роутер - SNR-CPE-ME1

Прошивка - 7.5.32,  в 7.6.15 тоже самое.

  1. Не отображается сохраненный пароль для 5ГГц.
  2.  Может не сохранять другие параметры, например - период сканирования при использовании автовыбора канала.
  3. Складывается ощущение, что начиная с какой-то версии что-то поломано в логике Веб-интерфейса. При нескольких изменениях и сохранениях в меню "Настройки радио" начались проблемы с 2,4ГГц сетью. Некоторые устройства перестали ее видеть, некоторые писали, что сеть скрыта.

Временно прошил 7.3.20, проблемы пропали.

Загруженные файлы:
  • wpa_me1_7.5.32.png

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

Опять таки браузеры какие. При доступе по http или https? Всякие фильтровалки и прочее отключено? Антивирусы и т.д.?

Как включить отладку и что посмотреть Sadler подскажет. Но я ничего подобного лично не вижу. Т.е. нужно выяснять в чём отличия. Т.е. обновляетесь на последню  тестовую версию, сбрасываете настройки кнопкой, настраиваете с нуля вручную (не загрузкой конфига).

Далее Sadler расскажет что делать. Очень похоже на то, что рожу нагло покрамсала какая-то баннерорезалка.

 

Сетевая карта Intel, встроенная в материнскую плату. Операционная система Win7 x64 HP. Используемые браузеры - FF, Chrom, Opera, все последних версий, дополнительные плагины не устанавливались. Доступ в последней прошивке вроде по https, в 7.3.20 по http. Антивирус Dr.Web, который кстати временно не отключается как Касперский или я что-то не знаю.

Встроенная в браузер Банерорезка возможно, но почему тогда на 7.3.20 проблем нет ?

 

 

Например потому что кода который не нравиться могло ещё не быть там например. Со всеми этими антивирусами и баннерорезалками регулярно всплывает геморрой т.к. лезут руками в трафик.

Отключение не всегда спасает, часто либо нужно  в исключения тех же говноантивирусов добавлять адрес роутера либо только удаление, либо геморрой с обходом на стороне UI т.е. выявление чего режется и т.д.

Вроде как по https это круто. 7.3.20 забудьт уже мертва надо разбираться с последним. Проверьте в общем при доступе по http/https нужно сократить место поиска и  выяснить при каких условиях повторяется, тогда можно будет поправить.

Цитата: DizMan от 10/11/2018, 10:42

Используемые браузеры - FF, Chrom, Opera, все последних версий,

Перейдите на страницу, где не отображается пароль, нажмите Ctrl+Shift+I (это инструменты разработчика как в Chrome, так и в FF), перейдите на вкладку "Console"  и посмотрите, отображаются ли какие-то ошибки.

Антивирус Dr.Web, который кстати временно не отключается как Касперский или я что-то не знаю.

Даже если нет специальной опции для отключения на время, можно перейти в "компоненты защиты" и отключить их все на несколько минут для проверки.

Отключил кабель от Wan.
Отключил на время все компоненты DrWeb. Сбросил через кнопку настройки роутера, поставил обратно прошивку 7.6.15.RU.08112018, больше ничего не менял.
Использовал:
Firefox ESR  60.3.0 October 23, 2018 (32 бит)
Google Chrome 70.0.3538.102 (Официальная сборка) (64 бит)

Подключение hhtp.
Смотрите прикрепленные фаилы.
Загруженные файлы:

Перейдите на http://192.168.1.1/js/nvram.js , найдите строку  "var NVRAM_WPAPSK1INIC = ваш_пароль" . Там тоже пусто, или пароль отображается? Вы также можете перейти в "Администрирование / Управление", сохранить конфигурацию в файл и прикрепить к сообщению, чтобы я сам взглянул, но учтите, что все пароли там тоже будут в открытом виде.

Пароли потом поменяю.

Сделал эксперемент. Возможно проблема в этом. У меня пароль из 63 символов, пароль для 5Ггц - {пароль удалён}

Если ввожу простой пароль проблема вроде пропадает. Может дело в наборе символов ?

См. архив. {архив удалён}

 

Цитата: DizMan от 10/11/2018, 15:11

Может дело в наборе символов ?

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

Sadler

Я уже думал, что особенный.)

Будьте добры, затрите все что мной написано. Если все не хотите, то только конфиденциальную информацию.

Рад, что смог помочь в улучшении прошивки.

Пробуйте 7.6.17, должно полечиться https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/test-only/

Вышеописанная проблема с паролями в 7.6.17 не проявляется. Проверил именно на проблемном наборе символов.

Ок. Там сейчас Sadler ещё допилит окончательно все эти дела с проверками ввода и экранированием, будет просьба ещё разок контрольный выстрел в голову с проверкой. И поедем дальше.

Проверил на 7.6.18. Сменил несколько комбинаций паролей, проблем не обнаружено.