bigpu
-
Posts
1,512 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by bigpu
-
-
9 минут назад, eralde сказал:
Гм, а мы еще ничего не делали. Скорее всего при меньшей ширине экрана снова вылезет.
нет, тоже все корректно, причем версии браузера те же - Файрфокс, Хром
выравнивание стало корректным до самого перехода двух ссылок в две строки при изменении ширины окна.
-
1
-
-
В логе контроллера периодически "Dns::Manager: invalid domain name: Keenetic_Start" после того, как сменил имя экстендера на "Keenetic_Start"
проблема была и в ПО 3.3.10 и в последней Альфа
-
Только что, eralde сказал:
Это какая-то совсем другая проблема. Лучше создайте отдельную тему.
понял вас.
-
16 часов назад, enterfaza сказал:
мда, а я пока что ещё не разобрался с этими командами, давайте наверное через ТП заведу тикет?
проще всего в браузере - 192.168.1.1/a , дальше все логично.
-
1
-
-
В 19.02.2020 в 11:39, eralde сказал:
Да, надо поправить валидацию. Пробел в этом имени и в имени домена недопустим.
Спасибо за репорт!
немного другая проблема, в логе контроллера периодически "Dns::Manager: invalid domain name: Keenetic_Start" после того, как сменил имя экстендера на "Keenetic_Start"
и в ПО 3.3.10 и в последней Альфа
-
-
6 минут назад, eralde сказал:
Да, разумно, надо доделать.
тоже удивился, когда вкладка не стала фиксироваться. Спасибо!
-
1
-
-
13 часа назад, Le ecureuil сказал:
Да, известная ситуация с переполнением счетчиков в ppe hardware, когда хостов слишком много. Боремся с ней.
планируется сделать привязку вкладки Незарегистрированные устройства в Мониторе через "+", чтобы она как и вкладка у определенных уст-в, не пропадала при обновлении страницы?
-
1
-
-
17 часов назад, Le ecureuil сказал:
Спасибо за репорт, поправлено.
Будет в следующей сборке.
огромный респект за скорость правок!
-
В 16.02.2020 в 02:17, dmitry.a сказал:
Простите, но многие говорят полную глупость.
Во-первых, отличие белого от серого адресов я и так знаю, не стоит тыкать статейками и выставлять меня дураком.
Во-вторых, вы совершенно не знаете ситуации. Мой текущий провайдер самый лучший в районе по цене/качеству, и менять я его не собираюсь (хотя, видимо, местные знатоки хотят мне выделить пару тысяч рубликов каждый месяц на другого провайдера). А еще нет гарантий, что у другого провайдера не будет NAT'а.
В-третьих, людям дешевле вернут роутер и купить другой, написав отрицательный отзыв, чем менять провайдера и переплачивать ежемесячно. Еще раз повторю, что смена провайдера гораздо дороже смены роутера.
В-четвертых, фактически услуга выделенного адреса означает, что доступ из Интернета будет по этому адресу, но не подразумевает, что оконечному оборудованию выдадут белый IP. И поскольку все работает, кроме KeenDNS, то и нет оснований полагать, что провайдер как-то нарушает Закон. Зато есть основания полагать, что KeenDNS работает неправильно, и я нахожу это багом, а не улучшением.
В-пятых, Тут писали, что пользователи слезно просили добавть прямой доступ с серым адресом. Вот, уважаемые знатоки, объясните мне, почему разработчики идут на поводу и добавляют хотелку, но не исправляют очевидный баг? Чем я хуже?
В-шестых, это не фича, а самый настоящий баг. При имеющимся прямом доступе KeenDNS не работает. А что если у меня роутер находится за другим роутером? Тоже предложите пробрасывать белый адрес с первого роутера на второй?
Во-первых, отличие белого от серого адресов я и так знаю
Не знаете, а статейки почитайте, не зря же пишет их Кинетик
Буквально сегодня получил белый IP за 200₽ месяц у плохого РТ.
KeenDNS прекрасно работает "напрямую"
Деньги мне не выделял никто - взял за свои.
-
1
-
1
-
-
При отключении подключения IPv6 через IPv4 (IP4Market) отключается и активное соединение Wireguard'a.
До версии ПО 3.3.10 включительно, такой особенности работы IPv6 через IPv4 точно не было.
-
1
-
-
19 часов назад, Антон Петров сказал:
У меня Wireguard стартует раньше чем PPPoE и дестроится, судя по логам. Чтобы заработал надо руками переподключить.
в логе у меня тоже destroyed у WG, причина мне неизвестна.
-
1
-
-
38 минут назад, r13 сказал:
возможно и так...
это возможно идет с тех пор как реализовали WG у Кинетика, поэтому скорее вопреки)
-
45 минут назад, r13 сказал:
Не, просто ipoe
Тут проблема иного рода - при статическом шлюзе на ISP, WG не поднимается после перезагрузки Кинетика.
Проблема с выбором шлюза по умолчанию для WG-интерфейса, которую до сих пор не допилили.
-
2 часа назад, r13 сказал:
Да, появилась какая-то нестабильность в поднятии wg после перезагрузки.
Потестил, может подняться, а может и нет.
Из отличий по логу вижу такое при неудачной загрузке:
Feb 15 16:48:30 kernel: wireguard: Wireguard0: peer "*********=" (1) (*.*.*.*:51820) destroyed
Далее селфтесты с удачной и не удачной загрузкой.
Gpon в бридже?
-
13 минуты назад, keenet07 сказал:
Ваше право.
верно, оставлю за собою это право, не поддерживать в их желании тех кто ленен и пытается спросить не с тех.
-
1
-
-
1 час назад, vk11 сказал:
Ему уже десять раз сказали, даже разработчики. Но он "купил" адрес у провайдера "10.*" и тупо продолжает утверждать, что это честный белый/прямой адрес, где все на тарелочке с голубой каемочкой (с).
в таком случае приношу свои глубочайшие, раз ТС купил серый IP, а он не не работает как белый
-
1 час назад, keenet07 сказал:
В таком случае оптимальным для кого? Для пользователя в сложившейся ситуации явно так проще, если всё остальное с провайдером его полностью устраивает.
Вы же новых функций типа IPv6 и всего прочего просите у создателей прошивки. Хотя проще пойти и купить другой роутер, где всё это уже есть.
Не хотите? Вот и не будьте тогда столь эгоистичны в своих советах.
оптимальными для большинства юзеров, оптимальными для адекватности реализации базового функционала.
Для данного пользователя, в текущих реалиях, явно проще, о чем я и говорю, требовать изменения "пары строк" от Кинетика, а не пинать своего убогого прова - это же сложнее и тяжко.
Нет, вы не правы, я не хочу новых функций, я хочу лишь допиливания до адекватного состояния текущих, а уже потом реализации новых фич.
Я первый, кто готов укорить Кинетик в косяках и недопиле, но при всем при этом, я всегда стараюсь быть объективным.
В данном разрезе ТС может стать в очередь в реализации нужной ему фичи, которая не пригодится 99% обывателей.
- муждународный рынок продаж компании Кинетик его не должен трогать от слова вообще
- намек о реализации для ТС белого IP силами и средствами другого юзера продукции компании Кинетик, считаю бредом.
-
29 минут назад, keenet07 сказал:
К сожалению, ещё далеко не все провайдеры способны обеспечить себя нужным порой довольно дорогостоящим оборудованием или достаточно квалифицированным сисадмином способным нужным образом всё настроить. Сделали абы как. Обслуживают небольшое количество домов и рады.
И вот теперь подумайте, что будет легче: как-то повлиять на уже состоявшееся положение провайдера. Заставить их обновить оборудование и т.д. Или добавить несколько строк пода в прошивку которые решили бы вопрос оптимальным образом?
Да, можно попробовать сменить провайдера. Подключиться к федералам и т.д. Но в этом всегда есть и свои минусы для конечного пользователя.
тут нечего думать - подключиться к нормальному прову/пинать текущего проще, большинство провов, да те же местечковые, дают нормальный белый IP, не позволяя себе брать бабки за воздух, как в случае с провом у ТС.
Не считаю оптимальным, косяки и убогую работу кого бы то ни было, сваливать на "пару строк" в пользу Кинетика, в силу того, что с них требовать проще.
-
18 минут назад, keenet07 сказал:
Реализовать возможность командой в CLI форсированно применять к домену внешний IP адрес не смотря на наличие серого в связке (для тех кому нужно). А по умолчанию оставить текущее поведение роутера для подобной конфигурации. Чтоб никто не пострадал.
есть ТП, есть раздел "развитие Keenetic", есть ТС.
На мой взгляд, в данной ситуации уместнее пинать прова - есть гораздо более нужные хотелки, которые до сих пор не реализованы.
-
6 минут назад, Кинетиковод сказал:
Тут видимо редкий случай особой организации NAT. Провайдер выдаёт роутеру серый ip при этом с белого ip идёт полная переадресация на это серый. Как бы такой DMZ от провайдера. KeenDNS ориентируется на WAN адрес, который серый, а требуется ориентироваться на внешний белый. Но в общем случае в такой ситуации подключение проходить не будет, т.к. Кинетик будет за NAT, но в данном конкретном случае подключение проходит из-за организованной провайдером DMZ.
в целом, пров не предоставляет белый IP, пинать прова, и точно не Кинетик.
-
1
-
-
2 часа назад, dmitry.a сказал:
Еще раз повторяю, адрес куплен, все работает напрямую (openvpn, wireguard, etc), текущий NO-IP определяет адрес правильно и прописывает, что надо, но он условно бесплатный. А вот KeenDNS не уметь это при явном указании "Прямой доступ". Хватит мне рассказывать про серые адреса. Если у вас белый на роутере - это еще не значит, что у всех так. И я полагаю, что люди из NO-IP про это прекрасно знают, что схемы подключения пользователей к Интернету есть разные и ситуации разные. Или вы лично хотите мне организовать доступ в Интернет и выдать белый адрес?
Может оказаться так, что keendns не будет нормально работать за пределами РФ, т.к. там вполне может окзатаься статический NAT у многих провайдеров. А это проблема выхода на международный рынок.
а вы статейку в базе знаний Кинетика видели? - В чем отличие "белого" и "серого" IP-адреса?
Не слушаете вы нескольких людей, сказавших про ваш серый IP, может эта статья вразумит.
...проблема выхода на международный рынок.
уверен, что там или будут юзать KeenDNS через облако, или заплатят за нормальный белый IP.
Кстати, почему вы у своего прова не спросите, почему он вам не дает белый IP нормальный, почему не смените прова?
Если вас парит раз в месяц подтверждать учетку NO-IP, юзайте DuckDNS, он бесплатен и никаких подтверждений.
-
Кинетик в качестве клиента Wireguard, сервер на VPS, к Кинетику по WAN подключен GPON-модем в бридже.
Собственно проблема с выбором шлюза по умолчанию для WG-интерфейса, которую до сих пор не решили, насколько понимаю.
до ПО 3.3.10 включительно все работало в двух вариантах:
- "без IP-адреса" на интерфейсе ISP
- с принудительной маршрутизацией через PPPoE - ip route x.x.x.x PPPoE0 auto + статически указанный шлюз на ISP
в 3.4.1 оба варианта неработоспособны - соединение Wireguard не подключается после перезагрузки Кинетика.
лог и self-тест ниже скрытым постом
-
1
-
-
В версии ОС 3.3.10 без изменений.
Web-интерфейс: выравнивание ссылок по высоте
in 3.3
Posted
вы бы завели отдельный кейс - тут проблема иная.