sergeyk
-
Постов
1 468 -
Зарегистрирован
-
Посещение
-
Победитель дней
10
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент sergeyk
-
Всё равно не понятно, почему одного недостаточно.
-
Вы сделали две подсети, а теперь хотите их объединить, вместо того чтобы использовать одну. В чём идея?
-
Это особенность работы клиента Wi-Fi: когда он не приассоциирован к точке доступа, но настроен, он находится в режиме поиска станции. Поиск предполагает периодическое сканирование эфира с переключением каналов. Поскольку радиотракт общий у клиента и точек доступа, точки вместе с клиентом переходят на другие каналы при сканировании. Выход тут только один — вручную фиксировать канал.
-
(config)> components auto-update channel delta Components::Manager: Auto-update channel is "delta". (config)> copy running-config startup-config (config)>
- 1 ответ
-
- 2
-
-
@Дмитрий Столетов что насчёт 3.9.5? https://forum.keenetic.com/topic/14584-журнал-изменений-39/#comment-162331
-
@KYTECHNGAMING please also attach a (hidden) self-test from the running device.
-
Как уже написал выше @r13, команда управления только одна [no] interface <Parent>/VlanX В качестве <Parent> может выступать любой интерфейс Wi-Fi. Интерфейс <Parent>/VlanX передаёт данные в среду, добавляя тег X, и принимает данные из среды, снимая тег. Например, если у вас есть тегированный трафик с VLAN 10 на порту свитча GigabitEthernet0/1, его можно тегированным же передавать по Wi-Fi через точку доступа, настроив мост между этими интерфейсами: interface GigabitEthernet0/1 switchport mode trunk interface GigabitEthernet0/1 switchport trunk vlan 10 interface GigabitEthernet0/Vlan10 interface WifiMaster0/AccessPoint0/Vlan10 interface Bridge10 interface Bridge10 include GigabitEthernet0/Vlan10 interface Bridge10 include WifiMaster0/AccessPoint0/Vlan10 При такой конфигурации внутри Bridge10 ходит нетегированный трафик из VLAN 10, а в сторону порта свитча GigabitEthernet0/1 и точки WifiMaster0/AccessPoint0 — тегированный.
-
Yes, then please upload to Yandex.
-
Please attach here in a hidden post.
-
@KYTECHNGAMING Sorry for inconvenience, the right command is tcpdump -i br0 -s 0 -U -w /<path-to-usb-storage/tsmb_crash.pcap port 445 >/dev/null 2>&1
-
Строго говоря, никакие функции не теряется, только настраивать некоторые из них становиться менее удобно.
-
Вы можете не добавлять устройство в Wi-Fi-систему и настраивать его интерфейсы вручную.
-
Unfortunately syslog messages are not enough. It is need the packet dump saved at the crash moment. Could you use the tcpdump utility in an unbuffered mode from opkg? tcpdump -U -w /<path-to-usb-storage/tsmb_crash.pcap port 445 >/dev/null 2>&1
-
(config)> interface GigabitEthernet0/Vlan9 standby enable Network::Interface::Standby: "GigabitEthernet0/Vlan9": enabled. (config)> interface PPPoE0 standby enable Network::Interface::Standby: "PPPoE0": enabled.
-
Когда в очередной раз обнаружите такое состояние, сохраняйте self-test до отключения Wi-Fi (когда DHCP не работает) и после (когда DHCP заработает).
-
Как вы его перезапускаете?
-
I suppose you may reconfigure the camera to make backups at any time to speedup the investigation.
-
@Race можете попробовать воспользоваться новой функцией Включайте на обоих подключениях к провайдеру и они будут автоматически включаться попеременно.
-
Сервер только предлагает (OFFER) адрес, присваивать и назначать его себе — задача клиента.
-
@KYTECHNGAMING looks like the root cause of reboots is a tsmb module crash (see proc:mtdoops/ndm section in your self-tests). "oops": { "origin": "kernel", "version":"4.00.A.13.0-0", "board": "KN-1011", "timestamp": "2023-03-14 00:19:58", "hash": "b6d5955", and "oops": { "origin": "kernel", "version":"4.00.A.13.0-0", "board": "KN-1011", "timestamp": "2023-03-15 00:19:59", "hash": "9e603c3a", Could you investigate what happens at this time in your network? I do not see any configured schedules in your startup configuration. Probably a packet capture for a SMB protocol close to this time will help (a packet capture should be stored on a USB storage to keep it in a case of a kernel crash).
-
Все эти сообщения от процесса ndhcps (DHCP-сервера). С его стороны видно, что приходят запросы от клиента 44:da:30:**** и он на них исправно отвечает.
-
Из вашего журнала со стороны сервера видно, что сервер отсылает OFFER, про клиента тут ничего нет.
-
Видимо придётся захватить обмен пакетами для диагностики.
-
Если вы хотите помочь в отладке, нужно сохранить файлы self-test с обоих устройств через telnet или мобильное приложение, например.
-
Для отладки его не нужно принимать. Оно не новое: <eula-status> <version>20200330</version> </eula-status>