ARP-флуд hotspot, батареи мобильников, таблица устройств.. На кой это все?!

[KorDen]

Все меньше перестаю понимать смысл дефолтных настроек и нововведений. В основном претензии направлены к авто-сканированию по ARP, выжирающему батарейки мобильных устройств, и все ради чего?

Ради того, чтобы быстро показывать, какое устройство отключилось, а какое подключилось в вебморде? Зачем?! Основная масса пользователей видела вебморду один раз при настройке (если, очень вероятно, не просили кого-то настроить), затем они зачастую даже не знают как на нее зайти! Но даже если пользователь заходит на морду - зачем слать эти запросы бесконечно в остальное время?

Поясните мне этот тайный смысл. Что там такого собираетесь добавить, что это является неотложной необходимостью? Мельком уже по постам читается какое-то подобие IP-MAC Binding и слежение за MAC-адресами.. Но опять, зачем ради этого сканировать сеть, ведь достаточно просто следить за ARP-таблицей, которая сама построится при активности клиента?

 

Касательно фразы "влияние на батарейки мобильников незначительное" - так оно все незначительное, условно: отрубил автосканирование, плюс 2% за ночь, поигрался с rekey-interval - плюс еще 2%, и так далее... И телефон уже живет гораздо дольше.

 

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

Изменено 14 февраля, 2017 пользователем KorDen

[TheBB]

[offtop] что root`у хорошо, то user`у смерть... 

[vasek00]

2 часа назад, r13 сказал:

Так это и не для него. Ему все это arp по боку. Интернет есть, вконтактик работает и слава богу 

Раз не для него, тогда в WEB кнопку отключения для выбора. А раз ему тогда все по боку так и пусть у него и вертится/включает все что хочет.

Один будущий пользователь спрашивает опытного пользователя, что ему купить из роутеров, ну он иму все описал и посоветовал из диапазона 3000-4000р. описав что если то-то то можно то-то и т.д. Слушал его будущий пользователь и спросил, а этот показав на 1500р. будет работать, ну как сказать ответил пользователь ..... хозяин барин. В результате купил он за 1500р. Так может оставить две/три модели с минимальными наборами функций (по ним и вопросов будет меньше) остальные посерьезней и цена по выше.

 

[r13]

4 минуты назад, vasek00 сказал:

Раз не для него, тогда в WEB кнопку отключения для выбора. А раз ему тогда все по боку так и пусть у него и вертится/включает все что хочет.

Один будущий пользователь спрашивает опытного пользователя, что ему купить из роутеров, ну он иму все описал и посоветовал из диапазона 3000-4000р. описав что если то-то то можно то-то и т.д. Слушал его будущий пользователь и спросил, а этот показав на 1500р. будет работать, ну как сказать ответил пользователь ..... хозяин барин. В результате купил он за 1500р. Так может оставить две/три модели с минимальными наборами функций (по ним и вопросов будет меньше) остальные посерьезней и цена по выше.

 

Это уже сильно не наше дело, у зухеля есть отдел маркетинга, который и должен решать подобные задачи. 

[IgaX]

В 16.03.2017 в 17:11, Le ecureuil сказал:

Еще какие-либо идеи есть?

Так-то если комплексно .. нужно в т.ч. снизить трафик в сторону клиентов, в т.ч. служебный/управляющий.

Т.е. даже если оставить сканер на wireless (если в т.ч. можно было бы подстраивать нужный интерфейс), но на минимуме напряга, скажем:

ip hotspot auto-scan interface AccessPoint passive 1 hps (int? т.е. меньше никак видимо)

+ м.б. таймаут записи кэша в зав-ти от скорости скана и размера подсети (но тут конечно от архитектуры) +

ip hotspot auto-scan interface AccessPoint interval 60 unicast (point-to-point ARP - особо погоды не сыграет в этом сценарии, но как вишенка на торте и внимание к деталям, некоторые это оценят)

Дальше даже не знаю, если раскопать .. божоле-нуво подойдет?

Предположим, все возможно, клиенты топовые, идем исключительно на скорости, физические препятствия минимальны/приемлемы итд., т.е. вполне вероятная ситуация для не особо подготовленного пользователя, но есть педальки (при мощности макс. на TxPower=100).

Смотрим на резалт калькулятора при:

BasicRate=2048 (54 Mbps онли, да, уменьшит покрытие, но это всегда индивидуально)
BeaconPeriod=1024 (вроде макс. по манускрипту, т.е. ~1 маяк/сек)

(про крайне вероятную необходимость изменения других связанных параметров не говорю)

Скрытый текст

-> Служебный оверхед минимален (и разница очевидна).

Потом уже можно крутить DtimPeriod.

Больше особо тут не выжмешь в этом аспекте (вроде бы).

[IgaX]

Или м.б. как-нибудь так для минимизации гулянья arp:

