Le ecureuil

@Хосе Де Чекитос Скиньте настройки от dlink, иначе непонятно ничего. Тоже скрытым постом.

Подключение не из WAN может показывать странные результаты, поскольку на это не рассчитано. Для правильных тестов нужно подключаться ко всем VPN из WAN. Почему из гостевой сети доступен SMB - разбираемся по другому запросу, видимо где-то недонастроен firewall. Спасибо за исследование, разбираемся.

В прочих прописывайте 127.0.0.1, там же и dnsmasq повесьте.

Копируете через соединение к серверу L2TP/IPsec? Вообще винда очень странно себя ведет, а именно постоянно пересогласовывает параметры после каждых 250 мегабайт переданных данных. Как видно из лога, инициатива по разрыву постоянно приходит от нее.

Поведение скопировано с уже существующего PPTP-сервера. Просьба проверить этот сценарий с ним и описать, что различается, а что совпадает.

Сделано, появится в ближайшем draft.

Скиньте ваши логи при подключении 88179, с которым не работает (наподобие первого лога, что скинул я), и модель роутера.

С моим 88179 все прекрасно работает: kernel: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd kernel: usb 2-1: New USB device found, idVendor=0b95, idProduct=1790 kernel: usb 2-1: Product: AX88179 kernel: usb 2-1: Manufacturer: ASIX Elec. Corp. kernel: usb 2-1: SerialNumber: 0000000000076B kernel: ax88179_178a 2-1:1.0: eth0: register 'ax88179_178a' at usb-xhci-hcd-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 9c:eb:e8:10:83:07 Network::Interface::Usb: "AsixEthernet0": interface "AsixEthernet0" is plugged (port 2). AsixEthernet0: NDM DHCP client (version 3.2.14) started. AsixEthernet0: created PID file "/var/run/ndhcpc-asx_br0.pid". kernel: ax88179_178a 2-1:1.0: eth0: ax88179 - Link status is: 1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready # cat /proc/fastvpn/binds - SWNAT bind entry (flags: FNTX: 1 PPPTX: 0 RTX: 1 RRX: 1 BIND: 2) #0 - --> is L2TP: 0, is PPTP: 0, is PPPoE: 0, is IPoE: 1, is USB CDC/DSL: 1 --> Original LAN src: 192.168.1.237:52036 --> New WAN src: 172.16.110.124:52036 --> WAN dst (proto): 172.16.110.59:80 (6 : TCP) --> WAN UBridge device: asx_br0 --> WAN MACs: src (CPE) => dst (BRAS) (WAN vlan_id @ dev): 9c:eb:e8:10:83:07 => 00:90:0b:3a:42:32 (0 @ eth0) --> LAN MACs: src (USER) => dst (CPE) (LAN vlan_id @ dev): ec:08:6b:00:92:ef => ec:43:f6:91:2b:a6 (1 HWTX @ eth2) --> Traffic LAN => WAN (bytes / packets): 114956 / 2137 --> Traffic WAN => LAN (bytes / packets): 6113140 / 4070 $ wget -O /dev/null http://172.16.110.59/test.img --2017-11-28 16:40:32-- http://172.16.110.59/test.img Connecting to 172.16.110.59:80... connected. HTTP request sent, awaiting response... 200 OK Length: 10737418240 (10G) [application/octet-stream] Saving to: ‘/dev/null’ /dev/null 67%[============> ] 6,76G 77,1MB/s eta 43s

Ага, к следующему драфту наколдую

Давайте логи и подробности.

Сперва нужно активировать модуль, и только потом можно будет менять протокол и версию.

Иначе его не встроить. Все интерфейсы внутри Bridge теряют свои настройки, в том числе и IP-адреса, и не могут быть использованы индивидуально для рассылки проверочных сообщений. Потому и приходится извращаться с Pingcheck на Bridge.

Скорее всего во время вашего обновления netfilter NDMS пытается еще раз перезаписать таблицу и в итоге вы получаете вот это.

Ну я писал еще на прошлой странице, пока да, ppe software не дружит с ним. Но починим.

88179 получил на почте (отстояв 2 часа в очереди), на следующей неделе ожидайте фиксов по нему.

Надо флаг -w добавлять к своим командам + еще желательно полный путь к бинарнику, иначе есть возможность случайно зацепить не тот.

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

По идее не должно.

Как вариант. Только репрезентативно это сделайте, ничего не упустите.

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

LLMNR починили. Оказывается, он всегда был в новой версии nqE, но из-за ошибки в коде он слушал loopback-интерфейс и не отвечал на запросы. Начиная с этого draft винда должна нормально видеть Keenetic по LLMNR (проверял на windows 7). Одновременно приделан фильтр, чтобы LLMNR-запросы, приходящие или хотящие уйти в public-интерфейс дропались.

Сами разбирайтесь со сторонними решениями (например, в курилке). А в этой теме - только работоспособность и баги модуля Netflow в NDMS.

А что именно не пошло? Ну хотя бы self-test, логи, описание проблем и действий.

Напишите сайт этого провайдера, попробуем проверить что с ним не так. Если несложно - скиньте ваш конфиг в личку для дебага. Покупать подписку ради теста что-то не очень хочется.

Планируется (как и много чего другого), но сроков нет.