Re: OpenWrt auto migration

Dimitar Grigorov <dimitar.grigorov-bPNF1IFG+sGG/[email protected]> Tue, 23 Aug 2016 17:19:25 +0300
Newsgroups gmane.linux.region.bulgaria
Message-ID <[email protected]>
Пропуснах да допълня:

1. Всички рутери broadcast-ват една и съща мрежа.

2. След като кикнем клиента от едната мрежа, то той обикновено се 
кънектва към по-близкото AP.

3. Възможно е подобна методика да наруши връзката при устройства, които 
са в power saving mode.


On 23.8.2016 г. 15:40 ч., Dimitar Grigorov wrote:
>
> Здравейте,
>
>
> програмист съм и не разбирам много от Linux, но съм ровил доста по 
> темата.
>
> Давам първо "временното" решение на проблема, а накрая са поместени 
> методите, които се говори че ги прилагат професионалистите.
>
>
> Приемаме, че клиентите са тъпи и няма да се дискънектнат сами. Затова 
> ще ги дискънектват AP-тата.
>
>
> Написах с краката си скрипт, който през определено време вижда всички 
> клиенти с *iw dev wlan0 station dump* и киква тези, които са с много 
> нисък сигнал.
>
> Моля за съвети по оптимизацията му.
>
>
> -------------------------------------------------------------------------------------------------------------------------------
>
> #!/bin/ash
> #Kicks connected workstations that have signal lower than certain value.
> #Use command on the next row to view how is builded mac-address list 
> and their signal
> #iw dev wlan0 station dump | egrep '(Station|signal:)' | sed -e 
> ':a;N;$!ba;s/\n\tsignal//g' | awk '{ print $5 " " $2}'
> #Pay attention how $MAC variable is used in ubus
>
> MIN_SIGNAL=-81
> MACS_TO_KICK=`iw dev wlan0 station dump | egrep '(Station|signal:)' | 
> sed -e ':a;N;$!ba;s/\n\tsignal//g' | awk -v MIN_SIGNAL=${MIN_SIGNAL} 
> -F ' ' '$5 < MIN_SIGNAL {print $2}'`
>
> #echo $MACS_TO_KICK
>
> for MAC in $MACS_TO_KICK
> do
>     logger -s "MAC:" $MAC "is below threshold at "$MIN_SIGNAL
>     ubus call hostapd.wlan0 del_client '{"addr":"'$MAC'", "reason":1, 
> "deauth":true, "ban_time":3000}'
> done;
>
> -------------------------------------------------------------------------------------------------------------------------------
>
>
> Не съм експериментирал с "ban_time", но би трябвало да може да се 
> постигне още по-добър ефект с тази настройка.
>
> Скрипта е пуснат с cron на 3 рутера TL-WR1043N от около седмица и 
> изглежда дава положителен резултат.
>
>
> -------------------------------------------------------------------------------------------------------------------------------
>
>
> За работещи решения с други продукти знам за:
>
>     - UniFi APs и техния дървен софутер. Там обаче без VLAN-s трудно 
> може да се мине в условията на споделена(private и public) backbone 
> wired мрежа.
>
>     - Mikrotik CAPsMAN - 
> https://blog.linitx.com/howto-improved-capsman-wireless-client-roaming/
>
>     - Cisco имат също добро решение, което е изключително скъпо.
>
>
> В TODO list-a имам за проучване на следните протоколи, за които се 
> говори, че карат AP-тата да си споделят информация за клиентите:
>
>     - 802.11r и 802.11k
>
>     - 802.11s
>
>
>
> On 23.8.2016 г. 08:47 ч., Marian Marinov wrote:
>> Здравейте група,
>>
>> от известно време се чудя(не съм задълбавал в research-а), кой би бил най-адекватният начин за мигриране на WiFi клиенти от едно AP към друго AP.
>>
>> Да приемем, че имаме офис сграда или хотел на 4 етажа. Всеки етаж се покрива от 4 AP-та.
>> Пешо влиза на първият етаж и се закача на wireless-а, след което се качва на вторият, в заседателната зала, но все още вижда с добро качество AP-то от първият етаж. В тази ситуация laptop-а му няма да се закачи автоматично на по-близкото AP.
>> От друга страна AP-тата виждат Пешо с различни нива на сигнала и сами могат да преценят, кое е по-правилното AP.
>>
>> Проблемите са няколко:
>> 1. Колко време трябва едно AP да наблюдава влошаване на сигнала от клиента за да го помоли да се deassociate-не?
>> 2. Как да се накара клиента да се върже към правилното(най-близко) AP?
>>
>> Мариян
>>
>> П.С. Нека се съсредоточим въху въпросите, които поставям а не играчка със силата на сигнала от всяко едно AP. Въпросът е хипотетичен :)
>>
>>
>>
>> _______________________________________________
>> Lug-bg mailing list
>> Lug-bg-R/uZOSXD/[email protected]
>> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>
> -- 
>
> Best regards,/Поздрави,
>
> Dimitar Grigorov/Димитър Григоров
>
> Software Developer/Програмист софтуерни приложения
>
> Megalan Ltd/Мегалан ООД
>
> Fax/Факс: +359 2 968 6005
>
> Mobile / Мобилен: +359 885 494 144
>
> E-mail: dimitar.grigorov-bPNF1IFG+sGG/[email protected] 
> <mailto:dimitar.grigorov-bPNF1IFG+sGG/[email protected]>
>
>
>
> _______________________________________________
> Lug-bg mailing list
> Lug-bg-R/uZOSXD/[email protected]
> http://linux-bulgaria.org/mailman/listinfo/lug-bg

-- 

Best regards,/Поздрави,

Dimitar Grigorov/Димитър Григоров

Software Developer/Програмист софтуерни приложения

Megalan Ltd/Мегалан ООД

Fax/Факс: +359 2 968 6005

Mobile / Мобилен: +359 885 494 144

E-mail: dimitar.grigorov-bPNF1IFG+sGG/[email protected] 
<mailto:dimitar.grigorov-bPNF1IFG+sGG/[email protected]>

_______________________________________________
Lug-bg mailing list
Lug-bg-R/uZOSXD/[email protected]
http://linux-bulgaria.org/mailman/listinfo/lug-bg