Навигация Форума
Вы должны войти в систему для того, чтобы создавать сообщения и темы.

Проблемы с DHCP ...

На прошивке 7.6.19.RU.17112018 проблема с падением DHCP не проявилась.
Конфиг и кусок Лога (маки порезал) прикрепил.
Лог снимал по ssh как вы просили командой "tail -f /var/log/messages".
Honor 8 на это время был переведен на 2,4ГГц диапазон (может важно).

Загруженные файлы:

Что странно.

Мак хонора проблемного с 80кой мне на мыло (раз уж маки в паблик для вас страшно, хотя я вот откровенно не понимаю чем =))). Вот сейчас прям какраз есть время, возможность и необходимость всё дерево пересобрать. Чего вот было не скинуть блин? Просил же.

Попробовал поставить 7.6.18 и за 46 часов пока всё хорошо(один телефон специально висит на DHCP). Хотя сколько Wive использую всегда были изменены границы диапазона(начало, конец и даже маска подсети). Однако у меня сейчас 5ГГЦ выключен и пароль не содержит спецсимволов, может в этом направлении надо пробовать? Кстати интересно было бы узнать, какие символы можно на данный момент использовать в паролях?

З.Ы. WatchDog теперь по-умолчанию включен?

1 Есть подозрение что регрессия в dhcp может себя проявлять только в случае если клиент пытается запросить запомненный им адрес за границами выделенного диападона. Т.е. был полный диапазон, его уменьшили, клиент пытается продлить лизу для уже полученного адреса который терь вне границ, шлёт это серверу и сервер склеивает ласты. Вернусь в екб расколупаю этот момент. Ничего другого там в голову не приходит.

2 Пароли и спецсимволы и прочие тут точно не причём. Собсно весь низкий уровень продолжает работать, а отваливается dhcp и выше.

3 Отключена софтовая пиналка, ватчдог  на 762х всю жизнь включен всю дорогу только что не страдает буйством, всмысле не агрессивен. Включаем пиналку и получаем полностью аналогичное 305х поведение. Без пиналки будет срабатывать гораздо позже что бы можно было с консоли логи успеть снять и что бы ложных срабатываний не было уж точно и гарантированно. При нормальной работе нет разницы по большому счёту, крутилку можно было бы вообще убрать и оставить поведение вообще без софт запинывания. Но решил пусть будет.

По спецчимволам. Драйвер ничего не знает ни о каких многобайтовых кодировках и оперирует строками напрямую, т.е. гарантированно может корректно сожрать us ascii-7 . Сейчас Sadler занимается выверением везде и всего на эту тему, а то с годами там уже бардачок вырисовался, пора привести в чувства.

Хонор очередной добавлен, собираю 7.6.20 в test-only.

 

Продолжаю тестировать 7.6.19.RU.17112018. Вчера выключил на 5ГГц 80Мгц, утром все работает. Сегодня переключу 5ГГц в режим an/ac, 2,4ГГЦ в n-only и до завтра протестирую, логирование по ssh пока прекращаю, если повторится проблема, то сделаю логирование.

Просто перейдите на 7.6.20 и не выключайте 80ку. Хонор будет работать в 40, остальные в 80.

Т.е. больше из-за одного кривенького клиента не придётся всем обрушивать производительность. Особенно это важно если одновременно работающих клиентов. Чем быстрее каждый закончит своё грязное дело (приём/передачу) тем  больше достанется эфирного времени остальным. Тем менее заметное влияние друг на друга они будут оказывать при одновременной работе.

 

На 7.6.20 без отключения 80мгц Хонор подключается и работает. Спасибо.

 Есть подозрение что регрессия в dhcp может себя проявлять только в случае если клиент пытается запросить запомненный им адрес за границами выделенного диападона. Т.е. был полный диапазон, его уменьшили, клиент пытается продлить лизу для уже полученного адреса который терь вне границ, шлёт это серверу и сервер склеивает ласты.

Скорее всего в этом и причина.

