Появилась (или была ранее на 4.x) старая болячка "флуд на WG" по описанному п.3 т.е.
- основной канал PPPoE поднят и он основной
- WG канал в резерве
отключаю основной канал PPPoE на и WG появляется "флуд"
Скрытый текст
под wifi клиентом на WEB роутера не войти, под LAN клиентом без проблем. После восстановления каналов интернета - клиент wifi основного bridge0 сегмента без проблем подключился, почему основного потому что есть доп. сегмент bridge1 с wifi 2.4 и своими клиентами, но про них речь уже ниже.
******
Так же заметил проблему после такого эксперимента с октлючением PPPoE канала и флудом на WG. Есть доп.сегмент wifi 2.4 для умного дома и чуток клиентов. Так после описанной выше "болячки" когда все поднялось PPPoE/WG и клиент wifi основного сегмента подключился без проблем, то клиенты доп.сегмента bridge1 умного дома отказались подключаться (в этом сегменте только wifi 2.4 клиенты). Пришлось передернуть Wifi данного сегмента (вкл/выкл.) тогда один клиент подключился сразу же (марка всех одинакова), а другие курили.
Фев 4 08:36:07 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout).
Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had associated successfully.
Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had associated successfully.
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) pairwise key handshaking timeout (msg 1 of 4-way).
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had deauthenticated by AP (reason: PTK 4-way handshake timeout).
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) pairwise key handshaking timeout (msg 1 of 4-way).
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout).
через некоторое время еще одному удалось подключиться
Фев 4 08:38:06 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:5f) set key done in WPA2/WPA2PSK.
Фев 4 08:38:06 ndhcps DHCPDISCOVER received from .....:5f.
Фев 4 08:38:06 ndhcps making OFFER of 192.168.150.4 to .....:5f.
Фев 4 08:38:06 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f.
Фев 4 08:38:06 ndm Netfilter::Util::Conntrack: flushed 52 IPv4 connections.
Фев 4 08:38:06 ndhcps sending ACK of 192.168.150.4 to ......:5f.
Фев 4 08:38:07 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f.
Фев 4 08:38:08 ndhcps sending ACK of 192.168.150.4 to .....:5f.
Фев 4 08:38:08 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.......:99) had associated successfully.
с момента первой записи о проблеме на клиентах
Подъем каналов - PPPoE и WG ранее
[I] Feb 4 08:30:06 kernel: br1: port 2(ra1) entered disabled state
[I] Feb 4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "running" to "disabled".
[I] Feb 4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is down.
[I] Feb 4 08:30:06 ndm: Core::System::StartupConfig: saving (http/rci).
[I] Feb 4 08:30:06 kernel: br1: port 2(ra1) entered disabled state
[I] Feb 4 08:30:06 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "running" to "pending".
[I] Feb 4 08:30:06 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer stopped.
[I] Feb 4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_UP): ra1: link is not ready
[I] Feb 4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ra1: link becomes ready
[I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered blocking state
[I] Feb 4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "disabled" to "running".
[I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered listening state
[I] Feb 4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is up.
[I] Feb 4 08:30:10 ndm: Core::System::StartupConfig: saving (http/rci).
[I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered blocking state
[I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered listening state
[I] Feb 4 08:30:10 ndm: Core::System::StartupConfig: configuration saved.
[I] Feb 4 08:30:10 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "pending" to "running".
[I] Feb 4 08:30:10 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer started.
[I] Feb 4 08:30:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.....:99) had associated successfully.
....
После ожидания все подключились
Фев 4 08:41:02 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:99) set key done in WPA2/WPA2PSK.
Фев 4 08:41:02 ndhcps DHCPDISCOVER received from .....:99.
Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99.
Фев 4 08:41:02 ndhcps DHCPDISCOVER received from ......:99.
Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99.
Фев 4 08:41:02 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.2 from ......:99.
Фев 4 08:41:02 ndm Netfilter::Util::Conntrack: flushed 60 IPv4 connections.
Фев 4 08:41:03 ndhcps sending ACK of 192.168.150.2 to .....:99.
Время на раздумье около 10минут при таком поведение хватило.
В итоге делаю вывод что оценка интернет каналов (состояние) приводит ????? на других интерфейсов не связанных с данными каналами - например bridge1 доп.сегмент в котором только 2.4 wifi.
Все как бы ОК но в WEB роутера "шторка" с надписью "Потеря соединения с интернет центром". Придется перезапустить его.
Настройки доп.сегмента простые
Скрытый текст
interface Bridge1
description HomeSmart
include GigabitEthernet0/Vlan3
include WifiMaster0/AccessPoint1
mac access-list type permit
mac access-list address .....:af
mac access-list address .....:99
mac access-list address .....:5f
mac access-list address .....:00
mac access-list address .....:c1
mac access-list address .....:e0
security-level protected
ip address 192.168.150.101 255.255.255.0
ip dhcp client dns-routes
ip dhcp client name-servers
up
interface WifiMaster0/AccessPoint1
mac access-list type none
security-level protected
authentication wpa-psk ns3 ***
encryption enable
encryption wpa2
ip dhcp client dns-routes
ip dhcp client name-servers
ssid Smart
up
You can post now and register later.
If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.
Question
vasek00
Появилась (или была ранее на 4.x) старая болячка "флуд на WG" по описанному п.3 т.е.
- основной канал PPPoE поднят и он основной
- WG канал в резерве
отключаю основной канал PPPoE на и WG появляется "флуд"
под wifi клиентом на WEB роутера не войти, под LAN клиентом без проблем. После восстановления каналов интернета - клиент wifi основного bridge0 сегмента без проблем подключился, почему основного потому что есть доп. сегмент bridge1 с wifi 2.4 и своими клиентами, но про них речь уже ниже.
******
Так же заметил проблему после такого эксперимента с октлючением PPPoE канала и флудом на WG. Есть доп.сегмент wifi 2.4 для умного дома и чуток клиентов. Так после описанной выше "болячки" когда все поднялось PPPoE/WG и клиент wifi основного сегмента подключился без проблем, то клиенты доп.сегмента bridge1 умного дома отказались подключаться (в этом сегменте только wifi 2.4 клиенты). Пришлось передернуть Wifi данного сегмента (вкл/выкл.) тогда один клиент подключился сразу же (марка всех одинакова), а другие курили.
Фев 4 08:36:07 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout). Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had associated successfully. Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had associated successfully. Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) pairwise key handshaking timeout (msg 1 of 4-way). Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had deauthenticated by AP (reason: PTK 4-way handshake timeout). Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) pairwise key handshaking timeout (msg 1 of 4-way). Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout).
через некоторое время еще одному удалось подключиться
Фев 4 08:38:06 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:5f) set key done in WPA2/WPA2PSK. Фев 4 08:38:06 ndhcps DHCPDISCOVER received from .....:5f. Фев 4 08:38:06 ndhcps making OFFER of 192.168.150.4 to .....:5f. Фев 4 08:38:06 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f. Фев 4 08:38:06 ndm Netfilter::Util::Conntrack: flushed 52 IPv4 connections. Фев 4 08:38:06 ndhcps sending ACK of 192.168.150.4 to ......:5f. Фев 4 08:38:07 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f. Фев 4 08:38:08 ndhcps sending ACK of 192.168.150.4 to .....:5f. Фев 4 08:38:08 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.......:99) had associated successfully.
с момента первой записи о проблеме на клиентах
Подъем каналов - PPPoE и WG ранее [I] Feb 4 08:30:06 kernel: br1: port 2(ra1) entered disabled state [I] Feb 4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "running" to "disabled". [I] Feb 4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is down. [I] Feb 4 08:30:06 ndm: Core::System::StartupConfig: saving (http/rci). [I] Feb 4 08:30:06 kernel: br1: port 2(ra1) entered disabled state [I] Feb 4 08:30:06 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "running" to "pending". [I] Feb 4 08:30:06 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer stopped. [I] Feb 4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_UP): ra1: link is not ready [I] Feb 4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ra1: link becomes ready [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered blocking state [I] Feb 4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "disabled" to "running". [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered listening state [I] Feb 4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is up. [I] Feb 4 08:30:10 ndm: Core::System::StartupConfig: saving (http/rci). [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered blocking state [I] Feb 4 08:30:10 kernel: br1: port 2(ra1) entered listening state [I] Feb 4 08:30:10 ndm: Core::System::StartupConfig: configuration saved. [I] Feb 4 08:30:10 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "pending" to "running". [I] Feb 4 08:30:10 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer started. [I] Feb 4 08:30:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.....:99) had associated successfully. ....
После ожидания все подключились
Фев 4 08:41:02 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:99) set key done in WPA2/WPA2PSK. Фев 4 08:41:02 ndhcps DHCPDISCOVER received from .....:99. Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99. Фев 4 08:41:02 ndhcps DHCPDISCOVER received from ......:99. Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99. Фев 4 08:41:02 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.2 from ......:99. Фев 4 08:41:02 ndm Netfilter::Util::Conntrack: flushed 60 IPv4 connections. Фев 4 08:41:03 ndhcps sending ACK of 192.168.150.2 to .....:99.
Время на раздумье около 10минут при таком поведение хватило.
В итоге делаю вывод что оценка интернет каналов (состояние) приводит ????? на других интерфейсов не связанных с данными каналами - например bridge1 доп.сегмент в котором только 2.4 wifi.
Все как бы ОК но в WEB роутера "шторка" с надписью "Потеря соединения с интернет центром". Придется перезапустить его.
Настройки доп.сегмента простые
interface Bridge1 description HomeSmart include GigabitEthernet0/Vlan3 include WifiMaster0/AccessPoint1 mac access-list type permit mac access-list address .....:af mac access-list address .....:99 mac access-list address .....:5f mac access-list address .....:00 mac access-list address .....:c1 mac access-list address .....:e0 security-level protected ip address 192.168.150.101 255.255.255.0 ip dhcp client dns-routes ip dhcp client name-servers up interface WifiMaster0/AccessPoint1 mac access-list type none security-level protected authentication wpa-psk ns3 *** encryption enable encryption wpa2 ip dhcp client dns-routes ip dhcp client name-servers ssid Smart up
Link to comment
Share on other sites
5 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.