vasek00
-
Posts
4,469 -
Joined
-
Last visited
-
Days Won
76
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by vasek00
-
-
На верно я погорячился вверху что должно работать.
Так как AdguardHome весит на br0 (основной роутера 192.168.1.1 или в моем случае 192.168.130.100) и лок.сервисы спок.уходят по нему, то со вторым каналом и созданным профилем доступа и в нем клиент оказалось не все так просто.
При основном профиле - основной Инет1 рез. Инет2
AdGuardHome по конф bind_host: 192.168.130.100 .. dns: bind_host: 0.0.0.0 port: 53 В итоге / # netstat -ntulp | grep :53 tcp 0 0 :::53 :::* LISTEN 791/AdGuardHome udp 0 0 :::53 :::* 791/AdGuardHome / # ip name-server 192.168.130.100 "" on Home и откл. DNS провайдерат.е. основной профиль все работает.
Переводим клиента в новый профиль где основной канал Инет2
ip hotspot ... host хх:хх:хх:хх:хх:e2 policy Policy0 ip policy Policy0 description Inet2 permit global PPTP0 permit global PPPoE0 так же на Инет2 игнорирование DNS провайдера, иначе просто в таблицу маршрута прописаны будут DNS провайдера на данный интерфейс Инет2 и будут работать они, а хотелось бы использовать AdGuardHome так же для данного профиля Policy0.Но не тут то было, клиент вообще не может обработать DNS запрос и скорей всего из-за REDIRECT, так как имеем hotspot
Скрытый текстChain _NDM_HOTSPOT_DNSREDIR (1 references) pkts bytes target prot opt in out source destination 71 4536 REDIRECT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 mark match 0xffffd00 PKTTYPE = unicast udp dpt:53 redir ports 41100 0 0 REDIRECT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 mark match 0xffffd00 PKTTYPE = unicast tcp dpt:53 redir ports 41100 Chain _NDM_HOTSPOT_PRERT (1 references) ... 18 938 MARK all -- br0 * Клиент_Policy0 0.0.0.0/0 MARK set 0xffffd00 18 938 CONNMARK all -- br0 * Клиент_Policy0 0.0.0.0/0 CONNMARK save ...где 41100 весит ndnproxy
ndnproxy 665 root 4u IPv4 995 0t0 UDP *:41100 ndnproxy 665 root 5u IPv4 996 0t0 UDP *:50876 ndnproxy 665 root 6u IPv6 997 0t0 UDP *:41100 ndnproxy 665 root 7u sock 0,6 0t0 998 protocol: UDPv6 ndnproxy 665 root 8u IPv4 999 0t0 TCP *:41100 (LISTEN) ndnproxy 665 root 9u IPv6 1000 0t0 TCP *:41100 (LISTEN) -
6 минут назад, moomey сказал:
я немного про другое
в одном случае (общий профиль) при обращении к кинетику мне отвечает AdGuard, чего я и ожидаю
во втором случае (policy) при обращении к кинетику мне отвечает ndnproxy
про то, как и куда лезет отвечающий мне демон на ответом, мы ещё не дошли. вопрос в том, кто мне отвечает. только что перепроверил ещё раз, всё так, как я описываю.
Такое поведение идет уже давно когда пробовал DNSmasq и DNSproxy, поиск по форуму "opkg dns-override", а именно для простоты локальные сервисы роутера как работали через свой DNS так и работают в отличие от внешних запросов.
Так же в подтверждение сказанного ответ разработчиков
Смотрите команду "netstat -ntulp" для 53 порта, после выполнения "opkg dns-override"
-
44 минуты назад, moomey сказал:
Установил AdGuard Home. Такое впечатление, что при создании нового профиля доступа в интернет и перемещении в него зарегистрированного устройства (или всего сегмента Гостевая сеть) на запросы с этого устройства вместо adguard начинает отвечать сам кинетик. Переношу устройство в "Основной профиль" - начинает отвечать AdGuard
Проверял командой в cli
ip host 192.168.168.168 example.exampleи пользовательским правилом фильтрации AdGuard
192.168.200.200 example.exampleпри этом nslookup с устройства на кинетике
nslookup example.example 192.168.23.1выдаёт 192.168.168.168 или 192.168.200.200 в зависимости от того, находится устройство в основном профиле или в другом
Giga KN-1010, 3.4.12, AdGuard Home 0.103.3, opkg dns-override сказал. Воспроизводится устойчиво. ЧЯНТД?
По умолчанию для сетевых интерфейсов для интернета используется правило "ipcp name-servers" т.е. в итоге получаем согласно WEB "http://192.168.1.1/dashboard" подробности данного соединения раздел DNS, например такой - DNS от провайдера и сам роутер (наличие последней зависит от записи "Серверы DNS")
IP_DNS1_Провайдер IP_DNS2_Провайдер 192.168.1.1а согласно
<file name="temp:resolv.conf"> <![CDATA[ nameserver 192.168.1.1 nameserver IP_DNS1_провайдера nameserver IP_DNS2_провайдера options timeout:1 attempts:1 rotate
При настройках
1.opkg dns-override 2.на http://192.168.1.1/controlPanel/secureInternet "Серверы DNS" указан сам роутер 192.168.1.1 3.на каждом сетевом интерфейсе интернета указан параметр "ipcp no name-servers" то на выходе согласно WEB "http://192.168.1.1/dashboard" подробности данного интернет соединения раздел DNS уже имеем только одну запись 192.168.1.1 сам роутер и <file name="temp:resolv.conf"> <![CDATA[ nameserver 192.168.1.1 options timeout:1 attempts:1 rotate
т.е. на любом интернет интерфейсе в поле DNS стоит сам роутер, а все запросы в том числе и от лок.сервисов на самом роутере в данном случае будут идти через основной канал если их более одного
/ # dig mail.ru ; <<>> DiG 9.16.3 <<>> mail.ru ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58623 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.ru. IN A ;; ANSWER SECTION: mail.ru. 14 IN A 217.69.139.202 mail.ru. 14 IN A 217.69.139.200 mail.ru. 14 IN A 94.100.180.201 mail.ru. 14 IN A 94.100.180.200 ;; Query time: 28 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Tue Aug 11 21:26:15 MSK 2020 ;; MSG SIZE rcvd: 100 / # / # netstat -ntulp | grep :53 tcp 0 0 :::53 :::* LISTEN 784/AdGuardHome udp 0 0 0.0.0.0:53ххх 0.0.0.0:* 799/ndnproxy udp 0 0 :::53 :::* 784/AdGuardHome / # / # traceroute mail.ru traceroute to mail.ru (94.100.180.201), 30 hops max, 38 byte packets 1 br_Inet_основной.ru (хх.хх.хх.1) 4.489 ms 13.007 ms 4.318 ms 2 хх.хх.хх.хх (хх.хх.хх.48) 4.011 ms хх.хх.хх.44 (хх.хх.хх.44) 3.937 ms 3.962 ms 3 хх.хх.хх.85 (хх.хх.хх.85) 24.998 ms 28.165 ms 25.008 ms ...А сам клиент на профиле где Инте2 основной
Трассировка маршрута к MAIL.ru [94.100.180.200] с максимальным числом прыжков 30: 1 <1 мс <1 мс <1 мс G-KN [192.168.1.1] 2 1 ms 1 ms 1 ms v_Inet2.ru [хх.хх.хх.26] 3 2 ms 1 ms 2 ms v_Inet2.ru [хх.хх.хх.1] 4 5 ms 6 ms 5 ms хх.хх.хх.21 5 10 ms 10 ms 10 ms хх.хх.хх.17 ...В данном случае перемена клиентом профиля с основного на любой созданной роли не играет, так как сервер DNS он один для любого интерфейса выхода в интернет -> сам роутер => основной канал (основной профиль)
-
Возможно ли в мобильном приложение сделать "график" для оценки уровня сигнала rssi для клиента в масштабе например 30мин 1час 1день. Данные ведь есть
/ # ndmq -p 'show assoc' -x <response> <station> <mac>f0:хх:хх:хх:хх:6e</mac> <ap>WifiMaster1/AccessPoint0</ap> <authenticated>yes</authenticated> ... <rssi>-76</rssi> ... </station> <prompt>(config)</prompt> </response> / #
хотя бы для 5 клиентов, разными цветами.
-
Схема
ПК ---LAN---KN30----LAN---KN10
Клиент доступ в интернет имеет, отключение кабеля LAN между роутерами, так же все работает, но доступа к WEB KN30 нет, ping на KN30 не проходят.
Клиент смартфон, спокойно подключился к KN30 как к более близкому, проблем с интернетом на нем нет.
Подключение кабеля LAN между KN30 и KN10 не чего не изменили, как работает так и работает, в логе KN10 нет нечего, что заслуживало бы внимание, доступа к KN30:80 нет.
-
Есть какой то бзик при связке KN10 и KN30 но при обновление (соединены по LAN), с начала обновился KN10 35A17 (перезпуск все ОК) потом KN30 и тут в Wifi системе на KN10 проверить состояние KN30. Лог на KN10 (получение по DHCP адреса вплоть до ACK и так несколько раз, на KN10 прописан MAC и присвоен IP). На KN10 в WEB как всегда в моем случае ошибка - пароль на Extendere admin.
Путем сброса через WEB KN30 к заводским а так же выключение его из сети и потом опять включение, к жизни удалось вернуть через мобильное приложение, т.е. есть запись в Wifi системе для него. Хорошо что точка не удаленная была.
Скрытый текст[I] Aug 8 20:22:22 ndm: Network::Interface::Switch: "GigabitEthernet0/2": switch link up at port 3. [I] Aug 8 20:22:31 ndhcps: DHCPDISCOVER received from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:31 ndhcps: making OFFER of 192.168.130.98 to 50:хх:хх:хх:хх:6b.. [I] Aug 8 20:22:31 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:31 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:39 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:39 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:39 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:39 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:39 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:39 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:39 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:40 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:40 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:40 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:40 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:40 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:40 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:41 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:41 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:22:41 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. ... [I] Aug 8 20:40:02 ndm: Mws::Candidate: "50:хх:хх:хх:хх:6b": revisit started. [I] Aug 8 20:40:02 ndm: Mws::Controller: candidate "50:хх:хх:хх:хх:6b" revisit started. [I] Aug 8 20:40:03 ndm: Io::TcpSocket: connected to 192.168.130.98:80. [I] Aug 8 20:40:03 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": response code 200 (OK). [I] Aug 8 20:40:03 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": Content-Length: 1818. [I] Aug 8 20:40:03 ndm: [truncated] Mws::RciClient: "50:хх:хх:хх:хх:6b": [6176]: "{"probe":{"found":false},"show":{"version":{"release":"3.05.A.17.0-0","sandbox":"draft","title":"3.5 Alpha 17","arch":"mips","ndm":{"exact":"0-11be749","cdate":"8 Aug 2020"},"bsp":{"exact":"0-7054b3ff9","cdate":"8 Aug 2020"},"ndw":{"version":"3.5.30","features":"hw_mode_switch,wifi_button,wifi5ghz,led_control,mimo5ghz,atf5ghz,dual_image,wifi_ft,wpa3","components":"adguard-dns,base,chilli,cloudcontrol,cloudflare-dns,corewireless,ddns,dhcpd,dns-https,dns-tls,dot1x,dpi,eoip,gre,igmp,ike-client,ip6,ipip,ipsec,l2tp,lang-en,lang-ru,miniupnpd,monitor,mws,nathelper-ftp,nathelper-h323,nathelper-pptp,nathelper-rtsp,nathelper-sip,netflow,openvpn,pingcheck,ppe,pppoe,pptp,skydns,snmp,ssh,sstp,sstp-server,trafficcontrol,udpxy,vpnserver,vpnserver-l2tp,wireguard,wpa-eap,ydns"},"manufacturer":"Keenetic Ltd.","vendor":"Keenetic","series":"KN","model":"Speedster (KN-3010)","hw_version":"10308000","hw_id":"KN-3010","device":"Speedster","region": [I] Aug 8 20:40:03 ndm: Io::TcpSocket: connected to 192.168.130.98:80. [I] Aug 8 20:40:03 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": response code 200 (OK). [I] Aug 8 20:40:03 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": Content-Length: 117707. [I] Aug 8 20:40:03 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": [6176]: excessive (92280 bytes). [I] Aug 8 20:40:22 ndm: Mws::Candidate: "50:хх:хх:хх:хх:6b": acquire started. [I] Aug 8 20:40:22 ndm: Mws::Controller: candidate "50:хх:хх:хх:хх:6b" acquire started. [I] Aug 8 20:40:22 ndm: Io::TcpSocket: connected to 192.168.130.98:80. [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": response code 200 (OK). [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": Content-Length: 3. [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": [6190]: "{}". [I] Aug 8 20:40:22 ndm: Mws::Candidate: "50:ff:20:2f:f0:6b": accepted "eula". [I] Aug 8 20:40:22 ndm: Mws::Candidate: "50:хх:хх:хх:хх:6b": firmware is up to date. [I] Aug 8 20:40:22 ndm: Io::TcpSocket: connected to 192.168.130.98:80. [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": response code 200 (OK). [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": Content-Length: 3. [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": [6190]: "{}". [I] Aug 8 20:40:22 ndm: Mws::Candidate: "50:хх:хх:хх:хх:6b": accepted "eula". [I] Aug 8 20:40:22 ndm: Io::TcpSocket: connected to 192.168.130.98:80. [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": response code 200 (OK). [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": Content-Length: 639. [I] Aug 8 20:40:22 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": [6190]: "{"csr":{"csr":"-----BEGIN CERTIFICATE REQUEST-----\nMIHrMIGRAgEAMC8xL..........K6yEVlqtuTsA==\n-----END CERTIFICATE REQUEST-----\n","status":[{"status":"message","code":"5505124","ident":"Mws::Member","source":"","warning":"no","message":"sent CSR."}]}}". [I] Aug 8 20:40:22 ndm: Io::TcpSocket: connected to 192.168.130.98:80. [I] Aug 8 20:40:25 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": response code 200 (OK). [I] Aug 8 20:40:25 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": Content-Length: 221. [I] Aug 8 20:40:25 ndm: Mws::RciClient: "50:хх:хх:хх:хх:6b": [6190]: "{"lock":{"status":[{"status":"message","code":"5505224","ident":"Mws::Member","source":"","warning":"no","message":"locked."}]}}". [I] Aug 8 20:40:25 ndm: Network::Interface::Rtx::WifiController: backhaul STP enabled. [I] Aug 8 20:40:25 ndm: Mws::MemberList: member "50:хх:хх:хх:хх:6b" (b98a0bf........d7) acquired. [I] Aug 8 20:40:33 ndm: Mws::MemberList: "50:хх:хх:хх:хх:6b": 2.4 GHz interface detected. [I] Aug 8 20:40:33 ndm: Mws::MemberList: "50:хх:хх:хх:хх:6b": 5 GHz interface detected. [I] Aug 8 20:40:41 ndhcps: DHCPDISCOVER received from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:40:41 ndhcps: making OFFER of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:40:41 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:40:41 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:40:53 kernel: br0: port 1(eth2.1) received tcn bpdu [I] Aug 8 20:40:53 kernel: br0: topology change detected, propagating [I] Aug 8 20:44:45 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:44:45 ndhcps: sending ACK of 192.168.130.98 to 50:ff:20:2f:f0:6b. [I] Aug 8 20:44:45 ndhcps: DHCPREQUEST received (STATE_RENEWING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:44:45 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:44:51 kernel: br0: port 1(eth2.1) received tcn bpdu [I] Aug 8 20:44:51 kernel: br0: topology change detected, propagating [I] Aug 8 20:52:43 ndhcps: DHCPRELEASE received for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:52:48 ndhcps: DHCPDISCOVER received from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:52:48 ndhcps: making OFFER of 192.168.130.98 to 50:хх:хх:хх:хх:6b. [I] Aug 8 20:52:48 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.98 from 50:хх:хх:хх:хх:6b. [I] Aug 8 20:52:49 ndhcps: sending ACK of 192.168.130.98 to 50:хх:хх:хх:хх:6b. ....Сейчас же утром проблема по доступу к KN30 LAN клиентом при наборе 192.168.130.98 тишина, мобильное показывает не в сети, при наборе KN10 как 192.168.130.100 так же тишина, но при наборе 192.168.130.100/dashboard есть выход
Сейчас какой то сумбур, ощущение что какой то конфликт с IP, так как только набираю WEB KN10 то сразу пропадает KN30 (видно по клиенту LAN который подключен к KN30, нет сети). Выкл вкл KN30 сеть нормально, опять доступ к КN10 и опять вылет нет сети на клиенте LAN. Только перегруз обоих по питанию как то привел в чцвство, по мобильному приложению достучался до обоих. По логам какая то фигня. После доступа через мобильное, получил доступ к WEB с клиента но опять же к 192.168.130.100 нет только через любой набор http://192.168.130.100/controlPanel/wifiSystem или http://192.168.130.100/dashboard. Wifi система есть и KN30 как положено на месте. Так же достучался и KN30 но опять же через набор 192.168.130.98/dashboard потом имя и пароль
Нужно еще посмотреть.
-
7 часов назад, art1840 сказал:
Нужно обновить роутер (обновляю с расчетом нормальной работы лет на 5). Изначально хотел брать Ultra KN-1810, так как там Wi-Fi мощнее и дополнительный чип, да и вообще беспроводная сеть построена по другому. Но вот незадача, не получается роутер по акции выхватить за 10 000, а Giga KN-1010 могу купить за 7700.
Отсюда у меня вопрос, насколько целесообразно переплачивать? У меня трешка, 60.5 кв.м, бетонные стены, роутер стоит в углу дальней комнаты. К роутеру подключено обычно до 6 устройств одновременно......
Поэтому думаю, оправдает ли Ultra KN-1810 переплату в 2300р? Если он в дальнейшем будет работать дольше и лучше, то я готов переплачивать.
Кто что думает по этому поводу?
Заранее спасибо!
Вопрос по самим клиентам - их возможности 1х1/2х2 и MU-MIMO.
1х1 MU-MIMO - практически все современные телефоны (кроме Apple )
2х2 MU-MIMO - в основном топовые телефоны, но сейчас и в бюджете естьКак уже писали ранее на данном форуме
Цитатаотличия Giga KN-1010 от Ultra KN-1810 по Wifi:
- 2T2R в каждом диапазоне
- Нет поддержки BW160 и 80+80 в 5ГГц
- Нет поддержки eBF/iBF и MU-MIMO в 2.4ГГц (в 5ГГц есть)
- MU-MIMO схема возможна только с двумя 1SS клиентами
- нет поддержки фонового сканирования DFS каналов (ZeroDFS)Не большие комментарии
Скрытый текстЦитатаЯвное формирование луча - Explicit beamforming (EBF)
Требует поддержки клиента, работает только в MIMO режимах (2 передатчика и больше). Если клиент не умеет EBF то упрощенный вариант Implicit beamforming (IBF) - "универсальное
формирование луча". Требует ресурсов проца для оценки канала связи и времени для адаптации алгоритма передачи на основе реакции клиента на передачу пакетов (если клиент запрашивает больше чем дает роутер скорость то это хорошо, если меньше просит скорость то это плохо, на основе этого происходит подбор мощности и фазовый сдвиг)Ограничение MU-MIMO
...
3. Клиенты должны находится на значительном расстояниее друг от друга, если близко то трудно сформировать потоки с разнесением во времени и пространстве.
4. Скорость передачи выравнивается по самому медленному клиенту, пока не закончится передача всем клиентам новая сессия передачи не начнется.
Для пункта 4 принципиально - например ПК качает торрент и ТВ смотрит youtube. Загрузка канала эфира например ПК 15 мс (условно) ТВ 5мс - т.е. будет выравнивание по 15мс, так как
на его сторону закончится передача через 15мс медленный. -
4 часа назад, Сергей Молоков сказал:
keenetic giga (3.5 Alpha 14) - контроллер
keenrtic 4g (3.5 Alpha 14) - усилитель
все как описывал топикстартер, со шнурком загорается индикатор - интернет, захват происходит,
отключаешь шнурок, индикатор интернета гаснет, в вай-фай системе контроллера, усилитель отключается.
Через кратковременное нажатие кнопок на устройствах, соединения не происходит. День гугления, вникание в мануалы,
неоднократный сброс keenrtic 4g и перенастройка ни к чему не привели.
Не скажу не чего про индикатор интернeта (не пользуюсь, да и не видно как то) пара KN10+KN30 на 35А14 таких проблем нет.
Логи двух устройств после момента отключения кабеля KN10---LAN--KN30 по логу после "switch link down" и потом "interface "Home" is global, priority 1" и "adding a default route via 192.168.1.100" т.е. на KN10
Скрытый текстKN10
Июл 21 16:57:02 ndm Network::Interface::Switch: "GigabitEthernet0/1": switch link down at port 2. Июл 21 16:57:02 kernel br0: port 1(eth2.1) entered blocking state Июл 21 16:57:02 kernel br0: port 1(eth2.1) entered listening state Июл 21 16:57:02 kernel br0: port 1(eth2.1) entered blocking state Июл 21 16:57:02 kernel br0: port 1(eth2.1) entered listening state Июл 21 16:57:05 kernel br0: port 1(eth2.1) entered learning state Июл 21 16:57:08 kernel br0: port 1(eth2.1) entered forwarding state Июл 21 16:57:08 kernel br0: topology change detected, propagating Июл 21 16:57:13 ndhcps DHCPDISCOVER received from 50:хх:хх:хх:хх:6b. Июл 21 16:57:13 ndhcps making OFFER of 192.168.1.8 to 50:хх:хх:хх:хх:6b. Июл 21 16:57:13 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.1.8 from 50:хх:хх:хх:хх:6b. Июл 21 16:57:13 ndhcps sending ACK of 192.168.1.8 to 50:хх:хх:хх:хх:6b.KN30 - 192.168.1.8
Июл 21 16:57:05 ndm Network::Interface::Switch: "GigabitEthernet0/3": switch link down at port 4. Июл 21 16:57:05 kernel br0: port 1(eth2.1) entered blocking state Июл 21 16:57:05 kernel br0: port 1(eth2.1) entered listening state Июл 21 16:57:06 kernel br0: port 8(apclii0.1) entered listening state Июл 21 16:57:07 ndm Network::Interface::Rtx::WifiController: "WifiMaster0/Backhaul0": set metric 51. Июл 21 16:57:07 ndm Network::Interface::Rtx::WifiController: "WifiMaster1/Backhaul0": set metric 51. Июл 21 16:57:09 ndm Dhcp::Client: DHCP server is not responding. Июл 21 16:57:09 ndnproxy stopped. Июл 21 16:57:09 ndm Network::Interface::Ip: "Bridge0": IP address is 192.168.1.3/24. Июл 21 16:57:09 kernel br0: port 1(eth2.1) entered learning state Июл 21 16:57:09 ndm Network::InternetChecker: Internet access lost (status: 0x0000). Июл 21 16:57:09 ndm Core::Peripheral::Manager: "WLAN/click" handler set. Июл 21 16:57:09 ndm Core::Peripheral::Manager: "WLAN/double-click" handler set. Июл 21 16:57:09 mtkiappd stopped. Июл 21 16:57:09 kernel br0: port 8(apclii0.1) entered learning state Июл 21 16:57:10 ndm Http::Nginx: loaded SSL certificate for "3e4...........13.keenetic.io". Июл 21 16:57:10 ndm Http::Nginx: loaded SSL certificate for "s......-8.keenetic.pro". Июл 21 16:57:10 ndm Http::Nginx: loaded SSL certificate for MWS. Июл 21 16:57:10 ndm Core::Server: started Session /var/run/ndm.core.socket. Июл 21 16:57:10 ndm Core::Session: client disconnected. Июл 21 16:57:10 ndm Http::Manager: updated configuration. Июл 21 16:57:10 ndm Core::Server: started Session /var/run/ndm.core.socket. Июл 21 16:57:10 ndm Core::Session: client disconnected. Июл 21 16:57:11 ndnproxy NDM DNS Proxy, v1.3.0b36. Июл 21 16:57:11 ndnproxy PID file: /var/ndnproxymain.pid. Июл 21 16:57:11 ndnproxy stats. file: /var/ndnproxymain.stat. Июл 21 16:57:11 mtkiappd MediaTek IAPP daemon v2.0.0 started on br0. Июл 21 16:57:12 kernel br0: port 1(eth2.1) entered forwarding state Июл 21 16:57:12 kernel br0: topology change detected, sending tcn bpdu Июл 21 16:57:12 kernel br0: port 8(apclii0.1) entered forwarding state Июл 21 16:57:12 kernel br0: topology change detected, sending tcn bpdu Июл 21 16:57:12 coalagent version 0.4.22 starting. Июл 21 16:57:16 ndhcpc Bridge0: received OFFER for 192.168.1.8 from 192.168.1.100. Июл 21 16:57:16 ndhcpc Bridge0: received ACK for 192.168.1.8 from 192.168.1.100. Июл 21 16:57:16 ndm Dhcp::Client: configuring interface Home. Июл 21 16:57:16 ndm Network::Interface::Ip: "Bridge0": IP address is 192.168.1.8/24. Июл 21 16:57:16 ndm Dhcp::Client: obtained IP address 192.168.1.8/24. Июл 21 16:57:16 ndm Dhcp::Client: interface "Home" is global, priority 1. Июл 21 16:57:16 ndm Dhcp::Client: adding a default route via 192.168.1.100. Июл 21 16:57:16 ndm Dhcp::Client: adding name server 192.168.1.100. Июл 21 16:57:16 ndm Dns::Manager: name server 192.168.1.100 added, domain (default). Июл 21 16:57:16 ndnproxy stopped. Июл 21 16:57:16 ndm Core::Peripheral::Manager: "WLAN/click" handler set. Июл 21 16:57:16 ndm Core::Peripheral::Manager: "WLAN/double-click" handler set. Июл 21 16:57:16 mtkiappd stopped. Июл 21 16:57:17 ndm Cloud::Agent: can not connect to the cloud server. Июл 21 16:57:17 ndm Http::Nginx: loaded SSL certificate for "3e4........13.keenetic.io". Июл 21 16:57:17 ndm Http::Nginx: loaded SSL certificate for "s.........-8.keenetic.pro". Июл 21 16:57:17 ndm Http::Nginx: loaded SSL certificate for MWS. Июл 21 16:57:18 ndm Core::Server: started Session /var/run/ndm.core.socket. Июл 21 16:57:18 ndm Core::Session: client disconnected. Июл 21 16:57:18 ndm Http::Manager: updated configuration. Июл 21 16:57:18 ndm Core::Server: started Session /var/run/ndm.core.socket. Июл 21 16:57:18 ndm Core::Session: client disconnected. Июл 21 16:57:18 ndnproxy NDM DNS Proxy, v1.3.0b36. Июл 21 16:57:18 ndnproxy PID file: /var/ndnproxymain.pid. Июл 21 16:57:18 ndnproxy stats. file: /var/ndnproxymain.stat. Июл 21 16:57:18 mtkiappd MediaTek IAPP daemon v2.0.0 started on br0. Июл 21 16:57:21 ndm Core::Server: client disconnected. Июл 21 16:57:21 coalagent version 0.4.22 starting. Июл 21 16:57:23 ndm Network::InternetChecker: Internet access detected. -
(iperf3 -c .... -R -t 480)ПК(LAN)---(LAN)KN3010(LAN)---(LAN)KN1010(iperf3 -s) или (iperf3 -c .... -t 480)ПК(LAN)---(LAN)KN3010(LAN)---(LAN)KN1010(iperf3 -s)В итоге
Скрытый текст
/ # iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.130.2, port 50375
[ 5] local 192.168.130.100 port 5201 connected to 192.168.130.2 port 50376
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.02 sec 94.8 MBytes 778 Mbits/sec 0 406 KBytes
[ 5] 1.02-2.02 sec 95.0 MBytes 801 Mbits/sec 0 406 KBytes
[ 5] 2.02-3.02 sec 93.4 MBytes 780 Mbits/sec 0 568 KBytes
[ 5] 3.02-4.03 sec 81.2 MBytes 679 Mbits/sec 0 650 KBytes
[ 5] 4.03-5.04 sec 92.5 MBytes 768 Mbits/sec 0 696 KBytes
[ 5] 5.04-6.02 sec 87.5 MBytes 749 Mbits/sec 0 696 KBytes
[ 5] 6.02-7.01 sec 97.5 MBytes 819 Mbits/sec 0 749 KBytes
[ 5] 7.01-8.02 sec 98.8 MBytes 821 Mbits/sec 0 749 KBytes
[ 5] 8.02-9.02 sec 95.0 MBytes 799 Mbits/sec 0 749 KBytes
[ 5] 9.02-10.02 sec 91.2 MBytes 765 Mbits/sec 0 749 KBytes
[ 5] 10.02-11.02 sec 96.9 MBytes 817 Mbits/sec 0 817 KBytes
[ 5] 11.02-12.01 sec 95.0 MBytes 798 Mbits/sec 0 817 KBytes
[ 5] 12.01-13.02 sec 95.0 MBytes 790 Mbits/sec 0 817 KBytes
[ 5] 13.02-14.02 sec 95.0 MBytes 799 Mbits/sec 0 817 KBytes
[ 5] 14.02-15.02 sec 97.5 MBytes 815 Mbits/sec 0 817 KBytes
[ 5] 15.02-16.02 sec 93.8 MBytes 790 Mbits/sec 0 817 KBytes
[ 5] 16.02-17.02 sec 96.2 MBytes 804 Mbits/sec 0 817 KBytes
iperf3: error - unable to write to stream socket: Connection reset by peer
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
^Ciperf3: interrupt - the server has terminated
/ #То же самое только передача
Скрытый текст/ # iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.130.2, port 50391
[ 5] local 192.168.130.100 port 5201 connected to 192.168.130.2 port 50392
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 78.2 MBytes 655 Mbits/sec
[ 5] 1.00-2.00 sec 87.3 MBytes 732 Mbits/sec
[ 5] 2.00-3.00 sec 98.9 MBytes 831 Mbits/sec
[ 5] 3.00-4.00 sec 96.8 MBytes 811 Mbits/sec
[ 5] 4.00-5.00 sec 88.2 MBytes 740 Mbits/sec
[ 5] 5.00-6.00 sec 96.8 MBytes 812 Mbits/sec
[ 5] 6.00-7.00 sec 86.9 MBytes 729 Mbits/sec
[ 5] 7.00-8.00 sec 91.9 MBytes 772 Mbits/sec
[ 5] 8.00-9.00 sec 86.7 MBytes 727 Mbits/sec
[ 5] 9.00-10.00 sec 86.7 MBytes 727 Mbits/sec
[ 5] 10.00-11.00 sec 95.8 MBytes 804 Mbits/sec
[ 5] 11.00-12.00 sec 96.6 MBytes 810 Mbits/sec
[ 5] 12.00-13.00 sec 95.5 MBytes 800 Mbits/sec
[ 5] 13.00-14.00 sec 94.6 MBytes 794 Mbits/sec
[ 5] 14.00-15.00 sec 86.9 MBytes 729 Mbits/sec
[ 5] 15.00-16.00 sec 99.2 MBytes 833 Mbits/sec
[ 5] 16.00-17.00 sec 87.4 MBytes 733 Mbits/sec
[ 5] 17.00-18.00 sec 99.1 MBytes 832 Mbits/sec
[ 5] 18.00-19.00 sec 93.0 MBytes 780 Mbits/sec
[ 5] 19.00-20.00 sec 87.8 MBytes 737 Mbits/sec
[ 5] 19.00-20.00 sec 87.8 MBytes 737 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-20.00 sec 1.82 GBytes 783 Mbits/sec receiver
iperf3: the client has terminated
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------возможно драйвера на ПК
-
3 часа назад, Александр Воробьёв сказал:
1-ая проблема: Total Commander (установлен на компьютере) - подключение по FTP - 530 login authentication failed.
В журнале:
Июл 13 11:57:06 ndm
Core::Authenticator: user "admin" authenticated, realm "Keenetic Extra", tag "ftp".
Июл 13 11:57:06 pure-ftpd
(?@192.168.1.85) [ERROR] FTP<->NDM: a "Shared:" root for "admin" is not mounted.
Июл 13 11:57:06 ndm
Core::Session: client disconnected.Логин и пароль правильные.
А если проверить права пользователя на
Скрытый текст
WebDav
Скрытый текст
-
1
-
-
2 часа назад, zyxmon сказал:
Вот Makefile - https://github.com/Entware/graveyard/tree/master/nextdns
nextdns собирается (под arm).Когда/если ответственные за mips* соберут пакет - за Вами тестирование и инструкция.
Если есть связь с автором - напишимте ему, что неплохо бы добавить пару строк в wiki - как собирать приложение.
Связи нет, но попробую написать автору.
-
Возможно ли собрать nextdns для Entware
https://github.com/nextdns/nextdns/wiki/OpenWRT
https://github.com/nextdns/nextdns/wiki
-
22 часа назад, WMac сказал:
Что-то «через раз работает» блокировка. «Игнорировать DNS провайдера» галка стоит», а реклама пролезает. Допустим какого-то домена нет в черном списке. Клик по рекламному баннеру, скопировать адрес и добавляю в пользовательский список запись типа ||скопированный-ркламный.домен^, но реклам один хрен лезет. Кэш браузера чистил.
Это как-то имеет отношение к теме данной ветки "AdGuard Home для Entware. Возможно?"
-
9 часов назад, iburyl сказал:
Есть 3-х этажный дом. На верхнем этаже лучше всего ловит 4G (стоит Keenetic 4G), на нижнем этаже вот-вот доведут PON'овский кабель. Между верхним и нижним этажами проложена витая пара.
Хотелось бы оставить 4G модем, как резервный источник интернета. Инструкции рассказывают, как настроить резервные каналы в рамках одного роутера, но в моей конфигуарации их видится два.
Закуплен Keenetic Giga, чтоб стать основным для получения и раздачи интернета из оптики. Но как настроить систему, чтоб в случае чего, интернет брался из другого роутера я не понимаю.
Интернет--4G---Роутер1-----LAN-----Роутер2---ИнтернетВыход клиента в интернет обеспечивается настройкой маршрута по умолчанию на нем, т.е. клиент должен менять адрес шлюза по умолянию
а - IP адрес Роутера1 например 192.168.1.1
б - IP адрес Роутера2 например 192.168.1.10
Клиенту для выход в интернет нужно чтоб у него адресом шлюза был либо п.а или п.б
или в место клиентов на основном Роутере2 менять IP адрес шлюза по умолчанию :
а - по умолчанию на провайдера (после подключения к интернету)
б - на адрес Роутера2
Если это будет довольно редко (что скорей всего) то можно ручками на странице WEB, а так для автоматического создать скрипт (установить Entware на основном) который будет отслеживать падение интернета и делать смену маршрута по умолчанию на Роутер1 (тут на клиентах менять не чего не надо уже будет).
-
Правильно ли понял про данный функционал релиза 35А10 - "реализована привязка класса обслуживания к зарегистрированным хостам"
ip hotspot host {mac} service-class {1-6}Так как есть упоминание про - CONNNDMMARK и DSCP то это что-то из серии "Реализация политик Qos с кодами DSCP"
Или что-то другое.
-
В 19.06.2020 в 17:35, Goblin сказал:
и где listen на udp?
К ответу на вопрос.
Ну так на релизе 3.4 и бета такого поведения с портами незамеченно.
Релиз 33B24 tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 637/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 637/tsmb-server Релиз 34A tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 630/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 630/tsmb-server Релиз 35A1 tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 630/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 858/tsmb-serverПо смотрим в Windows в PowerSheel
- "netstat -an"
- "netstat -anb"
Дублируемая запись данного порта в TCP
Скрытый текстПротокол TCP - он ориентирован на соединения и обеспечивает надежную передачу данных. Прежде всего, TCP следит за тем, чтобы получающий данные компьютер был готов к их приему. Протокол проводит предусматривающий передачу трех пакетов сеанс согласования, в ходе которого отправитель и получатель договариваются о том, что они готовы к обмену данными. Для этого в состав пакета TCP вводятся флаги состояния; с их помощью узлы обмениваются данными о текущем состоянии передачи (начало, завершение, продолжение). Трафик TCP предусматривает сохранение данных о состоянии. Далее TCP следит за тем, чтобы данные попали в пункт назначения. Если получатель не подтверждает прием того или иного пакета, протокол TCP автоматически возобновляет его передачу — обычно это повторяется три раза. При необходимости TCP разделяет крупные пакеты на пакеты меньших размеров, так чтобы обмен информацией между отправителем и получателем происходил без риска потери данных. TCP отбрасывает пакеты-дубликаты и восстанавливает очередность пакетов, прибывающих не в свою очередь.
Протокол UDP не ориентирован на соединения. Он больше подходит для передачи пакетов ограниченной емкости. UDP не наделен механизмом самопроверки, который подтверждал бы получение данных или следил бы за тем, чтобы они приходили в том же порядке, в каком были посланы. Однако такую проверку часто осуществляет использующее UDP приложение; оно же может направить компьютеру-отправителю запрос на повторную передачу утерянной информации. Кроме того, рассматриваемый протокол не предусматривает сохранение данных о состоянии; следовательно, UDP не проводит сеанса согласования, а пакеты UDP не имеют флагов состояния.
-
24 минуты назад, r777ay сказал:
проблема в 2.16 на 3.5 её нет
ОК, потерялся в релизах в теме.
А так да упоминание порта 3072 стало с 3.4.
-
1
-
-
Погонял Sams на последней 3.5 в режиме BS (предпочитать 5) + 802.11r (FT) смартфон поддерживает.
Да как то корректней стал переключаться обратно и значение Sams действительно уже в других пределах, надо подольше попробовать.
-
6 минут назад, MikhailTSL сказал:
Спасибо за ответы.
Поэкспермпентировал побольше .Вышло, что переход 5->2.4 происходит при rssi ниже -70, а вот 2.4->5 при rssi выше -60. Это телефон определяет? Без рута легальными путями эти настройки меняются? У меня по всей квартире rssi= -60-63, в дальней комнате -70-73. Т.е.значение при котором смарт переходит с 2.4ГГц на 5ГГц мне необходимо опустить до -65.
На всех Sams которые были 2017,2018,2019 года выпуска у всех значение переключения 75, до данного значения держаться зубами - в любом переключении. Надо будет погонять на последних релизах, так как произошли изменения в работе.
Например при использовании "interface {Bridge} mac band {mac} (0|1)" например за 5 то после подключение и некоторого периода времени он вообще не видит 2.4 с данного роутер, соседей видит.
Значение про которое выше можно поменять программой про которую написано выше.
-
5 минут назад, r777ay сказал:
Ну так на релизе 3.4 и бета такого поведения с портами незамеченно.
О каком поведение портов.
В данном случае 3.5 последний на тек.дату
Скрытый текст/ # netstat -ntulp | grep tsmb tcp 0 0 127.0.0.1:7004 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7005 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7006 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7010 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7014 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7020 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7022 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7024 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7025 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 127.0.0.1:7026 0.0.0.0:* LISTEN 646/tsmb-server tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 646/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 646/tsmb-server udp 0 0 0.0.0.0:137 0.0.0.0:* 646/tsmb-server udp 0 0 0.0.0.0:138 0.0.0.0:* 646/tsmb-server udp 0 0 0.0.0.0:5355 0.0.0.0:* 646/tsmb-server / # /proc/646/fdinfo # lsof -i | grep tsmb tsmb-serv 646 root 8u IPv4 1747 0t0 TCP localhost:7010 (LISTEN) tsmb-serv 646 root 15u IPv4 1748 0t0 TCP localhost:afs3-volser (LISTEN) tsmb-serv 646 root 16u IPv4 766 0t0 TCP localhost:50224->localhost:afs3-callback (ESTABLISHED) tsmb-serv 646 root 22u IPv4 1751 0t0 TCP localhost:7014 (LISTEN) tsmb-serv 646 root 23u IPv4 1752 0t0 UDP *:netbios-ns tsmb-serv 646 root 29u IPv4 1754 0t0 TCP localhost:7022 (LISTEN) tsmb-serv 646 root 30u IPv4 1755 0t0 UDP *:netbios-dgm tsmb-serv 646 root 36u IPv4 2991 0t0 TCP localhost:7020 (LISTEN) tsmb-serv 646 root 42u IPv4 1826 0t0 TCP localhost:7024 (LISTEN) tsmb-serv 646 root 43u IPv4 4135 0t0 TCP *:3702 (LISTEN) tsmb-serv 646 root 44u IPv4 4136 0t0 UDP *:3702 tsmb-serv 646 root 50u IPv4 1827 0t0 TCP localhost:7025 (LISTEN) tsmb-serv 646 root 51u IPv4 4144 0t0 UDP *:hostmon tsmb-serv 646 root 57u IPv4 1828 0t0 TCP localhost:7026 (LISTEN) tsmb-serv 646 root 66u IPv4 1829 0t0 TCP localhost:afs3-kaserver (LISTEN) tsmb-serv 646 root 72u IPv4 1832 0t0 TCP localhost:afs3-errors (LISTEN) tsmb-serv 646 root 73u IPv4 1834 0t0 TCP localhost:afs3-kaserver->localhost:56994 (ESTABLISHED) tsmb-serv 646 root 74u IPv4 1838 0t0 TCP localhost:7026->localhost:51200 (ESTABLISHED) tsmb-serv 646 root 75u IPv4 1839 0t0 TCP localhost:7010->localhost:53026 (ESTABLISHED) tsmb-serv 646 root 81u IPv4 6178 0t0 TCP localhost:afs3-errors->localhost:49798 (ESTABLISHED) tsmb-serv 646 root 82u IPv4 5317 0t0 TCP localhost:52978->localhost:7019 (CLOSE_WAIT) tsmb-serv 646 root 83u IPv4 1867 0t0 TCP localhost:afs3-volser->localhost:53914 (ESTABLISHED) tsmb-serv 646 root 84u IPv4 1878 0t0 TCP localhost:56832->localhost:7013 (CLOSE_WAIT) tsmb-serv 646 root 86u IPv4 10302 0t0 TCP 192.168.1.1:3702->192.168.1.2:54576 (CLOSE_WAIT) tsmb-serv 646 root 87u IPv4 21143 0t0 TCP 192.168.1.1:3702->192.168.1.2:49670 (CLOSE_WAIT) tsmb-serv 646 root 88u IPv4 21824 0t0 TCP 192.168.1.1:3702->192.168.1.2:49673 (CLOSE_WAIT) tsmb-serv 646 root 89u IPv4 21826 0t0 TCP 192.168.1.1:3702->192.168.1.2:49676 (CLOSE_WAIT) tsmb-serv 646 root 90u IPv4 21828 0t0 TCP 192.168.1.1:3702->192.168.1.2:49677 (CLOSE_WAIT) tsmb-serv 646 root 91u IPv4 21830 0t0 TCP 192.168.1.1:3702->192.168.1.2:49681 (CLOSE_WAIT) tsmb-serv 646 root 92u IPv4 21863 0t0 TCP 192.168.1.1:3702->192.168.1.2:49684 (CLOSE_WAIT) tsmb-serv 646 root 93u IPv4 21864 0t0 TCP 192.168.1.1:3702->192.168.1.2:49690 (CLOSE_WAIT) tsmb-serv 646 root 94u IPv4 21866 0t0 TCP 192.168.1.1:3702->192.168.1.2:49693 (CLOSE_WAIT) tsmb-serv 646 root 95u IPv4 24438 0t0 TCP 192.168.1.1:3702->192.168.1.2:51801 (CLOSE_WAIT) tsmb-serv 646 root 96u IPv4 28142 0t0 TCP 192.168.1.1:3702->192.168.1.2:52166 (CLOSE_WAIT) tsmb-serv 646 root 97u IPv4 28193 0t0 TCP 192.168.1.1:3702->192.168.1.2:52213 (CLOSE_WAIT) tsmb-serv 646 root 98u IPv4 28194 0t0 TCP 192.168.1.1:3702->192.168.1.2:52215 (CLOSE_WAIT) tsmb-serv 646 root 101u IPv4 28200 0t0 TCP 192.168.1.1:3702->192.168.1.2:52222 (CLOSE_WAIT) tsmb-serv 646 root 102u IPv4 28201 0t0 TCP 192.168.1.1:3702->192.168.1.2:52223 (CLOSE_WAIT) /proc/646/fdinfo # [global] ... listen = ANY,192.168.1.1,IPv4,445,DIRECT_TCP listen = ANY,192.168.1.1,IPv4,137,NBNS listen = ANY,192.168.1.1,IPv4,138,NBDS listen = br0,::,IPv6,445,DIRECT_TCP listen = ANY,192.168.1.1,IPv4,3702,WSD listen = ANY,192.168.1.1,IPv4,5355,LLMNR listen = ANY,192.168.1.1,IPv4,139,NBSS listen = br0,::,IPv6,139,NBSS log_level = 1 [/global]Релиз 33B24
tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 637/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 637/tsmb-serverРелиз 34A
tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 630/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 630/tsmb-serverРелиз 35A1
tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 630/tsmb-server udp 0 0 0.0.0.0:3702 0.0.0.0:* 858/tsmb-serverРелиз 33A3 данный порт не использовался
-
1 час назад, Goblin сказал:
есть ltsc версии 2004? на сколько я знаю последняя ltsc 1809 и больше не было. так что не судьба. ждемс.
Без проблем работает описанным выше способом, так что можно не ждать.
-
3 часа назад, MikhailTSL сказал:
Имею роутер Keenetic Giga, не совсем понимаю в чем смысл работы данной функции (band steering). Подключаю смартфон(samsung a51) к сети wifi, находясь прямо перед роутером, скорость достигает 40МБ/с (роутер показывает соединение 5ГГц с шириной канала 1х80), ухожу в дальнюю комнату квартиры, 5ГГц там почти не ловит, роутер переключается на 2 4ГГц и дает скорость около 5МБ/с, далее подхожу вплотную к роутеру, получаю скорость 7-8МБ/с...и прежних 40 уже и в помине нет и не будет, пробовал час передачи файлов вплотную, т.е. более 7-8 уже не получить, только если вручную wifi выключить/включить...
Насколько понимаю, дело тут в ширине канала (80), т.е. роутер переключает меня на частоту 5, но ширину канала 80 уже не дает, соответственно, нет и особого роста скорости.
Как(и можно ли) решить данную проблему?
Прошивка последняя, не бета.
По Samsung в том числе и по A51.
1.Root не нужен, включаете разработчика и в новом разделе "Параметры разработчика" идете в раздел "Сети" там включаете
- Серт.беспровод.мониторов
- Подробный журнал WiFi
- Ограничение поиска сетей WiFi
на прочий функционал смартфона (не влияет) включение разработчика.
2. При подключении к сети Wifi долгий таб на Wifi (шторка сверху)
3. Включаем
4. Выбираем нужную сеть и видим информацию по выбранной сети - частота, MAC роутера, rssi. Если band steering используеться то увидите две частоты и два rssi и "*" на активном.
5. Гуляя с телефон по помещению (квартире) видим изменение значений rssi и на каком "*"
6. Для Sams параметр переключения равен 75.
Для проверки работы в вашем случае так же учесть параметры "Предпочтение для 5GHz" и "Управление BSS-окружением 802.11k/v"
Скрытый текстSamsung a51 "station": [ { "mac": "...", "ap": "WifiMaster1/AccessPoint0", wifi 5 "authenticated": true, "txrate": 292, "rxrate": 433, "uptime": 78, "txbytes": 472937, "rxbytes": 12983217, "ht": 80, "mode": "11ac", "gi": 800, "rssi": -70, "mcs": 7, "txss": 1, "ebf": true, "mu": false, "_11": [ "k", "r", "v"Для изменения параметра 75 есть программа WifiFixer.
Так же возможно будет интересно
-
1
-
-
В 18.06.2020 в 10:14, Goblin сказал:
я забил на все эти поиски/определения и руками прописал сетевой диск на 192.168.1.1 и он доступен всегда. кстати, после входа в этот диск появляется и сам роутер в сети.
На одном Win10 сделал запуск скрипта при старте клиента, т.е. запись "Work (\\G-kn10\d3-1) (Z:)"
Скрытый текстMapDrivers.cmd PowerShell -Command "Set-ExecutionPolicy -Scope CurrentUser Unrestricted" >> "C:/Windows/Script/StartupLog.txt" 2>&1 PowerShell -File "C:/Windows/Script/MapDrives.ps1" >> "C:/Windows/Script/StartupLog.txt" 2>&1 MapDrives.ps1 $i=3 while($True){ $error.clear() $MappedDrives = Get-SmbMapping |where -property Status -Value Unavailable -EQ | select LocalPath,RemotePath foreach( $MappedDrive in $MappedDrives) { try { New-SmbMapping -LocalPath $MappedDrive.LocalPath -RemotePath $MappedDrive.RemotePath -Persistent $True } catch { Write-Host "There was an error mapping $MappedDrive.RemotePath to $MappedDrive.LocalPath" } } $i = $i - 1 if($error.Count -eq 0 -Or $i -eq 0) {break} Start-Sleep -Seconds 30 }В планировщике стоит - задача "reMapNetworkDrives" при входе, параметр "Действие" - запуск "C:/Windows/Script/MapDrives.cmd"
После рестарта Windows появляется окно (можно сделать так что не будет появляться" отрабатывает и закрывается (если есть проблема в сети то окно может не закрыться)
На ПК с NVMe диском как-то все быстро - окно появилось и через 1-2сек. исчезает.
Но как написано выше на последних релизах Windows все исправлено.
-
13 часа назад, sabretoothedhamster сказал:
Локально в качестве удлиннителя подключен ведомым (по WiFi) Keenetic Air, и на них обоих висит 5-10 WiFi устройств.
В логах ничего криминального не видно. Идёт обычная сетевая жизнь, обновляются dhcp, upnp и всё такое. Единственное не вполне понятное:
kernel: br0: port 5(rai4.1) received tcn bpdu kernel: br0: topology change detected, propagatingиногда раз в несколько часов, а иногда несколько раз за минуту. Что за топология может меняться в моём случае - ума не приложу.
Куда смотреть, чтобы найти причину этих тормозов?
Wifi система на основном Keenetic Giga III, 3.4.3, интерфейс "rai4.1"
Предварительно прочитать что ниже.
Скрытый текстВот например ком. ТП по схожему вопросу, правда речь про LAN
[I] May 28 20:01:50 kernel: br0: port 1(eth2.1) entered blocking state [I] May 28 20:01:50 kernel: br0: port 1(eth2.1) entered listening state [I] May 28 20:01:53 kernel: br0: port 1(eth2.1) entered learning state [I] May 28 20:01:56 kernel: br0: port 1(eth2.1) entered forwarding stateВ KeeneticOS 3.4.1 для предотвращения образования петель добавлен протокол STP. Прежде всего он необходим для работы интернет-центра в составе Wi-Fi системы. Когда появляется новое подключение на порту, роутер должен проверить не приведет ли его включение к возникновению петли. Для этого он временно блокирует обмен и изучает приходящие данные. Это требует некоторого времени. Как только роутер поймет, что включение порта безопасно и не ведет к возникновению петли, передача данных возобновляется.
Это может быть критично, если в сети есть устройства, которые в силу каких то особенностей часто поднимают/бросают Ethernet подключение. Насколько мне известно, такое поведение характерно для телевизоров Sony. На роутере несколько раз в минуту пропадает подключение на порту 3.
Если Keenetic один и вы не используете Wi-Fi систему, удалите компонент Контроллер Wi-Fi-системы в
меню Общие настройки > Изменить набор компонентов.и посмотреть https://help.keenetic.com/hc/ru/articles/360007279039-Mesh-Wi-Fi
Для начала попробовать Air на кабель, так же релиз на Air до текущего и оценить работу клиентов в данный момент времени.
Пример
Ниже скрин от схемы двух роутеров на wifi между ними и работу интерфейсов
Скрытый текст
--KN3010--Wifi--KN1010-- / # brctl show ... br0 = ra5 + ra9.1 + eth2.1 + ra4.1 + ra0 где br0 - основной интерфейс роутера, в данном случае в него включены : - ra... wifi интерфейсы на 5 и 2.4 - eth2.1 LAN интерфейс
UPnP: Открытие портов по UPnP
in 3.5
Posted
Простое прокидывание портов, как работало начиная с 3.5 так и работает 35А16
NAS---LAN----KN10---LAN---KN19----ИнтернетПо конф файлу
ip static tcp ISP 8xxx 192.168.xxx.xx2 8x !Dxxxx9
ip static tcp ISP 6xxxx 192.168.xxx.xx2 2x !Sxx
ip static tcp ISP 4xx 192.168.xxx.xx2 4xx !Dzzzz9 HTTPS
ip static tcp ISP 2xxxx 192.168.xxx.xx2 2xxx4 !S-conf
ip static tcp ISP 2xxxx 192.168.xxx.xx2 2xxx5 !S-play
ip static tcp ISP 2xxxx 192.168.xxx.xx2 2xxx6 !S-potok
ip static tcp ISP 6xxx6 192.168.xxx.xx2 6xxx6 !BTSync
ip static tcp ISP 6xxx6 192.168.xxx.xx2 2x !uT
ip static tcp ISP 6xxx1 192.168.xxx.xx2 21 !Fxxx32