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

 

начало

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

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

семинари ...

документи

как да ...

 

 

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

Re: [Lug-bg] OpenWrt auto migration


  • Subject: Re: [Lug-bg] OpenWrt auto migration
  • From: Dimitar Grigorov <dimitar.grigorov@xxxxxxxxxxxxx>
  • Date: Tue, 23 Aug 2016 17:19:25 +0300

Пропуснах да допълня:

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@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



_______________________________________________
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

_______________________________________________
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.