Чтобы завис dhcp в роутере алгоритм настройки следующий. Сначала даем dhcp в роутере раздать ip-адреса,  потом сужаем диапазон и можно поставить статику (у меня 1 статический ip), роутер не перезагружаем.

Я с прошивки 7.6.19.RU.17112018 начал роутер после всех настроек перезагружать и видимо по этому проблема пропадала.

 

Вот и у меня других объяснений нет. Попробую проверить как вернусь. Благо при эксплуатации в нормальном режиме (всмысле настроил и забыл) проблема не повториться.

Тестирование в течение последней недели на прошивке SNR-CPE-ME1-5GHZ-MT-MT7621-MT7603-MT7610-1T1R-16M-USB.7.6.21.RU.20112018 показало, что описанная проблема проявляется когда делаем так:

Чтобы завис dhcp в роутере алгоритм настройки следующий. Сначала даем dhcp в роутере раздать ip-адреса,  потом сужаем диапазон и можно поставить статику (у меня 1 статический ip), роутер не перезагружаем.

Единственное, что заметил в Логе, так это постоянно находит статику (1 статический адрес). Роутер работает и после настройки никаких изменений не в настройки роутера, не в настройки сетевого подключения операционной системы (Win7) изменения не вносятся.

Nov 30 10:34:14 kernel: ESW: Link Status Changed - Port1 Link Up
Nov 30 10:34:18 kernel: ESW: Link Status Changed - Port1 Link Down
Nov 30 10:34:23 kernel: ESW: Link Status Changed - Port1 Link Up
Nov 30 10:34:41 kernel: ESW: Link Status Changed - Port1 Link Down
Nov 30 10:34:44 kernel: ESW: Link Status Changed - Port1 Link Up
Nov 30 10:34:51 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:34:51 udhcpd[3784]: sending OFFER of 192.168.1.2
Nov 30 10:34:51 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:34:51 udhcpd[3784]: sending ACK to 192.168.1.2
Nov 30 10:34:54 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:35:58 kernel: ESW: Link Status Changed - Port1 Link Down
Nov 30 10:36:00 kernel: ESW: Link Status Changed - Port1 Link Up
Nov 30 10:36:17 kernel: ESW: Link Status Changed - Port1 Link Down
Nov 30 10:36:20 kernel: ESW: Link Status Changed - Port1 Link Up
Nov 30 10:36:23 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:36:23 udhcpd[3784]: sending ACK to 192.168.1.2
Nov 30 10:36:26 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:38:37 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:47:00 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:51:05 udhcpd[3784]: found static lease: 201a8c0
Nov 30 10:54:29 udhcpd[3784]: found static lease: 201a8c0

 

Т.е. если после настройки ребутнуть что бы клиент забыли адреса за пределами диапазона то всё ок?

Я накропал синтетику под такой кейз но проявляться не хочет. Надо репорт родить бизибоксерам. Освобожусь чутка сделаю. Благо косяк не критичный ибо после завершения конфигурации таки must have контрольный выстрел в голову с перезагрузкой что бы убедиться что всё ок.

Нет ну можно конечно при реконфигуре dhcp мигать портами, но это не решение самой проблемы, а воркэраунд.

Чёт подумалось, по хорошему надо же старый файл лиз при изменении настроек-то прибивать. Добавил. Будет в 7.6.28.

Хотя как бы это не должно приводить в любом случае к такому поведению.

Может проблема с постоянным обнаружением статики в моей сетевой карте, драйверах или самой ОС Windows?

Ну во первых падать оно не должно один фиг. Во вторых дрова как бы к этому отношения обычно не имеют. Скорее всего что-то в udhcpd поломали в бизибоксе, но вот что именно служит триггером пока выяснить не удаётся.

Удаление lease file при apply параметров dhcp сервера скорее всего решит проблему. Но как бы надо таки будет разобраться.

Часа через 3 залью срез в test-only с этой правкой.

Залил 7.6.27 с правкой https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/ просьба погонять.

