Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

линукс учебник

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: [Lug-bg] OpenWrt auto migration


  • Subject: Re: [Lug-bg] OpenWrt auto migration
  • From: Marian Marinov <mm@xxxxxx>
  • Date: Tue, 23 Aug 2016 17:55:01 +0300
  • Organization: 1H Ltd.

On 08/23/2016 05:19 PM, Dimitar Grigorov wrote:
> Пропуснах да допълня:
> 
> 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;

на мен ми харесва скрипта ти... но аз обмислям малък patch на hostapd(ieee802.11.c):

     char macStr[18];
     int res = os_snprintf(macStr, 18, MACSTR, MAC2STR(sta->addr));
     if (res != -1)
         os_exec("/usr/bin/wifi_assoc.sh", macStr, 0);
>>
>> -------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> Не съм експериментирал с "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@xxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxx <mailto:dimitar.grigorov@xxxxxxxxxxxxx>
>>
>>
>>
>> _______________________________________________
>> Lug-bg mailing list
>> Lug-bg@xxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxx <mailto:dimitar.grigorov@xxxxxxxxxxxxx>
> 
> 
> 
> _______________________________________________
> Lug-bg mailing list
> Lug-bg@xxxxxxxxxxxxxxxxxx
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
> 

-- 
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hackman@xxxxxxxxxx
ICQ: 7556201
Mobile: +359 886 660 270

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg


 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.

Hosted by SiteGround Inc