1) 1 бридж - 1 сканер;
2) на бридже, например: 192.168.1.1/26 (62 хоста - 1 (роутер)) -> 61 хост для сканирования (Ntot);
3) ip hotspot auto-scan interval 0 - включает "новый" механизм (для обратной совместимости);
4) можно установить ip hotspot auto-scan passive 0.1 hps -> скорость: 1 хост в 10 секунд -> общее время сканирования: 61*10=610 сек. или Ntot/hps -> 61/0.1=610 сек. + по совместительству - это интервал (Ttot) получения broadcast arp по кругу одним и тем же потенциальным сканируемым хостом (если нет записи в кэше роутера) или unicast arp (если запись есть) - т.е. сканер заодно и рефрешер;
5) можно установить ttl записей кэша роутера как: Ttot+buf (где buf - время "пограничного ожидания" ролей на случай отсутствия запроса сканера (например, выключился) в течение которого могут использоваться нативные методы валидирования arp; предположим, buf=60 сек.), ожидается, что ttl записи кэша обновляется автоматически нативными механизмами до заданного значения Ttot+buf при получении соответствующего broadcast/unicast от клиентов;
6) продолжая п.4 и учитывая дублирующую систему из п.5 - если по unicast arp ответа нет, то повторная попытка, например, по параметру ip hotspot auto-scan timeout 15 (если запись еще жива в кэше не смотря на п.5) и если ответа нет, то удаляем запись;
7) если предполагается, что все клиенты с привязкой ip к mac от dhcp, то можно заодно привести все под общий знаменатель со стороны клиентов с помощью 35-й опции dhcp как: Ttot+buf... т.е. минимизируем нативную валидацию arp со стороны клиентов.

В разных симуляциях вроде бы норм.

Изменено 21 марта, 2017 пользователем IgaX

[Le ecureuil]

В 3/21/2017 в 03:42, IgaX сказал:

Или м.б. как-нибудь так для минимизации гулянья arp:

1) 1 бридж - 1 сканер;
2) на бридже, например: 192.168.1.1/26 (62 хоста - 1 (роутер)) -> 61 хост для сканирования (Ntot);
3) ip hotspot auto-scan interval 0 - включает "новый" механизм (для обратной совместимости);
4) можно установить ip hotspot auto-scan passive 0.1 hps -> скорость: 1 хост в 10 секунд -> общее время сканирования: 61*10=610 сек. или Ntot/hps -> 61/0.1=610 сек. + по совместительству - это интервал (Ttot) получения broadcast arp по кругу одним и тем же потенциальным сканируемым хостом (если нет записи в кэше роутера) или unicast arp (если запись есть) - т.е. сканер заодно и рефрешер;
5) можно установить ttl записей кэша роутера как: Ttot+buf (где buf - время "пограничного ожидания" ролей на случай отсутствия запроса сканера (например, выключился) в течение которого могут использоваться нативные методы валидирования arp; предположим, buf=60 сек.), ожидается, что ttl записи кэша обновляется автоматически нативными механизмами до заданного значения Ttot+buf при получении соответствующего broadcast/unicast от клиентов;
6) продолжая п.4 и учитывая дублирующую систему из п.5 - если по unicast arp ответа нет, то повторная попытка, например, по параметру ip hotspot auto-scan timeout 15 (если запись еще жива в кэше не смотря на п.5) и если ответа нет, то удаляем запись;
7) если предполагается, что все клиенты с привязкой ip к mac от dhcp, то можно заодно привести все под общий знаменатель со стороны клиентов с помощью 35-й опции dhcp как: Ttot+buf... т.е. минимизируем нативную валидацию arp со стороны клиентов.

В разных симуляциях вроде бы норм.

1 - так есть и так было всегда

2 - так есть и так было всегда

3 - какой новый механизм?

4 - сильное занижение скорости будет показывать погоду на марсе

5 - так и есть, если хост сам посылает ARP, то он заносится в БД как "только что найденный"

6 - ничего не понял

7 - dhcp сюда приплетать нельзя

[IgaX]

48 минут назад, Le ecureuil сказал:

ничего не понял

Ладно, не трогаем сканер

Если выключить сканер, то я смогу добраться до нативных механизмов linux, например, с помощью:

set net.ipv4.neigh.default.base_reachable_time_ms

- поставленного в начале конфига?

Как я понимаю, для всех созданных после команды интерфейсов ttl arp-кэша пойдет как:

Скрытый текст

base_reachable_time (since Linux 2.2)
Once a neighbor has been found, the entry is considered to be valid for at least a random value between base_reachable_time/2 and 3*base_reachable_time/2. An entry's validity will be extended if it receives positive feedback from higher level protocols. Defaults to 30 seconds. This file is now obsolete in favor of base_reachable_time_ms.

base_reachable_time_ms (since Linux 2.6.12)
As for base_reachable_time, but measures time in milliseconds. Defaults to 30000 milliseconds.

- или есть подводные камни помимо сканера? .. какие-нибудь неучтенные нюансы, которые переписывают правила по ходу пьесы?

И еще вопросик: set .. все могу касательно ядра 3.4 в пределах возможностей или что-то специально выпилено?

Спасибо.

[IgaX]

И есть подозрение, что эта часть:

Цитата

An entry's validity will be extended if it receives positive feedback from higher level protocols

- не работает, по крайней мере, на wireless .. это было бы самым простым объяснением.

[IgaX]

Немного пруфов.

Скрытый текст

When there is no positive feedback for an existing mapping after some time (see the /proc interfaces below), a neighbor cache entry is considered stale. Positive feedback can be gotten from a higher layer; for example from a successful TCP ACK.

https://linux.die.net/man/7/arp

Картинко.

Скрытый текст

После успешного TCP ACK в сторону 192.168.2.39 спустя ~3 сек. идет ptp ARP к этому же клиенту, ответ и помчали дальше.

[IgaX]

А крутилки из серии:

set net.ipv4.neigh.br0.locktime

- работают?

[Le ecureuil]

В 4/13/2017 в 12:59, IgaX сказал:

А крутилки из серии:

set net.ipv4.neigh.br0.locktime

- работают?

По идее должны, если они есть в vanilla 3.4