Кабель из Wan вынут.  Роутер перезагружен после прошивки 7.6.27. DHCP роутера присвоил подключению по лан IP-адрес.  Статику пока не настраиваю. После устанавливаю конечный IP адрес на 192.168.1.25. Снизу лог и скрины.

Dec 3 21:22:48 udhcpd[9179]: started, v1.29.3
Dec 3 21:22:49 udhcpc[7751]: sending discover
Dec 3 21:22:49 irqbalance: Stopping irqbalance
Dec 3 21:22:49 irqbalance: Start irqbalance routing/wifi optimize mode
Dec 3 21:22:49 irqbalance: Start irqbalance auto mode
Dec 3 21:22:53 udhcpd[9179]: sending ACK to 192.168.1.28
Dec 3 21:22:53 kernel: br0: port 1(eth2) entered forwarding state
Dec 3 21:22:54 udhcpc[7751]: sending discover
Dec 3 21:22:56 kernel: br0: port 2(ra0) entered forwarding state
Dec 3 21:22:56 kernel: br0: port 3(rai0) entered forwarding state
Dec 3 21:22:59 udhcpc[7751]: sending discover
Dec 3 21:23:04 udhcpc[7751]: sending discover
Dec 3 21:23:09 udhcpc: Lease fail eth3.
Dec 3 21:23:29 udhcpc[7751]: sending discover
Dec 3 21:23:34 udhcpc[7751]: sending discover
Dec 3 21:23:39 udhcpc[7751]: sending discover
Dec 3 21:23:44 udhcpc[7751]: sending discover
Dec 3 21:23:49 udhcpc[7751]: sending discover
Dec 3 21:23:54 udhcpc: Lease fail eth3.
Dec 3 21:24:14 udhcpc[7751]: sending discover
Dec 3 21:24:19 udhcpc[7751]: sending discover
Dec 3 21:24:24 udhcpc[7751]: sending discover
Dec 3 21:24:29 udhcpc[7751]: sending discover
Dec 3 21:24:34 udhcpc[7751]: sending discover
Dec 3 21:24:39 udhcpc: Lease fail eth3.
Dec 3 21:24:59 udhcpc[7751]: sending discover
Dec 3 21:25:04 udhcpc[7751]: sending discover
Dec 3 21:25:09 udhcpc[7751]: sending discover
Dec 3 21:25:14 udhcpc[7751]: sending discover
Dec 3 21:25:19 udhcpc[7751]: sending discover
Dec 3 21:25:24 udhcpc: Lease fail eth3.
Dec 3 21:25:44 udhcpc[7751]: sending discover
Dec 3 21:25:49 udhcpc[7751]: sending discover
Dec 3 21:25:54 udhcpc[7751]: sending discover
Dec 3 21:26:00 udhcpc[7751]: sending discover
Dec 3 21:26:05 udhcpc[7751]: sending discover
Dec 3 21:26:10 udhcpc: Lease fail eth3.
Dec 3 21:26:30 udhcpc[7751]: sending discover
Dec 3 21:26:35 udhcpc[7751]: sending discover
Dec 3 21:26:40 udhcpc[7751]: sending discover
Dec 3 21:26:45 udhcpc[7751]: sending discover
Dec 3 21:26:50 udhcpc[7751]: sending discover
Dec 3 21:26:55 udhcpc: Lease fail eth3.
Dec 3 21:26:58 ntp: Stopping NTPD
Dec 3 19:26:58 ntp: Starting NTPD
Dec 3 19:26:58 nginx-wive[4338]: doSystem: (service ntp restart) > /dev/console 2>&1 (0)
Dec 3 19:27:15 udhcpc[7751]: sending discover
Dec 3 19:27:20 udhcpc[7751]: sending discover
Dec 3 19:27:25 udhcpc[7751]: sending discover
Dec 3 19:27:30 udhcpc[7751]: sending discover
Dec 3 19:27:35 udhcpc[7751]: sending discover
Dec 3 19:27:40 udhcpc: Lease fail eth3.
Dec 3 19:28:00 udhcpc[7751]: sending discover
Dec 3 19:28:05 udhcpc[7751]: sending discover
Dec 3 19:28:10 udhcpc[7751]: sending discover
Dec 3 19:28:15 udhcpc[7751]: sending discover
Dec 3 19:28:20 udhcpc[7751]: sending discover
Dec 3 19:28:21 nginx-wive[4338]: doSystem: (rm -f /var/udhcpd.dhcpLeases) > /dev/console 2>&1 (0)
Dec 3 19:28:21 dhcpd: Stop dhcpserver
Dec 3 19:28:21 dhcpd: Configure dhcpserver
Dec 3 19:28:21 dhcpd: Start dhcpserver
Dec 3 19:28:21 nginx-wive[4338]: doSystem: (service dhcpd restart) > /dev/console 2>&1 (0)
Dec 3 19:28:21 udhcpd[9777]: started, v1.29.3
Dec 3 19:28:25 udhcpc: Lease fail eth3.
Dec 3 19:28:45 udhcpc[7751]: sending discover
Dec 3 19:28:50 udhcpc[7751]: sending discover
Dec 3 19:28:55 udhcpc[7751]: sending discover
Dec 3 19:29:00 udhcpc[7751]: sending discover
Dec 3 19:29:05 udhcpc[7751]: sending discover
Dec 3 19:29:10 udhcpc: Lease fail eth3.
Dec 3 19:29:30 udhcpc[7751]: sending discover
Dec 3 19:29:36 udhcpc[7751]: sending discover
Dec 3 19:29:41 udhcpc[7751]: sending discover
Dec 3 19:29:46 udhcpc[7751]: sending discover
Dec 3 19:29:51 udhcpc[7751]: sending discover
Dec 3 19:29:56 udhcpc: Lease fail eth3.
Dec 3 19:30:16 udhcpc[7751]: sending discover
Dec 3 19:30:21 udhcpc[7751]: sending discover
Dec 3 19:30:26 udhcpc[7751]: sending discover
Dec 3 19:30:31 udhcpc[7751]: sending discover
Dec 3 19:30:36 udhcpc[7751]: sending discover

