Jump to content

Dale

Forum Members
  • Content Count

    81
  • Joined

  • Last visited

Community Reputation

16 Good

About Dale

  • Rank
    Advanced Member

Equipment

  • Keenetic
    Ultra II 2.11.D

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Dale

    Писали же уже про это не один раз. Функция мастер браузера на роутере нужна из-за того, что это - самое редко отключаемое устройство, кому, как не ему вести список NetBIOS устройств домашней сети, где, как правило, отсутствуют круглосуточно работающие сервера. Типичная проблема в домашней сети - после выключения компьютера, который был мастером, список устройств в локальной сети еще достаточно долгое время выводится либо непозволительно долго, либо не выводится вообще. Да, конечно, NetBIOS и все, что с ним связано - вещь устаревшая, но во вкладке "сеть" используется, и без стабильно работающего master browser'а часто глючит. Проблема с Windows 10 - совсем другая история, к топику отношения не имеющая.
  2. Dale

    Уважаемый @ndm, боюсь, что Вы поняли неправильно. Нужна именно функция Master Browser'а. В сетевом окружении роутер и так прекрасно видится по имени, есть же настройка соответствующая в #usb.cifs. 2.09.C.0.0-5:
  3. @Le ecureuil Скажу больше, достаточно добавить только разрешение на входящие соединения от адреса VPN сервиса к ISP, хотя при установленном L2TP\IPSec соединении нет входящих с адреса VPN сервиса, только, как положено, исходящие соединения IPSec и L2TP - чудеса...
  4. Потратив определённое время на анализ, привожу моё решение проблемы: в настройках брандмауэра для интерфейса своего ISP прописал два правила - разрешил любые соединения на IP адрес VPN провайдера от себя и от него ко мне. После этого все заработало.
  5. То есть сейчас PEM уже поддерживается? Какой для него нужно ставить тег, <pem></pem>? auth-user-pass, как я понял, пока не поддерживается?
  6. Хотелось бы, чтобы клиент поддерживал вариант конфига с CA и X509 PEM, конечно же в виде файлов. Спасибо.
  7. На прошивке 2.09.A.7.0-2 L2TP\IPSec по прежнему не работает, но поведение немного изменилось, в логах syslog сервера вижу теперь такое: Селфтест прилагаю ниже.
  8. Начиная, как минимум, с версии 2.09.A.6.0-2 перестало работать L2TP\IPSec соединение. В логе при попытке соединения пишет следующее: Как я понимаю, причиной такого поведения является вот это: "[E] Apr 29 10:25:24 ndm: Core::Configurator: not found: "interface/ipsec/preshared-key/key"." Естественно, PSK указан и не изменялся, соединение никак не редактировалось. Так же пробовал удалить старое и создать новое соединение - картина не меняется. На текущей прошивке 2.09.A.7.0-0 ситуация такая же. Конфиг и селфтест прилагаю в сообщении ниже.
  9. Жаль От нагрузки, по моим наблюдениям, не зависит, к тому же через этот интерфейс работает transmission, долгий простой исключен. Если включить debug на этом интерфейсе, это может как-то прояснить картину?
  10. Только сейчас заметил то, на что, похоже, никто не обратил внимание в теме Периодически отваливается L2TP/IPSec соединение - при использовании L2TP/IPSec соединения отваливается только L2TP без пересогласования IPSec. Поэтому скромно спрошу у уважаемых администраторов, программистов и @Le ecureuil персонально - не появилось ли у Вас новых идей, почему такое может быть? Полный селфтест, как обычно, в следующем сообщении. PS Более того, VPN провайдер, похоже, не считает это событие разрывом соединения, потому что, например, сохраняется port-forwarding, запрошенный в начале соединения.
  11. В клиентском. Серверный точно не померить, но видно, что нагрузка больше. Но топикстартер говорил, кажется именно о клиентском соединении? Кстати, вопрос, почему шифрование клиентского PPTP соединения явно ускоряется аппаратно, а серверного - нет, может @Le ecureuil знает что-нибудь по этому поводу?
  12. Неправда Ваша, у меня на Ultra II при соединении по PPTP со 128битным шифрованием MPPE выдает порядка 80-90 МБит/c при загрузке процессора около 30%.
  13. Dale

    Это не баг, Le ecureuil уже писал по этому поводу тут. Другое дело, что значение, на которое меняется MTU, отсюда не узнать, т.к. во всех vanilla-like версиях, к которым относится и прошивка наших роутеров, в выводе этого сообщения используется неправильная переменная, я про это уже писал.
  14. Понятно, неудивительно, что этот баг плавает с 2005 года и периодически выныривает Смотрите, в данном куске кода сравниваются значения osize и isize+MPPE_OVHD+2. В случае, если первое меньше второго, то пакет дропается и выводится то самое отладочное сообщение, что osize (практически это MTU) слишком мало и оно должно быть не меньше чем osize+MPPE_OVHD+2, хотя по логике вещей должно выводиться сообщение, что osize должно быть не меньше чем isize+MPPE_OVHD+2. В первом случае сообщение бесполезно и является неинформативным, более того, в интернете полно пользователей и советчиков, которые увидев это сообщение увеличивают MTU на 4 и удивляются, почему сообщение продолжает возникать вновь, но со значениями, увеличенными на 4. Во втором случае сообщение весьма информативно и пользователь может из него сделать выводы в виде изменения начального значения MTU на основании реальных данных. А вы говорите, про новые алгоритмы, которые не реализовывают якобы из-за каких-то высших соображений, а такой банальный баг копипастят уже более 10 лет. PS Кстати, можете считать это сообщение багрепортом.
  15. А я не про то, что такое сообщение выводилось, хотя оно, конечно, раздражало, а про то, что оно выводилось неправильно. Как Вы там говорили, "Talk's cheap, show us the code!"? Их есть у меня: https://github.com/torvalds/linux/blob/master/drivers/net/ppp/ppp_mppe.c#L384 https://github.com/ndmsystems/linux-3.4/blob/master/drivers/net/ppp/ppp_mppe.c#L383 И т.д. Ничего странного не замечаете?
×
×
  • Create New...