Загруженные файлы:
  • dhcp.png
  • win_lan.png

Назначил один статический ip адрес, лог без перезагрузки роутера..

Dec 3 19:34:03 nginx-wive[4338]: doSystem: (rm -f /var/udhcpd.dhcpLeases) > /dev/console 2>&1 (0)
Dec 3 19:34:03 dhcpd: Stop dhcpserver
Dec 3 19:34:03 dhcpd: Configure dhcpserver
Dec 3 19:34:03 dhcpd: Start dhcpserver
Dec 3 19:34:03 nginx-wive[4338]: doSystem: (service dhcpd restart) > /dev/console 2>&1 (0)
Dec 3 19:34:03 udhcpd[10165]: started, v1.29.3
Dec 3 19:34:07 udhcpc[7751]: sending discover
Dec 3 19:34:12 udhcpc[7751]: sending discover
Dec 3 19:34:17 udhcpc[7751]: sending discover
Dec 3 19:34:22 udhcpc[7751]: sending discover
Dec 3 19:34:27 udhcpc: Lease fail eth3.

Кусок лога после полной настройки и перезагрузки роутера на 7.6.27.

Dec 4 08:25:00 nginx: 2018/12/04 08:25:00 [info] 4104#0: *3 client 192.168.1.2 closed keepalive connection
Dec 4 08:25:00 nginx: 2018/12/04 08:25:00 [info] 4104#0: *5 client 192.168.1.2 closed keepalive connection
Dec 4 08:25:00 nginx: 2018/12/04 08:25:00 [info] 4104#0: *1 client 192.168.1.2 closed keepalive connection
Dec 4 08:25:00 nginx: 2018/12/04 08:25:00 [info] 4104#0: *2 client 192.168.1.2 closed keepalive connection
Dec 4 08:25:00 nginx: 2018/12/04 08:25:00 [info] 4104#0: *4 client 192.168.1.2 closed keepalive connection
Dec 4 08:25:00 nginx: 2018/12/04 08:25:00 [info] 4104#0: *6 client 192.168.1.2 closed keepalive connection
Dec 4 08:25:07 kernel: ESW: Link Status Changed - Port1 Link Down
Dec 4 08:25:10 kernel: ESW: Link Status Changed - Port1 Link Up
Dec 4 08:45:03 kernel: ESW: Link Status Changed - Port1 Link Down
Dec 4 08:45:04 kernel: ESW: Link Status Changed - Port1 Link Up
Dec 4 08:45:06 kernel: ESW: Link Status Changed - Port1 Link Down
Dec 4 08:45:10 kernel: ESW: Link Status Changed - Port1 Link Up
Dec 4 08:45:13 udhcpd[3765]: found static lease: 201a8c0
Dec 4 08:45:13 udhcpd[3765]: sending ACK to 192.168.1.2
Dec 4 08:45:27 nginx: 2018/12/04 08:45:27 [info] 4104#0: *7 Authentication successful:
Dec 4 08:46:20 nginx: 2018/12/04 08:46:20 [info] 4104#0: *8 client 192.168.1.2 closed keepalive connection
Dec 4 08:46:20 nginx: 2018/12/04 08:46:20 [info] 4104#0: *11 client 192.168.1.2 closed keepalive connection
Dec 4 08:46:20 nginx: 2018/12/04 08:46:20 [info] 4104#0: *7 client 192.168.1.2 closed keepalive connection
Dec 4 08:46:20 nginx: 2018/12/04 08:46:20 [info] 4104#0: *12 client 192.168.1.2 closed keepalive connection
Dec 4 08:46:20 nginx: 2018/12/04 08:46:20 [info] 4104#0: *9 client 192.168.1.2 closed keepalive connection
Dec 4 08:46:20 nginx: 2018/12/04 08:46:20 [info] 4104#0: *10 client 192.168.1.2 closed keepalive connection
Dec 4 08:55:53 udhcpd[3765]: found static lease: 201a8c0
Dec 4 09:12:08 nginx: 2018/12/04 09:12:08 [info] 4104#0: *13 Authentication successful:

Port1 Link Down - Port1 Link Up компьютер переводил в спящий режим и соответственно выходил из него.

Да по логу нет ничего подозрительного. Статическая лиза она у вас и задана в конфиге на 192.168.1.2. По логу вообще всё хорошо как было так и есть.

Если не удаться на коленке таки повторить и бизибоксеры ничего не найдут, придётся цеплться strace`ом и ждать повтора.

dhcpd всяко умирает сильно раньше чем связь у всех пропадает т.к. liase time задан большой, то как минимум половину времени lease time клиенты продолжат работать и без dhcp после падения.

Прошивка 7.6.27. Роутер настроен, после ночи, утром для проверки включил стационарный ПК и по wi-fi подключил смартфон. Данные для информации.

Dec 5 06:32:19 kernel: ESW: Link Status Changed - Port1 Link Up
Dec 5 06:32:29 kernel: ESW: Link Status Changed - Port1 Link Down
Dec 5 06:32:34 kernel: ESW: Link Status Changed - Port1 Link Up
Dec 5 06:32:53 kernel: ESW: Link Status Changed - Port1 Link Down
Dec 5 06:32:55 kernel: ESW: Link Status Changed - Port1 Link Up
Dec 5 06:32:58 udhcpd[3768]: found static lease: 201a8c0
Dec 5 06:32:58 udhcpd[3768]: sending ACK to 192.168.1.2
Dec 5 06:33:01 udhcpd[3768]: found static lease: 201a8c0
Dec 5 06:43:24 udhcpd[3768]: found static lease: 201a8c0
Dec 5 07:11:30 kernel: Client 0c:xx:xx:xx:xx:xx is bcm BCM4345x based. Disable 80MHz channel (bcm bug).
Dec 5 07:11:30 kernel: ASSOC - Assign AID=1 to 5GHz STA 0c:xx:xx:xx:xx:xx
Dec 5 07:11:30 kernel: ASSOC - HT support STA. Update AP OperaionMode=0 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 5 07:11:30 kernel: ASSOC - VHT support STA
Dec 5 07:11:32 udhcpd[3768]: sending OFFER of 192.168.1.18
Dec 5 07:11:32 udhcpd[3768]: sending ACK to 192.168.1.18
Dec 5 07:24:35 udhcpd[3768]: found static lease: 201a8c0
Dec 5 07:30:10 udhcpd[3768]: found static lease: 201a8c0

Ну т.е. всё ок?

Если перезагрузить роутер, то как и раньше работает. Если dhcp раздаст адреса, а потом уменьшить конечный IP адрес, и розданный ранее будет вне диапазона, то проявляются все признаки некорректной работы, но я до зависания не доводил, перезагружал роутер.

На прошивке 7.6.27 в логе увидел следующее:

5:23:45 udhcpd[3771]: sending OFFER of 192.168.1.8
Dec 4 15:23:45 udhcpd[3771]: sending ACK to 192.168.1.8
Dec 4 15:33:17 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:17 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:17 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-3) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:17 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:17 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:17 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-7) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:17 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:17 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:17 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-11) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:17 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:17 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-15) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-19) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-23) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-27) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-31) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-35) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-39) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-43) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:18 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-47) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:18 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:18 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Dec 4 15:33:19 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-51) from b8:xx:xx:xx:xx:xx, reason=1
Dec 4 15:33:20 kernel: ReASSOC - Assign AID=1 to 2.4GHz STA b8:xx:xx:xx:xx:xx
Dec 4 15:33:20 kernel: ReASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1

Ранее такого не наблюдал.

Ничего не понял. Какие признаки некорректной работы ещё? Вопрос исключительно в падении dhcp был, откуда ещё какие-то признаки взялись? Что за признаки?

Ну клиент у вас какой-то по логу сошёл с ума, соединяется, потом тут же сам шлёт deauth и так по кругу. ХЗ чего чему причудилось.

Некорректной работы dhcp естественно.) При тех же действиях:

Чтобы завис dhcp в роутере алгоритм настройки следующий. Сначала даем dhcp в роутере раздать ip-адреса,  потом сужаем диапазон и можно поставить статику (у меня 1 статический ip), роутер не перезагружаем.

Ещё раз спрашиваю, что за некорректная работа dhcp и как проявляется? Что за признаки?

Более того если клиенты уже получили адреса и вы тупо ограниили диапазон до до истечении половины скора аренды dhcp вообще не будет по сути работать т.к. Клиент ходит к DHCP за адресом, а не наоборот. Т.е. пока клиент не соизволит прогуляться до dhcp снова он ни о каких изменениях и не узнает, а lease time сути (если склероз не замучал стоит).

Поэтому ещё раз, что за признаки блин какие?

 то проявляются все признаки некорректной работы, но я до зависания не доводил

Переводя с вашего на мой это означает, что с момента нажатия apply  в роже после уменьшения диапазона и до падения (которого вы не дождались в этот раз, а может и скорее всего его бы и не было) наблюдаются какие-то ещё "признаки".

Вот и спрашиваю какие, в чём выражаются и вообще был ли мальчик.

Ибо если dhcp адреса выдал то его можно тупо прибить и как минимум половину от lese time клиенты ничего об этом не узнают и будут продолжать работать как ни в чём не бывало до реконнекта или истечения половины срока аренды.

Перевод у вас правильный.)

Чтобы все было достоверно, еще раз настрою роутер по описанному алгоритму и посмотрю, после сообщу.

Постараюсь до конца недели.

Может вы у себя тоже попробуете ?

У меня в том-то и дело что стоит ещё на то версии что зедетектили сразу девайс уже неделю аптайма, всё на месте ничего не падает. Синтетику тоже написал в виртуалке развернул udhcpd со своими правками т.е. изwive и скрипт там его насилует в разных позах по диапазонам и тоже повтора нет.

Возможно нужно ещё какое-то условие, не очень понятно какое.

Описанная проблема с dhcp на прошивке 7.6.27 не наблюдается. Но заметил другое поведение в web-интерфейсе. dhcp выдал стационарному ПК IP - 192.168.1.160, уменьшаю диапазон раздаваемых IP до 192.168.1.25 и в Web-интерфейсе стационарный ПК как клиент не отображается, раньше отображение клиентов Dhcp в такой ситуации оставалось, что позволяло сразу задать статику. Сейчас, клиенты с IP выданным до уменьшения диапазона не отображаются в Web-интерфейсе до переподключения со стороны клиента и выдачи ему нового IP.

Загруженные файлы:

А должно быть как-то иначе?

Смысл в том, что теперь при перезапуске dhcp мы удаляем lease file, т.е. он забывает о старых клиентах которым уже выдал адреса пока они снова не попросят. Если там оставить запись выданную за диапазоном у вас оно падает по истечению лизы.

Значит очистка лиз файла при изменении настроек пока единственный правильный выход (пока не разобрался почему лиза за диапазоном просто не инвалидейтиться).

DHCP не сессионный протокол. Клиент спросил адрес, получил и отвят на половину времени lease/time или события link beat (собсно реконнект). Если в это время запустить чистую копию dhcp без lease файлов то dhcp ессно ничего о клиентах не узнает пока они снова к нему не обратятся.

Не ну можно принудительно моргать портами и отрубать с радио, но это вот явное членовредительство.

Что мешает сразу задать статику, а потом уже сократить диапазон я не очень понимаю. Ну или описать статику руками.

Так что пока оставляем так, основную проблему это решает, разберёмся почему падает если в лизах адреса вне диапазона - вернём старое поведение.

 

А должно быть как-то иначе?

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

Что мешает сразу задать статику, а потом уже сократить диапазон я не очень понимаю. Ну или описать статику руками.

Ничего не мешает, пытался воспроизвести алгоритм при котором раньше были проблемы с dhcp.

 

Ну вот я потому и объясняю как работает и что поменялось что бы вопросов не оставалось и не искали чёрную кошку в тёмной комнате.

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

Если нарою чего по этому моменту подниму тему.

Вот на самом деле логиченее было бы при appy настроек dhcp таки да, выпунть всех клиентов и мигнуть портами. Сразу бы получили бы актуальные данные и клиенты бы перезапросили бы инфу.

Но это достаточно длительное ожидание на самом-то деле в случае с радио. В общем надо почесть затылок как бы таки лучше сделать.

Увы послать что-то клиентам что бы сказать перезапросите-ка адрес через N сек низя. Если им уже выдали адрес с лизой в сутки, то раньше чем через 2 часов их ждать назад dhcp не стоит.

 

В общем надо почесть затылок как бы таки лучше сделать.

ИМХО. Найти в чем проблема и вернуть "стандартный" режим работы dhcp сервиса. Добавить кнопку "Перезапустить, перегрузить и т.п. сервис DHCP", с описанием Зачем оно тут.

Не поленился и посмотрел как это работает на rt-n56u с прошивкой (3.4.3.9-099_base, 29-Jan-2018 08:49 ) от Андрея, так же как и у вас на 7.6.19.RU.17112018, но проблем не было. Статику можно задавать любую, даже если ограничен диапазон IP адресов.

 

То, что это регрессия в busybox факт, но вот насчёт штатности вопрос. udhcpd никогда не умел инвалидэйтить записи.

Более того, у Андрея юзается dnsmasq в роли dhcp, у нас совсем другая схема. В общем спишусь с товарищами бизибоксерами.